Re: [tcpm] TCP tuning

[Joe Touch <[e-mail]>]

rick jones wrote:
> 
> On Feb 3, 2010, at 10:25 PM, Joe Touch wrote:
>> Did you use a netperf option to disable Nagle?
> 
> No, there should be no need for that.  For a TCP_RR test netperf
> presents all the data of a request or response to the transport in a
> single send call,  there should be no delays Nagle at all.

I don't know why this still isn't widely known, but there is *no*
correlation between the OS interface and TCP segment emissions per se.
Send calls don't correspond to buffer flushes or anything else. All they
do is load the buffer.

Nagle still needs to be disabled.

> Further, in
> this case, there was only ever the one transaction in flight at a time,
> so at the time of each send() the connection was "idle" in the Nagle sense.

Again, "at the time of each send()" is irrelelvant. What's relevant is
what's in the buffers.

>> There are also many reasons this could happen; it might be easier to see
>> in a plot.
> 
> Anyone should feel free to grab either the binary (.pcap) or "cooked"
> (ascii) traces off of netperf.org and run them through whatever post
> processing tools they like.  I would have shoved them into the original
> email, but didn't want to stuff peoples' inboxes unnecessarily.  Still,
> if you think that copying some examples from the ascii into email would
> help I'm willing to do that.
> 
> I'm not the acme of tcpdump trace reading, but it seemed pretty
> conclusive in the traces - with slowstart after idle, the 2.6.31 server
> sent the data of each 16K response with what certainly appears to be
> slow-start behaviour, with that sysctl set to disable slowstart after
> idle, no such slow start behaviour in the middle of the trace.  So, for
> Linux 2.6.31, as distributed by Ubuntu, it would seem that the arrival
> of the next request is not going to preclude slowstart after idle
> behaviour.

Some versions of Linux may have various tricks implemented. None of them
havae been standardized, though. It's worth checking with a few
different OS's.

Joe