[lkml]   [1998]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Poor TCP throughput in 2.1.103
From <> writes:
>> The problem is suspected to lie with my ISP's Ascend servers, using larger
>> ( > 12k ) windows causing them to stall the TCP pipeline. So many other
>> people could have the same problem as Ascends are very popular.
>Slow start should detect that. If it doesn't something is fishy in 2.1
>TCP. Do you have the same problem with 2.0 too?

As far as I can recall slow start is not the problem here, and the
problem will be present with 2.0.x kernels as well. The problem is not
quite so simple as slow start detecting the correct maximum window when
a drop occurs. I seem to recall seeing actual extra delays being introduced
in some traces that could not be attributed to simple packet loss.

Also, slow start behaves rather badly (correctly implemented mind you)
when the bandwidth*delay product of your real path is significantly
smaller than your window size setting. Van Jacobson noted this in his
original paper on slow start and stated that this should be considered
punishment for failing to correctly choose window size settings.
Alternatively this can also be viewed as TCP performs badly when the
available queueing on a path for a particular flow greatly
exceeds badwidth*delay. The problem is that a packet loss detection will
be delayed a long time due to the long queue length, and this starts
to have bad effects on the timing of the whole enterprise.

Summary: until someone deploys a TCP that actually tries to detect
bandwidth*delay for its path, window size settings are going to be
necessary to achieve best performance.


Eric Schenk www:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.051 / U:1.848 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site