TCP is fine in Linux kernel 2.4.3

[Josip Loncaric]

My TCP patches (see http://www.icase.edu/~josip/LinuxTCP-patches.html)
which improve TCP performance in Linux kernels 2.2.x are not needed in
Linux kernel 2.4.3 (and above?).

In Linux kernels 2.0 and 2.2, the TCP has an unfavorable interaction
between sender side congestion control and receiver side delayed
acknowledgments, where delayed ACKs mimic congestion and force the
sender into repeated data stream stalls lasting 1-2 scheduler intervals
(10 or 20 milliseconds).  This creates a huge problem for two reasons:
(1) at regular intervals, small packets get delayed 1000-2000 times
longer than normal and (2) parallel applications, which use
unidirectional small packets to synchronize operation, can experience
protracted stalls lasting a minute or more because the probability of a
1000 times longer delay is proportional to the number of data paths,
which grows like n^2 where n is the number of processes involved.

For kernels 2.0 and 2.4, my patch produced 10-20 fold improvement
through a probabilistic delayed ACK policy.  By choosing immediate ACKs
with probability 1/8, the receiver could maintain the sender in a mode
where several small outgoing packets were merged into a single larger
one.  This of course increased efficiency of the transfers so that each
queued single byte TCP packet averaged 5.5 microseconds (sometimes as
low as 3.3 microseconds), whereas without packet merging 7.2
microseconds is the theoretical best time using fast ethernet.  By
contrast, the plain 2.2 kernel requires 65.2 microseconds on the average
(with great variability: standard deviation is 64.5 microseconds, and
the worst case is about 10,000 microseconds).

Alas, Linux 2.4 is less efficient in merging packets, and it typically
requires 12.3 microseconds per single byte TCP packet queued.  However,
the probabilistic delayed ACK policy does not help much, reducing this
average time to 11.6 microseconds.  Both plain 2.4 and 2.4+patch deliver
EXCELLENT consistency, with standard deviation of only about 0.1
microseconds.

Given all this, I do not think that patching kernel 2.4 is worth the
effort.  Some packet merging efficiency has been lost, but more
importantly, the results are now very consistent, so the likelyhood of
causing stalls in a parallel application is greatly reduced.

Sincerely,
Josip

-- 
Dr. Josip Loncaric, Research Fellow               mailto:josip at icase.edu
ICASE, Mail Stop 132C           PGP key at http://www.icase.edu./~josip/
NASA Langley Research Center             mailto:j.loncaric at larc.nasa.gov
Hampton, VA 23681-2199, USA    Tel. +1 757 864-2192  Fax +1 757 864-6134