Whirlpool

First off, a big thanks goes to Yarre, a rogue on Blackrock who started a thread on the WoW Tech Support forums on this issue.

You can access the thread here:
forums.worldofwarcraft.c...6&sid=1&pageNo=1

There is a large amount of technical discussion, some of you may be interested in going to the thread and reading about it, but I'm sure for the majority of us, we don't have a spare linux box, and we're running Windows.
We have Hathios, from Nazjatar to thank for finding the Window's "equivalent" setting.

What you are required to do, is change your TcpAckFrequency, from 2 to 1. If you want to know why, you're best reading the thread.
This is a registry setting, and so it works differently in Windows XP and Vista.

The WindowsXP explaination can be found here: support.microsoft.com/kb/328890

Those under WinXP, goto start > run > "regedit"

You will need to navigate to this folder:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentC­ ontrolSet\Services\Tcpip\Parameter­ s\Interfaces\<Interface GUID>

When you are in your Interface folder, you'll find a few folders you can choose from, you need to find the one which represents your Network Interface Card settings.

Generally, it will be the one with all the IP settings, etc. Hopefully its not to difficult to figure out which one it is.
Chances are the registry value isn't there, if it is all is good, just change its Binary value to 1.
If it isn't there, you'll need to create a new one. Right click on some white space and make a new DWORD.
For the name, type in (case sensitive) TcpAckFrequency.
Right click on it, then select modify.
Edit its Binary value to 1.

Note, that its default value is 2 (visit the microsoft page linked up above).

Your computer will require a restart for it to take effect. Please read below about the affect this setting may have on programs other than WoW.

It apparently has an affect on things such as downloads, and P2P where "larger" packets are being sent, apparently WoW uses smaller sized packets. As a result, you may want to change the setting back when you wish to download stuff. I'm not entirely sure.

For those under Vista, Chones from Proudmoore has apparently mentioned something about this:
The TcpAckFrequency registry key change can be made to work in vista if you locate and install KB935458-v2-x86.msu for 32 bit or KB935458-v2-x64.msu for 64 bit.

Google it, it seems to be part of the vista sp1 beta and isn't generally available.

It made about 150-200ms difference to my ping, its a whole new world.
If someone with Vista could confirm this, it would be appreciated.

I suggest you first log onto WoW, and record your latency doing something fairly similar for 10 mins, making sure to record your latency every minute or so.
THEN change the registry setting, restart your computer, and record yourself doing basically the same thing for 10 mins.

I did this and recorded my results, It would be appreciated if people could do the same to figure out if this helps you at all.

First log, TcpAckFrequency = 2
6:42am: 209ms (logon, always a low ping)
6:43am: 273ms
6:45am: 353ms
6:46am: 350ms
6:48am: 364ms
6:50am: 434ms
6:52am: 387ms
6:54am: 394ms

When calculating the avg, I ignore the first two minutes.
Avg low: 356ms
Avg high: 407ms

Second Log, TcpAckFrequency = 1
[after a computer restart of course]
6:58am: 206ms
6:59am: 304ms
7:00am: 306ms
7:01am: 290ms
7:02am: 297ms
7:03am: 280ms
7:05am: 289ms
7:06am: 280ms
7:07am: 270ms

Avg low: 277ms
Avg high: 331ms
Generally the first two minutes of connecting should be ignored. At the moment my bar is 279 and green, and I've seen it go as low as 249 while running around Shattrath. It appears to be working for me, so I'm happy.

Once again a special thanks to Yarre from Blackrock, Hathios from Nazjatar, and the others who helped find and figure out this stuff. If this helps you, please post your results here, and a thanks in the thread on the WoW forums. The more attention it gets, the closer we are to a working easy solution.

I'd be interested to know what sort of side effects there are to changing this value.

For stuff like large downloads etc, ACK'ing frequently is not ideal, as confirming every single packet that arrives isn't ideal.

Usually it goes something like:

server send packet x bytes
server send packet x bytes
server send packet x bytes
server send packet x bytes
client ack confirm all those bytes

With this 'fix':

server send packet x bytes
client ack confirm those bytes
server send packet x bytes
client ack confirm those bytes
server send packet x bytes
client ack confirm those bytes
server send packet x bytes
client ack confirm those bytes

And as you can see that can add a lot of unnecessary traffic. Also if the client is advertising a small tcp window which it may well be this stops the server from pushing data as fast as it could.

So stuff like download transfers it isn't ideal, but there's nothing particularly sinister about the change, it won't corrupt your HDD or steal your girlfriend.

