lkml.org 
[lkml]   [1998]   [Mar]   [21]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 21 Mar 1998 00:06:10 -0800
From"David S. Miller" <>
SubjectRe: TCP fix for sluggish rlogin/rsh
   Date: Fri, 20 Mar 1998 16:25:40 +0100 (CET)
   From: Andrea Arcangeli <arcangeli@mbox.queen.it>

   On Wed, 18 Mar 1998, David S. Miller wrote:

   >This is the right fix.  It should apply cleanly to 2.1.90, but
   >even if it doesn't you can get the idea.  We ACK quickly, if we
   >see PSH _and_ we saw less than 1/2 the MSS worth of data in
   >incoming packet.

   Seems to work well against 2.1.90 even if 2.0.33 seems again a
   __bit__ faster. I don' t know what "tp->ato = HZ/50" means but
   maybe setting it to a lower value.... but I havn' t tried yet since
   I don't know if it make sense.
tp->ato is the period for which we delay a delayed ACK.  I cannot set
it lower for two reasons:

1) The next nice multiple value lower is HZ/100, this has a special
   meaning, as it forces out an immediate ACK.

2) Delaying too quickly prevents NAGLE from being realized, enough
   time must pass so that the application can have a chance to read
   the data, and send the echo characters back, on which the ACK
   can be "piggybacked".  This saves bandwidth on the network.

I'm sure there are a few quirks with my current scheme.  If people
believe the current heuristic acts suboptimally in certain cases, or
when talking to some other TCP implementations, _please_ send me
packet traces of the behavior in progress.  I can only analyze and fix
the behavior when I have this information.

Later,
David S. Miller
davem@dm.cobaltmicro.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008