It's been a long time since I first heard about jumbo ethernet frames
(more than 10 years I think).
It is now 2005.
Where are they? When can we expect support to be widely available?
Does the gigabit NIC one finds in a typical PC support them?
There are some no-ack protocols that could benefit greatly from not
having to worry about the 1500-byte MTU of regular ethernet frames.
-Le Chaud Lapin-
DComTalk.com
Discussion of VoIP, VPN, Video Conferencen, DSL and other data commucations.
Jumbo Ethernet Frames
7 posts
• Page 1 of 1
Re: Jumbo Ethernet Frames
by Rick Jones » Tue Nov 08, 2005 11:01 pm
unoriginal_username@yahoo.com wrote:
More or less where they were before?
It is about as wide as it gets now.
I believe so. I believe that all the Intel and Broadcom NICs support
them.
Switches can be a bit interesting though - I seem to have heard that
some will say they support "jumbo frames" when their support is for
something << 9000 bytes.
There is still the issue of making sure that everything from one end
to the other supports JF. In the TCP/IP space, I would posit that JF
is being supplanted by Large Send/TSO - it allows the TCP stack to
send large segments down the stack that the NIC resegments into
packets which fit the network. Now there is no need for JF support
end-to-end - although at the cost of not getting all the performance
benefits of JF.
And then one can start talking about TOE...
rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
It's been a long time since I first heard about jumbo ethernet frames
(more than 10 years I think).
It is now 2005.
Where are they?
More or less where they were before?
When can we expect support to be widely available?
It is about as wide as it gets now.
Does the gigabit NIC one finds in a typical PC support them?
I believe so. I believe that all the Intel and Broadcom NICs support
them.
Switches can be a bit interesting though - I seem to have heard that
some will say they support "jumbo frames" when their support is for
something << 9000 bytes.
There are some no-ack protocols that could benefit greatly from not
having to worry about the 1500-byte MTU of regular ethernet frames.
There is still the issue of making sure that everything from one end
to the other supports JF. In the TCP/IP space, I would posit that JF
is being supplanted by Large Send/TSO - it allows the TCP stack to
send large segments down the stack that the NIC resegments into
packets which fit the network. Now there is no need for JF support
end-to-end - although at the cost of not getting all the performance
benefits of JF.
And then one can start talking about TOE...
rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
- Rick Jones
Re: Jumbo Ethernet Frames
by glen herrmannsfeldt » Wed Nov 09, 2005 4:20 am
unoriginal_username@yahoo.com wrote:
I have known 10baseT cards to support them, as they were designed
with 16 bit registers. Don't count on them going through any
equipment you don't supply, though.
The Internet likely won't be changing anytime soon. If you want to
do it in the privacy of your own net, no-one will stop you. As far
as I understand it there is work to speed up 1500 octet traffic
such that the differences will be small.
-- glen
It's been a long time since I first heard about jumbo ethernet frames
(more than 10 years I think).
It is now 2005.
Where are they? When can we expect support to be widely available?
Does the gigabit NIC one finds in a typical PC support them?
I have known 10baseT cards to support them, as they were designed
with 16 bit registers. Don't count on them going through any
equipment you don't supply, though.
There are some no-ack protocols that could benefit greatly from not
having to worry about the 1500-byte MTU of regular ethernet frames.
The Internet likely won't be changing anytime soon. If you want to
do it in the privacy of your own net, no-one will stop you. As far
as I understand it there is work to speed up 1500 octet traffic
such that the differences will be small.
-- glen
- glen herrmannsfeldt
Re: Jumbo Ethernet Frames
by Patrick Schaaf » Wed Nov 09, 2005 4:20 am
unoriginal_username@yahoo.com writes:
They were not standarised.
Never.
Yes.
best regards
Patrick
It's been a long time since I first heard about jumbo ethernet frames
(more than 10 years I think).
It is now 2005.
Where are they?
They were not standarised.
When can we expect support to be widely available?
Never.
Does the gigabit NIC one finds in a typical PC support them?
Yes.
best regards
Patrick
- Patrick Schaaf
Re: Jumbo Ethernet Frames
by James Knott » Wed Nov 09, 2005 12:20 pm
glen herrmannsfeldt wrote:
The internet shouldn't be a factor, as it'd designed to work with a variety
of technologies, including those that support much bigger frames. For
example, years ago I used to run on a token ring network, using 4K frames.
IP will either fragment the packets or use MTU discovery to limit packet
sizes as necessary, to pass through the smallest MTU along the path. Even
with 1500 byte MTU, this occurred because some paths through the internet
used even smaller (~570 bytes IIRC) frames. IP is supposed to be
independent of the underlying hardware.
There are some no-ack protocols that could benefit greatly from not
having to worry about the 1500-byte MTU of regular ethernet frames.
The Internet likely won't be changing anytime soon. If you want to
do it in the privacy of your own net, no-one will stop you. As far
as I understand it there is work to speed up 1500 octet traffic
such that the differences will be small.
The internet shouldn't be a factor, as it'd designed to work with a variety
of technologies, including those that support much bigger frames. For
example, years ago I used to run on a token ring network, using 4K frames.
IP will either fragment the packets or use MTU discovery to limit packet
sizes as necessary, to pass through the smallest MTU along the path. Even
with 1500 byte MTU, this occurred because some paths through the internet
used even smaller (~570 bytes IIRC) frames. IP is supposed to be
independent of the underlying hardware.
- James Knott
Re: Jumbo Ethernet Frames
by Guest » Fri Nov 11, 2005 9:44 pm
James Knott wrote:
I guess I should have mentioned: I am experimenting with a new protocol
stack (new layers, new everything).
Layer 2 of my protocol stack disallows fragementation. However, there
are some instances where 3K is the ideal minimum "useful payload" size,
and 7800 would be the minimum size for efficient amortization of
overhead cause by security and other mechanims. So you can imagine how
I would be interested in 9K buffers.
I realize that the entire 'Net would have to change to make this
feasible, but I would just be content in knowing that the capability 9K
is present in most NICs. Naturally, there are other ways to support
the no-fragmentation requirement.
-Le Chaud Lapin-
The internet shouldn't be a factor, as it'd designed to work with a variety
of technologies, including those that support much bigger frames. For
example, years ago I used to run on a token ring network, using 4K frames.
IP will either fragment the packets or use MTU discovery to limit packet
sizes as necessary, to pass through the smallest MTU along the path. Even
with 1500 byte MTU, this occurred because some paths through the internet
used even smaller (~570 bytes IIRC) frames. IP is supposed to be
independent of the underlying hardware.
I guess I should have mentioned: I am experimenting with a new protocol
stack (new layers, new everything).
Layer 2 of my protocol stack disallows fragementation. However, there
are some instances where 3K is the ideal minimum "useful payload" size,
and 7800 would be the minimum size for efficient amortization of
overhead cause by security and other mechanims. So you can imagine how
I would be interested in 9K buffers.
I realize that the entire 'Net would have to change to make this
feasible, but I would just be content in knowing that the capability 9K
is present in most NICs. Naturally, there are other ways to support
the no-fragmentation requirement.
-Le Chaud Lapin-
- Guest
Re: Jumbo Ethernet Frames
by James Knott » Sat Nov 12, 2005 3:05 am
unoriginal_username@yahoo.com wrote:
Again it shouldn't make any difference. With IPv4 you can use MTU discovery
to limit your packet size. And if you don't some downstream router will
fragement the packets for you. With IPv6, you'll have to use MTU discovery
or fragmentation at the source.
James Knott wrote:
The internet shouldn't be a factor, as it'd designed to work with a
variety
of technologies, including those that support much bigger frames. For
example, years ago I used to run on a token ring network, using 4K
frames. IP will either fragment the packets or use MTU discovery to limit
packet
sizes as necessary, to pass through the smallest MTU along the path.
Even with 1500 byte MTU, this occurred because some paths through the
internet
used even smaller (~570 bytes IIRC) frames. IP is supposed to be
independent of the underlying hardware.
I guess I should have mentioned: I am experimenting with a new protocol
stack (new layers, new everything).
Layer 2 of my protocol stack disallows fragementation. However, there
are some instances where 3K is the ideal minimum "useful payload" size,
and 7800 would be the minimum size for efficient amortization of
overhead cause by security and other mechanims. So you can imagine how
I would be interested in 9K buffers.
I realize that the entire 'Net would have to change to make this
feasible, but I would just be content in knowing that the capability 9K
is present in most NICs. Naturally, there are other ways to support
the no-fragmentation requirement.
Again it shouldn't make any difference. With IPv4 you can use MTU discovery
to limit your packet size. And if you don't some downstream router will
fragement the packets for you. With IPv6, you'll have to use MTU discovery
or fragmentation at the source.
- James Knott
7 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 0 guests