How is a device throughput defined
Ali sent me a question that should bother every networking engineer:
Could you explain how Cisco [or another vendor] comes up with the throughput parameters in a products datasheet? For example if a vendor says that "if IPSec is turned on the throughput is 20Mpps", exactly what does it mean? What is the packet size he is referring to and what are the implications here, because very seldom do we have fixed packet sizes in a traffic flow.
The answer, as always, is "it depends". If you're reading a serious performance analysis report, it should document the test procedures, including the packet sizes. If you're getting a "marketing" figure with no further explanation, you can be sure it's been cooked as much as possible. For example, a Gigabit Ethernet link sometimes has 2 Gbps performance (in-and-out) and in case of IPSec packet-per-second values, they are most probably measured with optimal (in this case low) packet size.
This article is part of You've asked for it series.
Posts
7 comments:
Sorry - 'optimal' packet sizes for use in marketing materials are large packets, around 1500 bytes or thereabouts.
Cisco and other vendors still make use of 'iMix', even though it's both old and has never borne any relevance whatsoever to traffic profiles on any real network anywhere, at any time.
As you indicate, what's really needed is to develop a performance envelope for a given device/interface with packet sizes/frame rates from the applicable minimum to the applicable maximum, a la RFC2544, as well as with various features enabled/disabled.
For testing throughput in pps, optimal should be "as small as possible", but for testing throughput in bps, optimal should be "as large as possible not fragmented" - am I right?
All three of us are basically in agreement. If you're measuring throughput in bps, it's ideal to use large packets (increasing bps @ constant pps).
If you're measuring throughput in pps, packet sizes usually don't matter much as long as you can generate enough packets based on your bps throughput and port density. Most of the receive/send processing (which is packet-size-dependent) is done in hardware and the CPU (or ASICs) just swaps pointers to packet headers.
For IPSec performance in pps, it's probably ideal to have small packets ... I'm assuming that the packet size affects the encryption/decryption time, which should be the major part of the per-packet processing time.
Just found an interesting link about the "usefulness" of IMIX.
Ivan, thanks for linking to the IMIX post we put up, you might also find the truth in testing series of running posts we have helpful, we try and hit on this topic a lot about what realistic testing actually means and how to question data sheets in that light.
Kyle
There is also the flip-side to this... whenever a vendor talks to you about replacing your existing products, they tend to put the most broken mirror they can find in front of what you have and claim the existing product is inadequate. We recently experienced this from our cisco account team... they threw up 64-byte ethernet throughput numbers for one of our devices and claimed that it didn't offer as much 'throughput' as the cisco product.
However, using 64-byte ethernet frames is hardly a good indication of throughput. It is a good way to test packet-per-second rates, but throughput is best tested with 1500 byte frames as Roland mentioned above.
Post a Comment
If you're using Internet Explorer, your first attempt to publish a comment will probably fail (a feature of Blogger). Don't worry, just press the Post Comment button again.