Server locations, Latency & Australia - Page 11

IKT · 02/25/08, 9:03 PM

Originally Posted by ter

ADSL2+, while being relative new

A technology that was primed and ready in 2005 is considered a relatively new product in 2008?

Baalzaman · 02/25/08, 10:14 PM

Originally Posted by Denvald

how do i create a text file?

I wouldn't bother with MSMQ, its proved unnecessary.

• trinket · 02/26/08, 12:32 AM

Originally Posted by IKT

A technology that was primed and ready in 2005 is considered a relatively new product in 2008?

That pretty much sums up all of my internet problems.
I've been on 1500/256 for 3 years, i'm on a RIM and can't get ADSL2, like 3/4 of the country can't get it also.
I really don't think the removal of nagles algorithm was implemented properly in 2.3, i don't even think it was implemented at all.
I'm seeing a constant 400-450 ms with no registry edits on, and i use lowerping for raiding / pvp and it goes to 180-200ms, it's a good service, but i just wish it wasn't necessary to make the game playable.

Drunkmunky · 04/15/08, 11:40 PM

Incoming thread necromancy!!!

I'm sure most of you remember the ruckus that was caused when someone discovered why lowerping.com worked and how Blizzard had muffed up their network stack but what exactly has happened about it? I remember that patch 2.3.2 was supposed to add tcpnodelay to wow's traffic but so far as I could tell after the patch it hadn't done a goddamn thing. So I continued using lowerping.com and havn't really looked back.

Last night I was playing around trying to get it working through a linux gateway and I thought "hold on a goddamn second why am I bothering with this when Blizzard claimed that they'd fixed the issue?". So why the hell haven't they fixed it and why am I still using lowerping's service?

Kegsta · 04/16/08, 12:04 AM

I believe all blizzard did is change the same thing that registry patch that was posted on MMO champion did. Which basicly did nothing at all.

A few of our guild members rented there own US servers which we all run through and its costs us about $2 each a month, pretty good for a 300ms reduction.

If your with internode they also run there own free ping server aswell.

SecSolidus · 04/16/08, 3:38 AM

I have been using the 'MSFix' for months now. And i can still confirm its the next best thing.

The TcpAckFrequency registry check is still fully functional, actually after deciding i was fed up with vista. And re-installed Windows XP. I reinstalled WoW and logged in to check just how much blizzard's msfix actually lowered my ping. And to my surpise not much at all. I had around 260 MS. So then i proceeded with the Registry fix. And logged back in again. and voila 55 MS.

Is it even worth paying lowerping services when you can just proceed and apply the TcpAckFrequency fix?

Edit: Grammar

◊ Cadfael · 04/16/08, 4:22 AM

Blizzard *did* do some changes, I went from a ~90ms to ~45 ms (yes I am a low-ping bastard) without any change from my part. Note that in networking, there are always lots of factors and different components involved. Nothing that Blizzard does helps if your operating system decides to optimize something wrongly.

The registry tricks seem to still help some people getting better results, so try them out. Generally they shouldn't be needed anymore though and they could still cause some probably not readily noticeable side-effects with other software.

Cyn · 04/16/08, 5:53 AM

Originally Posted by Cadfael

The registry tricks seem to still help some people getting better results, so try them out. Generally they shouldn't be needed anymore though and they could still cause some probably not readily noticeable side-effects with other software.

With all due respect, this thread is with respect to Oceanics mostly as the thread title describes, and the registry changes are a difference between 600 and 300ms for alot of that demographic

◊ Cadfael · 04/16/08, 7:05 AM

Originally Posted by Cyn

With all due respect, this thread is with respect to Oceanics mostly as the thread title describes, and the registry changes are a difference between 600 and 300ms for alot of that demographic

It was my understanding that Blizzard's change did better the latency for oceanic people by an amount in that ballpark already.

I did not say nor did I mean to imply you cannot further optimize. If you still suffer from some bad latency, it might very well be worthwhile to investigate a bit of time to try out different options. There are a lot of them, but not all are easily done.

