How I Reduced Gaming Latency by 192ms on a Locked ISP Network
🔗 Project Repository
GitHub: https://github.com/SoumyaKhaskel/Network-router-optimization.git
Most gaming setup posts focus on GPU, RAM, or CPU tuning.
This one is about the part people usually ignore: the network path.
I worked on a single NAT home network with an ISP-locked ONT and limited router access, then documented every change with before/after testing. The goal was simple: reduce latency spikes, stabilize the connection, and improve responsiveness for CS2 and Valorant.
What I was dealing with
The setup had a few hard constraints:
ISP-locked main gateway
No custom firmware support on the existing router hardware
No proper port-forwarding control from the admin panel
Windows 11 Home, so no Group Policy editor for QoS
Bufferbloat on the download side under load
That meant the fix had to be practical, measurable, and done mostly from the OS side.
Baseline testing first
Before changing anything, I measured the network.
A few key baseline findings:
Google DNS averaged around 43ms
Cloudflare DNS averaged around 4–5ms
Fast.com showed idle latency of 3ms but loaded latency of 64ms
Waveform bufferbloat testing confirmed download-side bufferbloat
The peak download ping was high enough to fail low-latency gaming thresholds
That gave me a clear starting point. No guessing. Only data.
What I changed:
1) Switched DNS to Cloudflare
The DNS tests made the decision obvious. Cloudflare was much faster than the ISP default, so I configured 1.1.1.1 / 1.0.0.1 directly on the Windows adapter, including IPv6, to avoid fallback to the ISP resolver.
2) Locked the gaming PC to a static IP
DHCP changes were a problem for consistency, so I set a manual static IP on the Windows Ethernet adapter. That made the machine easier to target for QoS and kept the address stable across reboots.
3) Verified MTU
I checked MTU using the DF flag ping method and confirmed MTU 1500. No fragmentation changes were needed.
4) Applied DSCP 46 QoS for game traffic
For real-time UDP traffic, I applied DSCP 46 (Expedited Forwarding) for CS2 and Valorant through Windows registry-based QoS policy entries, since Windows 11 Home does not provide the usual Group Policy path.
5) Tuned the TCP stack
I used TCP Optimizer to improve the Windows TCP stack behavior for latency-sensitive traffic. One setting, TCP Chimney, caused upload latency spikes on my NIC, so I reverted it after testing. That part mattered: I kept only what was actually stable.
What did not work
Not every route was available.
The router hardware did not support the firmware path I wanted
The ISP ONT was locked
Port forwarding was blocked by the admin panel
Router-level DNS changes did not fully apply as expected
That is normal in real-world consumer networking. The important part is documenting the ceiling, not pretending it does not exist.
Results
The improvements were measurable:
Google DNS max spike dropped from 228ms to 36ms
Google DNS average dropped from 45ms to 32ms
Download-side bufferbloat improved from 41ms spike to 34ms
Peak download ping dropped from 82.4ms to 57.49ms
The network was better after optimization, but the remaining bufferbloat was still limited by ISP hardware. That meant the final fix would require a compatible router with SQM support, not just software tuning.
Main takeaway
The biggest lesson was this: If download latency spikes while upload stays clean, the bottleneck is often inside the ISP hardware.
You can still improve performance from the OS side, but there is a hard ceiling when the modem/ONT cannot be controlled.
What I learned
DNS choice can make a real difference depending on location
DSCP 46 is the correct priority class for time-sensitive UDP traffic
MTU should be verified, not assumed
TCP tweaks should always be benchmarked
Static IP at adapter level is often more reliable than router-side reservation in locked environments
Bufferbloat fixes are limited if the ISP hardware cannot be replaced.
Top comments (0)