Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: IPACP hogging CPU
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Tue, 26 Jan 1993 04:11:57 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

|> Since I posted my message 'IPACP goes wild' a week ago, nobody has come back
|> with any ideas as to what the problem might be, or how to start diagnosing
|> it - BUT I have had mailings from two other people who are encountering
|> the same thing.
|>
|> So if you have ANY light to shed on why IPACP should suddenly start hogging
|> 99.999% of the CPU for large periods of time, or ANY ideas about how to start
|> diagnosing the problem, there are at least three of us who would be very glad
|> to hear from you.
|

bodoh@dgg.cr.usgs.gov (Tom Bodoh) replies:

|
|Alas, I did respond, but the response must have gotten munged somewhere!
|
|	This problem has been around forever and is USUALLY caused by someone
|telnetting into your system and then outputting large volumes of data on their
|screen.  To test this, telnet in and 'type sys$share:starlet.req'.  You will
|immediately see your system lock up as the ip_acp - running at priority 6 -
|continuously processes interrupts.  Three suggestions;
|
	This problem HAS NOT been around forever.  It is a fairly recent
development, within the last year or so.  The TELNET pause bug, which is the
other side of the coin, has been around 2-3 years or so.

|	o  Modify [cmutek.sysmgr]ip_startup.com so that it starts IP_ACP at
|	   a priority of 4.  This may occasionally slow user screen I/O but it
|	   is a heck of a lot less noticable than total system lockup.
|
	This will work, but is not necessary, as the problem has been
fixed.

|	o  Modify user behaviour by notifying your users that volumes of
|	   output to the terminal should be avoided - even with IP_ACP at
|	   priority 4.  Then monitor the system and watch for IP_ACP
|	   impersonating the Null process - sucking up all of the available
|	   cycles.  Track the offending user by looking at monitor, usually
|	   will be the second highest CPU user and the highest DIO or BIO user.
|
	This is not a real solution, since the TELNET service should appear
to the user as if the remote system is a local connection.  Asking the users
to modify their behavior based upon the system they are logged into, and
the way the log into the system is unrealistic.

|	o  Buy a real TCP/IP package.  I don't want to advertise here, but
|	   the pre-eminent seller of TCP/IP packages for VMS is offering a
|	   70% discount to licensed CMUTEK sites through Feb 28.  This will
|	   resolve many problems and boost performance (measured by file
|	   transfer rates) by 2000% (20+ times the xfer rate).  I cannot
|	   praise this product enough.  If you still don't know who I'm
|	   talking about, email me.  We now move 85mb+ satellite images from
|	   our VAX 3800 acquisition system to our Silicon Graphics - about
|	   3.5gb per day.  We are seeing average xfer rates of 380kb/sec and
|	   peaks of about 431kb/sec.  CMUTEK managed a best of 20kb/sec.
|
	How do you define a "real" package?  Is Andy Harper's VMS_SHARE a
"unreal" package because you don't pay for it, sign a license agreement
or get the software via magnetic media?  Hell, if that's the case then
90% of the UNIX software in the universe is "unreal", and Tom, we are in
real trouble because you know how picky the Government gets about running
unsupported software.  But, do you run the vendor standard named on your
UNIX boxes that doesn't work worth a damn, or do you go out and FTP bind 4.8.3
from gatekeeper or uunet?

	Just because you don't pay big bucks and get the software from
a "major vendor" don't mean it's no good.

	Also, the speed problem has been fixed, partly inside of IPACP,
and partly inside of the various utilities.  The main problem was that
most applications used VERY small QIO buffers, some as small as 64 bytes!
Some applications would read a line of data from a file, then do the QIO
with PUSH set, thus flooding the network with very small packets.  By doing
a little bit of intelligent buffering inside of the application, it is possible
to get much better throughput.  The performance improvement is almost linear
until you get up to about an 8K buffer, where you start hitting the point
of diminishing returns.  You also have to increase MAXBUF.

|
|
|	Before I get flamed, I really do appreciate the effort that has been
|put into CMUTEK over the years.  The problem is that many sites, such as ours,
|rely too heavily on TCP/IP and it is no longer the 'experiment' that it was
|when we first got CMUTEK.  The final clincher for us was that we were fighting
|a losing battle with bugs even with CMU support, but now we really can't
|afford to trust our data to a package supported by the general public.  I
|would still endorse it's use for experimentation, but nothing more critical.
|
|
	I ran the same version of 6.6-5A for over three months without a crash
as I am currently offering via ANONYMOUS FTP.  The software was heavily used,
transferring many megabytes of data per day.  The only reason why it finally
crashed was that the DNS running under it was flooded with bogus requests
from another physical subnet in our building, and the brain damaged version
of bind that there were running would not accept the fact that the host name
they were asking us to resolve was non-existant.

	The fact that the product was not supported adequately in the past
does not mean that it will not be supported in the near future.

	Now, am I saying don't take advantage of the 70% discount?  NO!  It's
a hell of a deal, and if your site can afford it, then go for it!  But some
sites cannot justify the cost, even with 70% off, for older or smaller
systems.  In that case, their options are kind of limited to UCX or CMU.
Not to badrap DEC, but UCX, well, you know.

	The CMU package is and will continue to be a viable low-end TCP/IP
package for VMS.  And we ain't done yet...

-HWM
----------
Henry W. Miller
Assistant Systems and Network Manager
U.S. Bureau of Reclamation
Mid Pacific Region
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS - Same as commercial
Inet:	"henrym@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"