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

~975 ns

full-CGNAT path, measured

per-packet cost

commodity x86

no appliance, no lock-in

runs on servers you already buy

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 on a production gateway
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 of operating 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 from production gateways, sampled over three hours:

Gateway	Packet rate	Busy cores	Cores installed
A	2.29 Mpps	1.68	56
B	2.39 Mpps	9.46	44
C	0.54 Mpps	17.25	32

The counterintuitive result, reported as found. Across the sampled gateways, 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 fraction of Gateway A’s load 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; 7.x recommended (7.2.5 ships in the current image and is what we test on)
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	131,072 ceiling
Full integrated	CGNAT + firewall + QoS	131,072 ceiling

Both modes share the same architectural ceiling — 131,072 per node, the per-node map limit. We do not publish separate measured per-mode ceilings because we have not measured them; what decides your real number is busy-hour throughput, which on 2×100G at ~3 Mbps works out near ~64,000. Size against your own busy-hour figure. Flow cache hit rate runs around 90% on residential traffic patterns, which is what keeps per-packet cost in the hundreds of nanoseconds under load rather than in the microseconds. The one figure we publish is ~975 ns per packet on the full-CGNAT monolithic datapath, measured A/B/A′ under live production traffic on a single node (i40e) at roughly 41 million packets per arm — the A/B delta was −1.42 ns against a same-config noise floor of −1.92 ns, so it is a null result rather than a favourable one. We do not publish a QoS-only per-packet figure, because we have not measured one. That is the lighter program and would be faster, but a number we have not taken is not a number we will print.

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	production 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 figures are drawn from a three-hour sample of operating gateways and are reported without operator identifiers or subscriber totals. This brief describes BNGSOFT data-plane behaviour; internal component names and deployment details are omitted by design.