WoW on Mac: TCP Tuning

howto Add comments

My sister plays WoW, and had some latency issues. Rather than go to a higher-speed WAN connection (hey, Wifi-B works OK for most people, but not when you’re raiding) she drilled a bunch of holes in her floors and went direct-wired.

Not to nock direct-attached LAN connections: it’s faster overall, and your latency/jitter in the environment cannot be influenced by a steel stovepipe, or driving a car between your PC and your router. unfortunately, it may have the effect of switching the upstream bottleneck (of data blocks or ACKs stuck behind them) to the router.

Since Wifi bandwidth already exceeds Broadband bandwidth, your speed won’t go up by doing this, but latency improves (insert the first dweeb quoting Linus Torvalds on a “because Linus Sez So! Linus 3:16!” quote here)

Latency can also be a factor of buffering in terms of number of sliding windows, window size, etc. In cases of raw video, you can get better performance (ie less jitter) at the cost of a few dropped frames if you reduce your buffering, for example.

I would take notes on performance (which might be a subjective “feels better” or “feels sluggish”) and then twist a few knobs, as follows. DO NOT change more than one at a time, lest those changes be misattributed to the wrong change.

  • reduce net.inet.tcp.sendspace
    • sudo sysctl -w net.inet.tcp.sendspace=250000
    • make sure that kern.ipc.maxsockbuf = (net.inet.tcp.recvspace + net.inet.tcp.sendspace)
    • net.inet.tcp.sockthreshold may need to be set lower (0 to disable) so that sendspace/recvspace are respected earlier on
  • reduce net.inet.tcp.mssdflt to 1500 – (20 * wrapper) —
    • in most cases, this is 1480, because 20 bytes overhead for a PPPoE link
    • it’s OK to reduce that further without a huge drop in performance
    • further drop because of WiFi? Not logical, but it does protect your stream in the event of unseen X-over-Y tunneling
    • 1440 is OK on a local LAN, even a gigabit; if all LAN members permit jumboframes (9k), use 8940
  • I’m not sure there’s benefit to increasing net.inet.tcp.win_scale_factor above 3 (for gigabit ethernet) because the bottleneck at the router and cablemodem/DSL will only be exacerbated. The congestion should be caught at the desktop to avoid filling the queue at the cable/DSL for outbound traffic.

These reductions are an attempt at reducing queuing at various hops that can reduce the effectiveness of TCP’s congestion algorithm.

If I get other ideas, I’ll add them here.

As always, Netalyzr is a good first-flinch when checking out an unknown network, even if you think you’ve used that net for months.

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in