UDP Packet Loss Concealment and Forward Error Correction (FEC): Competitive Benchmark Analysis and Hårdvara Interactions

[Sebastian Phillips]

I’ve been running controlled benchmarks on UDP-based netcode with FEC enabled, and I’m seeing some interesting interactions between redundancy overhead and frametime stability that I can’t fully reconcile. When I bump the redundant state packet ratio above a certain threshold, my 1% lows degrade even though packet loss drops—so there’s clearly a tradeoff curve I’m trying to map precisely. Has anyone here measured the exact header overhead percentage where FEC stops being net positive for low-loss wired connections, and how did you isolate that breakpoint empirically?

I’m also curious about burst loss recovery behavior under real-world conditions. My lab tests use uniform random loss, but actual network congestion produces clustered drops, and I’m not sure my concealment algorithm handles those well. How are you modeling burst patterns in your test harness, and what concealment window length are you using to interpolate missing state without introducing visible rubber-banding?

On the hardware side, I’ve noticed FEC CPU overhead scales differently across cores depending on whether we’re using vectorized instructions. Which CPU generation are you running your benchmarks on, and did you see meaningful single-thread performance differences that would matter for a competitive 240Hz setup?

"Beyerdynamic DT 770 Pro (80 Ohm) + Focusrite Scarlett Solo Gen 4"

[Ella Brooks]

Great topic. The key thing most people miss is that UDP is chosen for competitive titles precisely because retransmission latency is worse than an occasional lost packet. In a fast-paced shooter, waiting for a NAK/retrans cycle can add 30-50ms of input delay, which is a dealbreaker. So the question isn’t “how do we eliminate packet loss” but “how do we minimize its perceptible impact while keeping latency flat.” That’s where PLC and FEC each play a distinct role. PLC (interpolation, last-packet repeat, or simple muting) masks the gap after the fact—cheap and latency-free, but you’re stuck with whatever fidelity the algorithm produces. FEC, on the other hand, lets the receiver reconstruct lost packets on-the-fly without any round-trip, so it’s strictly better for the packets that actually matter (input state, hit registration), but it burns bandwidth and CPU. My take: run forward FEC at a modest redundancy level (8-15% is a reasonable sweet

"⚠️ When asking for FPS/stutter troubleshooting, please include your exact RAM specs and PSU model!"

[Author]

Posts