North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: MAE-EAST Moving? from Tysons corner to reston VA.

  • From: Richard A. Steenbergen
  • Date: Sat Jun 17 10:58:13 2000

On Sat, 17 Jun 2000, RJ Atkinson wrote:

> Sounds like a filter on which product one buys. :-)

Based on those who don't support a non-standard extension? At any rate,
people will buy them, and problems will ensue. :P

> >That fact aside,
> >several OS drivers for GigE NICs do not currently support jumbo frames.
> Which OSs don't yet support this ?

Not OS, drivers. Pick your favorite OS with GigE support, grep jumbo the
drivers section. In a few cases the unix drivers support jumbo frames and
the reference vendor drivers do not, in a couple its the other way around.
I see its getting better though, there is more support then there used to
be the last time I looked.

> >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.
> For content replication, as differentiated from content distribution,
> the larger MTU should be safe.  A larger than 1518 MTU won't be
> safe for content distribution anytime soon because the Cable Modem
> standards specify a 1518 MTU and cable modems are a leading way
> to provide high performance networking to homes.
> > > 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. 
> Curious.  
> sendfile(2) is using TCP ?  Any TCP extensions present ?
> This was off-the-shelf FreeBSD ?  Which version ?
> Which GigE card (NetGear GA-620 ?) ?

Based off 4.0-STABLE, using some work I'm doing on the FreeBSD TCP/IP
stack (mainly cleaner code and a few trivial optimizations at this point,
nothing earth shattering), some additional optimizations and shortcuts
through the stack based on IP Flow which I'm writing, using back to back
NetGear GA620s, 512k send/recvspace buffers and a 1MB socket buffer, and a
really quick in-kernel ack & discard in the receiving end.

The last time I tried it with standard userland transfers was on back to
back p3 500s which pulled about 450Mbps between a GA620 and an Intel GE.

> >It would
> >certainly help to be doing less packets/rateoftime though, as this is a
> >(the?) major bottleneck.
> Packet processing overhead and memory manipulation are generally
> the bottlenecks in hosts.  There is substantial literature to
> this effect.

Isn't that the truth. I think of a lot of it is poorly optimized and
well-planned code though.

Richard A Steenbergen <[email protected]>
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)