Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: <None>
From: bodoh@dgg.cr.usgs.gov
Date: Fri, 22 Jan 1993 10:19:50 -0600
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>
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.


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;

	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.

	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.

	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.



	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.



						Tom Bodoh, Sr. Systems SW Engr.
						USGS/EROS Data Center
						bodoh@dgg.cr.usgs.gov
						605-594-6830