>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.
Take a look at http://www.ietf.org/html.charters/bmwg-charter.html. BMWG is the IETF group that sets objective criteria for testing, although, to quote Randy Bush at the meeting this week, "it is beyond the power of the IETF to control marketdroids." Definitely read RFC 2544. Throughput is bad enough...I'm dealing with the fun of convergence benchmarking! > > >>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. Good characterization of packet sizes in a general environment, even a large enterprise, is NOT a trivial problem. > > >> >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=39232&t=38956 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
