Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: <None>
From: bodoh@dgg.cr.usgs.gov
Date: Wed, 27 Jan 1993 16:04:31 -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

>>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.

	The problem I described HAS been around since version 6.3!  I think
that the problem here is that we have been talking about two different problems
that have the same symptom - IP/ACP eating all of the CPU.  The problem I
am talking out is a design problem.  The problem you are talking about is a
bug which has been fixed.  The problem I am talking about has not been fixed.

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

	I did not mean to imply that free software is unworthy, just that in
this particular instance the software in question has not lived up to our
needs regarding speed or reliability.

>	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.

	Hmmmm... we have a file transfer program which we developed to look
like rcp (but it works across many platforms) and it uses 8k buffers - but
it still only gets around 20 kb/sec with 6.6-5a.  Even if we could speed it up
to 100 kb/sec we still would expect more since our UNIX boxes are getting rates
of 300 kb/sec to 900 kb/sec on Ethernet and up to 1.5 mb/sec on FDDI.  A 20
kb/sec transfer rate is no longer viable.

	Again, I am appreciative of the effort that has been put into CMU/TEK
over the years, but it is time for us to move on.  I may stay on this list so
that I can monitor it's progress.  I hope that it can be made fast enough to
satisfy the needs of those that can't afford a commercial solution, or those
that have Bliss and enjoy tinkering.  Hey... what ever happened to the port to
C which Bruce had been preparing for V7?  If that ever came to be, that would
tend to enhance the development effort.


						bodoh@dgg.cr.usgs.gov