Messages in this thread | | | Subject | Re: Weird tcp performance differences with 2.0 and 2.2 kernels | From | lantz moore <> | Date | 12 Feb 1999 09:40:24 -800 |
| |
>>>>> "Andi" == Andi Kleen <ak@muc.de> writes:
Andi> In article <199902112125.NAA06814@dancer.ca.sandia.gov>, Andi> pw@dancer.ca.sandia.gov (Pete Wyckoff) writes:
>>> remote client linux 2.2.1, 400mhz Pentium II, 3c905B Cyclone 100baseTx >>> 10 bytes 46.51 c/s 723 bytes 47.68 c/s 724 bytes 279.62 c/s 1024 bytes >>> 300.92 c/s
>> Delayed acks are a good thing (see the RFCs), but linux tries to be >> clever during slow start to help ramp transfer rates up faster by using >> "quick ack mode". See tcp_delack_estimator(). But the function >> tcp_remember_ack() seems to be messing things up for small packets. It >> tries to speed up pending acknowledgements when it sees PSH and small >> packets, but in so doing, erases the "quick ack mode" bit.
Andi> The reasoning is simple: Quick ack mode is used to speed up bulk Andi> transfers, and in bulk transfer you don't use small packets. In Andi> other situations we want the full packet saving benefit of delayed Andi> acks. So artifically using small packets is a bad idea.
Andi> "It hurts when I do this." "Then don't do this"
unfortunately though, sometimes we don't have much of a choice.
the problem that Mark Boyns and i originally observed <7femnzca6b.fsf@contigo.com> was seen when talking to a webserver. if the size of the headers plus the data being returned on a web-request was less than 724 bytes (roughly mtu>>1), then we got a *maximum* of 50 connections per second due to the 20 millisecond delay. the problem was even more pronounced when making the requests over the loopback interface. over the loopback the payoff point was at 1936 total bytes.
granted, this problem can be alleviated by using keep-alive, but again, that's not always possible.
so now, i guess the question is: do we care about these short lived small data transfer connections? or is this just a pathological case.
while i do not like the idea of always entering quickack mode on a small packet push, i thought that Pete Wyckoff's patch, simply retaining the quickack bit, looked pretty promising.
-- lantz moore, contigo software lmoore@contigo.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |