Packet size includes the FCS
The most important definition in the tool:--packet-size is the whole Ethernet frame, including the 4-byte frame check sequence.
So --packet-size 64 is the classic 64-byte frame, and 64-byte frames at 10G line rate is the familiar 14.88 Mpps. Wireblast writes 60 bytes into each buffer and the NIC appends the FCS.
Three ways to count bits
For every packet:
L1 is link utilisation. A 10G link carries 10 Gbit/s of L1 and nothing more, whatever the frame size. That’s exactly why 64-byte frames top out at 14.88 Mpps rather than 19.5. If you’re asking “am I filling the pipe”, L1 is your number.
L2 is the frame you asked for,
--packet-size bytes of it. If you’re asking “how much payload moved”, L2 is closer.
Both are always on screen, labelled:
--bps is measured in L1. So --bps 10G means 10G line rate, which is what people mean when they say it, and it’s the only definition under which small frames can saturate a 10G link.Why bwm-ng disagrees with both
Because it reads the kernel’s byte counters, and what those count depends on which interface you point it at. Measured against a receiver’s/sys/class/net/*/statistics/rx_bytes while sending known packet counts:
One steady run of 512-byte frames at 200 kpps, all four numbers taken at once:
bwm-ng at the physical NIC and it lands just under L2, short by the 4-byte FCS that the kernel excludes by specification. Point it at a VLAN sub-interface and it drops another 18 bytes, because by then the kernel has stripped the Ethernet header and the tag.
Neither is wrong. They’re counting different things at different layers. The gap is about 6% at 64-byte frames and about 1% at IMIX, so it’s most visible exactly where people do their small-frame testing.
iftop, nload, ifstat and ip -s link all read the same counters and behave the same way.
Rates are aggregate
--pps 1M is a million packets per second in total, whether Wireblast is using one queue or twelve. Measured across 1, 4 and 12 queues on a 10G ixgbe NIC: 999.34, 999.35 and 999.44 kpps.
Both limits can be set at once, and the slower one binds:
--bps counts as asking: it lifts the default packet cap, since otherwise --bps 1G would quietly run at 100 kpps.
What the counters mean
Drops on the receive side mean the RX ring filled up faster than Wireblast emptied it. That’s a real signal: the far end is sending faster than this box can absorb. Per-queue detail shows up under the dashboard:
One catch with tagged frames
The 64-byte Ethernet minimum is measured on the untagged frame, so a tagged frame can’t be smaller than 68 bytes. The NIC pads anything less. Verified on ixgbe:--packet-size 64, 66 and 68 with --vlan all left as 68-byte frames.
Wireblast therefore requires --packet-size 68 or more when --vlan is set, rather than accepting 64 and then reporting rates 6% below what’s actually on the wire: