Bits per second vs. Packets per second

Question

Lately I have been checking datasheets of several switch models from diferent vendors. For a given switch, vendors publish a couple of figures that I think are a measure of the capacity/performance of the switch:

• One value is always measured in packets per second
• The other one is always measured in bits per second

Despite different vendors use different names for the figures, seems the meaning is always the same.

I would like to understand three things:

1. What is the exact meaning of each figure?
2. What is the difference between them?
3. When should I focus on each value for switch assessment?

Answer 1

I just want to briefly mention the reality of marketing math when you're considering vendor data sheets. It is very common for vendors to double-count bps or pps capacity when you have full-duplex links. For instance, Cisco's Catalyst 6500 has a Supervisor 720. 720 is used because it is marketed as having 720Gbps of fabric capacity.

But... if you ask how Cisco calculates 720Gbps, the answer is:

• 80Gbps of fabric per slot times 9 slots in a chassis

The issue here is their fabric is only a 40Gbps full-duplex fabric... However, Cisco counts both ingress and egress in the 720G number, even though it doesn't really make sense to count like that. The take-away is you sometimes need to be careful and inspect how you can apply the numbers in vendor literature to reality.

Almost every vendor twists marketing numbers like this, and I only pick the Cat6500 because I'm very familiar with the platform. This is not a condemnation of Cisco or the Cat6500 (which I actually have quite a passion for).

What is the exact meaning of each figure? What is the difference between them?

• bps
  • Number of bits of data per second that can be processed without dropping data. bps is almost always measured using 1500 byte (or potentially larger) ethernet payloads.
  • bps is frequently used when measuring the capacity of components which interconnect multiple linecards or ports within a chassis (like a switch fabric). Occasionally, a central processing engine might have a bps limitation...
• pps
  • Number of packets of data per second that can be processed before dropping data; pps is always measured using the smallest packet sizes possible.
  • pps is frequently used when measuring components that look inside a packet header (for an IP address, mac-address, DSCP value, etc...). For example, the capacity of route and switch processors are measured in pps.

When should I focus on each value for switch assessment?

There is a time and place for this kind of analysis, but most people only use a tiny fraction of their switch pps / bps capacity, unless it's a top of rack switch in a busy data center, or a core switch for a mid to large service provider POP.

Even so, vendor sales staff might not be interested in highlighting the product limitations, or may not understand the limits well themselves. Also, the packet-per-second numbers often change depending on the features, or combination of features that you turn on... there really is no substitute for coming up with a few good test cases, and testing the performance of the box with the combination of features you think you realistically need.

Due to variances and the games people can play with numbers on data sheets, the most important thing you can ask the vendor is "show me how you calculated the bps and pps numbers for this component".

That said, hardware and software features are as important, or more important to consider than drag-race bps / pps numbers... I'm including a small sample of items you might want to look at... this is very subjective...

• On forwarding engines (normally measured in pps)

  • Add up the bandwidth of an average chassis port count, and find the average packet size (at the advertised non-drop rate) with features on and then with off (compare how these numbers may change)
  • Aggregate IPv4 / IPv6 / MPLS pps performance (these numbers may change, depending on the platform, or combinations of features that you use)
  • ACL rule limitations (on number of ACEs, header fields you can filter on, counters, etc...)
  • Total number of prefixes / mac addresses supported in HW and in DRAM
  • SNMP MIBs supported
  • QoS modes and features supported, as well as how easily you can integrate these QoS features into the rest of your network.
  • Route processor failover times
  • Availability and reliability of In service software upgrades
  • Does the OS have modular software components
  • Are Vlans locally significant to an interface, or does the box have global vlan utilization

• fabric / linecard fabric connections / linecard ASICs (normally measured in bps)

  • Average cost per 1GE or 10GE port
  • Port count and linecard oversubscription ratios
  • Linecard and port buffer sizes
  • Whether the switch supports backpressure to ingress linecards, if the egress fabric port is congested
  • Ingress vs Egress multicast replication

Answer 2

Usually you are presented with throughput in Mbps (M-bits/sec) and Mpps (M-packets/sec). These are considered backplane or box throughput numbers. Marketing materials usually present the numbers in the best light which is under ideal conditions of large packets with 1500 bytes in length. Realistic throughput can be obtained under test conditions that use Internet Mix (IMIX) of data where both packets lengths and protocols vary.

1. Mbps vs Mpps -- "M" included as the numbers are often shown x 10^6 -- is simply the difference between the raw "bit" vs "packet" switching or processing capacity. When hardware switching is possible, the numbers assume the best conditions where process-switching (punting to CPU) isn't necessary on every packet.
2. Since large frames (not Jumbos) have payloads of 1500 Bytes, this 1 packet of 1500 Bytes x 8 bits/Byte = 12,000 bits.
3. The Mbps clues you into the capacity of bit switching when aggregating all the interfaces. The Mpps helps you understand how many aggregate packets can be handled. This can all be changed if you're considering something like Cisco switch modules with DFC.

Answer 3

To add to good answers given by @generalnetworkerror and @MikePennington

Both pps and bps reported in datasheets are idealized numbers, not only is bps often double counted (the double counting comes from the fact that to cater 10Gbps interface, you'll need 20Gbps of memory bandwidth, so in this context it's fair, but may be confusing to buyer) like Mike explained.

But they, especially pps are also idealized to a scenario of vendor's definition of 'typical', the scenario has much less affect in switch-like devices (Cisco catalyst, Juniper ex, Force10, Brocade) as they tend to run in constant-time ASIC type devices for lookup. And it tends to have more effect to router-like devices (Cisco ASR9k, Juniper MX, Alcatel SR) as they tend to run NPU, which is close to normal CPU in design, and it'll take variable time to perform work.

This inherent feature is exploited when vendors buy 'verified by 3rd party' tests, like Cisco might pay Miercom to test Cisco+Juniper and Juniper might pay EANTC to test Cisco+Juniper.
These EANTC and Miercom engineers are given inside information for both platforms and they use this inside information to show how one platform (of paying customer) out-performs another platform. Because they choose test-cases which target compromises in the idealized scenario chosen by that vendor.

Luckily rarely will in switch-like device will pps or bps become an issue to you, it's far more likely you'll be bitten by for example micro-bursting (consequence of small buffers) before even close to platforms bps/pps limits.
More typically pps and bps affect you in low-end boxes running COTS CPU's, i.e. software-based boxes, like Cisco ISR, Juniper SRX branch or firewalls.

In very generic and rough terms, bps measures memory bandwidth and pps measures lookup performance ('CPU' speed)

Answer 4

Agree with the above statements, also know that every vendor fudges their stats a little bit. ie Enable PAT, simple firewall rules, access control lists, QOS and you will find these numbers can even halve some of the time - this is often due to the processing capacity of a network device and every service running on a network device requires a certain amount of CPU resources. PPS and BPS arent always the best stats to use.

When considering your upgrade, see what you are currently utilising. SNMP (Simple Network Management Protocol) can help you achieve this. Have room for growth by upgrading your environment to achieve less than %50 bandwidth on the current network utilisation on the new device and less than %40 CPU usage.