couldnt you just change the value back?
someone with more experience than me could (im sure) write a little scipt.
a 'supernerd' could write an app.

Hey all

I'd recommend against changing the Windows TCP ACK response frequency if you can avoid it as it will have an adverse effect on "normal" TCP applications. For most internet applications that use TCP time is not an overly huge concern; they're more concerned about filling the available bandwidth between you and the host. So, for instance, downloading files from a website (and definitely high speed torrents) will work better with combined ACK's than single ACKs as your machine (and the link between you and the host) doesn't have to transfer as many packets.

If you can, I'd highly recommend using a linux or openbsd based firewall/NAT device. Rather than change your ACK response frequency for all TCP connections, a SOCKS or socat solution will only change your wow connection. Just read the first page of the WoW thread mentioned in the first post (forums.worldofwarcraft.c...3271071466&sid=1). If you're scared about setting up a linux box, don't be! :D They're getting friendlier and friendlier.

Perhaps a little networking 101 would help (forgive me if this is a bit inaccurate but it's early on Sunday morning and I haven't studied this in detail for about 5 years! ;) ).

TCP sits on top of IP and is a transmission protocol that has a number of handy inbuilt features. This makes sending data between two computers easier than with other protocols such as UDP (which is a much more bare bones protocol). One of the features is guaranteed delivery. So, as a programmer, when you start sending a stream of data, you don't have to check the arrives and arrives in order; TCP does that for you. For most applications this is good but for real time apps it can be bad. Most computer games actually use UDP as this allows the game to choose whether to resend missing data or just forget about it and move on.

Games usually use UDP as resending and waiting is irrelevant. Take an FPS game. I shoot a rocket at you standing 10 metres away. When your client gets that message it draws a rocket on screen 10 metres away. 1 second later you move to your left. 2 seconds later your machine gets another packet from the server saying the rocket is 7 metres away. Rocket is redrawn 7 metres away. Your machine then:

(a) doesn't receive another message until the rocket is 2 metres away; OR
(b) receives a message saying it's 2 metres away then receives a message that it's 5 metres away.

In either A or B the "5 metre" packet is irrelevant. In A it's been lost (routed the wrong way or perhaps was corrupted or had an error at the IP level). In B it's come too late to be helpful. Using UDP the game simply chooses to use the "2 metre" packet as important and charge on. The data's relevance is time dependant. [Aside - in addition the game uses a number of methods to better draw the rocket such as using the starting position, orientation and known velocity to predict where the rocket will be at different times, draw that and then use the server updates as adjustments]

In the same scenario using TCP we'd be in all sorts of trouble. The game (well actually it's the TCP stack in the operating system) would wait for that "5 metre" packet and would likely have the server resend both the 5 and the "2 metre" packets so would we'd end up receiving both the "5 metre" packet and then the "2 metre" packet too late. This is why most fast games (like shooters) use UDP.

For WoW (and Guild Wars but I think Hellgate uses UDP) TCP was chosen as most (if not all) of the "decisions" are made on the server as the event occurs. It's not a reactionary game. I can't "dodge" a fireball spell (not like I can dodge a rocket in Unreal Tournament 3). Whether I dodge a spell is determined as the spell is cast by the server (even if it isn't shown that way). As such, WoW is sending events rather than time relevant position updates (exception being character and mob/NPC positions in the world). Events such as "Player X started casting this spell", "Mob Y hits you for n damage with m resisted". TCP is good for this.. until latency gets too high.

By default, TCP tries to maximize the throughput of a link. This is typically a good thing. One method to help with this is combing acknowledgments. For TCP when the server sends a packet, the TCP stack on the server side _requires_ an acknowledgment before sending the next piece of data (or actually the next piece of data after the current buffer is emptied). So for every packet in, the client sends back an ACK. ACK's are small so TCP "optimizes" the link by waiting for a bunch of packets and then sending a single ACK for all the packets. This works well for bulk transfers as it allows for a large stream of data to keep flowing.

For TCP streams that send small bursts of time sensitive data, holding back and combining ACK's is bad. This is where the socket option TCP_NODELAY comes in. For WoW it wants the ACK's back before it sends the next event update. So if a WoW server sends 3 events per buffer (it would be obviously far more than that) the 4th event must wait for ACK's on the first 3 before sending. So, if the first three come in at 200ms, 275ms and 400ms after the server sends the first packet, your machine sends back three ACKs at the 400ms mark. That ACK takes 200ms to get to the server. So, the 4th event is sent 600ms after the start point. That is the default TCP behavior.

If we turn on NODELAY (which is an option when the socket between client and server is established), the 4th packet will be sent after 400ms. How so? The ACK for packet 1 will be sent straight back thus it will arrive at 400ms mark (200ms for packet to get to client + 200ms for ACK to get back to server). The server can then move packet 1 out of the buffer/queue and add packet 4. Similarly, packet 2's ACK is received at 475ms mark (assuming starting at 200ms after first packet sent + 75ms to send to client + 200ms for ACK to get back) so packet 5 will be sent at 475ms mark.

So, it's less efficient in terms of using the capacity of the link (the bandwidth) but much more efficient in terms of time. For small data sends such as games, bandwidth is irrelevant as not much data is transferred but what is sent needs to be moved quickly. Removing the waits is vital.

Sorry, that is way longer than what I'd hoped but it'll hopefully provide some understanding for those new to all these concepts. There are plenty of far more elegant explanations out on the web for sure and it's actually very interesting.. if you're a geek like me! ;)

