[95475] in North American Network Operators' Group
RE: Jumbo frames
daemon@ATHENA.MIT.EDU (Jim Shankland)
Tue Mar 27 19:35:33 2007
From: Jim Shankland <nanog@shankland.org>
To: <nanog@merit.edu>
Cc: <michael.dillon@bt.com>
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B01AAC5C@E03MVC4-UKBR.domain1.systemhost.net>
Date: Tue, 27 Mar 2007 16:28:27 -0700
Errors-To: owner-nanog@merit.edu
<michael.dillon@bt.com> writes:
> [...]
> if there are several factors that will contribute to solving the
> problem, I think that you get better results if you attack all of them
> in parallel.
Well, I guess; except that "only buy IP network access from a service
provider who supports jumbo MTUs end-to-end through their network"
may be a much bigger task than tuning your TCP stack.
Jumbo frames seem to help a lot when trying to max out a 10 GbE link,
which is what the Internet land speed record guys have been doing.
At 45 Mb/s, I'd be very surprised if it bought you more than 2-4%
in additional throughput. It's worth a shot, I suppose, if the
network infrastructure supports it.
On a coast-to-coast DS-3, a TCP stack that's correctly tuned for a
high bandwidth-delay product environment, on the other hand, is
likely to outperform an untuned stack by a factor of 10 or so
in bulk transport over a single TCP session. (Though, as somebody
pointed out, tuning may have to occur all the way up the application
stack; there are, e.g., ssh patches out there for high-BDP environments.)
So I guess, sure, try anything you can; but I know what I'd try
first :-).
Jim Shankland
