I know that James Hofmeister lurks on this list and I'd really like to hear his comments on this topic.  We've had significant telnet problems at our site and were an escalated site for a while. We do have the problem Wirt describes although our users have learned to live with this irksome problem. They just keep trying until they get a response.

Cynthia Bridges-Fowler
MIS Operations Analyst
IMC Salt, Inc., a division of IMC Global
[log in to unmask]
[log in to unmask]

>>> Wirt Atmar <[log in to unmask]> 08/13/00 05:14PM >>>
A few weeks back, there was some discussion about the difficulty some users
have logging onto a system when using telnet. That difficulty, I've found, is
extremely easy to recreate. It's also quite easy to workaround.

To create the problem, all you need do is produce at least one CPU-intensive
process. The simplest process that I use is this BASIC program that generates
an infinite loop of calculations:

     10 a=2+2
     20 goto 10

I've found that any program that will drive the CPU to 100% will indefinitely
prohibit any new telnet logons so long as the program is running. However,
100%-CPU utilization has absolutely no effect on currently logged on
sessions. When these other current make a request of the processor, they get
their fair share of system resources, exactly as they should, based on their
process priorities.

The problem is that while the CPU is completely busy, the situation for new
logons is the equivalent of you cutting the network connection; the HP3000 is
completely non-responsive to requests to establish new telnet connections
(this effect currently concerns only telnet; NS/VT is unaffected in its
ability to create a new logon). The problem exists in 5.5, 6.0, and 6.5 and
applies equally well to all telnet clients I've tested (QCTerm, Reflection
and the Windows telnet client programs).

The reason, I'm sure, why the problem has been so very little noticed is that
it is very rare on an HP3000 to have a process consume 100% of the CPU for
any significant period of time. When such high-usage episodes do occur, they
tend to be short enough that the user barely notices the delay until a
low-CPU usage period occurs and a logon can be established.

Nonetheless, because of the kinds of things we do, we *do* have these
long-duration high-utilization periods and the ability to not be able to log
on to the HP3000 has a rather surprising and stark effect on our users :-).

Because of this, I have conducted a few experiments with workarounds. The
simple -- and by all of my measures -- completely safe workaround is simply
to raise the JINETD job from the C queue, where it normally resides, to the B
queue. It completely eliminates the problem and seems to induce no new ones.

To do this, all you need do when signed on as system manager is type:

     :ALTPROC JOB=#J5;PRI=BS

(of course, altering the job number appropriately for whatever job number is
currently assigned your copy of JINETD).

Beginning with 6.0, FTP was moved within the JINETD job. While it was clear
that new session logons were not going to make much of a dent in B queue
scheduling nor very much affect any lower level (C, D, E) processes, I wasn't
nearly as sure that FTP wouldn't have any sort of deleterious effects, thus I
conducted a great number of 3000-to-3000 FTP transfers on a 10Mb LAN to see
the extent of the effect. I'm pleased to report that the effect is almost
non-existent. You can just barely measure the increased load in Glance at
10Mbit/sec data flow over that that JINETD produces when no FTP sessions are
active (approx. 1% CPU utilization increase on a 918) and all lower-level
processes continue exactly as they should, with absolutely minimal processing
times elongation.

Nor do other 100%-CPU processes in the B-queue seem to have any effect on a
user's ability to logon. A user logon always seems to be possible and
initiates a new connection instantly, regardless of how busy the B-queue is.
Whatever inability exists for a new user logon to be created when JINETD is
running in the C-queue appears to be completely dissipated when it is moved
to the B-queue, with apparently no negative consequences.

Wirt Atmar