Re: [PATCH][RFC] Re: high latency with TCP connections

[Rick Jones <rick.jones2@hp.com>]

>>Regardless, kudos for running the test.  The only thing missing is the 
>>-c and -C options to enable the CPU utilization measurements which will 
>>then give the service demand on a CPU time per transaction basis.  Or 
>>was this a UP system that was taken to CPU saturation?
> 
> 
> It is my notebook. :-) Of course, cpu consumption is 100%.
> (Actally, netperf shows 100.10 :-))

Gotta love the accuracy. :)

> 
> I will redo test on a real network. What range of -b should I test?
> 

I suppose that depends on your patience :) In theory, as you increase 
(eg double) the -b setting you should reach a point of diminishing 
returns wrt transaction rate.  If you see that, and see the service 
demand flattening-out I'd say it is probably time to stop.

I'm also not quite sure if "abc" needs to be disabled or not.

I do know that I left-out one very important netperf option.  The 
command line should be:

netperf -t TCP_RR -H foo -- -b N -D

where "-D" is added to set TCP_NODELAY.  Otherwise, the ratio of 
transactions to data segments is fubar.  That issue is also why I wonder 
about the setting of tcp_abc.

[I have this quixotic pipedream about being able to --enable-burst, set 
-D and say that the number of TCP segments exchanged on the network is 
2X the transaction count when request and response size are < MSS.  The 
raison d'etre for this pipe dream is maximizing PPS with TCP_RR tests 
without _having_ to have hundreds if not thousands of simultaneous 
netperfs/connections - say with just as many netperfs/connections as 
there are CPUs or threads/strands in the system. It was while trying to 
make this pipe dream a reality I first noticed that HP-UX 11i, which 
normally has a very nice ACK avoidance heuristic, would send an 
immediate ACK if it received back-to-back sub-MSS segments - thus 
ruining my pipe dream when it came to HP-UX testing.  Hapily, I noticed 
that "linux" didn't seem to be doing the same thing. Hence my tweaking 
when seeing this patch come along...]

>>What i'm thinking about isn't so much about the latency
> 
> 
> I understand.
> 
> Actually, I did those tests ages ago for a pure throughput case,
> when nothing goes in the opposite direction. I did not find a difference
> that time. And nobody even noticed that Linux sends ACKs _each_ small
> segment for unidirectional connections for all those years. :-)

Not everyone looks very closely (alas, sometimes myself included).

If all anyone does is look at throughput, until they CPU saturate they 
wouldn't notice.  Heck, before netperf and TCP_RR tests, and sadly even 
still today, most people just look at how fast a single-connection, 
unidirectional data transfer goes and leave it at that :(

Thankfully, the set of "most people" and "netdev" aren't completely 
overlapping.

rick jones