nanog mailing list archives

RE: jumbo frames


From: Roeland Meyer <rmeyer () mhsc com>
Date: Fri, 27 Apr 2001 09:11:58 -0700


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 () corp earthlink net]
Sent: Friday, April 27, 2001 8:45 AM
To: 'Kurt Kayser'; Tony Hain
Cc: Roeland Meyer; John Fraizer; Paul Lantinga; nanog () 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 () noris de]
Sent: Friday, April 27, 2001 8:07 AM
To: Tony Hain
Cc: Roeland Meyer; John Fraizer; Paul Lantinga; nanog () 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



Current thread: