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