It's a common benchmarking practice to take multiple measurements of throughput or latency, each using a different packet size. There's no one right answer as to which packet size represents the "best" result.

Medium-size frames, such as the 512-byte packets used in this test, are often considered useful, because they're close to the "average" Internet size of roughly 300 to 400 bytes. However, "average" may not be terribly meaningful, because the majority of Internet and enterprise traffic uses TCP. That protocol involves a mix of very long and very short packet lengths (long packets downstream, short acknowledgment packets upstream). Thus, an "average" somewhere in the middle doesn't necessarily describe the actual mix of long and short packet lengths.

Short packets, such as the 88-byte packets we used, are a good way to stress a device. Short packets mean there is more work for a device to process per unit of time. With many devices, each new packet represents a software interrupt; the more packets there are, the more interrupts the device must process.

However, because no production network carries entirely short packets, these tests are mainly useful as an indicator of device limits. Note that the 88-byte packet length we used in this test is longer than the 802.3 wired Ethernet minimum of 64-byte packets; we did this because 802.11 Wi-Fi framing adds additional overhead.

Long packets, such as the 1,518-byte packets we used, are a good way to stress a network. With long packets, the ratio between packet payload and packet headers is higher; therefore, it is easier to fill up a pipe with longer packets.

While each of these packet lengths offers a useful way to describe device performance, there's no one-size-fits-all approach that indicates which device is best suited to enterprise use. Every enterprise network carries a different distribution of packet lengths, and for best results it's necessary to develop a custom test traffic profile to test suitability for a given network.