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