Jumbo frames?

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <vnr7omtlhq.fsf@kenny.ex.ac.uk>,
John Rowe <rowe@excc.ex.ac.uk> wrote:
:I'm trying to get to the bottom of using jumbo frames on
:gigabit. Specifically:

:1. Does it really make a difference to performance?

It can, but it depends a lot on how the applications use data transfers.
For example, if 90% of your traffic is telnet and web surfing to
outside your LAN, then that last 10% might not be worth the trouble
and expense.

There are papers available that discuss the performance of TCP as
packet size changes. You can make calculations yourself based upon
the size of your data bursts and upon the sizes of all the TCP
overheads -- but when you do the calculations, be sure to take
into account how systems in *your* network contend for the bottleneck
link, together with the packet buffer sizes on the switches / routers,
and be sure you use the actual TCP windowing and selective-ack model
that you will be using in real life. (e.g., if you have not already
enabled selective acks and the larger window sizes, then you might
find that turning those on would have a greater benefit than going to
a larger frame would have.)

The calculations of theoretical maximum throughput usually are
dominated by the latency instead of the bandwidth. Jumbo frames allow
you to have about six times as much payload in transit as regular
frame sizes, which makes a *big* difference if you have a high latency.
If, though, your latency is low enough that the ACK to the first packet
would not still be in transit back by the time the sender has reached
the end of the TCP window, then frame overheads become the more important
factor: the less overhead you have [including intrapacket gaps] to send
a given payload size, the better your efficiency.

But... if you are using an OS that does not have an efficient IP driver,
or you are using dumb NICs that require the main CPU handle all the
fragmentation and checksums and so on, or if you have an inefficient
internal architecture, then you will not be able to reach the theoretical
maximum. For example, a standard old PCI bus cannot (in practice)
handle a full gigabit feed, but the wider and faster PCI busses can.
And your disk drive together with your device drivers might not be able
to load data from disk at full gigabit speeds.

To use the full capacity of gigabit links, you have to pay attention
to the entire system architecture, as -most- architectures have not
caught up yet. For an examination of this topic, please look on
tomsnetworking.com, which in roughly the April timeframe had an
investigation of how various NICs and motherboards combined for gigabit
networking.




:2. How to handle older 100BaseT machines? Is there anything better
: than having a designated jumbo gigabit VLAN?

As noted above, quite possibly yes. If you haven't turned on selective
acks and larger windows, then do so: the performance increase can be
substantial.


:3. Do the HP Procurve 28xx/26xx switches support jumbo frames?

Sorry, I don't know. To find out, I would have to google HP's technical
documents, which I don't really have time for. I suggest you check out
the technical documents yourself.
--
Caution: A subset of the statements in this message may be
tautologically true.

Archived from groups: comp.dcom.lans.ethernet (More info?)

John Rowe wrote:

> I'm trying to get to the bottom of using jumbo frames on
> gigabit. Specifically:

> 1. Does it really make a difference to performance?

> 2. How to handle older 100BaseT machines? Is there anything better
> than having a designated jumbo gigabit VLAN?


As far as I know there is no connection between jumbo frames
and gigabit. It can be done it 10 megabit or 100 megabit, too.

If you do frame bursting doesn't that come close, and yet
remain standard, though with a little more overhead for the
processor.

-- glen

Archived from groups: comp.dcom.lans.ethernet (More info?)

Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
> The calculations of theoretical maximum throughput usually are
> dominated by the latency instead of the bandwidth. Jumbo frames
> allow you to have about six times as much payload in transit as
> regular frame sizes, which makes a *big* difference if you have a
> high latency.

Given that JumboFrames in and of themselves do not increase the TCP
window it might be better to put that as "about six times as much
payload in transit with the same CPU overhead..."

JumboFrame is (IMO) all about minimizing CPU overhead, although it can
also help with masking stuff like DMA latency (as contrasted with
stuff like WAN latencies)


If one happens to have switches that do not support JumboFrame, there
is a "poor man's" version called "large send" or TSO depending on the
context. Some NICs (and OSes) can take larger-than-MTU TCP segments
and further segment them based on the link MTU. For the sender, the
benefit is just about the same as JumboFrame as JumboFrame end-to-end
also minimizes ACKs per byte. However, the receiver still sees a
"standard" stream of normally sized segments (which is why it works
with switches that don't do JumboFrame and also with clients that
don't also exchange the large MSS of JumboFrame).

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...