jumbo frames
Roeland Meyer
rmeyer at mhsc.com
Fri Apr 27 16:11:58 UTC 2001
In both cases, it is a bandwidth issue. You either consume the bandwidth in
the CPU or consume it on the wire. CPU is cheaper and often under-utilized.
Of the two, CPU bandwidth is also cheaper/easier to upgrade.
> -----Original Message-----
> From: Rowland, Alan D [mailto:alan_r1 at corp.earthlink.net]
> Sent: Friday, April 27, 2001 8:45 AM
> To: 'Kurt Kayser'; Tony Hain
> Cc: Roeland Meyer; John Fraizer; Paul Lantinga; nanog at merit.edu
> Subject: RE: jumbo frames
>
>
> I am not an EE but maybe if you rephrased the question as
>
> Which is greater, the cpu cycles to assemble/dissemble jumbo
> frames or the
> additional cycles/bandwidth of more numerous ACK packets?
>
> Then again, I may be way out of my depth here.
>
> -Al
>
> -----Original Message-----
> From: Kurt Kayser [mailto:kurt at noris.de]
> Sent: Friday, April 27, 2001 8:07 AM
> To: Tony Hain
> Cc: Roeland Meyer; John Fraizer; Paul Lantinga; nanog at merit.edu
> Subject: Re: jumbo frames
>
>
>
> Hi,
>
> Isn't it a lot more cpu-intensive to 'collect' some 1500-byte frames
> into some larger bucket, reassemble it into a jumbo-frame
> when the next
> box has to chop it in order to send it out on a Sonet/PPP/etc
> interface
> which
> might have a smaller MTU again?
>
> Doesn't make too much sense to me. I guess that was Tony's
> aim as well..
>
> Kurt
>
> > Roeland you are talking about jumbo frames from the end
> system lan, while
> > John is talking about only using the jumbo frames between
> the routers. My
> > point was that in John's environment the packets will all
> be 1500 since
> the
> > packets are restricted to that size just to get to the
> router with the GE
> > interface. I understand that there are perf gains as long
> as the entire
> path
> > supports the larger packets, but I don't understand the
> claim that having
> a
> > bigger pipe in the middle helps.
> >
> > Tony
> >
> --
> noris network AG * tel +49 911 93 52-0 * internet
> Kilianstraße 142 * fax +49 911 93 52-100 * solution
> 90425 Nürnberg * http://www.noris.net * provider
>
More information about the NANOG
mailing list