Verzion lag issue is still in the building (probably)

[Suggestion]

Edit, my data is not correct to support this thread, forgive me for my ignorance. I still hope that some true salvation from server lag will be attained in the near future and that the only way to address it is to keep talking about it.

I say this because after SE acknowledged that a large portion of their customers were lagging do to P2p Throttling (i think that was the term) the following 3 days after that, lag progressively showed up later and later. Becoming nonexistent during peak hours. Which was awesome and amazing and i thought about making a thread that dedicated thanks to the dev lords for finally (to my knowledge addressing the issue).

But as of the past two days the lag has returned during peak hours and im forced with a decision to doom fellow dungeon mates with a laggy SMN or log off and call it a night... er afternoon.

Anyroad! This is a trace route from my isp to Zaleras server that i took because i wanted to be sure i was right, even if it was just my computer



Tracing route to 199.91.189.57 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [000.000.0.0]
2 7 ms 4 ms 4 ms L100.DLLSTX-VFTTP-58.verizon-gni.net [173.71.9.1
]
3 11 ms 12 ms 8 ms G0-14-2-3.DLLSTX-LCR-22.verizon-gni.net [130.81.
223.166]
4 * * * Request timed out.
5 6 ms 6 ms 8 ms 0.ae2.BR2.DFW13.ALTER.NET [140.222.225.53]
6 10 ms 9 ms 11 ms ix-20-0.tcore1.DT8-Dallas.as6453.net [66.110.56.
17]
7 67 ms 69 ms 68 ms 64.86.78.5
8 69 ms 67 ms 73 ms if-22-2.tcore2.CT8-Chicago.as6453.net [64.86.79.
1]
9 67 ms 78 ms 68 ms if-3-2.tcore1.W6C-Montreal.as6453.net [66.198.96
.45]
10 112 ms 118 ms 110 ms 66.198.96.50
11 65 ms 66 ms 65 ms 192.34.76.2
12 64 ms 67 ms 76 ms 199.91.189.234
13 * * * Request timed out.

[Raist]

199.91.189.57 is no longer serving a world...hasn't been since the infrastructure changes made back in March/April. Not the first time they've changed up our IP's. May want to check the IP your client uses by loading resource monitor (resmon.exe from search/run box) after you logged fully into the game, or using one of the neolobby addresses instead:

neolobby02.ffxiv.com (this is the registered DNS name for Aether)
neolobby04.ffxiv.com
neolobby06.ffxiv.com

If you were to forward that .57 IP to your ISP to use for an investigation, they won't get any responses from that address...which will not help your case much.

As for the tracert... it is interesting that (once again) we are seeing a hop going into full ICMP rejection right at the hand off from Verizon into TATA. We continually see this happening at their peering exchanges (despite what they tell people, it is NOT that common a thing unless there is a problem with high utilization)....more of the same-old stuff we've seen in the past. Begs the question of whether they STILL have not upgraded the bandwidth at their border routers. (that link is to an interesting blog post demonstrating Verizon's refusal to make such upgrades that were obviously needed)

[Suggestion]

199.91.89.57 is no longer serving a world...hasn't been since the infrastructure changes made back in March/April. Not the first time they've changed up our IP's. May want to check the IP your client uses by loading resource monitor (resmon.exe from search/run box) after you logged fully into the game, or using one of the neolobby addresses instead:

I think you meant to put a 1 in that ip address, but anyroad.

But, what about this website http://arrstatus.com/, i definatnly see an ip address for zaleras server.

if that is true though i thank you very much for bringing it to my attention. But, even if my data doesnt support my issue, the problem remains.

[Raist]

Yeah...fat fingers on a small phone. Prone to lots of typos. Don't always catch them right away. It was documented roughly 4 months ago that some addresses were no longer serving worlds. People keep posting .57 over and over, and have also provided that address to their ISP's not knowing they are sending a bad address. Some are still using a bad address from 1.0 that is actually a web server on someone else's network.

As has been noted often in these forums, arrstatus has not kept up with the IP changes, and it has never been entirely accurate since SE implemented the separate lobby services shortly after 2.0's official launch. Ever since that change it has been noted that each world can be served by at least 3 IP addresses and that site has always only listed one address with each world (and the same IP is listed for multiple worlds as well). They even only show the one lobby address that is bound to neolobby02...but the game uses 3 unique addresses per region for lobby services (the DNS names are embedded in the files).

I have never used that .28 for Midgard they've listed for about a year now. I've used .74 (prior to the lobby server revamp), .25, .30,and.31...but never .28. It is important to use a valid, actively responding address for testing--especially if bringing the ISP in to investigate.

[Suggestion]

Yeah...fat fingers on a small phone. Prone to lots of typos. Don't always catch them right away. It was documented roughly 4 months ago that some addresses were no longer serving worlds. People keep posting .57 over and over, and have also provided that address to their ISP's not knowing they are sending a bad address. Some are still using a bad address from 1.0 that is actually a web server on someone else's network.

As has been noted often in these forums, arrstatus has not kept up with the IP changes, and it has never been entirely accurate since SE implemented the separate lobby services shortly after 2.0's official launch. Ever since that change it has been noted that each world can be served by at least 3 IP addresses and that site has always only listed one address with each world (and the same IP is listed for multiple worlds as well). They even only show the one lobby address that is bound to neolobby02...but the game uses 3 unique addresses per region for lobby services (the DNS names are embedded in the files).

I have never used that .28 for Midgard they've listed for about a year now. I've used .74 (prior to the lobby server revamp), .25, .30,and.31...but never .28. It is important to use a valid, actively responding address for testing--especially if bringing the ISP in to investigate.

Quite an eye opener thanks for the info

[I_Punch_Bees]

I will just say this.

I am on Verizon. I live in PA. I can only play FF14 with WTFast. If not, I DC every 10 minutes.

I can do anything else in any other game. But I can't with FF14.

Verizon says it is not them. That it is FF14 itself.

[Raist]

I will just say this.

I am on Verizon. I live in PA. I can only play FF14 with WTFast. If not, I DC every 10 minutes.

I can do anything else in any other game. But I can't with FF14.

Verizon says it is not them. That it is FF14 itself.

If that were true the VPN wouldn't fix it. The VPN alters how your traffic is routed. Your ISP sets the policies in motion that govern how your packets are handled.

The VPN encrypts the data (potentially bypassing some shaping rules that may be put in place by your ISP and/or their peering partner), and then gives you a means to alter the path your packets take to get to the servers in Montreal. That path is normally managed by your ISP's policies first and then further by their peering partner, but when you tunnel to a different region through a VPN you get a chance to switch off and play by someone else's routing rules.

Another important thing to note also: the servers are in Montreal Canada. Chances are those other services do not face the same routing challenges you have getting specifically to Ormuco's networks in Montreal.

Edit:
It is interesting to see how frequently Verizon keeps pushing the blame to SE, and yet other ISP's have been able to address problems for their customers. It's not just my story with TWC fixing it...but reports have come in from around the world where an ISP found an issue and fixed it. People have also switched ISP's or moved and it got better. Lots of others like you found a VPN fixes it (which quite clearly demonstrates a routing issue).

But for some strange magical reason it just can't possibly be something that Verizon is/isn't doing differently.