At 04:43 PM 3/22/02, s vermill wrote: >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.
The contributing factor that I noticed is that 1518 is a lot bigger than 64. ;-) Notice that the Mbps number is just derived from multiplying the PPS by the frame size in bits. I'm not sure what to make of this, but it's what I noticed.... It seems a little suspicious that they managed to come up with a number that almost exactly matches the speed of an HSSI interface. Hmmmmm. >Not in any particular >order of importance, it has been mentiond already that there is: > >less interframe gap With the minimum IFG, the FE side could be feeding 148,800 64-byte packets per second into the router. Of course, the HSSI can't handle that, so some queuing is happening. This is beginning to sound like a CCIE question, but is that what accounts for the rather small PPS, or is it a slow CPU? I'm sure Cisco would say the former. ;-) Priscilla >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 ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39264&t=38956 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
