Network stack
Nagle's algorithm (TcpAckFrequency and TCPNoDelay)
What Nagle actually does, and why disabling it is not a ping fix
Last updated
Does disabling Nagle's algorithm reduce ping?
Nagle's algorithm reduces network overhead by holding very small outbound TCP segments briefly so they can be combined. Delayed ACK holds acknowledgements for a short period for similar reasons. Together they can add tens of milliseconds to small, latency-sensitive TCP exchanges. Disabling them is a real, well-understood change -- but most competitive games send gameplay over UDP, where Nagle does not apply at all.
Registry location and values
TcpAckFrequency
- Location
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{adapter GUID}- Value name
TcpAckFrequency- Type
REG_DWORD- Default
- not present (behaves as 2)
| Value | What it does |
|---|---|
1 | Acknowledge every segment immediately, disabling delayed ACK. |
2 | Default behaviour: acknowledge every second segment, or after the delayed-ACK timer expires. |
TCPNoDelay
- Location
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{adapter GUID}- Value name
TCPNoDelay- Type
REG_DWORD- Default
- not present (Nagle enabled)
| Value | What it does |
|---|---|
1 | Disables Nagle's algorithm for this interface. |
0 | Nagle enabled. |
What Windows actually does with this
Nagle prevents a sender from having more than one small un-acknowledged segment outstanding, coalescing small writes into fewer packets. Delayed ACK, on the receiving side, waits before acknowledging in the hope of combining the ACK with outbound data. The pathological case is the interaction between them: a small send waits for an ACK that is itself being deliberately delayed, adding latency measured in tens of milliseconds.
What it affects
Latency of small TCP messages. The adapter GUID in the path is specific to your network interface; the correct one is the subkey containing your adapter's IP address.
Is it worth changing?
Legitimate for latency-sensitive TCP applications, and genuinely irrelevant for most gaming. Competitive titles send gameplay state over UDP, which Nagle does not touch. If your game's netcode is TCP, or you are chasing latency in a TCP-based application, this is a real setting with a real mechanism. If you are trying to lower your ping in a UDP shooter, it will do nothing, and the ping figure you are watching is dominated by distance to the server.
What can go wrong
Slightly higher packet counts and marginally more overhead. On a modern connection this is not a practical concern. The real risk is editing the wrong adapter subkey.
How to undo it
Delete both values from the interface subkey and restart. They are not present on a default install.
Create a System Restore Point before editing the registry. Every setting on this page is reversible, but a restore point is the difference between undoing one change and reinstalling Windows.
Which Windows versions this applies to
All modern Windows versions.
Nagle's algorithm (TcpAckFrequency and TCPNoDelay): common questions
How do I find the right adapter GUID?
Under the Interfaces key, each subkey is one adapter. Open them until you find the one whose IPAddress or DhcpIPAddress matches the address shown by ipconfig for your active connection.
Does my game use TCP or UDP?
Almost all real-time multiplayer gameplay is UDP, because retransmitting a stale position update is worse than dropping it. TCP is typically used for login, matchmaking, chat and patching.
Sources
Does JINSHI Tweaks change this?
This page documents settings that correspond to the following toggles in JINSHI PC Tweaks: Disable Nagle's Algorithm, Disable TCP Timestamps.
The reference above is written to be usable without the product. Everything here can be applied by hand for free. What the application adds is that the change is applied in one pass, a System Restore Point is created first, and each toggle can be reversed individually.