Cyn · 04/16/08, 10:18 AM

Not really, the change that Blizzard made, made almost zero difference what so ever for myself, and anyone i spoke to, well nothing discernible from day to day lag variance. Everyone has just accepted the fact, if you want good pings, pay $7 a month to lowerping.com

• Intermission · 04/17/08, 7:42 PM

Normal (pre and post that patch): 450ms
With Regedit: 250-300ms
With Lowerping: 170-200ms

Paying 7 bucks a month for a 300+ dps upgrade, plus general faster reaction time is worth it for me.

Drunkmunky · 04/17/08, 9:30 PM

Yeah I still pay for lower ping as when I tried to play without it last week my latency was still 500-800ms. This thread was originally created as I thought the problem was only for Australia but if it's helping Americans too then they are quite welcome to contribute to the thread.

And screw using those registry hacks, it will do bad things to the rest of your internet traffic.

• squiffy · 04/17/08, 10:25 PM

I mean, it's not like you can a, actually partition off wow traffic altogether and pipe it through a function (vmware/socat) to achieve the same thing you're paying for, and b, you couldn't ever restart your machine between wow and leeching sessions...

It will potentially slow down your throughput in high bandwidth use situations yes, but a generic "do bad things" is misleading.

Baalzaman · 04/17/08, 11:56 PM

Something for the Oceanic players:

Posted by Syndri (Blizzard CS forum) here

Head's up, guys—

As I mentioned, our Technicians are presently working out various strategies to best resolve the ongoing latency issue. They're approaching this matter from different angles in attempt to both ensure optimal play time for you overnight folk, as well as guarantee that all the necessary maintenance processes are run.

Because our Technicians are trying these "different angles," you guys may see varying results for the next few evenings. Last evening one tactic; tonight we're trying another. In order for our Technicians to truly understandd the benefits/side-effects, though, we need your imput.

During your peak play times, please report what you experience—good and bad. No latency? Let us know. Latency spike? Let us know. Instance crash? Let us know. Multiple disconnections? Let us know. Vendors non-responsive? Let u—

You get the picture.

Your reports are key here, as they'll give external value to internal data. We'd be greatly appreciative if you would continue to work with us on this. Like, a lot a lot.

Certainly worthwhile keeping an eye on this and adding feedback in that forum.

Ragnor · 04/18/08, 12:29 AM

1% of the oceanic player base will read or know about that thread, 0.5% will post in it, seems like a pretty useless way to get feedback.

• Falk · 04/18/08, 12:54 AM

Isn't that the same as any other forum thread? Being targetted at Oceanic players seems irrelevant.

In any case, the post is in reference to the random spikes and instance/world server crashes that have been occuring during the past two weeks due to background processes WoW apparently runs overnight, i.e. server performance - it has nothing to do with the client-server connection code, TcpAckFreq, TcpNoDelay, routing issues, and the like. Just so that's clear.

◊ Embar · 04/18/08, 1:05 AM

Originally Posted by Ragnor

1% of the oceanic player base will read or know about that thread, 0.5% will post in it, seems like a pretty useless way to get feedback.

That's only because most people would rather sit there and complain, and/or post whine posts that don't provide the information required, than actually do something constructive. Some feedback is better than no feedback, and at least Syndri has been active in that respect.

I know on Jubei'Thos people have been posting the forum links in trade channel and asking people to report lag. And it would seem that most of the people driving the forum effort come from the server's raiding community, who will also be the group most affected by the lag. So I think, or I have to believe, that the ones who do post and give feedback will do a decent job of it if only out of self-interest.

Pand · 04/21/08, 1:34 PM

at least you're telling people, lower ping is awesome for oceanic players.

Teldra · 04/23/08, 11:56 AM

I've tried editing my registry, but I dont seem to have a MSMQ under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\

any ideas on how to do this?

• squiffy · 04/23/08, 6:49 PM

Originally Posted by Teldra

I've tried editing my registry, but I dont seem to have a MSMQ under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\

any ideas on how to do this?

You don't need that key, it doesn't actually effect the latency at all it was discovered.

