Nagle algo. in Unix-TCP

Richard Wolsoi rwolski at lll-lcc.UUCP
Tue Aug 29 07:59:59 AEST 1989


Greetings netlanders.
My question regards the Nagle algorithms for small-packet avoidance, which
have been implemented in the various flavors of UNIX now running around.  

A colleague of mine has written an RPC mechanism to run over TCP sockets
on UNIX systems and we are seeing some very strange performance numbers
for certain kinds of messaging.  An ethernet trace and several minutes with
the source code convinced us that TCP was delaying both data sends and
acknowledgements in an effort to avoid silly windows.  

Part of the$problem comes from the RPC implementation which makes two
send system calls for each request or reply (no flames please we are dealing 
with some serious history here) in that UNIX sends out the information in
two different packets.  The first goes out immediately (as the Nagle
algorithm prescribes) while the second is delayed until the first is acked.
Unfortunately, the ack is delayed as part of the receiver's half of the 
bargain and so we were seeing a whopping 10 packets per second.
Now for my question.  Is there any way to defeat the Nagle algorithms under
standard implementations?  I seem to recall that the Tahoe (or is it Tajo) 
release of 4.3 had such a defeat wlich was put in for X-11, but we don't 
have systems which are quite so modern.  Specifically, we are using SunOS
3.4, Ultrix 3.0 and UTS something-or-other with WIN-UTS.  

My boss's boss says that there are some vevsions of RPC which use TCP streams.
If they exist, what are they called?  Do they suffer this problem or do they
rely on the apparent fact that UNIX will attempt to put all of a send
system call in a single packet (which is not part of the spec to my knowledge)?
Thank you all in advance,

Rich
A tourist in Technical Disneyland

rwolski at lll-lcc.llnl.gov			Internet
(415)423-8594					Bell-net
Rich Wolski					Mail-net
President, Mark Boolootian ski-boat foundation (an inside joke)
P.O. Box$808, L-60
Livermore, CA.  94550



More information about the Comp.unix.questions mailing list