WTFast Headend SD-WAN
WTFast
Headend SD-WAN
A WTFast headend is SD-WAN for real-time traffic, delivered from your distribution point. Every subscriber session gets its own independently optimised route across our global relay network to wherever its destination actually is. On a 10-watt fanless appliance we held 693 households mid-game at the same time — each with a separate end-to-end optimised path, spread across more than 200 destinations worldwide, at 44,400 packets per second on under half of four Celeron cores. Because that is a peak concurrency figure, the subscriber base behind it is considerably larger. This page shows the measurements, the profiling behind them, and a calculator to size a headend for your own subscriber mix.
SD-WAN for real-time traffic, run at your edge.
A headend sits at your distribution point and terminates subscriber game traffic. From there it does not simply forward packets toward the public internet — it selects and maintains a separate optimised route for every session, across a global network of 229 relay servers, chosen for that session's specific destination.
This is the part worth being precise about, because it changes how the capacity numbers should be read. The 693 sessions in these tests were not 693 connections to one place. They were 693 unique proxied connections to more than 200 different target servers around the world, each with its own relay chain, its own path state and its own end-to-end optimisation, all running at once on one appliance.
Why this makes the numbers harder, not easier. A proxy holding many sessions to a single destination shares route state and warms one path. Here each session carries its own destination, its own relay chain and its own timing, so there is no shared work to amortise across them — and the load test drove all 229 relays simultaneously rather than a convenient subset. The measured figures on this page were produced under geographic fan-out, which is the realistic condition for a live deployment.
Optimised routing for every subscriber, with nothing in their home.
Because the intelligence sits in the headend rather than at the customer premises, there is no CPE to ship, install or support, and no per-subscriber configuration to maintain. A subscriber playing on a server in Frankfurt and one playing in Singapore are both routed optimally by the same box, without either of them doing anything.
For the operator this turns route quality into a service you provision centrally: one appliance at the distribution point, sized to concurrent active play, upgrading path selection for every gaming subscriber behind it.
No customer premises equipment
Nothing to ship or install, no truck rolls, no firmware to maintain in the field. Path selection happens at your edge, so improvements deploy centrally and reach every subscriber at once.
Per-session, not per-tunnel
This is not one aggregate tunnel with subscribers multiplexed inside it. Each session is routed on its own merits toward its own destination, which is why route quality holds up across a geographically scattered subscriber base.
A 64-byte packet costs about the same as a 1,400-byte packet.
CPU profiling of the headend under load put 45% of all CPU time in the UDP packet copy loop, and the dominant cost inside that loop is the syscall — the transition into the kernel to send or receive. That cost is paid once per packet and barely varies with packet size.
The practical consequence for an ISP: two services with identical bandwidth can differ by an order of magnitude in headend cost if their packet rates differ. Sizing from Mbps will give you the wrong answer in one direction or the other, depending on your game mix.
| Traffic profile | Sessions | pps / session | Total pps | CPU above idle | %CPU per 1k pps |
|---|---|---|---|---|---|
| MMO | 697 | 12 | 8,364 | +21.9% | 2.62 |
| Typical online game | 677 | 30 | 20,310 | +32.8% | 1.62 |
| Competitive FPS | 693 | 64 | 44,352 | +39.8% | 0.90 |
Why it improves. Fixed per-flow overhead amortises across more packets; the network poller finds more packets ready per wakeup; and flow state stays resident in cache. Per-packet cost fell roughly 2.9× between 8k and 44k pps — the headend becomes more efficient as it gets busier, which is a favourable property for an edge box with variable load. A separate test varied flow count 2.5× at constant packet rate and moved CPU by only four points: connections are close to free, packets are what cost.
Measured on hardware you would not call a server.
This is deliberately modest kit — roughly the class of appliance an ISP might place at a distribution point rather than in a datacentre. Everything in the next two sections was measured on it.
4 cores · 10 W TDP
GPNC headend, Go 1.24.6
UDP/TCP relay-chain routing
CPU, heap, goroutine
Four load states, as captured.
Load was generated by a purpose-built stress tool driving iperf3 against all 229 relays simultaneously, with packet rates calibrated to real game traffic classes rather than synthetic bandwidth figures. Every flow in these captures is a separate proxied connection to its own destination — the flow counts below are counts of independently routed sessions, not connections sharing a path. Pick a state to see the readings and the dashboard capture.
What a 10-watt box actually carries.
Extrapolated within the measured range to a 60% operating point, leaving headroom for spikes — which matters more than average utilisation when the traffic is latency-sensitive. These are simultaneous gamers at peak, so each figure represents roughly that many households mid-game at the busiest moment of the evening.
| Game class | Packet rate | Simultaneous gamers on 4 cores / 10 W |
|---|---|---|
| Competitive FPS | 64 pps | ~1,050 |
| Typical online game | 30 pps | ~1,300 |
| MOBA / MMO | 12–15 pps | ~1,600 |
Sizing follows peak concurrency, not headcount. Only a fraction of gaming households are mid-session at any one moment, so the subscriber base a headend can serve is several times the numbers above — the multiplier is your own peak concurrency ratio, and the calculator below lets you apply it. Idle and connected-but-not-playing subscribers cost almost nothing.
Every session is independently routed to its own destination, so a headend carrying 1,050 FPS gamers is maintaining 1,050 distinct optimised paths. Memory measured at roughly 200 KB per active connection, about 5,000 per gigabyte, returning cleanly to baseline when sessions end. At 693 flows the process held 171 MB of 15.5 GB — 1.1% of RAM. Sizing a headend is a CPU exercise; memory and disk are not constraints.
What we expect from a 32-core server.
These are estimates, not specifications. They scale the measured packet rate by core count and by an assumed 2.5× per-core improvement over the Celeron J4125 against a modern server core — an assumption that has not yet been verified on target hardware.
| Game class | Packet rate | Projected concurrent sessions | Basis |
|---|---|---|---|
| Competitive FPS | 64 pps | ~15,000 | Recommended external figure |
| Typical online game | 30 pps | ~33,000 | Same pps ceiling, lighter traffic |
| MOBA / MMO | 12–15 pps | ~66,000 | Same pps ceiling, lighter traffic |
All three rest on a projected ceiling of roughly 1,000,000 packets per second at a 60% operating point. Supporting evidence: work parallelised evenly across all cores with no serialised bottleneck, per-packet cost improves rather than degrades at higher rates, and memory is nowhere near limiting (15,000 sessions × 200 KB ≈ 3 GB). What has not been established is where the curve bends — the tested appliance never exceeded 44.8% CPU, and nothing has been measured above 693 concurrent flows. See the limitations at the foot of this page before you commit budget.
Size a headend for your subscriber mix.
Enter simultaneous gamers at peak by game class — the number mid-session at your busiest moment, not your total subscriber count. Set your own peak concurrency ratio to see the subscriber base that supports. Adjust the per-core assumption if you know the hardware you intend to buy.
The model derives packets-per-core from the measured high-rate operating point and applies a conservative derating, so a default run reproduces the published ~15,000 FPS figure on 32 cores. Peak concurrency is your number, not ours — WTFast has not published a concurrency ratio, and the default here is a neutral placeholder. Use your own measured evening peak. Game class matters more than subscriber count: an MMO player costs roughly a fifth of a competitive FPS player, so a capacity figure quoted without a traffic profile is not meaningful.
Real-time only. Patches and downloads stay off the headend.
The headend proxies real-time game communication — the small, frequent packets that carry player state and where latency is felt. Large bulk transfers such as game patches, updates and downloads are excluded from proxying and route normally, so headend sizing is unaffected by patch-day traffic and your transit costs are not duplicated.
This is also why packet rate rather than bandwidth is the sizing input. Once bulk transfer is excluded, what remains is almost entirely small packets at high frequency, and the byte count stops being informative.
The same headend, other real-time workloads.
Nothing in the proxy path is specific to games. It moves small packets with minimal added latency, and the same engineering applies to any traffic class where the tail, not the average, is what the customer feels.
Real-time AI
Voice agents · live inference · roboticsContinuous bidirectional streams at conversational packet rates. A dropped packet becomes a stall or a gap the model has to guess through — invisible on an average-latency dashboard, obvious to the person talking to it.
Virtual healthcare
Consults · remote diagnostics · guided proceduresClinical video runs on a hard jitter budget and the freeze always lands at the worst moment. As care moves toward remote guidance, connection quality becomes a patient-safety question rather than an IT ticket.
Critical real-time comms
Dispatch · trading · live production · field opsWhere seconds of freeze cost money, safety or dead air, operators buy private circuits to escape the public internet. A headend at the distribution point reaches the same outcome over connections they already run.
Put SD-WAN at your distribution point.
Optimised routing for every gaming subscriber behind it, with no equipment in their home. We will size a headend against your actual subscriber mix and share the raw test data and profiling behind every figure on this page.
WTFast for businessMulti Path, tested to failure.
We deliberately destroyed half the packets on a live game session to see what reached the game. Loss, jitter and RTT results from that run.
Read the Multi Path testMethod
- Hardware under test: Protectli VP2410, Intel Celeron J4125, 4 cores, 10 W TDP, 16 GB RAM, Ubuntu 24.04. Software: GPNC headend built on Go 1.24.6, performing UDP/TCP proxying with relay-chain routing across 229 relay servers.
- Load was generated by a purpose-built stress tool driving iperf3 against all 229 relays simultaneously, at packet rates calibrated to game traffic classes. Each proxied flow terminated at its own target across more than 200 destinations, so the measurements reflect geographically diverse per-session routing rather than repeated connections along one warm path. Measurement came from live
/procsampling for CPU, RSS, load average and flow count, with Gopprofused for CPU, heap and goroutine profiling. - CPU figures are aggregate across four cores. The idle floor of approximately 5% has been subtracted where "CPU above idle" is stated. Per-core distribution was within 1% across all four cores under load, spread over 8–9 OS threads with no single hot thread.
- Figures follow a round of optimisation work directed by profiling: the idle floor was reduced from roughly 14% to under 5%, per-packet cost roughly halved, and three memory retention defects in the session teardown path were fixed so RSS now returns to baseline within the flow-table idle timeout.
What has not been verified
- The 2.5× per-core assumption is untested. No measurement has been taken on 32-core hardware. Real figures could be materially higher or lower, and every projected number on this page moves with this one assumption.
- Nothing has been measured above 693 concurrent flows. Lock contention, scheduler behaviour and cache pressure at 15,000 flows are unknown. The projection assumes linearity across a 20× range that has not been exercised.
- The appliance never reached saturation. The highest measured point is 44.8% CPU. Capacity curves typically bend before they break, and where this one bends has not been established.
- The efficiency gain is measured only between 8k and 44k pps. Whether the trend continues, flattens or reverses at higher rates is not known.
- Multi Path has not been load-tested. Functional testing with a live game session confirms it works and routing is verified independently, but iperf3's UDP mode does not drive Multi Path correctly, so no capacity figures exist for it. Every measured number on this page is single-path; the 2× Multi Path option in the calculator is arithmetic, not measurement.
- Traffic profiles are modelled, not captured. The 12 / 30 / 64 pps figures are reasonable industry values for their game classes but were not measured from production traffic.
Projected figures are based on measured single-path performance, scaled by core count and expected per-core improvement, and are not yet validated on target hardware.