Only the TCPAckFrequency registry change is needed.

Avele · 04/28/08, 5:41 PM

Cavaet I: I'm not a network engineer, but I've been known to have to play the role from time to time when people who should know what's going on don't.

Cavaet II: This is going to get technical in places; skip the bits you don't understand.

Let's start from the beginning. WoW exhibits excessive latency when you're playing in a location that's at a large distance from the WoW servers (particularly noticeable in Oceania, hence my personal interest). This has been traced down to the following behaviour: a packet arrives from the wow server, and an acknowledgement is generated by the client machine, as in the following example.

11:28:00.686393 IP wow.server.3724 > wow.client.1230: P 14746:14824(78) ack 162 win 14600
11:28:00.857213 IP wow.client.1230 > wow.server.3724: . ack 14824 win 17520

In this particular example, there's a ~170ms delay in the acknowledgement from the client. It is assumed that this is causing the problem (since removing the delay causes the problem to decrease).

Referencing from rfc1122: From rfc896, describing Nagle's algorithm:

The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unacknowledged. This inhibition is to be unconditional; no timers, tests for size of data received, or other conditions are required. Implementation typically requires one or two lines inside a TCP program.

From rfc813, describing delayed ack:

The following scheme seems a good compromise. The receiver of data will refrain from sending an acknowledgement under certain circumstances, in which case it must set a timer which will cause the acknowledgement to be sent later. However, the receiver should do this only where it is a reasonable guess that some other event will intervene and prevent the necessity of the timer interrupt. The most obvious event on which to depend is the arrival of another segment. So, if a segment arrives, postpone sending an acknowledgement if both of the following conditions hold. First, the push bit is not set in the segment, since it is a reasonable assumption that there is more data coming in a subsequent segment. Second, there is no revised window information to be sent back.

This algorithm will insure that the timer, although set, is seldom used. The interval of the timer is related to the expected inter-segment delay, which is in turn a function of the particular network through which the data is flowing. For the Arpanet, a reasonable interval seems to be 200 to 300 milliseconds. Appendix A describes an adaptive algorithm for measuring this delay.

From the above, this is delayed ack, not Nagle. So that's why setting TcpNoDelay in Windows has no effect on the above syndrome. There's no data waiting to be transmitted (else it would have been part of the acknowledge - but that had a window size of 0, so no data was sent). However, tcpAckFrequency does govern this delayed ack; setting it to 1 (as described in previous posts) should cause the delayed acknowledgement to be not delayed. (Important note: Microsoft's knowledge base indicates that a hotfix is required before setting tcpAckFrequency to 1 works. I suspect that's why some people don't see it working...)

Although the push bit is set on the incoming segment (the 'P'), the acknowledgement is delayed, anyway. I guess whomever implemented the TCP stack in Windows didn't bother following the reference in rfc1122 to rfc813. Grrr. (As a side-note, I'm going to assume that Macs don't suffer from this problem, since OS X was derived from a BSD variant, and I don't believe any of their TCP stacks are that broken.)

So far, so good. So why does a local proxy work in solving the problem as well? (either a linux gateway, or a vmware partition, or whatever). Well, this is what the packet trace looks like, on the proxy:

11:28:00.686393 IP wow.server.3724 > proxy.32800: P 14746:14824(78) ack 162 win 14600
11:28:00.686394 IP proxy.32800 > wow.server.3724: . ack 14824 win 17520
11.28.00.686396 IP proxy.3724 > wow.client.1230: P 14746:14824(78) ack 162 win 14600
11:28:00.857213 IP wow.client.1230 > proxy.3724: . ack 14824 win 17520

So, the proxy immediately acknowledges the packet from the server; the client still delays its ack. But the important thing is that the ack destined for the server is immediate.

Finally, lowerping. People have reported that lowerping gives lower in game latency than setting tcpAckFrequency, and that tcpAckFrequency gives improvements as well. Why is this? I'm going to ask a related question: why does removing the delayed ack locally (either by proxy or tcpAckFrequency) work to reduce in-game latency anyway?

