Re: Jumbo frames
Thus spake "Andy Davidson" <[EMAIL PROTECTED]> 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
RE: Jumbo frames
> 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
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.
RE: Jumbo frames
Use GigE cards on the servers with a jumbo MTU and only buy IP network access from a service provider who supports jumbo MTUs end-to-end through their network. To check MTU on transit paths, try mturoute: http://www.elifulkerson.com/projects/mturoute.php As well as the MTU eye-chart: http://www.elifulkerson.com/projects/mtu-eyechart.php -Hank Nussbacher http://www.interall.co.il
RE: Jumbo frames
<[EMAIL PROTECTED]> writes: > [...] > if there are several factors that will contribute to solving the > problem, I think that you get better results if you attack all of them > in parallel. Well, I guess; except that "only buy IP network access from a service provider who supports jumbo MTUs end-to-end through their network" may be a much bigger task than tuning your TCP stack. 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. On a coast-to-coast DS-3, a TCP stack that's correctly tuned for a high bandwidth-delay product environment, on the other hand, is likely to outperform an untuned stack by a factor of 10 or so in bulk transport over a single TCP session. (Though, as somebody pointed out, tuning may have to occur all the way up the application stack; there are, e.g., ssh patches out there for high-BDP environments.) So I guess, sure, try anything you can; but I know what I'd try first :-). Jim Shankland
RE: Jumbo frames
> > Use GigE cards on the servers with a jumbo MTU and only buy > IP network > > access from a service provider who supports jumbo MTUs end-to-end > > through their network. > > I'm not sure that I see how jumbo frames help (very much). The > principal issue here is ... The people who know what helps are the ones who have been setting the Internet land speed records. They typically use frames larger than 1500. As for the principal issue, well, if there are several factors that will contribute to solving the problem, I think that you get better results if you attack all of them in parallel. Then, if you learn that there really is one principal factor and you need some management approval to move on that issue, you will have laid the groundwork for making a business case because you've already done all the other things. --Michael Dillon
