Re: Cisco's pps claims [7:38956]
All, I agree that the industry has settled on pps. And yes, the smaller the packet size the greater the number appears. 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. 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=39177t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
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 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 Message Posted at:
Re: Cisco's pps claims [7:38956]
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/
Re: Cisco's pps claims [7:38956]
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 Fast40,500 pps 20.7 Mbps 128 Unidirectional Fast40,000 pps 41.0 Mbps 256 Unidirectional Fast22,000 pps 45.0 Mbps 512 Unidirectional Fast11,900 pps 48.7 Mbps 1518Unidirectional Fast4,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=7i=39225t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
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
Re: Cisco's pps claims [7:38956]
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
Re: Cisco's pps claims [7:38956]
At 04:43 PM 3/22/02, s vermill wrote: 3640 w/ FE to HSSI size: type: switching: performanc: 64 Unidirectional Fast40,500 pps 20.7 Mbps 128 Unidirectional Fast40,000 pps 41.0 Mbps 256 Unidirectional Fast22,000 pps 45.0 Mbps 512 Unidirectional Fast11,900 pps 48.7 Mbps 1518Unidirectional Fast4,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. Hm. 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=7i=39264t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
I don't really know what the overhead of that specific stuff is, but it's all part of a packet coming up the stack to the routing layer, and it has to be done per packet, so packet size is irrelevant to that. Using traditional routing techniques such as process or fast switching, the packet will be decapsulated to IP regardless of the underlying layers. I imagine that most of the framing work is done in hardware. Marc John Green wrote: the routing decision consumes the bulk of the CPU bandwidth, shovelling the rest of the packet through is low-overhead. say a router connects a between ethernet and Frame Relay or between two dissimilar Layer2 networks. Then the router would be stripping off one networks' layer2 frame and replace it with the layer2 frame of the other network where the packet is to be sent. Would you call this low-overhead as well ? I guess your example would be if the router were to connect between same Layer2 networks ie say both networks are ethernet. right ? just want to make sure... --- 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/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=39017t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
At 11:57 PM 3/20/02, John Green wrote: the routing decision consumes the bulk of the CPU bandwidth, shovelling the rest of the packet through is low-overhead. say a router connects a between ethernet and Frame Relay or between two dissimilar Layer2 networks. Then the router would be stripping off one networks' layer2 frame and replace it with the layer2 frame of the other network where the packet is to be sent. Would you call this low-overhead as well ? I guess your example would be if the router were to connect between same Layer2 networks ie say both networks are ethernet. right ? just want to make sure... 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=39068t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
Working on IETF stuff: :) http://www.ietf.org/html.charters/ieprep-charter.html This was in response to Scott's question on where Scott Bradner's been hiding. I imagine he's at the IETF meeting right now. Steven A. Ridder wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Working on IETF stuff: :) http://www.ietf.org/html.charters/ieprep-charter.html -- RFC 1149 Compliant. Get in my head: http://sar.dynu.com s vermill wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Sam, These calculations are almost always based on the minimum - 64 bytes. It's tempting to suspect the worst when you see that. But truth is, the larger the packet size, the more bytes you can generally move through a platform. The better studies will show you the pps for several packet sizes, ranging from 64 bytes to 1518. They will ideally show you the throughput for the various switching methods as well. Scott Bradner of Harvard fame is, well, famous for his thorough and independent testing of various internetworking products. However, I haven't been able to locate his ftp site lately. Anyone know where he is hiding that these days? Regards, Scott 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=39092t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
The Internet Emergency Preparedness (ieprep) group sounds very interesting and important. Thanks for letting us know about it (in a back-handed way. ;-) Priscilla At 05:01 PM 3/21/02, Steven A. Ridder wrote: Working on IETF stuff: :) http://www.ietf.org/html.charters/ieprep-charter.html This was in response to Scott's question on where Scott Bradner's been hiding. I imagine he's at the IETF meeting right now. Steven A. Ridder wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Working on IETF stuff: :) http://www.ietf.org/html.charters/ieprep-charter.html -- RFC 1149 Compliant. Get in my head: http://sar.dynu.com s vermill wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Sam, These calculations are almost always based on the minimum - 64 bytes. It's tempting to suspect the worst when you see that. But truth is, the larger the packet size, the more bytes you can generally move through a platform. The better studies will show you the pps for several packet sizes, ranging from 64 bytes to 1518. They will ideally show you the throughput for the various switching methods as well. Scott Bradner of Harvard fame is, well, famous for his thorough and independent testing of various internetworking products. However, I haven't been able to locate his ftp site lately. Anyone know where he is hiding that these days? Regards, Scott 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 Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=39096t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Cisco's pps claims [7:38956]
Sam, These calculations are almost always based on the minimum - 64 bytes. It's tempting to suspect the worst when you see that. But truth is, the larger the packet size, the more bytes you can generally move through a platform. The better studies will show you the pps for several packet sizes, ranging from 64 bytes to 1518. They will ideally show you the throughput for the various switching methods as well. Scott Bradner of Harvard fame is, well, famous for his thorough and independent testing of various internetworking products. However, I haven't been able to locate his ftp site lately. Anyone know where he is hiding that these days? Regards, Scott 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=38964t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
Working on IETF stuff: :) http://www.ietf.org/html.charters/ieprep-charter.html -- RFC 1149 Compliant. Get in my head: http://sar.dynu.com s vermill wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Sam, These calculations are almost always based on the minimum - 64 bytes. It's tempting to suspect the worst when you see that. But truth is, the larger the packet size, the more bytes you can generally move through a platform. The better studies will show you the pps for several packet sizes, ranging from 64 bytes to 1518. They will ideally show you the throughput for the various switching methods as well. Scott Bradner of Harvard fame is, well, famous for his thorough and independent testing of various internetworking products. However, I haven't been able to locate his ftp site lately. Anyone know where he is hiding that these days? Regards, Scott 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=38965t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Cisco's pps claims [7:38956]
Sam, IIRC, Cisco uses 64 byte packets as the baseline. FYI, I have been conducting some throughput tests on 2 2621's in the lab and here are some results for you. I used TTCP between 2 Sparc ultras for the traffic. The sparc ultras can generate about 90Mbps with no routers between them, so the 2621's are the limiting factor and not TTCP or the sparcs. I used a window size of 65,535 and the max packet size for my tests: No fast switching 9.3 Mbps W/ fast switching 51.2 Mbps W/ Netflow 46.5 Mbps W/ Cef 51.2 Mbps Nat, no fast switching 8.1 Mbps Nat, w/ fast switching 31.5 Mbps Nat, w/ netflow 14.1 Mbps Nat, w/ cef 29.5 Mbps ACL, no fast switching 8.7 Mbps ACL, w/ fast switching 40.4 Mbps ACL, w/ netflow 46.5 Mbps ACL, w/ cef 43.9 Mbps The IOS used for this testing was 12.1.5(T9) (the ACL was 20 entries, all numbers are averages of 5 tests, but the deviations were very small) The thing I found most interesting was that for the most part, using simple fast switching produced as good or better results than netflow or CEF. The only exception to this was with the ACL, but fast switching was only a few Mbps behind netflow and CEF. Also, notice the suprisingly bad performance of netflow when using NAT. I ran this test many times with different NAT configurations and the results were always consistent. My local Cisco SE didn't really have a good explanation, and I haven't tried to really track down the issue, but I wouldn't use netflow if your using NAT. :-) (also notice there is a 40% performance hit when using NAT in the best case) Keep in mind these were single, persistent flows, so they did not simulate real-world traffic patterns. However, it does give an idea of the top end performance of the 2621. (suprisingly better than I expected given the low-end nature of the box) I should also mention that the CPU hovered around 99% for the duration of the tests. HTH, Kent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of sam sneed Sent: Wednesday, March 20, 2002 12:14 PM To: [EMAIL PROTECTED] Subject: Cisco's pps claims [7:38956] 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=38976t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=38983t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
Vendors usually quote the packets per second rate based on 64-byte packets because that makes the number look more impressive (i.e. larger)! The 2661 router may be able to keep pace at wire speed on 10-Mbps Ethernet. (You may still have a bottleneck if your outgoing WAN isn't that fast, but that's another issue.) If the router can do wire speed for 64 byte packets, the number you will see is 14,880 packets per second. If the router can do that with 64 byte packets, then it can keep up with large packets also. Vendors often don't advertise the packets per second for larger packets, however, because the number is smaller because there are fewer packets arriving per second. FYI: here's how the 14,880 packets per second number is derived: A 64 byte packet is actually 64 bytes header, data, FCS 8 bytes preamble 12 bytes inter-frame gap - 84 bytes = 672 bits On 10,000,000 bits per second Ethernet, that means the maximum packets per seconds is 10,000,000/672 = 14,880. Priscilla At 03:14 PM 3/20/02, 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 Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=39002t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Cisco's pps claims [7:38956]
the routing decision consumes the bulk of the CPU bandwidth, shovelling the rest of the packet through is low-overhead. say a router connects a between ethernet and Frame Relay or between two dissimilar Layer2 networks. Then the router would be stripping off one networks' layer2 frame and replace it with the layer2 frame of the other network where the packet is to be sent. Would you call this low-overhead as well ? I guess your example would be if the router were to connect between same Layer2 networks ie say both networks are ethernet. right ? just want to make sure... --- 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/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=39006t=38956 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
