Home page logo

nanog logo nanog mailing list archives

Re: MAE-EAST Moving? from Tysons corner to reston VA.
From: "Richard A. Steenbergen" <ras () e-gerbil net>
Date: Sat, 17 Jun 2000 10:24:03 -0400 (EDT)

On Sat, 17 Jun 2000, RJ Atkinson wrote:

At 22:46 16/06/00 , Richard A. Steenbergen wrote:
 The common number that all
those using jumbo frames should support is 9000 bytes (not 9k aka 9216).

Disagree, for the reasons described in RFC-1626.  The IP MTU 
described in RFC-1626 has a number of advantages for hosts
using TCP, whether or not NFS is in use.

That came out wrong, my point was that the number on all jumbo frame
implementations should be no lower then 9000 bytes, not that this is the
best possible number. Optimizing for NFS seems to be one of the lowest
considerations on the list of important things though. :P

This would probably need to be a condition of using GigE at the NAP,
in order to achieve any kind of common support, and you're eliminating
some vendor gige support (assuming their network can even carry the 9k
packets TO the nap without requiring even more work and possible

Virtually all GigE vendors already do support the ~9K size 
I've been talking about.

Some don't, we've already found a couple on this list. That fact aside,
several OS drivers for GigE NICs do not currently support jumbo frames.

POS has a configurable MTU.  One could easily reconfigure one's POS
interfaces to have a ~9K MTU.

The point is that unless everyone makes these changes, any attempt to run
a higher MTU along a non-supporting path without a reliable PMTU-D
mechanism will result in bloody horror.

The real number ought to be >= 9180 IP bytes + Ethernet overhead,
so that hosts can do page-flipping and other optimisations.
Without Jumbo-grams, neither NT nor any common UNIX can run full
line-rate over TCP/IP with GigE today.  With Jumbo-Grams, both
NT and UNIX can achieve 1 Gbps of throughput over TCP/IP/GigE.

I've been able to get DAMN NEAR line rate with sendfile(2) zero-copy
transfer, and some optimizations for the entire packet output path, using
FreeBSD and some AMD K7 800s, without using jumbo frames. It would
certainly help to be doing less packets/rateoftime though, as this is a
(the?) major bottleneck.

Richard A Steenbergen <ras () e-gerbil net>   http://www.e-gerbil.net/humble
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]