On this page
Key points
- Record both dimensionsGbit/s measures bits per second; packets/s measures the number of packets handled.
- State the measurement boundaryAn IP-byte counter, an Ethernet-frame counter and a wire-rate estimate are not interchangeable.
- Keep evidence with the numberFrame sizes, direction, enabled features and observed loss make a result interpretable.
Two counters describe different demands on the network
Gbit/s expresses a rate of bits, while packets/s counts packets over time. A link carries bytes, but a forwarding or filtering path also does work for each packet. Parsing, lookups, queues, counters and state handling contribute to that work. Packet size therefore matters when comparing two traffic patterns.
Record the interval and direction for each value. A one-second receive peak cannot be compared directly with a five-minute average of both directions. An aggregate across multiple links may count traffic more than once as it crosses the network. Before attributing an incident to capacity, establish what the graph is counting.
Low bandwidth does not by itself exclude a packet-processing bottleneck. High bandwidth does not by itself prove that CPU work is the bottleneck either. Correlate rates with drops, queue pressure and application behavior at the relevant boundary.
Use a stated frame definition for conversion
The Peeryx packet-rate calculator uses an Ethernet frame length that includes FCS, then adds 20 byte-times for preamble, start-frame delimiter and inter-frame gap. With that convention: PPS = bits/s ÷ [8 × (frame bytes + 20)].
That is wire-rate arithmetic for the stated frame size, not the application payload rate or the result of a hardware test. An IP-layer byte counter may omit Ethernet headers and FCS. A packet capture may also omit FCS or show packets affected by offloads. Do not apply the formula to an unexplained counter and treat the answer as a measurement.
VLAN tags, encapsulation and a mixture of packet sizes change the accounting. Keep the definition beside the number and use a representative distribution when planning real traffic. A single average size can obscure short periods dominated by small packets.
Two hypothetical examples, with reproducible arithmetic
These are calculation examples, not customer incidents or Peeryx performance measurements. At 10 Gbit/s, 64-byte Ethernet frames use 84 byte-times each under the stated convention: the theoretical rate is about 14.88 million frames per second. At the same bit rate, 1,518-byte frames use 1,538 byte-times each and produce about 0.81 million frames per second.
The smaller-frame stream therefore contains about 18.3 times as many frames at the same wire bit rate. That ratio does not predict an identical increase in CPU usage: implementation, enabled features, traffic distribution and hardware matter. It does show why a bandwidth figure alone is insufficient for comparing workloads.
For another hypothetical comparison, 12 million 64-byte frames per second account for 8.064 Gbit/s on the wire under this convention. If a graph reports another value, first compare sampling, direction and byte-accounting boundaries. Do not invent a device limit to force two unlike counters to agree.
| Hypothetical wire rate | Ethernet frame including FCS | Frame plus 20 byte-times | Theoretical rate |
|---|---|---|---|
| 10 Gbit/s | 64 bytes | 84 byte-times | 14.88095 Mpps |
| 10 Gbit/s | 1,518 bytes | 1,538 byte-times | 0.81274 Mpps |
| 100 Gbit/s | 64 bytes | 84 byte-times | 148.80952 Mpps |
Locate the first constrained part of the path
Compare upstream link use, physical-interface drops, NIC queue counters, forwarding resources and application symptoms over the same interval. If traffic is lost before it reaches the host, an application setting cannot recover those packets. If a particular queue is overloaded while a link has room, a larger port alone may not address that queue.
Average CPU utilization can hide an uneven distribution. Review per-core or per-queue evidence where available and identify which receive path is in use. RSS and related Linux mechanisms distribute work differently; a change must fit the driver, virtual or physical NIC and application. More queues do not automatically produce a better result.
New connections, fragments and traffic that triggers expensive policy can create pressure that a basic packets/s value does not fully describe. Keep active features and traffic characteristics in the incident record. A number measured with filtering disabled is not a filtering-capacity result.
Choose mitigation where it can relieve that constraint
If an upstream link is the constraint, traffic must be reduced before that link to preserve usable capacity. Local filtering can still serve a separate role, but it cannot carry packets through a saturated upstream path. Protected transit and on-demand diversion need their own delivery and activation conditions.
If packet-processing work is the constraint, examine where unnecessary work can be avoided and what the legitimate traffic requires. Early filtering, a simpler policy path or a different distribution of work may help, but each option needs a measured acceptance test. A rule that removes many packets can also remove legitimate traffic if its scope is wrong.
Defense Fabric is software for compatible operator-controlled equipment; its licence and port declarations are not a universal Mpps benchmark. The local server, enabled features and network path determine what must be validated. Distinguish this from shared provider network capacity when comparing offers.
Write a test plan that keeps the result interpretable
Use an isolated, authorized environment for overload benchmarks. RFC 6815 explicitly limits the use of RFC 2544 methods on production networks. Routine service observation and an approved application acceptance check have a different purpose from driving a device to loss.
Record the equipment and software versions, direction, offered and received traffic, frame sizes or distribution, flow diversity, active policies, run duration and observed loss. Retain application outcomes alongside network counters. State what was not tested, including any host, link or failover dependency.
A repeatable result supports a specific configuration under stated conditions. A port label, a single short run and a theoretical conversion support narrower conclusions. Keep those distinctions visible when using measurements for procurement or a capacity plan.
Avoid conclusions that the counters cannot support
- Do not compare an IP-byte rate with an Ethernet wire-rate estimate without reconciling the boundaries.
- Do not add receive and transmit rates and present the result as one-way forwarding capacity.
- Do not infer a small-packet result from a large-packet benchmark, or a filtering result from unfiltered forwarding.
- Do not describe a worked example as an observed customer incident or a measured software result.
- Do not assume that a larger port fixes a queue, state-table or application bottleneck.
Questions about packet rate and protection capacity
Is a higher Mpps number always better protection?
Only comparable measurements can support that comparison. Check traffic size and mix, direction, features, loss and test conditions. A theoretical wire-rate ceiling and a measured filtering result answer different questions.
Can I convert Gbit/s to Mpps without a packet size?
Not to a single meaningful value. You need a size or distribution and a clear byte-accounting convention. Use a range of relevant sizes if the real distribution is unknown.
Does the calculator measure my server?
No. It performs transparent arithmetic from the values you enter. Server and filtering capacity require separate measurements with a stated configuration and acceptance criteria.
