Darn, and I was just getting ready to ask if that was packets per pound! Pound of what? I leave that to your imagination.
Prof. Tom Lisa, CCAI Community College of Southern Nevada Cisco ATC/Regional Networking Academy Priscilla Oppenheimer wrote: > 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=39231&t=38956 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
