At 03:30 PM 3/22/02, Priscilla Oppenheimer wrote: >At 12:01 PM 3/22/02, s vermill wrote: > >All, > > > >I agree that the industry has settled on pps. > >Router and switch vendors use ppp to advertise throughput measurements of >packets through their devices.
That should say pps! ;-) >This is just one minor aspect of network >performance. > > > And yes, the smaller the > >packet size the greater the number appears. > >The vendors do their tests with all packet sizes. They bandy about the one >that's best. > >This has nothing to do with actual traffic patterns and isn't a >recommendation on packet sizes that should be used, as I'm sure you realize. > > >However, if you look at the > >ratio of header to payload, smaller packet sizes seem to result in lower > >throughput as measured in bits or bytes. > >What problem are you trying to solve? What performance metric are you >trying to measure? > >When measuring application-layer throughput, it's common practice not to >count the headers. The measurement is application-layer bytes per second. >If these bytes are being divided into small chunks and each chunk has >headers that take up bandwidth, then application-layer throughput won't be >so good. If these bytes are divided into larger chunks, then a smaller >percentage of bandwidth is consumed by headers, and application-layer >throughput is better. > >Common wisdom used to be to always maximize packet sizes to ensure optimum >application-layer throughput. > >Maximum packet sizes can cause excessive serialization delay on low-speed >output interfaces, however. If you have a voice or other delay-sensitive >application, then maybe you shouldn't use maximum packet size. Or maybe you >should use one of the many link fragmentation technologies, such as FRF.12. > >Again, what problem are you trying to solve? > >Priscilla > > > A larger packet size has a lower > >ratio and thus a greater throughput in raw ones and zeros. Studies I have > >seen in the past seem to support that theory. Any comments on that aspect? > > > >Regards, > > > >Scott > > > >Priscilla Oppenheimer wrote: > > > > > > > > > The Layer 2 header changes whenever a router forwards a packet. > > > For one > > > thing, the Layer-2 destination address changes. The frame goes > > > to the next hop. > > > > > > The router strips the Layer 2 header on the incoming packet, > > > figures out > > > where to forward the frame from a routing table or cache, and > > > re-encapsulates the frame into a new Layer 2 header. The amount > > > of > > > processing required to strip an Ethernet header, figure out the > > > destination > > > port and encapsulation, and re-encapsulate into Frame Relay is > > > essentially > > > the same as the amount of overhead required to strip an > > > Ethernet header, > > > figure out the destination port and encapsulation, and > > > re-encapsulate into > > > an Ethernet header. > > > > > > Marc's point was that the amount of overhead is also the same > > > regardless of > > > the packet size. The job must be done whether it's a 46-byte or > > > 1500-byte > > > packet. And I like the way he said that "shovelling the rest of > > > the packet > > > through is low overhead." That's true. > > > > > > Keep in mind, however, that the packets-per-second ratings are > > > just vendor > > > marketing departments trying to "one up" their competitors. So, > > > they post > > > the results of testing with 64 byte packets because that makes > > > the number > > > higher. More packets are coming in to get processed. Long > > > packets take > > > longer, not because of extra processing, but simply because of > > > serialization delay. > > > > > > It's like a relay in a train-switching system. The relay > > > doesn't have to do > > > more work for long trains with many cars. But it still takes > > > longer to get > > > a long train through the relay than it does to get a short > > > train through it. > > > > > > Priscilla > > > > > > > > > > > > > > > > > > >--- Marc Thach Xuan Ky > > > >wrote: > > > > > Sam, > > > > > I think the question is: what is your average packet > > > > > size? Using > > > > > process or fast switching I should think that the > > > > > packet size is almost > > > > > irrelevant to the router. I have benchmarked many > > > > > PCs and NICs running > > > > > certain routing software. On a PCI bus PC the pps > > > > > difference between 64 > > > > > and 1518 octet frames was in the order of ten to > > > > > twenty percent, i.e. > > > > > the routing decision consumes the bulk of the CPU > > > > > bandwidth, shovelling > > > > > the rest of the packet through is low-overhead. > > > > > Marc > > > > > > > > > > sam sneed wrote: > > > > > > > > > > > > I noticed Cisco uses pps when they give their > > > > > specs for routers, firewalls, > > > > > > etc. What is the assumed packet size when they > > > > > come up with these specs? > > > > > I'm > > > > > > planning on using 2 2621's in HSRP mode (getting > > > > > default routes via BGP) > > > > > and > > > > > > need to be able to support a constant 10 Mb/sec > > > > > and would like know if > > > > > these > > > > > > routers will do the trick. > > > > > > thanks > > > >[EMAIL PROTECTED] > > > > > > > > > > > >__________________________________________________ > > > >Do You Yahoo!? > > > >Yahoo! Movies - coverage of the 74th Academy Awards. > > > >http://movies.yahoo.com/ > > > ________________________ > > > > > > Priscilla Oppenheimer > > > http://www.priscilla.com >________________________ > >Priscilla Oppenheimer >http://www.priscilla.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39218&t=38956 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
