High ping in Final Fantasy XIV only.

[TheJyu]

As reported by other players, I'm also suffering from high ping exclusively on Final Fantasy XIV to the Chaos Data Center, around an average of 125ms~.

I've talked to Square Enix support who instructed me to post about this issue on the forums. I've also already tried to talk to my ISP who'se answer was that the problem was not on their side, so that's why I'm following the support suggestion on posting here.

A trace route seems to reveal there is a problem in the path to the server:
1 1 ms 1 ms 1 ms NOSDRIVE [192.168.1.1]
2 * * * Request timed out.
3 10 ms 11 ms 11 ms 10.137.197.161
4 12 ms 11 ms 8 ms 10.255.48.86
5 26 ms 30 ms 26 ms ix-ae-3-0.tcore1.pv9-lisbon.as6453.net [195.219.185.29]
6 108 ms 106 ms 105 ms if-ae-1-3.tcore1.sv8-highbridge.as6453.net [80.231.158.30]
7 107 ms 106 ms 107 ms if-ae-2-2.tcore2.sv8-highbridge.as6453.net [80.231.139.1]
8 * * * Request timed out.
9 107 ms 112 ms 106 ms if-ae-66-7.tcore3.nto-newyork.as6453.net [80.231.130.23]
10 106 ms 106 ms 107 ms 63.243.186.19
11 110 ms 108 ms 106 ms nyk-bb2-link.ip.twelve99.net [62.115.135.132]
12 115 ms 114 ms 114 ms ldn-bb1-link.ip.twelve99.net [62.115.113.21]
13 116 ms 117 ms 117 ms prs-bb1-link.ip.twelve99.net [62.115.135.25]
14 124 ms * 125 ms ffm-bb1-link.ip.twelve99.net [62.115.123.12]
15 126 ms 123 ms 122 ms ffm-b10-link.ip.twelve99.net [62.115.137.227]
16 123 ms 123 ms 123 ms kddi-ic301630-ffm-b10.ip.twelve99-cust.net [62.115.32.110]
17 124 ms 123 ms 123 ms 195.82.60.29
18 143 ms 125 ms 123 ms 195.82.61.14
19 * 1325 ms 1359 ms 195.82.50.230
20 125 ms 124 ms 122 ms 195.82.50.9

Trace complete.

As you can see, for some reason, the connection is going through New York and there's no reason for that, since I'm in Portugal connecting to a server in Germany.

To provide answer to questions I've seen previously asked:
- Are you using a wired or wireless connection?
I'm using a wired connection.
- Do you have any firewalls or anti-virus software installed on the machine if are using a Mac or Windows PC? If so, which ones do you have installed?
None other than Windows Defender, which I've already tried to disable and also allow Final Fantasy to bypass. Since the question is asked about Mac and PC, I will add that the problem also happens in Playstation, so it's not related to that.
- Internet Service Provider
NOS Portugal.
- Location/Region you are in (Not in game, your actual location)
Portugal
- Does any specific error message/code occur when the issue happens?
No.
- Does the issue only happen with one specific character or time frame? Please clarify.
No. All character and consistent all day and have been through quite some time, according to feedback from other players I've seen on portuguese boards.

[Risvertasashi]

Welcome to SE's networking. You can try to use a VPN to get around the bad route. Otherwise... well, it is what it is.

[worldofneil]

Welcome to SE's networking. You can try to use a VPN to get around the bad route. Otherwise... well, it is what it is.

I'm all for blaming Square Enix when they do something wrong, but in this case it's nothing to do with them, they're the destination and have no control over how the Internet provider routes the traffic to get to them.

Simplifying it, when you want to go somewhere on the Internet your provider tells your computer how to get there and what route to take, but in this case it's sending them via New York instead of directly across Europe.

Why? I don't know for sure, but it's usually cost. The Internet provider will have agreements with multiple other providers and sending the traffic this way probably saves them money. The traffic still gets to where it needs to go and they saved some money by sending it this way... at the cost of some latency to the customer. In most cases (web based traffic) this wouldn't really be noticeable, but unfortunately as this is game traffic, it is.

Using a VPN fixes this because VPN providers have multiple servers around the world and when using a VPN it will connect to them (using as little of your Internet providers routing as possible) and then they will send the traffic through their own network in which they control the routing as they have multiple points they can use. Internet providers generally only operate in a single country so they have to pass the traffic to other companies, hence the agreements mentioned above.

Basically the options are:

A) Lean on ISP to change the routing, it'll probably be hard to get through to someone who even can change it and they probably won't though.
B) Change Internet provider and hope they have different routing
C) Use a VPN service
D) Wait and hope it gets better/routing changes in the future (I know this isn't a great option, but it is still technically an option)

Sorry I know this isn't overly helpful, but unfortunately posting here won't do anything as Square Enix don't own your Internet Provider and can't influence how they route traffic.

[Celte]

Seems most of us with this lag that began suddenly are in Portugal, though I've seen some say they're from Germany.

[Shinjo]

It's true that the routing isnt SE fault and they cant do anything about that BUT i would also rather look at the ip 195.82.50.230 with the high ms number.
There are dozen't of reports (old and new) and complains about the this IP in the EU datacenter.
Its part of KDDI Deutschland GmbH (who is a part of KDDI Japan i guess) and is hosting the EU servers.
I'm not playing on spriggan but here is my tracert to that server.

1 1 ms 1 ms 1 ms fritz.box [192.168.178.1]
2 * * * Zeitüberschreitung der Anforderung.
3 9 ms 7 ms 7 ms de-wup01a-rd02-ae10-2020.wup.unity-media.net [81.210.133.190]
4 16 ms 13 ms 15 ms de-fra04d-rc1-re0-aorta-net-ae-41-0.aorta.net [84.116.197.22]
5 11 ms 13 ms 11 ms 84.116.190.94
6 16 ms 19 ms 12 ms ae8-100-tcr1.fnt.cw.net [195.2.26.93]
7 11 ms 11 ms 11 ms ae34-pcr1.fnt.cw.net [195.2.31.38]
8 12 ms 12 ms 14 ms telia-gw.fnt.cw.net [195.2.22.238]
9 13 ms 14 ms 11 ms ffm-bb2-link.ip.twelve99.net [62.115.124.118]
10 11 ms 12 ms 11 ms ffm-b10-link.ip.twelve99.net [62.115.137.211]
11 12 ms 12 ms 14 ms kddi-ic301630-ffm-b10.ip.twelve99-cust.net [62.115.32.110]
12 12 ms 11 ms 11 ms 195.82.60.29
13 13 ms 12 ms 12 ms 195.82.61.14
14 1339 ms 1226 ms 1332 ms 195.82.50.230
15 13 ms 11 ms 10 ms 195.82.50.9

We have 01:33 am in morning (or night) so the servers and dataload should be pretty low but the 195.82.50.230 still have extrem high ping.... it gets low maybe around 4 ~ 7 am and then gets higher again.
A VPN sadly also dosen't help if the server at finish line is broken, overloaded or whatever.

[worldofneil]

i would also rather look at the ip 195.82.50.230 with the high ms number.

Sorry, but you're misreading the data. A high ping there isn't necessarily a problem, especially as the node after it is just fine.

All we really care about is the latency that you get with the destination (195.82.50.9) which is 10-13 ms in your example. The main job of that 195.82.50.230 router is to forward the packets to the next node as quickly as possibly and it's doing that, because you only have that 10-13 ms.

However when you do a traceroute it sends a ping to each node along the way. Some nodes won't even respond to pings (but they still forward packets as they're supposed to) and others such as 195.82.50.230 don't prioritise ping replies so although you do get a reply, it's just delayed because it's focusing on forwarding the packets.

A traceroute is good for showing the path and seeing where the latency increases, but a single high node should be ignored, if subsequent nodes are still low because it means that node isn't causing any delays, only that it is slow to reply to pings.

I hope this helps to make sense?

[Shinjo]

Sorry, but you're misreading the data. A high ping there isn't necessarily a problem, especially as the node after it is just fine.

All we really care about is the latency that you get with the destination (195.82.50.9) which is 10-13 ms in your example. The main job of that 195.82.50.230 router is to forward the packets to the next node as quickly as possibly and it's doing that, because you only have that 10-13 ms.

However when you do a traceroute it sends a ping to each node along the way. Some nodes won't even respond to pings (but they still forward packets as they're supposed to) and others such as 195.82.50.230 don't prioritise ping replies so although you do get a reply, it's just delayed because it's focusing on forwarding the packets.

A traceroute is good for showing the path and seeing where the latency increases, but a single high node should be ignored, if subsequent nodes are still low because it means that node isn't causing any delays, only that it is slow to reply to pings.

