We benchmarked Neurowall's fast packet filter using a kernel-native testing tool at 256-byte packets — the size most FPS titles actually send — across every filtering mode and traffic scenario, so game studios and hosting providers can pick a configuration with real numbers instead of guesswork.
Results come from Neurowall's throughput_benchmark tool, which drives the compiled
filter engine directly via a kernel-native testing facility — the same code path that
runs in production, exercised with no network hardware, NIC drivers, or virtualization overhead in the
measurement loop itself.
prefilter_only, prefilter_rules, prefilter_ddos, prefilter_ddos_rules, and prefilter_rules_ddos — each a different combination of enabled filtering steps.
rules_miss (no match, worst case for rule evaluation), rule_hit, blocklist_hit, and complex_config (large ruleset) — 20 measured configurations in total.
Chosen because it's the dominant packet size for FPS titles like CS2, Valorant, and Call of Duty — the largest and most latency-sensitive segment of the competitive gaming market.
Each configuration processes 10,000 packets through the real compiled program; wall-clock time is measured directly by the kernel test harness, not sampled or estimated.
128-byte (mobile) and 512-byte (MMO/MOBA) figures on this page are directional estimates based on observed packet-size latency scaling (roughly ±10% per 256-byte step), not separately measured runs. We show them for planning purposes and label them clearly as estimates below.
"rules_miss" is the traffic scenario where a packet doesn't match any rule — the most CPU-expensive path since the full ruleset must be evaluated before a default verdict. This is the scenario to plan capacity around.
| Profile | rules_miss | rule_hit | blocklist_hit | complex_config |
|---|---|---|---|---|
| prefilter_only | 0.9046 μs | 0.9149 μs | 0.9047 μs | 0.9173 μs |
| prefilter_ddos | 0.9400 μs | 0.9367 μs | 0.9478 μs | 0.9388 μs |
| prefilter_ddos_rules | 0.9366 μs | 0.9312 μs | 0.9338 μs | 0.9363 μs |
| prefilter_rules | 1.0242 μs | 1.0113 μs | 1.0000 μs | 0.9898 μs |
| prefilter_rules_ddos | 1.0378 μs | 1.0332 μs | 1.0334 μs | 1.0410 μs |
Directional estimates based on ±10% latency scaling per 256-byte step, applied to the measured 256-byte figures above. Treat these as planning guidance, not guaranteed numbers — always validate on your own traffic mix before committing to a profile.
| Game Type | Packet Size | Est. Latency | Recommended Profile |
|---|---|---|---|
| Mobile games | 128 bytes | ~0.81–0.85 μs | prefilter_only — lightweight, matches low CPU budget on mobile backends |
| FPS (CS2, Valorant, CoD) | 256 bytes | 0.90–1.04 μs (measured) | prefilter_ddos_rules — balanced protection, ~0.94 μs |
| MMO / MOBA (WoW, FFXIV, LoL) | 512 bytes | ~1.00–1.14 μs | prefilter_rules_ddos — full ruleset for larger, richer traffic |
| Minecraft (Java/Bedrock) | 256–512 bytes | ~0.90–1.14 μs | prefilter_ddos_rules — balanced protection; UDP/TCP on ports 25565–25575, <100ms RTT target tolerates the full profile range |
Minecraft is not separately benchmarked yet — the range above is interpolated from the measured 256-byte and estimated 512-byte figures, since Minecraft's packet sizes vary by activity (chunk/world data is larger, player-action packets are smaller) and it tolerates a higher RTT target (<100ms) than competitive FPS titles. We'll publish a dedicated measured run here once available.
prefilter_only — the lightest profile at ~0.90 μs, ideal where server-side CPU is shared across many concurrent low-bandwidth connections.
prefilter_ddos_rules — balanced protection at ~0.94 μs, combining DDoS mitigation with rule enforcement without the full-rules latency cost.
prefilter_ddos or prefilter_ddos_rules — fastest DDoS-focused profiles (~0.94 μs) for infrastructure that needs flood protection without a large custom ruleset.
prefilter_rules_ddos — the complete profile at ~1.04 μs, for gateways that need both a full custom ruleset and DDoS protection, where the ~0.1 μs premium is negligible against network RTT.
Run different profiles per tenant based on their game type — Neurowall's per-node licensing means switching profiles doesn't change your cost structure.
The benchmark script and methodology are available for hosting providers and studios who want to validate results against their own kernel version and hardware.
If you've compared firewall vendors before, you've likely run into one of these measurement gaps — each one makes a number look better than what you'll actually experience.
| Common measurement practice | Why it misleads for game servers |
|---|---|
| Round-trip / network benchmark (client → server → client) | Bundles physical network latency, NIC hardware, and OS scheduling jitter together with firewall processing time — you can't isolate what the security layer itself costs |
| 64-byte "line rate" packet benchmarks | Standard network-equipment test size, but far smaller than the 128–512 byte packets game servers actually send — a firewall's per-byte parsing cost doesn't show up at 64 bytes the way it does at real sizes |
| Best-case scenario only (rule_hit or no ruleset loaded) | Skips the worst-case path (an unmatched packet evaluated against a full ruleset) — exactly the scenario a real deployment with an active policy runs constantly |
| Marketing "up to X Gbps" headline numbers | Throughput at large packet sizes doesn't translate directly to per-packet latency at small, gaming-typical packet sizes — the numbers answer a different question than "how much delay does this add to a player's shot" |
Our numbers isolate the filter engine's own processing cost using a kernel-native testing tool, at the packet size that matters (256B for FPS), across the worst-case scenario (rules_miss) as well as best-case — so you're comparing the actual cost of the thing you're evaluating, not a number shaped to look good.