FIXED All VNC Apps Slow on All Windows Due to NIC Offloading Features
Huge confusion still exists, decades on, regarding this increasingly awful issue
TightVNC was almost unusably slow on 1 Gb LAN with nearly pixel-by-pixel updating!
Culprit was discovered to be various “offloading features” of modern NICs and network stacks in Windows. Disabling all “offloading features” inverted unusable to blink-fast. Here’s how.
Conflict Between TCP Checksum Offload and VNC
TCP checksum offload (and similar features) can sometimes cause problems with certain network protocols, such as Virtual Network Computing (VNC), due to the way offloading interacts with packet processing. Let’s break down why this happens and the nature of the conflict:
Overview of VNC
VNC is a remote desktop protocol that allows users to interact with a graphical interface on a remote computer. It sends screen updates, keyboard, and mouse input between the VNC server (on the remote machine) and the VNC client (on the local machine). VNC relies on the underlying TCP/IP stack for data transmission, including reliable delivery and error-checking mechanisms like TCP checksum verification.
Conflict with TCP Checksum Offload
- Checksum Validation Issues:
- When TCP checksum offload is enabled, the NIC handles the calculation and verification of checksums instead of the operating system’s TCP/IP stack. This works well for most applications, but in some cases, the interaction between the VNC software and offloading features can cause problems.
- Misleading checksums: The issue arises because the operating system’s TCP/IP stack may still perform some operations on packets before they are sent out or after they are received (e.g., modifying headers). However, when checksum offloading is enabled, the NIC hasn’t yet computed the actual checksum at the time the VNC application inspects the packet. This can lead VNC to see packets with incorrect or incomplete checksums, which may cause VNC to think the packet is corrupted.
- Dropped or corrupted packets: If the NIC offloads checksum computation incorrectly or the application sees “bad” checksums (when in fact they are not bad, just offloaded), this can result in the VNC client dropping packets, retransmitting them, or experiencing display and input lag.
- Fragmentation and Reassembly Issues:
- VNC, being highly interactive, sends frequent and sometimes small packets that must be reassembled at the client. Offloading features like TCP segmentation offload (TSO), in conjunction with checksum offload, can sometimes mishandle this reassembly, causing packet fragmentation and display inconsistencies.
- For VNC, small disruptions or slight packet losses can result in significant user-perceived issues like screen freezing, missing updates, or unresponsive input, due to its sensitivity to real-time data transmission.
- VNC’s Reliance on Low-Latency Networking:
- VNC is a low-latency application that demands quick, real-time transmission of packets. TCP offloading features are designed to optimize large data transfers (like file uploads or downloads) but can introduce slight delays or inconsistencies in processing smaller, interactive packets that VNC relies on.
- In cases where offloaded checksum calculations cause packets to be delayed, out of order, or even dropped, VNC’s performance suffers noticeably, making the experience sluggish or unstable.
- Issues with Virtualization and Bridging:
- Many VNC deployments run in virtualized environments (like virtual machines). When VNC is used in such scenarios, offloading features may conflict with virtual network interfaces (vNICs) or network bridging setups. The offload features may not be fully supported in virtual environments, leading to packets that are misinterpreted by the virtual network stack, compounding the issues VNC faces with offloading.
Similar Conflicts with Other Features
TCP checksum offload is just one feature that can cause conflicts with VNC. Other offload features that can similarly affect VNC include:
- TCP Segmentation Offload (TSO): This offloads the task of breaking large chunks of data into smaller TCP segments. While this helps with network throughput in general, for VNC’s frequent small packets, it can result in improper segmentation, packet reordering, or delays.
- Large Receive Offload (LRO): LRO combines multiple incoming packets into a larger one before passing them to the OS. For VNC, which depends on many small packets for real-time performance, LRO can cause delayed updates and increased latency.
- Receive Side Coalescing (RSC): This feature combines multiple incoming frames into a single larger frame. Just like LRO, this can lead to delays and out-of-order processing of VNC’s packets.
Mitigating the Conflict
To mitigate these issues, many users opt to disable TCP checksum offload (and other offload features) when using VNC or other latency-sensitive applications. Here’s how this can be done:
- Disable TCP Offload in the NIC settings:
- On Windows:
- Open Device Manager.
- Go to the properties of the NIC.
- In the “Advanced” tab, look for options like “TCP Checksum Offload,” “TCP Segmentation Offload,” “Large Receive Offload,” etc., and set them to “Disabled.”
- On Linux:
- Use
ethtool
to disable offloading features. For example:bash sudo ethtool -K eth0 tx off rx off tso off
- Use
- Tuning VNC for performance:
- Disable unnecessary features (e.g., graphical enhancements) within the VNC client or server to reduce the load on the network.
- In virtualized environments, ensure that the virtual network interface is optimized for performance without conflicting offload features.
Conclusion
The conflict between TCP checksum offload and VNC arises because offloading shifts responsibility from the CPU’s network stack to the NIC, which can cause unexpected behavior in latency-sensitive applications like VNC. Offloading optimizes large, bulk data transfers but can disrupt real-time data transmission by interfering with packet validation and delivery. Disabling these offload features is often the best solution to ensure a smooth VNC experience.