UDP-PPS stress test

Hammers your target with small 8-byte randomized UDP packets at very high packet-per-second rates to validate the limits of packet processing, not just bandwidth.

Run UDP-PPS test → All methods

600k pps

peak packet rate

How it works

Rather than chasing raw gigabits, this method maximizes the number of distinct packets per second using tiny 8-byte randomized payloads. High PPS stresses the parts of the stack that work per-packet: NIC interrupt handling, the kernel network path, firewall connection tables, and scrubbing-appliance lookups. It is the right test for confirming whether your forwarding plane and mitigation hardware can keep pace when the bottleneck is packet count rather than throughput.

Parameters

Packet rate600k ppsPrimary tunable, packets per second per thread

Payload bytes8 bytesSmall randomized payload to keep packets minimal

Threads1-16Parallel senders to scale aggregate PPS

Duration10-600 sTest window length

Run it from the CLI

retro-cli

$ retro run udp-pps --target 203.0.113.45 --port 443 --duration 120

UDP-PPS FAQ

How is a PPS flood different from a bandwidth flood?+

A bandwidth flood saturates the link with large packets, while a PPS flood overwhelms per-packet processing using many small packets. A device can have plenty of spare bandwidth and still collapse under high PPS because each packet costs CPU, interrupts, and table lookups.

Why does this method use 8-byte payloads?+

Tiny payloads keep each packet near the minimum size so more packets fit in the same bandwidth budget, pushing the PPS rate as high as possible. The goal is to test packet handling, not to fill the pipe.

What should I watch on the target during a PPS test?+

Track CPU on the network path, interrupt and softirq load, firewall state-table utilization, and any drops reported by the NIC or scrubbing layer. Those are the first resources to exhaust under high PPS.