I hope this helps to make sense?

I'm not saying thats wrong (i'm not a technician or something like that) yet i liked at ohter servers in the other datacenters (NA, JP, OCE and again EU) but there wasnt a single node that had such a latency connected to it.
And this is suspicious to me when i only see such a node with numbers on the EU side but nowhere else.

This is now the tracert to shiva :
1 <1 ms 1 ms 1 ms fritz.box [192.168.178.1]
2 * * * Zeitüberschreitung der Anforderung.
3 9 ms 7 ms 8 ms de-wup01a-rd02-ae10-2020.wup.unity-media.net [81.210.133.190]
4 13 ms 15 ms 14 ms de-fra04d-rc1-re0-aorta-net-ae-41-0.aorta.net [84.116.197.22]
5 17 ms 15 ms 14 ms 84.116.190.94
6 14 ms 12 ms 11 ms ae6-100-xcr2.fri.cw.net [195.89.100.33]
7 14 ms 17 ms 15 ms ae4-pcr1.fnt.cw.net [195.2.16.33]
8 12 ms 11 ms 13 ms telia-gw.fnt.cw.net [195.2.22.238]
9 13 ms 17 ms 12 ms ffm-bb2-link.ip.twelve99.net [62.115.124.118]
10 13 ms 11 ms 12 ms ffm-b10-link.ip.twelve99.net [62.115.137.211]
11 11 ms 12 ms 12 ms kddi-ic301630-ffm-b10.ip.twelve99-cust.net [62.115.32.110]
12 13 ms 19 ms 15 ms 195.82.60.29
13 15 ms 13 ms 13 ms 195.82.61.14
14 14 ms 13 ms 10 ms 195.82.50.230
15 12 ms 12 ms 10 ms 195.82.50.57

If the high number would be normal (because of the focusing on packets) then why is the number now (at 4:36 am).

This the NA server Balmung:
1 1 ms 1 ms 1 ms fritz.box [192.168.178.1]
2 * * * Zeitüberschreitung der Anforderung.
3 45 ms 8 ms 7 ms de-wup01a-rd02-ae10-2020.wup.unity-media.net [81.210.133.190]
4 12 ms 13 ms 12 ms de-fra04d-rc1-re0-aorta-net-ae-41-0.aorta.net [84.116.197.22]
5 11 ms 13 ms 11 ms 84.116.190.94
6 12 ms 11 ms 11 ms ae32-100-pcr1.fnt.cw.net [195.2.18.217]
7 89 ms 88 ms 95 ms ae17-tcr1.pat.cw.net [195.2.9.126]
8 88 ms 90 ms 88 ms et-7-1-0-xcr1.nyh.cw.net [195.2.24.241]
9 93 ms 88 ms 89 ms ae30-xcr2.nyk.cw.net [195.2.16.134]
10 88 ms 88 ms 88 ms ae-36.a01.nycmny17.us.bb.gin.ntt.net [128.241.2.153]
11 96 ms 89 ms 89 ms ae-5.r21.nwrknj03.us.bb.gin.ntt.net [129.250.4.174]
12 108 ms 106 ms 106 ms ae-3.r22.chcgil09.us.bb.gin.ntt.net [129.250.2.166]
13 109 ms 109 ms 106 ms ae-1.r23.chcgil09.us.bb.gin.ntt.net [129.250.2.27]
14 158 ms 158 ms 159 ms ae-1.r24.snjsca04.us.bb.gin.ntt.net [129.250.5.17]
15 161 ms 160 ms 161 ms ae-4.r00.scrmca02.us.bb.gin.ntt.net [129.250.7.57]
16 160 ms 166 ms 161 ms xe-0-1-0-1-1.r00.scrmca02.us.ce.gin.ntt.net [192.80.16.2]
17 160 ms * * 204.2.229.230
18 160 ms 160 ms 160 ms 204.2.229.106

But no extreme high node there even still being in primetime (19:47 sacramento where the servers should be i guess)...
I still believe there is a problem in the EU datacenter be hardware or bandwith issues... it just makes no sense why the EU node in the datancenter of KDDI be the only node with extremly high latency.
The ohter datacenter (NA, JP, OSCE) should also have a node in their datacenter hat is focusing on forwarding the packets but still dosent have a high lantency.

Sorry for my bad (probaly VERY bad) english but it's just dosent make sense to me why our EU datacenter shows a different behavior in the tracert routing.

