Skip to main content
“How fast can this go” is really three questions: how fast can the sender build packets, how fast can the NIC put them on the wire, and how fast can the far end take them. Wireblast can tell you which one you hit.

​
Ramp interactively

Start somewhere comfortable and use the hotkeys.
-d 0 runs until you stop it. Then:
  • + raises the rate 10%, - lowers it
  • g switches the graph between packets/sec and bits/sec
  • r zeroes the visible counters after each change, so you’re reading the new steady state rather than an average that includes the old one
Watch two things: whether actual keeps up with set in the header, and whether Errors starts moving.
When actual stops tracking set, you’ve found the limit.

​
Or jump straight to unlimited

Unlimited on an interface carrying your default route will starve the host’s own traffic, and Wireblast will make you confirm it. Do this on a test NIC.
Whatever comes back is the box’s ceiling for that frame size.

​
Frame size changes everything

Small frames are a packet-rate problem; large frames are a bit-rate problem. They fail differently, so test both:
If 1518-byte frames hit line rate but 64-byte frames don’t, you’re CPU-bound rather than link-bound. That’s the most common result on a first attempt, and it’s usually fixable.

​
Reading the failure

The sender can’t build packets fast enough. Try more queues:
Rates are aggregate, so more queues shouldn’t change the target, only whether the box can reach it. If --queues 1 and --queues 12 give the same number, adding cores isn’t your problem.Also check you got native XDP and zero-copy in the header. Generic mode or copy mode will cap you well below the hardware.
The kernel is rejecting descriptors. Usually the packet is bigger than the interface MTU, or bigger than a UMEM frame. Wireblast checks both before starting, so mid-run errors are worth investigating rather than ignoring.
You’ve found the receiver’s limit, not the sender’s. Per-queue detail appears under the dashboard:
“Ring full” means packets arrived faster than they were collected. More queues on the receiver is the first thing to try.
The path is dropping them: a policer, a shaper, a congested uplink, or a link that isn’t the speed you assumed. Neither end will show errors, because neither end is at fault. That’s the signature.

​
Isolating variables

The useful property is that a run is deterministic. The same flags produce the same packets in the same order, so you can change one thing at a time and trust the comparison.
Changing --pps, --duration, --flows or ports doesn’t require reattaching XDP, so in the TUI you can press e, change one number, and be running again in seconds. Changing --queues does force a reattach and another link bounce. Example 019 runs the queue sweep for you.

​
A reference point

Aggregate rate holds steady regardless of queue count. Measured on a 10G ixgbe NIC at --pps 1M: That’s what a working rate limiter looks like. If your numbers drift with queue count, something else is going on.

​
Line rate, for reference

10G, for the sizes above: L1 includes the preamble, start-frame delimiter and interframe gap, which is why 64-byte frames cap at 14.88 Mpps rather than 19.5. See reading the numbers.