Have fun with it all.

Andrew

A big thanks to Netrosis and Max Power for instructions and explanations. This was very informative! In fact it's NEARLY tempted me to re-subscribe to WoW and test out my ol' priests abilities with TcpAckFrequency=1 to see just how much quicker she could cast at. If only WoW wasn't such a timesink...

Anywho.... Much appreciated layman's terms info'!

Ant

And don't forget the two original whirlpool threads that spawned this:

forum-replies.cfm?t=841656&p=1
and
forum-replies.cfm?t=872425&p=1

So...I tried this, and it didn't really seem to help. Usually i'm around 500, only went down to 400(Whereas lowerping bring me down into the green 250-300. Could I have possibly done something wrong? Or is this normal?

i did some testing (on Vista!)
used a lowbie toon in starting zone to remove any 'ironlag'- no mods

original setup ping:

222
280
300
343
356
371
401
414
438
445

average: 357
trend: upward (but possi/probably not tested for long enough) high 400's low 500's

patched and regedited ping:

223
222
271
262
303
313
330
319
304
319

average:287
trend: stable @ low 300s

imho it works, i'll do some more testing and also see what effect there has been on my normal internet activity and downloads

the post by Pantss on this page
forum-replies.cfm?t=872425&p=27
is also very intersting, i think i'll try it out too

took me a while to get it working right.

What do you mean by "get it working right"? What else could I do? I'm pretty sure I followed it exactly. >_<

Just remember guys the two approaches are different.

The Windows registry addition/edit changes how long quickly Windows sends back the ACK but the socket connection to the WoW servers will still wait for the ACK before sending packets. As such, the ping you see will usually not decrease as much as if you use the linux/openbsd + socat/SOCKS combo.

Additionally, I think that lowerping and Internode are also changing some other things and probably have dedicated bandwidth to/from the WoW servers so packets going through those routes will travel faster than via the "standard" internet routes - that's just speculation on my part. I'm still looking into other possible optimizations for the wow traffic but at this point it's very playable so I'm using my weekend to play! ;)

Andrew

Ah ok, that makes sense. Would it be possible for anyone to do the windows equivilant of the linux/openbsd & socat/SOCKS combo? Someone mentioned on the thread they did it with VMware server.

so can I do this when I'm in wow, but change it after I'm done playing?
Or does it require a restart before the registry entry kicks in?

I'm thinking maybe someone can create a script that will change the value from normal to wow settings?

yeah you've gotta do a restart.
also editing the corrent network interface helps (ive got a few)

i wish i was better at scripting...

im sorry if ive missed this, but is it worth using this method whilst also using the lowerping.com method at the same time?

Probably not, no. They're much of a muchness.

My wow latency normally sits around 450msec. Now sitting around 300-320 :)

Zinga writes...

Usually i'm around 500, only went down to 400

I'm sure the lowerping/internode, and linuxbox solutions are more permanent and will lower your ping more.

Thanks for others on giving input on more detail about what happens when you change the setting. Until we can get a more permanent solution, you may just need to switch the setting back and restart when you're not playing WoW.

Tried it, I usually sit around 400, 360 ping
with the reg hack i get around 290 - 310
BUT......
I get lag spikes every now and then in wow.

yeah im getting spikes too,
seems to take longer for a downloads to reach 'full' speed, which may be a bit lower, although my connection speed is a little variable.
VM hack seems the most intersting for those without access to a second box.
im running a core2duo so i'll see how it runs with wow

Wish I knew how to get the VM method working. If you get it working could you post a quick guide?

Is it possible to run a VM on another XP PC on my network and connect to that?

