April 2001 - Test - lists.nanog.org

RE: jumbo frames
by Richard A. Steenbergen 27 Apr '01

27 Apr '01

On Fri, Apr 27, 2001 at 12:47:09PM -0700, Tony Hain wrote: > > I understand all those points; I was reacting to the comment that the > only jumbo frames were between the routers, so the only ones coming in > would be 1500. Look at John's notes from 4/25 8:10pm & 4/26 9:40am. > There is no way I know of for a larger frame by itself to increase the > speed of a packet. What was missing was the subsequent comment about > tunneling those packets (thus increasing the size beyond 1500) across > the GE links to the distribution router. Avoiding fragmentation > clearly has performance gains, but fragmentation is unnecessary if the > packet size remains the same from end to end. The original scenario > was simply standard-size feeders into a router, with jumbo frame GE > between the core routers, then standard-size distribution on the other > end. The claim was that jumbo frames in the middle made it go faster. > If this is true I want to know how. It is also possible that he has packets entering and leaving his network by SONET, ATM, FDDI, or anything else which is not Ethernet. By supporting jumbo frames on his GigE router links, he is potentially providing a path with larger MTU support. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: jumbo frames
by Stephen Sprunk 27 Apr '01

27 Apr '01

Thus spake Tony Hain: > > Hence my original question. Packets across the GE will be 1500 > unless you are packing them. Or unless you actually have >1500 MTU to the hosts, which is quite possible. A traffic study from MCI's backbone (obviously years ago) showed nearly 40% (byte-wise) of their traffic was in packets >1500 bytes. With the death of FDDI, this has probably come down, but GE-attached servers in colos should push it back up. > Assuming you are just passing the packets as received from the > aggregation switch, this would only happen if your router hardware > was better at managing jumbo buffer allocations than 1500B ones. > Clearly it will waste large chunks of memory, so do you have > measurements to show the actual performance increase? Routers usually have separate buffer pools for common packet sizes (or use buffer vectors), so the MTU of the interface does not noticeably affect memory usage. Router performance is, however, directly related to packet size, since forwarding overhead is per-packet and not per-byte. It is much easier to fill big pipes with 9000 byte packets than 1500 byte packets. > Tony S -- Stephen Sprunk "So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSS always said exactly what pleased me." --Albert Einstein

2 1

OT: Apologies
by Karyn Ulriksen 27 Apr '01

27 Apr '01

Wasn't aware of the charter about posting positions on NANOG. Never saw anything about it and didn't read the charter (or knew that a formal one existed). Color me chastised and apologetic. I figured if I post this apology, maybe some else who didn't know about it will learn. It was nicely pointed out that if recruiting was pursued at NANOG, that our companies wouldn't send us. Good point. Apologies all around. --------------------------------------------------------------------- Best regards, Karyn Ulriksen Network Operations Manager SiteStream, A VitalStream Company 1 Jenner, Suite 100 Irvine, California 92618 USA Phone: (949) 743-2000 email: kulriksen(a)vitalstream.com URL: http://www.vitalstream.com ===========================================

1 0

Re: Compatible Systems Spare Parts ?
by SMcGrath＠dhhs.state.nh.us 27 Apr '01

27 Apr '01

Go to www.mouser.com Mouser Electronics and/or call them on the phone as that is a standard voltage wall wart other sources are Digi-key and Arrow Electronics

1 0

OT: Network Engineer Position in Irvine, California
by Karyn Ulriksen 27 Apr '01

27 Apr '01

Colocation and webfarm looking for Senior Network Engineer. Please contact kulriksen(a)vitalstream.com for information. --------------------------------------------------------------------- Best regards, Karyn Ulriksen Network Operations Manager SiteStream, A VitalStream Company 1 Jenner, Suite 100 Irvine, California 92618 USA Phone: (949) 743-2000 email: kulriksen(a)vitalstream.com URL: http://www.vitalstream.com ===========================================

1 0

RE: jumbo frames
by Roeland Meyer 27 Apr '01

27 Apr '01

> From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Thursday, April 26, 2001 11:47 AM > > April 26, 2001 9:29 AM John Fraizer wrote: > > We only have jumbo frames enabled on router<->router links. > The GigE > > ports facing the aggregation switches runs standard 1500 MTU. > > Hence my original question. Packets across the GE will be > 1500 unless you > are packing them. > > April 25, 2001 8:10 PM John Fraizer wrote: > > Partially because I can. Partially because there seems to be a > > performance increase when you start stuffing the pipe. > > Assuming you are just passing the packets as received from > the aggregation > switch, this would only happen if your router hardware was better at > managing jumbo buffer allocations than 1500B ones. Clearly it > will waste > large chunks of memory, so do you have measurements to show the actual > performance increase? This depends on the type of traffic. We use it to enhance performance of the data tier. We've jiggered the TCP/IP stacks for ~4500 byte packets and have knee-capped the slow-start algorithm (which doesn't make sense in a pure switched environment anyway). What we then wind up with, is a dedicated data LAN between our application servers and the Oracle database servers. It comes out to about an order of magnitude increase in performance and SQL query responsiveness. At first we went to jumbo packets. We saw such a radical improvement that we started investigating and found the slow-start issue. Jumbo packets are one way around the slow-start problem if you can't jigger the stack itself. Most of the queries are reasonably short so we saw some serious improvements by killing the slow-start. If you can modify your IP stack then it still pays to use jumbo packets because you reduce the overhead on the wire. We got sufficient performance improvement that we were able to defer GigE implementation, at some sites. Those sites are using switched FDX 100baseTX.

4 4

Compatible Systems Spare Parts ?
by Smith, Rick 27 Apr '01

27 Apr '01

I'm at the end of my rope in the search for using two Microrouter 1200i's. Wondering if anyone has any spare power bricks for them ? I need ONE :) Specs: Class 2 Transformer Input: 120V 60Hz 50W Output: AC 12V 2.9A Model #: WP573512G No one anywhere has these, and Cisco's response is "Buy Ciscos to replace the 1200's". Sorry for the noise.. Thanks, Rick Smith Director of Technical Services Applied Tactical Systems (A division of Vertex Interactive, Inc.) <http://www.atsworld.com> --- <http://www.vertexinteractive.com> (973) 808 - 1750 x382

2 1

RE: jumbo frames
by Roeland Meyer 27 Apr '01

27 Apr '01

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(a)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(a)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 >

1 0

Re: jumbo frames
by Stephen Sprunk 27 Apr '01

27 Apr '01

From: "Kurt Kayser" <kurt(a)noris.de> > > 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? Intermediate routers to not 'collect' small packets into big packets. > Kurt S -- Stephen Sprunk "So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSS always said exactly what pleased me." --Albert Einstein

1 0

RE: jumbo frames
by Rowland, Alan D 27 Apr '01

27 Apr '01

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(a)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

1 0