[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090311110345.GA26294@bts.sk>
Date: Wed, 11 Mar 2009 12:03:45 +0100
From: Marian Ďurkovič <md@....sk>
To: Andi Kleen <andi@...stfloor.org>
Cc: netdev@...r.kernel.org
Subject: Re: TCP rx window autotuning harmful at LAN context
On Wed, Mar 11, 2009 at 11:03:35AM +0100, Andi Kleen wrote:
> > You say "was" as if this was a recent change. Linux has been doing
> > receive buffer autotuning for at least 5 years if not longer.
>
> I think his point was the only now does it become a visible problem
> as >= 1GB of memory is wide spread, which leads to 4MB rx buffer sizes.
Yes, exactly! We run into this after number of workstations were upgraded
at once to a new hardware with 2GB of RAM.
> Perhaps this points to the default buffer sizing heuristics to
> be too aggressive for >= 1GB?
>
> Perhaps something like this patch? Marian, does that help?
Sure - as it lowers the maximum from 4MB to 2MB, the net result is that
RTTs at 100 Mbps immediately went down from 267 msec into:
--- x.x.x.x ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8992ms
rtt min/avg/max/mdev = 134.417/134.770/134.911/0.315 ms
Still this is too high for 100 Mpbs network, since the RTTs with 64 KB static
rx buffer look like this (with no performance penalty):
--- x.x.x.x ping statistics --
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 5.163/5.355/5.476/0.102 ms
I.e. the patch significantly helps as expected, however having one static
limit for all NIC speeds as well as for the whole range of RTTs is suboptimal
by principle.
Thanks & kind regards,
M.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists