lkml.org 
[lkml]   [1999]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Weird tcp performance differences with 2.0 and 2.2 kernels
From
Date

>>>>> "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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.058 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site