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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