[worldofneil]

If the high number would be normal (because of the focusing on packets) then why is the number now (at 4:36 am).

Well I don't have access to that router to see the statistics for myself, but at a guess it's because like you said it's the early hours of the morning. Less people are using the network, so there's less traffic to forward and therefore the router has less to do and can reply to pings faster. As I said in my previous message it's main job is to forward packets, replying to pings is low priority that it'll do after it's forwarded the traffic.

But no extreme high node there even still being in primetime (19:47 sacramento where the servers should be i guess)...

I understand what you're trying to say, but you're still focusing on the wrong thing and you gave a good example of this with your traceroute to Balmung, specifically hop 17:

17 160 ms * * 204.2.229.230

Your traceroute sent 3 pings to that node, it replied to one of them, but two of them timed out waiting for a response. Because the router replied to 1 ping it means it is configured to reply to pings (instead of 3 stars which might suggest it ignores pings), but in this case the latency was so high (probably more than 2000) your traceroute gave up waiting for a reply. So really you should replace those stars with 2000+ and then you see you do have a high latency node that you were looking for. If you're using the Windows tracert command then using the -w flag will increase the timeout, such as -w 5000 would wait 5 seconds (5000 ms) for a reply and you'll likely see a number instead of a star.

But... as I've tried to explain, that doesn't matter. As long as the latency on the nodes before and after is comparable it means the router correctly forwarded the traffic with minimal delay. It's when the latency jumps up and STAYS up for the rest of the traceroute then you can see where the delays are.

Like in your Balmung example there's two big jumps:

1 1 ms 1 ms 1 ms fritz.box [192.168.178.1]
2 * * * Zeitüberschreitung der Anforderung.
3 45 ms 8 ms 7 ms de-wup01a-rd02-ae10-2020.wup.unity-media.net [81.210.133.190]
4 12 ms 13 ms 12 ms de-fra04d-rc1-re0-aorta-net-ae-41-0.aorta.net [84.116.197.22]
5 11 ms 13 ms 11 ms 84.116.190.94
6 12 ms 11 ms 11 ms ae32-100-pcr1.fnt.cw.net [195.2.18.217]
7 89 ms 88 ms 95 ms ae17-tcr1.pat.cw.net [195.2.9.126]
8 88 ms 90 ms 88 ms et-7-1-0-xcr1.nyh.cw.net [195.2.24.241]
9 93 ms 88 ms 89 ms ae30-xcr2.nyk.cw.net [195.2.16.134]
10 88 ms 88 ms 88 ms ae-36.a01.nycmny17.us.bb.gin.ntt.net [128.241.2.153]
11 96 ms 89 ms 89 ms ae-5.r21.nwrknj03.us.bb.gin.ntt.net [129.250.4.174]
12 108 ms 106 ms 106 ms ae-3.r22.chcgil09.us.bb.gin.ntt.net [129.250.2.166]
13 109 ms 109 ms 106 ms ae-1.r23.chcgil09.us.bb.gin.ntt.net [129.250.2.27]
14 158 ms 158 ms 159 ms ae-1.r24.snjsca04.us.bb.gin.ntt.net [129.250.5.17]
15 161 ms 160 ms 161 ms ae-4.r00.scrmca02.us.bb.gin.ntt.net [129.250.7.57]
16 160 ms 166 ms 161 ms xe-0-1-0-1-1.r00.scrmca02.us.ce.gin.ntt.net [192.80.16.2]
17 160 ms * * 204.2.229.230
18 160 ms 160 ms 160 ms 204.2.229.106

"fnt" (6) and "pat" (7) are going to be locations, although not ones I'm familiar with, but they're possibly quite far apart geographically and if so that would explain why it jumps up 75+ ms from then on.

"chcgil" (13) is Chicago, Illinois and "snjsca" (14) is San Jose, California, they're about 2000 miles apart so an increase of 50 ms there seems very reasonable.

Sorry if I'm not explaining very well, but what I'm trying to say is the only ping that matters if the one for where you're trying to go. The traceroute is helpful in showing why you're getting that ping/where the delays, but you can't just look at the ping of an individual node.

[TsunaYoshi]

Since 7:30 UTC:

