Performance & sizing · packet rate first · observed vs validated vs port capacity
Infrastructure Brief · Performance & Sizing
Packet rate is the number. Everything else is arithmetic.
Most BNG datasheets quote a headline Gbps and omit the frame size, which makes the figure unfalsifiable and useless to anyone specifying hardware. This brief states what the data plane does in packets per second with every feature enabled, and derives bit rate from frame size in the open — so you can check it with a calculator.
50 Mpps
full feature set
engine ceiling per box
33.6 Gbps
at 64-byte frames
the hardest test there is
~500 ns
cumulative, measured
per-packet cost
288,676
68 production gateways
live subscribers observed
One measured constant plus visible arithmetic beats seven unsourced headline numbers — because you can check it.
Three numbers that are not the same number
Conflating these is how vendor datasheets stop being useful. We keep them apart:
| Tier | What it means | Figure |
|---|---|---|
| Observed | Real subscriber traffic on a production gateway, not a test pattern. Tells you what a box carries in service. | 9 Gbps · 2.29 Mpps at 8,360 subscribers |
| Validated ceiling | The data plane’s limit under synthetic load with the full feature set enabled. Tells you the headroom. | 50 Mpps |
| Port capacity | Installed NIC bandwidth. An upper bound on the chassis — not a throughput claim. | 400 Gbps 2 × dual-port E810 |
Port capacity is not throughput. A box with 400G of ports fitted does not forward
400 Gbps of 64-byte frames — that would be 595 Mpps, which no x86 software data plane does.
400G is reachable, but only at large frames, where packet rate falls below the engine ceiling.
The table below shows exactly where that crossover sits.
Bit rate is a function of frame size
An Ethernet frame occupies its own length plus 20 bytes on the wire — 7 bytes preamble, 1 byte start-of-frame delimiter, 12 bytes inter-frame gap. So:
wire_bits = (frame_bytes + 20) × 8
Gbps = pps × wire_bits ÷ 1e9
64 B frame → (64 + 20) × 8 = 672 bits
50 Mpps × 672 bits = 33.6 Gbps
The whole page is this formula plus one measured constant.
| Frame size | Wire bits | Throughput at 50 Mpps | Limited by |
|---|---|---|---|
| 64 B (worst case) | 672 | 33.6 Gbps | packet rate |
| 128 B | 1,184 | 59.2 Gbps | packet rate |
| 256 B | 2,208 | 110.4 Gbps | packet rate |
| ~340 B (IMIX) | 2,880 | 144 Gbps | packet rate |
| 512 B | 4,256 | 212.8 Gbps | packet rate |
| ~980 B | 8,000 | 400 Gbps | crossover — ports saturate |
| 1518 B | 12,304 | 400 Gbps (capped) | port capacity |
How to read these figures (honest framing). The 50 Mpps ceiling is measured. Every Gbps
value in the table above is derived arithmetic from it — not an independent
measurement — and we label it that way deliberately. Subscriber figures assume roughly
3 Mbps per active subscriber at busy hour; substitute your own busy-hour average, because that
assumption moves the answer more than anything else on this page. The production fleet sample
covers three hours across 68 gateways: it is an observation, not a longitudinal study.
Why we lead with the 64-byte figure. 33.6 Gbps at 64 B with PPPoE, CGNAT, hierarchical QoS
and ACLs all enabled is the hardest test in this category. Most datasheets quote IMIX precisely
because 64 B full-features is where architectures fall over. If you are comparing vendors, ask
each one for their 64-byte number and what feature set was enabled when they measured it.
What production actually looks like
Synthetic ceilings tell you about headroom; they do not tell you what a gateway carries on a Tuesday evening. These are observations across a 68-gateway fleet, sampled over three hours:
| Gateway | Subscribers | Packet rate | Busy cores | Cores installed |
|---|---|---|---|---|
| A | 8,360 | 2.29 Mpps | 1.68 | 56 |
| B | 10,336 | 2.39 Mpps | 9.46 | 44 |
| C | 2,200 | 0.54 Mpps | 17.25 | 32 |
The counterintuitive result, reported as found. Across the fleet, subscriber count
correlates with traffic at +0.90, as expected. But subscriber count against CPU consumed
correlates at −0.16, and packet rate against CPU at −0.13. More
subscribers did not mean more CPU. Gateway C carries a quarter of Gateway A’s subscribers
and a fifth of its packet rate while burning ten times the cores. That is a configuration and
platform-tuning signal rather than a capacity signal — and it is the strongest argument
against sizing a BNG from subscriber count alone.
Sizing by hardware
Reference builds, with the NIC as the anchor:
| Build | NIC | Driver | CPU / RAM | Capacity | Subscribers | Power |
|---|---|---|---|---|---|---|
| Edge 1U | Intel X710-DA2 | i40e | 8-core, 32 GB | ~20 Gbps | ~6,700 | ~250 W |
| Standard 1U | Intel E810-CQDA2 | ice | 16-core, 64 GB | ~100 Gbps | ~33,000 | ~380 W |
| High-density 2U | 2 × E810-CQDA2 | ice | 2 × 16–24-core, 128 GB | ~200 Gbps | ~64,000 | ~650 W |
| SmartNIC 2U | ConnectX-6 Dx | mlx5 | 24-core, 128 GB | ~200 Gbps | ~64,000 | ~600 W |
Memory
Populate every channel
A packet-rate-bound data plane is memory-bandwidth sensitive. A CPU with half its channels filled gives up throughput that extra capacity cannot recover.
- 40G class — 32–64 GB, all channels populated
- 100G class — 128 GB, all channels populated
- State is modest: ~8 KB userspace plus BPF state per subscriber. Size for bandwidth, not tables.
Platform floor
Commodity x86, current kernel
- Kernel — 5.10 minimum, current 6.x recommended
- Architecture — x86-64 Intel or AMD; ARM64 in development
- Drivers — i40e, ice, ixgbe, bnxt_en, vmxnet3
- Bonding — 802.3ad LACP
Capacity modes
| Mode | Features enabled | Subscribers per box |
|---|---|---|
| QoS-only | Hierarchical shaping, no translation | 50,000+ |
| Full integrated | CGNAT + firewall + QoS | 30,000+ |
Flow cache hit rate runs around 90% on residential traffic patterns, which is what keeps per-packet cost near 500 ns under load rather than in the microseconds.
What we do not claim
| Headline Gbps without a frame size | No | Meaningless. A number without its packet size cannot be checked or compared. |
| Port capacity presented as throughput | No | 400G of ports is a chassis bound, not a forwarding result. |
| Derived values presented as measurements | No | The frame-size table is arithmetic from one measured constant, and says so. |
| Measured packet rate, full feature set | Yes | PPPoE + CGNAT + hierarchical QoS + ACL, all enabled. |
| Production observations, labelled as such | Yes | 68 gateways, three-hour window, reported with its limitations. |
Size it against your own traffic, not ours
Give us your subscriber count and busy-hour average per subscriber and we will work the arithmetic against your numbers rather than ours — then hand you a build to test on your own hardware, against real traffic.
Ask for the 64-byte full-feature result from every vendor you are evaluating. It is the question that separates measured platforms from marketed ones.
Frame-size arithmetic assumes standard Ethernet framing with 20 bytes of per-frame wire overhead
(7 B preamble, 1 B SFD, 12 B inter-frame gap). Throughput values in the frame-size table are
derived from the measured 50 Mpps ceiling and are not independent measurements. Subscriber counts
assume ~3 Mbps per active subscriber at busy hour and scale linearly with that assumption.
Production fleet figures are drawn from a three-hour sample across 68 gateways and are reported
without operator identifiers. This brief describes BNGSOFT data-plane behaviour; internal
component names and deployment details are omitted by design.