Another alternative is to alter the E queue to be 152,152 and have
JINETD log into the E queue.  Most people don't use the E queue for
anything anyway and this way you get some small amount of control over
quanta, etc.

Bill

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Wirt Atmar
Sent: Wednesday, February 15, 2006 6:16 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] weird telnet behavior?

Tracy writes:

> I have two e3k's one a 957 at 10.10.1.3, the other a 937 at 10.10.1.4.
>   
>  telnet readily connects to 1.4 but is extremely sluggish vs 1.3.

If by sluggish, you mean sluggish to sign on, but once on, everything
tends 
to work properly, then your problem lies in the queue that JINETD is
running 
in. A very CPU-busy machine will push JINETD's priority so low,
especially if a 
higher-priority CPU process's utilization is 100% for long periods of
time, 
that signon becomes impossible.

As I've mentioned several times before here on the list, the trick that
we 
adopt here is that we run JINETD in the B queue, but this solution has
not been 
much appreciated by James Hoffmeister. Unfortunately, the only thing to 
recommend doing this is that it works. That, and the fact that we've
seen no 
downside to doing this.

I do believe however that James has come up with some sort of patch to
modify 
telnet's queue signon queue position, but I don't have the details.

Moving JINETD only affects the signon process. Once signed on, a telnet 
session is basically unaffected by the CPU's busy-ness.

Wirt Atmar

   

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *