One 10 Gbps link carries about 812,000 full-size 1,518-byte Ethernet frames a second, or 14.88 million minimum-size 64-byte ones. That eighteen-fold spread at identical bandwidth is why packets per second (PPS) matters, and why a DDoS test reports packet rate as its own axis instead of deriving it from bits per second.
PPS counts how many individual packets a router, firewall, load balancer or host has to handle each second, whatever their size. (The figures include the 20 bytes of preamble and inter-frame gap every frame occupies on the wire.)
Why the per-packet ceiling arrives first
Most of the work a network device does is paid per packet, not per byte: a route or flow lookup, a rule match, a connection-table update, an interrupt or poll cycle, a buffer descriptor. Deciding on a 64-byte SYN costs about the same as deciding on a full-size frame. A device rated for 10 Gbps of large-packet throughput can therefore fall over at a small fraction of that bandwidth when the packets are tiny, and the headline figure on the datasheet, usually quoted with large or mixed packet sizes, does not say where.
Software paths show it most. A host pushing packets through the general-purpose kernel stack handles something on the order of one to a few million packets per second per core, so one 64-byte stream at 10 Gbps line rate already demands several cores doing nothing else. That is why kernel-bypass and XDP-style early filtering exist, and why protocol attacks such as SYN and ACK floods are sized in Mpps rather than Gbps.
Why it matters under attack
Capacity is bought and sold in bits. Transit commitments, scrubbing-service tiers and the headline figure on a firewall datasheet are all quoted in Gbps, while protocol floods are sized in Mpps. The two numbers rarely get compared until an incident compares them for you.
The usual mismatch is a throughput rating measured on large packets or an IMIX blend, with an average packet of a few hundred bytes, set against a 64-byte flood. A box that passes 10 Gbps of IMIX has been shown to handle somewhere around 3 Mpps. The same 10 Gbps of minimum-size packets is four to five times that, and nothing on the datasheet says what happens there. A scrubbing contract has the same gap: ask for the Mpps limit as well as the Gbps one.
Stateful devices pay twice. A firewall or load balancer that tracks connections does a connection-table lookup on every packet, and an insert for every new flow, so a spoofed-source flood consumes table entries as well as cycles. The table and the packet budget can run out together, and the device stops forwarding long before the link is full. For the attacker, small packets are the cheap way to get there: they pay for bandwidth, and the defender pays per packet.
What a DDoS test measures about it
A test separates the two ceilings, either by holding bandwidth constant and shrinking packet size, or by pinning packets at the minimum size and ramping the rate. It records:
- The PPS knee of each hop. The packet rate at which drops begin at the edge router, the firewall, the load balancer and the host. The lowest knee is the one an attacker will find.
- Where the drops land. NIC ring overflows (
rx_missed_errorsorrx_fifo_errorsinethtool -S), drops in the kernel's per-CPU backlog (/proc/net/softnet_stat), or a firewall CPU pinned at 100% while its interfaces sit half empty. - Collateral. Once the per-packet budget is gone, legitimate packets are dropped alongside attack packets, because the device no longer has the cycles to tell them apart. Real throughput falls while the bandwidth graph looks unremarkable.
The same reasoning applies to a server you own down to the network card, which bare-metal DDoS testing works through.