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

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

Alexey Kuznetsov wrote:
> Hello!
> 
> Of course, number of ACK increases. It is the goal. :-)
> 
>>unpleasant increase in service demands on something like a "burst 
>>enabled" (./configure --enable-burst) netperf TCP_RR test:
>>
>>netperf -t TCP_RR -H foo -- -b N   # N > 1
> 
> foo=localhost

There isn't any sort of clever short-circuiting in loopback is there?  I 
do like the convenience of testing things over loopback, but always fret 
about not including drivers and actual hardware interrupts etc.

> b	patched		orig
> 2	105874.83	105143.71
> 3	114208.53	114023.07
> 4	120493.99	120851.27
> 5	128087.48	128573.33
> 10	151328.48	151056.00
 >
> Probably, the test is done wrong. But I see no difference.

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?

>>to increase as a result.   Pipelined HTTP would be like that, some NFS 
>>over TCP stuff too, maybe X traffic,
> 
> 
> X will be excited about better latency.
> 
> What's about protocols not interested in latency, they will be a little
> happier, if transactions are processed asynchronously.

What i'm thinking about isn't so much about the latency as it is the 
aggregate throughput a system can do with lots of these 
protocols/connections going at the same time.  Hence the concern about 
increases in service demand.

> But actually, it is not about increasing/decreasing number of ACKs.
> It is about killing that pain in ass which we used to have because
> we pretended to be too smart.

:)

rick jones