1 1 ms <1 ms <1 ms 155.55.15.5
2 10 ms 8 ms 8 ms loopback1.0003.acln.01.ham.de.net.telefonica.de [62.52.200.149]
3 9 ms 8 ms 8 ms bundle-ether29.0006.dbrx.01.ham.de.net.telefonica.de [62.53.12.22]
4 20 ms 15 ms 19 ms ae5-0.0001.corx.06.ham.de.net.telefonica.de [62.53.14.232]
5 18 ms 16 ms 15 ms ae6-0.0002.corx.02.fra.de.net.telefonica.de [62.53.0.49]
6 17 ms 16 ms 19 ms bundle-ether2.0001.dbrx.01.off.de.net.telefonica.de [62.53.0.199]
7 16 ms 15 ms 15 ms ae9-0.0001.prrx.13.fra.de.net.telefonica.de [62.53.11.131]
8 * * 16 ms 5.53.1.64
9 141 ms 144 ms 165 ms ffm-b5-link.ip.welve99.net [62.115.37.18]
10 152 ms 158 ms 169 ms ffm-bb2-link.ip.twelve99.net [62.115.114.90]
11 177 ms 177 ms 156 ms ffm-b10-link.ip.twelve99.net [62.115.137.211]
12 140 ms 148 ms 159 ms kddi-ic301630-ffm-b10.ip.twelve99-cust.net [62.115.32.110]
13 165 ms * 170 ms 195.82.60.29
14 173 ms 163 ms 166 ms 195.82.61.14
15 1468 ms 1377 ms 1505 ms 195.82.50.230
16 153 ms 160 ms 168 ms 195.82.50.56

This looks the same for Odin, Twin or the Instanceserver.

Normal i have 20Ping, today its 170.

So whatevery this is, it is not a ISP problem, its on SE to cover this.

https://www.findip-address.com/
195.82.50.230


ISP KDDI Deutschland GmbH
Thats maybe the Hosting for SE? Would not be the first time some HW issues appear...


I actually wrote KDDI a Mail. idk if its related at all but, for me its fixed now. The Delay on twelve99.net is gone:

Tracing route to 195.82.50.56 over a maximum of 30 hops

1 1 ms <1 ms 1 ms 155.55.15.5
2 12 ms 42 ms 12 ms loopback1.0003.acln.01.ham.de.net.telefonica.de [62.52.200.149]
3 13 ms 12 ms 12 ms bundle-ether29.0006.dbrx.01.ham.de.net.telefonica.de [62.53.12.22]
4 20 ms 18 ms 19 ms ae5-0.0001.corx.06.ham.de.net.telefonica.de [62.53.14.232]
5 20 ms 19 ms 19 ms ae6-0.0002.corx.02.fra.de.net.telefonica.de [62.53.0.49]
6 20 ms 19 ms 19 ms bundle-ether2.0001.dbrx.01.off.de.net.telefonica.de [62.53.0.199]
7 20 ms 19 ms 19 ms ae9-0.0001.prrx.13.fra.de.net.telefonica.de [62.53.11.131]
8 * 20 ms 19 ms 5.53.1.64
9 20 ms 19 ms 19 ms ffm-b5-link.ip.twelve99.net [62.115.37.18]
10 20 ms 19 ms 19 ms ffm-bb2-link.ip.twelve99.net [62.115.114.90]
11 21 ms 19 ms 19 ms ffm-b10-link.ip.twelve99.net [62.115.137.211]
12 20 ms 19 ms 19 ms kddi-ic301630-ffm-b10.ip.twelve99-cust.net [62.115.32.110]
13 22 ms 19 ms 20 ms 195.82.60.29
14 21 ms 19 ms 19 ms 195.82.61.14
15 1290 ms * 1330 ms 195.82.50.230
16 20 ms 19 ms 18 ms 195.82.50.56

Trace complete.

My Ping is back to 20ms now.
195.82.50.230 seems unrelated to the high ping problem.

[IvyTayuun]

I've been having this issue for months and i'm from the same ISP (NOS Portugal)

It has been going on for the past 4 months, i've tried contacting the ISP so much that i've got into contact with the Networking team, and they tried to be smart about it saying its on the Game company's fault here.

But this is only an issue with NOS Specifically as all my other Portuguese friends have other providers and i've been paying a damn VPN to be even able to play the game, i have a consistent 220 ping and the Trace is going back to New York, the routing is wrong and nothing has changed.

On the forums of NOS Portugal there is a Thread specifically about this situation towards FFXIV and theres about 7 Pages of multiple people complaining and they haven't solved the issue for months.

Is the only way really continuing paying for a VPN or change ISP here?