See,

11:28:00.857213 IP wow.client.1230 > wow.server.3724: . ack 14824 win 17520

is just an acknowledgement. There's no information from the client in that packet, except something that says 'I got your packet'. Specifically, there's nothing related to user data - and so there's nothing there that directly speeds up the 'something happens on the server' to the 'user's response to that something reaches the server' time (which you could consider the important thing that in-game latency measures). So, why does removing the delay work? The answer would seem to be at the server (and this is worth putting in a paragraph all of its own):

Blizzard have Nagle's algorithm enabled on their servers.

If this is the case, then new data from the server is not transmitted until either a full packet (i.e. 1.5k of data) is available, or the previous packet is acknowledged (as per the description in rfc896, quoted above). But, with delayed ack at the client, this previous packet acknowledgement is sent ~170ms later than it could be, so new data from the server is delayed for another ~170ms i.e. it is delayed by up to 'network latency from server to client and back' + 170ms. For oceanic people that's ~250ms + 170ms i.e. ~ 420ms. Rather than just 250ms. So 'client action' to 'response from server arrives at client' is between 250ms and 670ms.

And that's where the latency comes from. And that's why lowerping works better. Their network latency from server to client and back is much lower (because, so far as the server is concerned, the client is in the US), and so data is queued up at the server for much less time.

So this:

* Reduced network latency by disabling the Nagle algorithm.

from the 2.3.2 patch notes appears to have been done on the client. It appears not to have been done on the server. (If it had been done on the server, removing delayed acks would not make *any* change to observed in-game latency. They still do. QED.)

The obvious solution is then that Blizzard should disable Nagle on their servers. However, I should point out that this could have serious negative impacts.

(a) The amount of bandwidth Blizzard uses would increase. That's because they'd be sending more packets to us. While the amount of server -> client data would remain the same, the overhead of packet headers would increase. And with many small packets, the packet header overhead predominates bandwidth consumption.

(b) The amount of bandwidth your client requires would also increase. For the same reason, more packets being sent to your client implies more bandwidth you need. And this would imply the 'Razorgore client disconnect syndrome' (in which the server sends more data to your client than your connection can handle, leading the server to believe that your client has timed out, and so disconnect you) would become more likely to happen. Especially if you're still on dialup.

So, I don't know.

PS. This is a reasonably well-known problem with delayed ack + Nagle. It's mentioned (in not quite so many words) in the wikipedia article for Nagle's algorithm, for instance...

PPS. I'll probably be posting this on the official forums once I find somewhere that it won't immediately disappear into the morass. Or unless someone here finds where I've been incredibly stupid, and I'm entirely wrong about what's going on. (It's happened before.)

◊ Greenexile · 04/28/08, 8:40 PM

Nice post.

Does this mean that Blizzard would need to pay for more bandwidth (a lot more) in order to improve oceanic pings in the same way that lowerping.com / others can? Sorry I know nothing about networking, but I'm guessing from your post the ultimate conclusion is that it would cost Blizzard a significant amount of money to fix things - and thus a fix from their end is pretty unlikely?

Avele · 04/28/08, 9:41 PM

Originally Posted by Greenexile

Does this mean that Blizzard would need to pay for more bandwidth (a lot more) in order to improve oceanic pings in the same way that lowerping.com / others can? Sorry I know nothing about networking, but I'm guessing from your post the ultimate conclusion is that it would cost Blizzard a significant amount of money to fix things - and thus a fix from their end is pretty unlikely?

Potentially. All I can say is that they'd use more bandwidth. How *much* more, I have no idea. I have no idea how small the messages their protocol can send are, so I'm unable to tell how many more packets they'd be generating if they turned Nagle off. I *also* don't have any idea of how many clients would be affected by the change (i.e. how many people in the US, with reasonably low latency, would still see more packets heading their way - and how many more packets that would be; I'm guessing that a small percentage increase for that class of people would outweigh all of Oceania...) Too many unknowns, too much data that only Blizzard have access to. And possibly they'd have to guess at the impact too.