Re: [tcpm] TCP tuning

[rick jones <[e-mail]>]

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.  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.

> 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.

rick jones

>
> Joe
>
> rick jones wrote:
>>
>> On Feb 3, 2010, at 9:41 PM, rick jones wrote:
>>> PS - I suppose if I'd been thinking more clearly, I'd have also
>>> included --enable-historgram in the ./configure command and been  
>>> able
>>> to give a histogram of the response times (adding a -v 2 option to  
>>> the
>>> global command line options), but I suppose that can be guesstimated
>>> from the traces.
>>
>> Ok, so perhaps I like running netperf too much :)  Here then are the
>> application-level measured response times.  The first netperf is with
>> tcp_slow_start_after_idle = 0, the second with it set to 1, I'll
>> leave-out the rest of the netperf output as it is repetitive:
>>
>> tcp_slow_start_after_idle = 0 on server:
>>
>> Histogram of request/response times
>> UNIT_USEC     :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> TEN_USEC      :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> HUNDRED_USEC  :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> UNIT_MSEC     :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> TEN_MSEC      :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> HUNDRED_MSEC  :    0:  294:    4:    0:    2:    0:    0:    0:     
>> 0:    0
>> UNIT_SEC      :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> TEN_SEC       :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>>> 100_SECS: 0
>> HIST_TOTAL:      300
>>
>> That means 294 times 100ms <= responsetime < 200ms, 4 times it was  
>> 200ms
>> <= responsetime < 300ms etc etc.
>>
>> tcp_slow_start_after_idle = 1 on server:
>>
>> UNIT_USEC     :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> TEN_USEC      :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> HUNDRED_USEC  :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> UNIT_MSEC     :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> TEN_MSEC      :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> HUNDRED_MSEC  :    0:    0:    0:  290:   10:    0:    0:    0:     
>> 0:    0
>> UNIT_SEC      :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>> TEN_SEC       :    0:    0:    0:    0:    0:    0:    0:    0:     
>> 0:    0
>>> 100_SECS: 0
>> HIST_TOTAL:      300
>>
>> Now it was 290 with 300ms <= responsetime < 400ms
>>
>> Just as a refresher, the request size was 128 bytes, the response  
>> size
>> 16384.
>>
>> The ICMP Echo RTT is ~120 ms between my home system and netperf.org:
>>
>> --- netperf.org ping statistics ---
>> 10 packets transmitted, 10 packets received, 0% packet loss
>> round-trip min/avg/max/stddev = 119.523/120.410/121.248/0.493 ms
>>
>> rick jones
>> Wisdom teeth are impacted, people are affected by the effects of  
>> events
>

Wisdom teeth are impacted, people are affected by the effects of events