Network Quality Ultra Is Eating Your Dedicated Server CPU
A recurring report from Satisfactory dedicated server admins in 2026: laggy projectiles, players getting attacked in vehicles, late-game vehicle stutter, even on hardware like an i5-12400F with the world still in early game. The most common root cause is the Network Performance setting being left on Ultra. Ultra is a default that assumes server-grade Xeon or Ryzen 9 hardware, not the mid-tier desktop CPUs that most home-hosted and managed-plan dedicated servers actually run on.
What Network Performance actually does
In the server admin panel and the Server Settings menu, Network Performance has four values: Ultra, High, Medium, Low. The setting controls how often the server recalculates and replicates entity positions, projectile arcs, vehicle physics, and player input acknowledgements to clients. Higher values = smoother visual updates for clients, but linear CPU cost on the server. The setting is single-thread-bound because Satisfactory's network replication runs on one core.
Coffee Stain's in-game description even hints at this ("higher quality requires more server CPU"), but the warning is easy to miss because the option defaults to Ultra in fresh installs.
The CPU cost ladder
| Setting | Tick rate target | Approx. CPU cost | Recommended hardware | Player count it scales to |
|---|---|---|---|---|
| Ultra | 60 Hz | Baseline (very high) | Modern Ryzen 9 / i9, 5GHz+ single-core | 4 players, late-game factories |
| High | 45 Hz | ~70% of Ultra | Ryzen 7 / i7, 4.5GHz+ | 4 players, mid-game |
| Medium | 30 Hz | ~50% of Ultra | Ryzen 5 / i5, 4.0GHz+ | 2-4 players, any phase |
| Low | 20 Hz | ~33% of Ultra | Older or shared hardware | 2 players, light load |
The i5-12400F report mentioned at the top of this article maps to Medium territory. Players run it on Ultra, factory complexity grows, vehicles + projectiles + thrall AI all spike together, and the single replication core saturates. The visual symptom is laggy projectiles and missed vehicle-immunity for players, even though the FPS counter on the client looks fine.
The diagnostic flowchart
- Check the server tick rate. Open the server console (~) or read the FactoryGame.log for
NetServerTickvalues. If you're gettingNetServerMaxTickRatedrops below the setting's target (Ultra targets 60, you're seeing 35), the setting is too high for your CPU. - Look at single-core utilization on the server.
top -p $(pgrep FactoryServer)or Task Manager → right-click the FactoryServer process → Set affinity → observe one core pegged at 95-100% while others sit at 5-15%. - If one core is pegged AND tick rate is below the target, drop one tier (Ultra → High, or High → Medium) and restart the server. Compare for 30 minutes.
- If dropping a tier reduces the saturated core to 75-85% and tick rate stabilizes at the new target, you've found your CPU's ceiling.
Engine.ini fine-tuning
Once you've picked the right tier, you can extract another 10-15% headroom by tuning MaxInternetClientRate in ConanSandbox/Saved/Config/WindowsServer/Engine.ini (or the Linux equivalent). The default is 10 MB/s per client which is wasteful on most home connections.
[/Script/Engine.NetworkSettings]
NetServerMaxTickRate=45 ; matches the High tier; lower if you went to Medium
MaxInternetClientRate=104857600 ; community-tested value for stable hosting
MaxClientRate=104857600
RelevantTimeout=5.0 ; how long a client can be silent before disconnect
SpawnPrioritySeconds=2.0 ; lower latency on freshly-spawned itemsThe 104857600 figure (100 MB/s) comes from community testing reported across multiple dedicated server troubleshooting threads. It's much higher than typical client need but eliminates "client rate clamp" stalls during burst factory updates. Don't lower it below 10 MB/s.
Hardware-side workarounds for stubborn lag
Beyond the in-game setting, two physical/driver-side tweaks routinely help home-hosted servers:
- Disable Large Send Offload in your ethernet adapter's advanced settings. This is reported as the single biggest network-side fix by multiple admins running mid-tier desktop CPUs. Device Manager → Network adapters → right-click your NIC → Properties → Advanced → Large Send Offload v2 (IPv4 and IPv6) → Disabled.
- Disable energy-efficient ethernet, green ethernet, and flow control on the same adapter properties tab. These three options interact badly with the burst replication pattern Satisfactory uses.
- Disable IPv6 on the NIC if you don't use it. Satisfactory's network code occasionally double-resolves which adds latency.
Set affinity to bind the FactoryServer process to specific physical cores (not hyper-threaded logical cores). On Windows, Task Manager → Details → right-click FactoryServer.exe → Set affinity. On Linux, taskset -p <cpu_mask> $(pgrep FactoryServer).
When Ultra is actually fine
If you're running on managed hosting from a provider with modern Ryzen 9 / EPYC hardware (typically 4.5GHz+ all-core boost), or on a dedicated bare-metal box with similar specs, you can leave Network Performance on Ultra and not worry about it. The single-thread budget is large enough to handle late-game factories at 60Hz tick.
The setting being wrong matters most for home-hosted servers on consumer desktop CPUs and for budget VPS plans where the underlying CPU is shared with other tenants.
Related troubleshooting
- Connection & authentication fixes
- Server performance optimization
- Linux late-game optimization
- Unreal Engine crash troubleshooting
Tired of single-core CPU math? Supercraft's Satisfactory hosting ships on 4.5GHz+ single-thread hardware tuned for the dedicated-server workload, with Network Performance correctly defaulted for the plan size. Plans from $7.99/mo.