Yeah a guide would be great, I've already downloaded VWware, unfortunately, I wouldn't know where to start. ;(

I will install Linux on my laptop - and see how I go. I'm pretty sure the method will be similar for VMware.

I'd use VMware on this computer, but I doublebox so I suspect it will clog up my computer to some aspect.
If someone could make a rough guide it would be appreciated :)

I tried this on EU servers (moved to london a while back) and my ping dropped from 80-120ms to 15ms. Things show up in my combat log before I see the person now, it's a little odd :)

Max, bad analogy.
Games would not update constant's every set time interval, they should send out a vector and have the clients handle the rest.

Single packet, far less bandwidth consumption :)

Kheldar writes...

Wish I knew how to get the VM method working. If you get it working could you post a quick guide?


I posted a Tutorial at forums.worldofwarcraft.c...8321751&sid=1#94

First Tutorial i have done (be nice lol) :)

Thanks very much. I spent quite a few hours trying to get this going yesterday, without any luck. I followed your tut and it's working. My ping has dropped from 450/550-ish in Org to 270/290-ish so I'm very happy with the result.

oh crap, the wow forums r down, anyone know the commands linux with socat and iptables?

sudo iptables -t nat -A PREROUTING -p tcp -d your.wow.server.here --dport 3724 -j REDIRECT --to-ports 3724

sudo socat -d -d -d TCP4-LISTEN:3724,nodelay,fork,reus­ eaddr,su=nobody TCP4:your.wow.server.here:3724,nod­ elay

i just happen to have that open in a notepad window :)

THere's no space in the last nodelay but somethings putting one in

I got the linux method to work and I must say, BIG IMPROVEMENT. Was sitting on 350-461 Ping before it and now I'm always below 250ms

Gonna grab my old PC and turn it into a linux box dedicated to lowering my wow pings hahahah

Gonna post a tute on how to set this up using VMware in XP soon just be patient.

Do any of the 'light' flavours of linux that run purely off a CD include socat and iptables?

I couldn't see if smoothwall does and I think feather linux might but I had trouble getting it to run.

Feather linux works, but after you restart Vmware you have to type all the settings again, I find Ubuntu is the easiest to install and setup

any chance someone can link me a non-wow forum copy of the text of Nostromo's awesome tutorial (could read it at work, but can't get to the wow forums now :( )

Just to confirm, this is 100% safe, right? I don't want to all of a sudden have my account banned or something :S.

Kheldar writes...

Gonna post a tute on how to set this up using VMware in XP soon just be patient.

Sweet :D

All the VMware tutorials I've seen so far require bridged networking instead of NAT, but I can't seem to get that to work with VMware and Feather Linux. I think it may be because I've got an ADSL modem instead of a router. Don't suppose anyone has any idea how I can deal with that?

is anyone nice enough to give some hints/tutorial how you would do the linux gateway trick on a smoothwall box? im pretty sure that uses iptables

:D

Nevok writes...

Just to confirm, this is 100% safe, right? I don't want to all of a sudden have my account banned or something :S.

Its totally safe.

TCP, a transport mechanism for packets (Data) accross a network, uses an internal windowing mechanism to find out the optimum ammount of packets to be sent, before any acknlowedge packets are returned.

Simplest terms, you have a host that sends a single packet, under TCP, it requires an acknowledgement from the receiver to identify that it got the packet in tact.

A host can also send say, 10 packets, and only receive a single ack. packet, signifying the last in-sequence packet received was 10, and everything will be fine. (This is also a window size of 10).

But if it sends 10 packets, and the receiver only ackknowledges that it last got packet 3 in tact...the host has to resend the last 7 packets...this causes quite a lot of lag, as the window shrinks back down to minimum, and slowly expands again.

With this tweak, its basically setting the window size to 1. That is, it requires an ack packet after every single packet sent, to avoid resending massive ammounts of packets.

WoW servers will be oblivious to this alteration.

Just wanted to give this thread some love as it worked for me.

Original wow latency on an telstra cable connection sat around 450, after applying the registery fix i'm now around 200-250 which is a big improvement.

Thanks heaps to the Netrosis for posting this up!

Thanks for the info. :) I did some experimenting last night on my terribly slow optus adsl 1.5k connection and found the registry hack did improve my ping. I went from an average of 500ms sitting in shatt for a good 15 mins to about 350ish. However, i've got friends who say that a raid encounter with 25 people and a bunch of data flowing through sends it back up.

Ideally i want a stable connection for raiding. If i have 500ms in shatt i don't care so much.

I also tried the trial account of lowerping and found i had a stable connection of 210-230ms for a good half hour. That was only sitting in shatt and it was about 10:00-10:30pm.

