Priscilla, No problem specifically. I think we all face a customer who doesn't really understand this stuff - but thinks they have it down perfectly. So I get questions like: "can that 3620 handle a full T3?" The answer, of course, is "it depends" (or perhaps the optimum response would be: "ask a better question"). So my comment was regarding the issue of packets vs. bits/bytes. It's rather obvious that a smaller packet size equate to better pps "performance." But here, as an example, are some numbers from the 3600 series:
3640 w/ FE to HSSI size: type: switching: performanc: 64 Unidirectional Fast 40,500 pps 20.7 Mbps 128 Unidirectional Fast 40,000 pps 41.0 Mbps 256 Unidirectional Fast 22,000 pps 45.0 Mbps 512 Unidirectional Fast 11,900 pps 48.7 Mbps 1518 Unidirectional Fast 4,200 pps 51.0 Mbps Notice the two-fold+ increase in bps between 64 and 1518 byte packets. I would guess there are several contributing factors. Not in any particular order of importance, it has been mentiond already that there is: less interframe gap less header handling (processing) I guess this is kind of follows from above: A lower ratio of header to payload. As was pointed out, it doesn't take much to switch the bits once the processing has taken place. And less re-encapsulation effor bit for bit. So I don't think I made any new points on a technical plane, but I was making note of the fact that the marketing technique somewhat backfires. Can that 3600 handle a "T3"? Not if all your packets are 64 bytes! 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. 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39225&t=38956 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
