Thank you for the reply! I know the SE side is limited since it's not in their direct control, but we appreciate any pressure that the SE side can put on those involved to get this fixed for your customers.Hello everyone,
We're aware that some users playing on the North American data center have been experiencing network delays and/or packet loss while playing. We understand the frustrations and concerns regarding the situation, especially with Patch 6.4 and new Savage raids on the horizon.
The Community team has been relaying your reports to the Development team as they continue their ongoing investigation. If your network connection seems to be slower or stuttering more than usual, we would appreciate it if you could take a moment to follow the instructions detailed in this Lodestone announcement and share your information with us through this form.
Thank you,
link worked for me lol maybe turn off your vpn
I managed to contact NTT, the guy was very nice and told me that this is on ATT, there's nothing wrong with their equipment. As a courtesy he performed some tests.
Good day,
Per our conversation, I have investigated your traceroute result. I want to add a caveat that this as a courtesy email response, because technically, if ATT is your upstream provider, you will need to work with ATT on this potential packet loss issue.
With that said, I do not see any issue within the NTT network that would cause your packet loss issue. I would suggest to work with ATT if they are your upstream provider.
Per your traceroute result:
7 25 ms 31 ms 31 ms 32.130.25.67 <<< This is the ATT node that is handing off traffic to NTT in Dallas, Tx
8 40 ms 36 ms 30 ms ae-5.a00.dllstx14.us.bb.gin.ntt.net [129.250.8.237] <<< This is the ATT node where the traffic is picked up by NTT
9 * * * Request timed out. <<< This is a node that is not responding to ICMP, does not indicate packet loss or latency
10 * * * Request timed out. <<< This is a node that is not responding to ICMP, does not indicate packet loss or latency
11 116 ms 117 ms * ae-5.a01.scrmca03.us.bb.gin.ntt.net [129.250.2.7] <<< The ms increase between Hop 8 and 11 is expected as the traffic traverses the NTT network between Dallas, TX to Sacramento, CA
12 118 ms 117 ms 116 ms ae-1.a00.scrmca03.us.bb.gin.ntt.net [129.250.4.76] <<< The ms stayed consistent
13 117 ms 119 ms * xe-0-0-5-0.a00.scrmca03.us.ce.gin.ntt.net [128.241.2.18] <<< The ms stayed constsent
Hopes 14 and 15 is where NTT hands off to a peer where the trace reaches its destination.
I performed a ping from our Dallas, TX node to the destination IP 204.2.29.87. And I did not receive any packet loss.
dllstx1> ping 204.2.29.87 count 100
May 17 23:03:36
PING 204.2.29.87 (204.2.29.87): 56 data bytes
64 bytes from 204.2.29.87: icmp_seq=0 ttl=57 time=40.044 ms
64 bytes from 204.2.29.87: icmp_seq=1 ttl=57 time=39.382 ms
64 bytes from 204.2.29.87: icmp_seq=2 ttl=57 time=39.889 ms
64 bytes from 204.2.29.87: icmp_seq=3 ttl=57 time=39.235 ms
64 bytes from 204.2.29.87: icmp_seq=4 ttl=57 time=39.100 ms
64 bytes from 204.2.29.87: icmp_seq=5 ttl=57 time=39.304 ms
64 bytes from 204.2.29.87: icmp_seq=6 ttl=57 time=39.403 ms
64 bytes from 204.2.29.87: icmp_seq=7 ttl=57 time=40.766 ms
64 bytes from 204.2.29.87: icmp_seq=8 ttl=57 time=40.019 ms
64 bytes from 204.2.29.87: icmp_seq=9 ttl=57 time=39.395 ms
64 bytes from 204.2.29.87: icmp_seq=10 ttl=57 time=40.190 ms
64 bytes from 204.2.29.87: icmp_seq=11 ttl=57 time=39.404 ms
64 bytes from 204.2.29.87: icmp_seq=12 ttl=57 time=41.263 ms
// Truncated //
64 bytes from 204.2.29.87: icmp_seq=84 ttl=57 time=39.327 ms
64 bytes from 204.2.29.87: icmp_seq=85 ttl=57 time=39.744 ms
64 bytes from 204.2.29.87: icmp_seq=86 ttl=57 time=39.615 ms
64 bytes from 204.2.29.87: icmp_seq=87 ttl=57 time=40.364 ms
64 bytes from 204.2.29.87: icmp_seq=88 ttl=57 time=41.482 ms
64 bytes from 204.2.29.87: icmp_seq=89 ttl=57 time=39.367 ms
64 bytes from 204.2.29.87: icmp_seq=90 ttl=57 time=39.399 ms
64 bytes from 204.2.29.87: icmp_seq=91 ttl=57 time=39.247 ms
64 bytes from 204.2.29.87: icmp_seq=92 ttl=57 time=39.258 ms
64 bytes from 204.2.29.87: icmp_seq=93 ttl=57 time=39.146 ms
64 bytes from 204.2.29.87: icmp_seq=94 ttl=57 time=39.738 ms
64 bytes from 204.2.29.87: icmp_seq=95 ttl=57 time=40.225 ms
64 bytes from 204.2.29.87: icmp_seq=96 ttl=57 time=39.203 ms
64 bytes from 204.2.29.87: icmp_seq=97 ttl=57 time=39.681 ms
64 bytes from 204.2.29.87: icmp_seq=98 ttl=57 time=39.681 ms
64 bytes from 204.2.29.87: icmp_seq=99 ttl=57 time=39.263 ms
--- 204.2.29.87 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 39.096/39.843/56.776/1.873 ms
---
Victor Nadalalicea
Network Analyst, Global IP NOC
I dunno about that. It seems that AT&T and NTT need to come together to fix it.
I don't have a vpn, but thanks for the suggestion :/
Well it seems like ATT is going to have to take the initiative because as far as I know, he told me there WERE issues with ATT, and this is known to them, but that they were fine on their end.
I guess we need someone from Dallas TX that doesn't use ATT to post a trace rt and see if it goes through NTT and see if they are dropping packets. I mean, it would rule them out.
Last edited by Ath192; 05-18-2023 at 08:31 AM.
Either way, at least all parties involved have been alerted to this. I seem to recall someone else mentioning speaking to an AT&T rep earlier this week and they also were made aware of it.
Yep, believe me, I want this fixed as bad as anyone else. Just relaying what I heard when I tried.
The only other major ISP that I'm aware of that's both in the Dallas area and a direct competitor of AT&T would be Charter/Spectrum.
Unfortunately, I don't know of anyone that's seen this thread yet that could provide their traceroute. That said, that's an excellent idea, Ath192.
If anyone from DFW/North Texas on a not-AT&T ISP can provide a traceroute, let's see it.
The report form says "an unexpected error has occurred" in japanese to me.
|
![]() |
![]() |
![]() |
|
Cookie Policy
This website uses cookies. If you do not wish us to set cookies on your device, please do not use the website. Please read the Square Enix cookies policy for more information. Your use of the website is also subject to the terms in the Square Enix website terms of use and privacy policy and by using the website you are accepting those terms. The Square Enix terms of use, privacy policy and cookies policy can also be found through links at the bottom of the page.