High ping in Final Fantasy XIV only.

[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.