Does Anet/Amazon monitor server/network load and packet loss?

[Anthonev.6452]

It's been happening on and off for the past few months and of course with the just new released story update, which brings more people back on line, my ping and hence server/skill lag takes a significant jump, making the game mostly unplayable.

I use to have a ping of around 260-270, but not its base 320 and into the 1-2K when things just totally lag out.

I have no other connection issues with anything else and every time I do a trace during the lag spikes, the slowdown/packet loss is always on Amazon IP numbers.

Surely if things where being monitored, higher packet resend stats would be ringing alarm bells and something done about it.

[Anthonev.6452]

To give people an idea, here's the specific Amazon IP that right now is giving me 600+ ping with packet loss.

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                           52.93.254.213 -   17 |   60 |   50 |  327 |  587 |  641 |  598 |
 

That is while just sitting in the PvP Lobby and yes, I looked it up. That IP number falls within the IP range that is a direct allocation to Amazon Technologies Inc.

All the hops that are more or less my ISP leading up to that are error free and sub 300ms.

[Anthonev.6452]

Another day and no better.

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                           52.93.254.199 -    0 |  338 |  338 |  364 |  483 |  582 |  374 |
|                            52.93.28.126 -    0 |  338 |  338 |  340 |  427 |  587 |  359 |
 

Well, a little better, not so much packet loss this time, but still high ping rate of 500+

Minor different IP numbers, but still all Amazon servers/routers. Clearly they just can't handle the load.

[fatihso.7258]

You can’t see the ping to gw2 amazon servers outside of game client or your own aws with enabled ping. Can only ping public amazon ip addresses and the outcome is not identical to how well gw2 servers are doing that moment. Most of the time gw2 servers don’t have ping issues Amazon as a live service offers one of the better reliability globally? Let me just say if your best average is 260ms then you should consider even a small ruffle in your route will affect your ping more than anyone else due to your distance to server. I suggest you to start looking at your isp’s contracted international data carrier partners to see which ones they use for your outbound traffic bcs it cost money and they usually don’t use the best partner. You would be surprised how much of a difference which partner your isp use. 

[Jin.8501]

Try to change the route your connection takes to the servers? Could be some issues in between the servers and you 

[Anthonev.6452]

Apart from the first few hops being directly my ISP, which in Australia are sub 30, the next lot are 'atlas.cogentco.com', as it goes across the pacific, etc. Those are all around 220 or less.

Then I start to hit the Amazon IP's, along with a bunch of 'no response'. That's when I got the already shown 500+.

When it comes to international data outside of Australia, there's really not a lot of options.

23 hours ago, Jin.8501 said:

Try to change the route your connection takes to the servers?

And how would I do that, since I don't have a VPN and really shouldn't have to pay more to get a working connection.

[costepj.5120]

16 minutes ago, Anthonev.6452 said:

Then I start to hit the Amazon IP's, along with a bunch of 'no response'.

Many organisations configure their edge devices to suppress/limit ICMP traffic such as Ping/echo response as a security measure or to protect bandwidth.

[Anthonev.6452]

So, I have an update on all this, which is possible much the same 'random' problem that others get as well.

First I need to apologize to Amazon, as it seems the issue isn't the servers/routers control, it just looks that way doing a normal network trace.

As luck would have it, I seem to have made contact with someone deep within the networking of AWS who could look into things much deeper, including a back trace to my IP.

Long story short, the issue is with my ISP or more specific, the routing policy they have in place for the return path of the packets. Instead of coming back direct from US to AUS, sometimes they are going via Hong Kong. This has two affects. First, it just adds a bit more latency, so going from 260-270 to 320.

Second, at times the network traffic around and between Hong Kong gets congested, at which point pings then jump from being more annoying to totally unplayable.

However, there's another twist. You can have two people, with the same ISP, in the same state and even be on the same server/map instance in GW2 but one of them can totally lag out while the other has no such issues. Basically who does or doesn't get impacted can change depending on your local public IP where the first three octets are all the same for both players, so x.x.x.5 gets lag, while x.x.x.10 is fine.

Edited January 12 by Anthonev.6452
Typo

[Mistwraithe.3106]

I think ISP routing is often the problem. I have a VPN because of this and usually if I encounter lag problems then starting up the vpn and restarting gw2 will fix it. This pretty much rules out Anet’s server speed, my computer and my direct isp connection as problems.

Edited January 13 by Mistwraithe.3106

[Anthonev.6452]

Yeah, still, one really shouldn't need a VPN to 'fix' poor ISP config issues. I even had a support ticket open with my ISP and their 'network team' said the best route was already being used. Starting to wonder if at the time they only looked at the packets being sent and not those on the return path, which is where the problem is.

Either that or the return path at the time they looked wasn't broken.