I'm going to try this when I get home! Thanks for the information Squirrelnut.
UPDATE: #3 has been tested by many users and is by far the most helpful for anyone trying to improve their WoW latency.
The other day I experienced 1000-3000ms latency when normally I have 50-80ms. Not only that but I was CONSTANTLY getting DCed from the raid which isn't fun when you are the 25m MT so I did some research and thought I would share it here as well as on my guild's site.
I. Find server IP
II. 3.2.2 DCing & Latency Issues
III. Leatrix Latency Fix
IV. Additional Tips
I personally tested these changes I have returned to a full night of raiding with 50-80ms, no disconnects and no other problems. Hopefully this might help some people resolve their issues without searching everywhere for things to try.
I. Finding your WoW server IP address
For testing purposes it is really important to have an IP that you can trace so that you can see if problems are a result of your ISP or elsewhere in the route to your game server.
Here is how to see what the IP to your WoW server is (PC based):
1. Login to WoW and connect to your normal server
2. Press alt+tab to minimize WoW and return to your desktop
3. Click 'Start', 'Run' then type 'cmd' and click ok
4. Type 'netstat -n' and wait until it finishes and the command prompt appears again
5. Find the IP address connected on port 3724 for example: xxx.xxx.xxx.xxx:3724 this is the IP to your WoW server
If you want to run a trace to that server do the following:
1. Click 'Start', 'Run' then type 'cmd' and click ok
2. Type 'tracert xxx.xxx.xxx.xxx' where the x's are the IP address of your WoW server (don't include the port 3724)
**Note** If you prefer you could type "tracert xxx.xxx.xxx.xxx > "C:\trace.txt" in the DOS window to have the trace saved to a 'trace.txt' file.
Blizzard has pinging functionality and the last few hops of a traceroute disabled to prevent attacks, don't worry that after the first group of hops in your trace to the WoW server the connections will all time out.
II. 3.2.2 DCing & Terrible Latency Fix
Here is a potential fix that has worked for some people (XP instructions but Vista should be similar), it mostly works for home users not so much for people on college internet.
1. Right click 'My Computer' and select 'Properties'
2. Under the 'Hardware' tab click the 'Device Manager' button
3. Under 'Network Adapters' right click your adapter and select 'Properties'
4. Under the 'Advanced' tab find the option for 'Flow Control' and enable it
5. Under the same 'Advanced' tab find the option for 'Speed and Duplex' and set it to '100 Mbs Full Duplex'
This really depends on what modem and connection you have, basically if you have 100 Mbs Full Duplex available you should use it. You should be able to leave it on 'auto negotiate' but some don't work correctly and it helps to set either Full or Half duplex depending on what you have available to you.
III. Leatrix Latency Fix (for PCs, read the wowinterface notes for a Mac fix)
I tried this latency fix and surprisingly it actually worked perfectly for me. I was averaging 180-300 pings while other games like Counter Strike I would have 30-65. After using this fix however, my wow latency is down around 50-80
Leatrix Latency Fix : WoWInterface Downloads : WoW Tools & Utilities
Give it a try and see what you think, it modifies your registry for you so you don't need any advanced computer knowledge to do it. If you don't like the fix you can easily take it back off at any time.
Read the included notes on the wowinterface page for full details and explanation of how the fix works and what exactly it does. There is no danger to your computer and the fix can easily be removed.
IV. Additional Tips
- Fubar Addon Spam Fu: tells you who has addons going crazy overloading your connection
FuBar_AddonSpamFu - Addons - Curse
- Get rid of Quest Helper
- Disable as much as possible from your combat log filtering (you can still run /combatlog to record raid info to post to wmo or wws since it is separate from your in-game filtering)
Last edited by Squirrelnut; 08-09-2010 at 08:36 AM.
* Finding your WoW server's IP: US realm list by datacenter - WoWWiki (may be incorrect for newer servers)
* Be aware that even though your latency to the server may be low, different locations in game correspond to different physical machines in the cluster of machines that make up a world server. Depending on the number of people on a given machine and how much traffic is required for one person (ironforge vs. barrens), some of your latency will be due to the sheer number of network requests it has to handle, and just how much processing it has to do to support the users that are on it.
* Read the EJ guide to fixing disconnects: Fixing the Chain Disconnecting - Elitist Jerks
* Understand what the Leatrix thing is doing. It's not necessarily good for other things you do on your computer:
The problem you are solving is the interaction between WoW and the network protocol - delayed ACK, or TCPNoDelay as it's called in the registry.
The delayed ACK mechanism assumes that after you receive some data, it can just wait for the next outbound datagram you're going to send and tack on the acknowledgement of the data you just received (assuming a fixed time interval does not pass before the next datagram goes out). Fine and well, and it does increase efficiency and reduce bandwidth.
This is a reasonable and good strategy, but it does not play well with online games such as WoW. With delayed ACK waiting for the next outbound datagram to attach the acknowledgement to, you're artificially increasing your latency from client to server. When you do this registry trick and your latency drops, it's because you removed the bottleneck that is caused by the poor interaction delayed ACK and the game - you're now getting your true latency to the server. For gameplay, this is a desirable thing
That said, what this thing above does is globally delayed ACK on your computer, for all applications. This has the benefit of improving your WoW performance (and really, any online game's performance,) but on the other hand it can and probably does slow down other things you do over the Internet. This change will not affect web browsing to any great extent, so if your biggest Internet activities are WoW and surfing, this is a very reasonable thing to do.
In past there was another actor at work here - Nagle's algorithm. Nagle's algorithm works by looking at the datagram you're about to send and if it is small, it just buffers it up and waits for enough data to make a "reasonable" sized datagram to send. Again, this is reasonable. Say your message is 4 bytes long. Attach to that the TCP/IP header of 32 bytes, and you can see that individually sending a stream of 4 byte messages will use a lot more bandwidth than the size of the message would indicate. Queueing ten or twenty 4 byte packets and only putting one header on them is a lot more efficient for sure. The WoW client disables Nagle now for you, so it's nothing you need to worry about.
That's for people who don't want to use something like Leatrix and go finding the manual way to do it on the web. Don't worry about disabling Nagle in the registry because the WoW client does it for you. (But also keep in mind that other games may not disable Nagle for themselves, so it may be worthwhile to see if disabling Nagle globally helps your performance in other games!)
Last edited by Satrina; 10-02-2009 at 09:50 AM.
- The problem with that datacenter list is that it is not entirely accurate. My posted method for viewing your server's IP has actually been posted by Bliz Dev's on the wowforums and thus I would think is the most accurate approach.
- The wowinterface page includes discussion on what the Leatrix Latency Fix does and includes mention of the Nagle stuff as well:
- After having used the fix WoW latency has dramatically improved and I have not noticed any reduction in speed in other games, web browsing or downloads/uploads. If anyone is concerned she also included a 1-click uninstall option as well.Didn't Blizzard disable this already?
This is a common misconception but the answer is no. What Blizzard did was disable nagling, way back in patch 2.3.2.
Nagling bundles small packets together into larger ones for more efficient transmission. The effects are similar - bundling packets together always produces higher latency which is why it's bad for online games. Blizzard disabled nagling because of this, however, the acknowledgement queueing system used by the TCP protocol remains.
For the technically minded, Blizzard made the TCPNoDelay function redundant, as Wow now includes it by default. They didn't change TcpAckFrequency. Leatrix Latency Fix changes that.
does this help for the people who get DCed cause of the Gormok fire?
Excellent, there's the Nagle question answered. The realm list is probably less accurate for newer servers, makes sense. Disabling delayed ACK is good for most online games; the only problems people might see is with other network applications.
Gormok fire is probably a combination of combat log and graphics settings.
Thanks for the EJ link addition Satrina, I had seen a couple on there but the one you linked has nice pictures exemplifying some of the tweaks I included such as:
- the Fubar Spam Addon link that I included in the additional tips.
- the leatrix fix except they explain how to do it yourself by modifying your registry instead of just clicking the leatrix file which does it for you
- the combat log filtering suggestion with pictures
And it also includes some additional tips on hardware, wireless, etc.
My biggest problem with wireless networks is when you have a neighbour with a cheap wireless telephone that doesn't play nicely as per IEC emission regs, and broadcasts full blast on all frequencies in the 2.4 GHz spectrum instead of frequency hopping to establish a clean connection. It's hard to track down the culprit if you live in densely populated area.
basically, you are diabling ethernet auto negotiation, and forcing your PC ethernet port to fixed 100Mb/s, full duplex. most likely, however, you are leaving your router set to autonegotiate. this creates a scenario called "parallel detection" where one side is trying to autonegotiate the speed and duplex, while the other side is fixed. here's the result of that scenario:
1) the router can and will autodetect the speed of your PC and set itself to 100Mb/s.
2) the router CANNOT autodetect the forced duplex setting and so will automatically choose half-duplex (per ethernet protocol standard) - this explains why you are having to force your PC to flow control.
with a full duplex link, there is no flow control since data can pass in both directions at full speed simultaneously. if you truly had a FD link, like you think you are forcing, then the flow control setting would be unnecessary.
however, since you are ending up with a duplex mismatch, and the router is operating in half-duplex mode, you need to set the flow control to stop your connection from slowing to a crawl. half-duplex links can only send data in one direction at a time. without flow control there are constant collisions; by forcing flow control, at least you have a back-off algorithym to help increase the speed somewhat, but it will not equal what a full-duplex link will give you.
my guess is someone tried this and their connection got better. it could have been by chance, or they could have had a very specific network problem that this fixed. perhaps they had a very old ethernet hub that did not support autonegotiate.
99.9% of the time, this is NOT going to help the average home user. any reasonably new hardware is going to support autonegotiate, and be configured for autonegotiate by default. this will result in a 100Mb/s, full duplex link at startup, or even a 1Gb/s link if both ends support it. either way is a better scenario than parallel detection.
don't do it, unless you know why.
Are you referring to just the flow control part or are you recommending not setting the full duplex part as well? I sifted through various tech support threads and found many people suggesting this approach with Blue dev support (specifically asking people to try using either 10mbs or 100mbs full duplex connection).
if you know what you are doing, you can force both ends of the link - meaning force the PC to 100Mb/s, FD and also force the router to 100Mb/s, FD, which will guarantee you a 100Mb/s, FD link. flow control is irrelevant with a FD link; the only reason it was necessary to force that in your suggestion is because the router must default to half duplex.
here's the thing though - by forcing both ends to 100Mb/s, FD, you will end up with the exact same thing you would have had by leaving both sides set to autonegotiate, which they should already be set to. per the standard, autonegotiate will pick the highest speed that both ends support, and will always choose full duplex if available at both ends. this will happen 100% of the time, unless something is broken.
the only time i could see this helping is if someone had previously forced their router to 100Mb/s, FD because of the same misunderstanding of how autonegotiate works. in that case, also forcing the PC setting would fix the existing parallel detection condition.
nobody said every tech support person was an ethernet expert either... SBC once told me to unplug my ethernet cable and turn it around and plug it back in the other way...
i like tip III though; i'm going to do that as soon as i get home
First of all, not receiving an ack does not in and of itself stop a computer from sending packets. A TCP sender will happily keep sending out packets without having received a single ack (and in fact, some congestion control approaches do that fairly aggressively).
Instead, TCP acks are used to recognize lost packets. If you don't ever lose a packet, sending acks early will not buy you much. But when you do, it can matter. Briefly, TCP generally relies on getting duplicate acks to recognize packet loss, as follows: Each ack has a byte sequence number showing the sender how much data the receiver has already received. The receiver sends an ack with the byte index of the last contiguous piece of data it has received. If there's a missing packet, it will just resend the last ack. So, if the sender starts getting duplicate acks, it will know that the sender is getting packets, but is not making progress because of a missing packet. So it knows to send data again, and the sequence number will tell it what needs to be resent.
This matters in two ways: One, with delayed acks, resending data can take longer, because it takes longer for the sender to recognize that a packet has been lost. Two, with delayed acks, you may run out of send buffer space: Until data receipt has been acknowledged, the sender has to keep around the data in case it has to be resent. Fast acknowledgements allow the sender to remove old data from the send buffer earlier (of course, this shouldn't matter for games, and if it does, you could also make the send buffer bigger). Finally, delayed acks can also interact oddly with flow/congestion control (but so can non-delayed acks, since congestion control algorithms are usually implemented assuming delayed acks). I'm not sure what exactly is happening in the Windows case, but I've seen it myself, and it can be noticeable (400+ ms latency with delayed acks vs. 200+ ms latency with non-delayed acks).
Incidentally, if you own a Mac, while you can apply a similar change, the tweak may not be necessary. To be precise, you can change the TCP ack mechanism policy by setting the kernel parameter net.inet.tcp.delayed_ack via sysctl -- 0 is off, 1 is on, 2 and 3 are different adaptive settings. On my Mac at least, the default (3) works well enough to not require further tweaking, while on my husband's spare Windows laptop (which I currently use because my Mac's graphics card gave up the ghost last week) I needed to tweak the TCP ack frequency parameter to get rid of a fairly noticeable lag effect. So, while you could set it to 0, there is unlikely to be a noticeable effect. (Note also that the values have meanings that are totally different from Windows!)
You guys should ALL get nerd of the year awards! I tried this and it made my turd raiding PC shine like a really shinny turd! Thanks to everyone!
From a complete dummy's perspective, reading these posts really helped me to understand why my connection was so bad. I've refered half my 25 team to this post and no one is dc'n anymore! I do not run a router and I changed my settings to 100mbs Full Duplex and it really sped me up!
Thanks again folks!