While the registry hack is an improvement, i'm not confident of its stability and it also comes with the issue of decreasing your download speeds. You can change it back but it requires a restart and that's becoming just too much of a pita. ;)

I tried this method, my Ping did improve, but not as much as lowerping.com gave me.

Yup i tried the VMware method last night. My regular latency was about 600-800. With the VMware method it dropped to about 400-500.

Nostromo writes...

I posted a Tutorial at forums.worldofwarcraft.c...8321751&sid=1#94

First Tutorial i have done (be nice lol) :)

Is this for use in windows? Don't know much about Linux systems, so not sure if the answer to my question is obvious or not >.<

Kirky writes...

but not as much as lowerping.com

lowerping may route your packets differently than from a connection from your pc to wow. Note also that blizzard are banning accounts using lowerping since its outside of the terms and conditions (tunnelling is not allowed)

the grommet writes...

Note also that blizzard are banning accounts using lowerping since its outside of the terms and conditions (tunnelling is not allowed)

Actually people are getting banned for possible link to powerleveling services. Because they were logging onto their alts and lvling really fast. So blizzard assume that multiple accounts logging in with the same IP = powerlvling service.

Blizzard stance on lowerping is that they do not support it.

Blizzard stance on lowerping is that they do not support it.

There was one blue post stating that.

Terms and conditions are pretty clear otherwise:

Limitations on Your Use of the Service.

1. Only Blizzard or its licensees have the right to host the Game. You may not host or provide matchmaking services for the Game, or intercept, emulate or redirect the proprietary communication protocols used by Blizzard in connection with the Program, regardless of the method used to do so. Such prohibited methods may include, but are not limited to, protocol emulation, reverse engineering, modifying the Program, adding unauthorized components to the Program, or using a packet sniffer while the Program is running.

Vivid.Beatz writes...

Is this for use in windows?

Sure is :)

the grommet writes...

1. Only Blizzard or its licensees have the right to host the Game. You may not host or provide matchmaking services for the Game, or intercept, emulate or redirect the proprietary communication protocols used by Blizzard in connection with the Program, regardless of the method used to do so. Such prohibited methods may include, but are not limited to, protocol emulation, reverse engineering, modifying the Program, adding unauthorized components to the Program, or using a packet sniffer while the Program is running.

None of this mentions modifying the TCP window.
Its a clause to prevent hacking and cheating, via a bot program, or spurious information injection to give yourself faster runspeed, more cash etc.

Modification of the TCP window (which, the TCP stack itself is not a proprietary stack, its open source IEEE) is not a hack.

I tried modifying my Tcpackfreq (or created it in vista after installing the update) and it's done wonders for my ping time, reducing it by about 200-300ms constantly. No spikes, perfect!

Looks like blizzard will be disabling the Nagle algorithm in the next patch.

www.worldofwarcraft.com/...-patchnotes.html

Does that mean the 'tcpackfreq' fix will stop working?

Will using TcpAckFrequency 1 help with lowerping? or will it do nothing?

Based on reports from PTR, once the patch goes live you won't need lowerping or the TcpAckFrequency fix to acheive a better ping.

Verdana writes...

Based on reports from PTR, once the patch goes live you won't need lowerping or the TcpAckFrequency fix to acheive a better ping.

Hurray!

Thank you Lowerping people for making the issue more well known and making Blizzard take some action. But looks like you're out of business lol.

Verdana writes...

Based on reports from PTR, once the patch goes live you won't need lowerping or the TcpAckFrequency fix to acheive a better ping.

to quote from www.worldofwarcraft.com/...-patchnotes.html -

"Reduced network latency by disabling the Nagle algorithm."

:-)

Can't believe this took 3 years to find and fix.

When will the patch be available?

My missus is always bitching about her high pings (Optus cable about 500ms) and if the patch is going to take some time I'll apply the registry hack!

Did this today as the service I was getting from LetsGo made WoW unplayable (4k+ ping). 665 after reboot. Still high, but almost playable.

One fix would be for Blizzard to quit being so Anal and set up an Australian server.

Matt writes...

Can't believe this took 3 years to find and fix.

Blizzard knew it was there, they chose to keep it in though. Nagle's algorithm reduces the frequency of packets sent by bunching them up and sending them in bursts. This is great for bandwidth because control data is sent less frequently, but it adds latency while you wait for enough data to be ready to be sent.
Note that this has nothing to do with lowerping.com who provide a proxy in the US for you to tunnel through and skip all the routing in between you and them.

It'll be interesting to see what happens with these bans, especially since internode uses a similar service... I can't imagine blizzard is allowed to ban anyone that uses a proxy...