> ## Documentation Index
> Fetch the complete documentation index at: https://wireblast.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Reading the numbers

> Two bit rates, three conventions, and why your monitoring tool disagrees with both.

Wireblast shows two bit rates. They're both right, they measure different things, and the first time you compare them against a monitoring tool you'll get a third number. Here's the whole story, once.

## 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:

|                                                                                                     | 64-byte frame | IMIX (362 B avg) | Who reports it                            |
| --------------------------------------------------------------------------------------------------- | ------------- | ---------------- | ----------------------------------------- |
| **L1**: the frame plus its 7-byte preamble, 1-byte start-frame delimiter and 12-byte interframe gap | 84 B          | 382 B            | Wireblast, T-Rex `Tx bps L1`, DPDK pktgen |
| **L2**: the Ethernet frame itself, including its 4-byte FCS                                         | 64 B          | 362 B            | Wireblast, T-Rex `Tx bps L2`              |
| **L2 minus the FCS**                                                                                | 60 B          | 358 B            | the Linux kernel's counters               |

**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:

```text theme={null}
Bits/sec  L1                    916.66 Mbit/s
Bits/sec  L2                    868.65 Mbit/s
```

<Note>
  `--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.
</Note>

## 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:

| Pointed at                         | Counts                          | 512-byte frame | vs Wireblast's L2 |
| ---------------------------------- | ------------------------------- | -------------- | ----------------- |
| the physical NIC (`eno2`)          | frame minus FCS                 | 508 B          | 0.8% low          |
| a VLAN sub-interface (`vlan.2131`) | frame minus FCS, header and tag | 490 B          | 4.3% low          |

One steady run of 512-byte frames at 200 kpps, all four numbers taken at once:

```text theme={null}
wireblast          L1 851.02 Mbit/s      532 B/pkt
wireblast          L2 819.03 Mbit/s      512 B/pkt   <- the frame you asked for
bwm-ng eno2           813.0  Mbit/s      508 B/pkt
bwm-ng vlan.2131      784.3  Mbit/s      490 B/pkt
```

Point `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:

```bash theme={null}
--pps 1M                 # a million packets a second
--bps 2.5G               # 2.5 gigabit of L1
--pps 1M --bps 100M      # both; whichever is reached first wins
--pps unlimited          # line rate
```

The default is **100 kpps**, not line rate, so an accidental run doesn't saturate anything. Unlimited is always available; you just have to ask.

Asking for a `--bps` counts as asking: it lifts the default packet cap, since otherwise `--bps 1G` would quietly run at 100 kpps.

## What the counters mean

| Row                       | Meaning                                                                     |
| ------------------------- | --------------------------------------------------------------------------- |
| `Packets/sec`, `Bits/sec` | The current rate, sampled four times a second.                              |
| `Packets`, `Bytes`        | Totals for this run. `r` zeroes the visible ones; lifetime totals are kept. |
| `Avg frame`               | Bytes per frame. Constant for fixed sizes, about 362 for IMIX.              |
| `UDP` / `TCP` / `Other`   | Protocol breakdown of what was sent or received.                            |
| `Errors` (TX)             | Frames the kernel rejected, invalid descriptors and the like. Should be 0.  |
| `Drops/errors` (RX)       | Packets that arrived but couldn't be taken. This is the one to watch.       |

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:

```text theme={null}
! queue 3: rx ring full (1.2 k)
```

## 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:

```text theme={null}
--packet-size 64 is out of range for --mode udp with a VLAN tag; use 68-9018
(total Ethernet frame bytes, including the 4-byte FCS). The 64-byte Ethernet
minimum applies to the untagged frame, so a tagged one starts at 68: the NIC
pads anything smaller, and the reported rates would not match the wire
```

That last block is Wireblast's own error text, quoted as it prints. More on this in [VLAN-tagged traffic](/guides/vlan).