Re: Jumbo frames

On 28 Mar 2007, at 00:28, Jim Shankland wrote:

> 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.

The original poster was talking about a streaming
application -  
increasing the frame size can cause it take longer for
frames to fill  
a packet and then hit the wire increasing actual latency in
your  
application.

Probably doesn't matter when the stream is text, but as
voice and  
video get pushed around via IP more and more, this will
matter.

 
> The original poster was talking about a streaming
application -  
> increasing the frame size can cause it take longer for
frames 
> to fill  
> a packet and then hit the wire increasing actual
latency in your  
> application.
> 
> Probably doesn't matter when the stream is text, but as
voice and  
> video get pushed around via IP more and more, this will
matter.

Increasing the MTU is not the same as increasing the frame
size. MTU
stands for Maximum Transmission Unit and is a ceiling on the
frame size.
Frames larger than the MTU must be fragmented. Clearly it is
dumb for a
voice application or a realtime video application to use
large frames,
but setting the MTU on a WAN interface to something higher
than 1500
does not require the application to fill up its frames.
Also, if a video
application is not realtime, then use of large frames is
more likely to
do good than to do harm. 

--Michael Dillon

Thus spake "Andy Davidson" <andynosignal.org>
> The original poster was talking about a streaming
application - 
> increasing the frame size can cause it take longer for
frames to fill  a 
> packet and then hit the wire increasing actual latency
in your 
> application.
>
> Probably doesn't matter when the stream is text, but as
voice and  video 
> get pushed around via IP more and more, this will
matter.

It's a serious issue for voice due to the (relatively) low
bandwidth, which 
is why most voice products only put 10-30ms of data in each
packet.

Video, OTOH, requires sufficient bandwidth that
packetization time is almost 
irrelevant.  With a highly compressed 1Mbit/s stream you're
looking at 12ms 
to fill a 1500B packet vs 82ms to fill a 10kB packet.  It's
longer, yes, but 
you need jitter buffers of 100-200ms to do real-time media
across the 
Internet, so that and speed-of-light issues are the dominant
factors in 
application latency.  And, as bandwidth inevitably grows
(e.g. ATSC 1080i or 
720p take up to 19Mbit/s), packetization time quickly fades
into the 
background noise.

Now, if we were talking about greater-than-64kB jumbograms,
that might be 
another story, but most folks today use "jumbo" to
mean packets of 8kB to 
10kB, and "baby jumbos" to mean 2kB to 3kB.

S

Stephen Sprunk      "Those people who think they know
everything
CCIE #3723         are a great annoyance to those of us who
do."
K5SSS                                             --Isaac
Asimov