Increase in ping and lag

[SoloD007]

Hi Square-enix network team.

From 27/07/2025 - 30/07/2025 the ping in Oceania server has jumped from around 30ms to 150/151ms (that's 5x more). What's going on...? Is it because of other players traveling over to Oceania server because their server is too congested. Could the team investigate and fix...?

C:\Users\OEM>ping 153.254.80.103

Pinging 153.254.80.103 with 32 bytes of data:
Reply from 153.254.80.103: bytes=32 time=151ms TTL=53
Reply from 153.254.80.103: bytes=32 time=152ms TTL=53
Reply from 153.254.80.103: bytes=32 time=153ms TTL=53
Reply from 153.254.80.103: bytes=32 time=150ms TTL=53

Ping statistics for 153.254.80.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 150ms, Maximum = 153ms, Average = 151ms

Also all my other characters on Oceania are experiencing the same ping. The reason why for that is because the ping from the cmd result is from my location to Oceania server.

Thanks in advance.

P.S The cmd ping test is tested using ethernet connection from PC to router. My internet connection is optical fiber. 100mbps down. 20mbps up (not that my speed is relevant here as it seems to me the Oceania server might be heavily congested or the server stability is compromised).

[Exmo]

tracert output?

[SoloD007]

tracert output?

C:\Users\OEM>tracert 153.254.80.103

Tracing route to 153.254.80.103 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.xxx.xx.1
2 * * * Request timed out.
3 4 ms 3 ms 3 ms 134.159.174.38
4 7 ms 7 ms 7 ms 134.159.174.37
5 5 ms 4 ms 7 ms i-93.tauc-core02.telstraglobal.net [202.84.227.53]
6 131 ms 131 ms 130 ms i-10520.tlot-core02.telstraglobal.net [202.84.138.82]
7 132 ms 130 ms 131 ms i-10520.tlot-core02.telstraglobal.net [202.84.138.82]
8 128 ms 132 ms 130 ms i-91.tlot02.telstraglobal.net [202.40.149.177]
9 * 129 ms * lax-b22-link.ip.twelve99.net [62.115.162.134]
10 145 ms 143 ms 148 ms ntt-ic-326358.ip.twelve99-cust.net [213.248.103.171]
11 144 ms 143 ms 143 ms ae-3.r26.lsanca07.us.bb.gin.ntt.net [129.250.3.130]
12 153 ms 168 ms 154 ms ae-5.r20.sydnau05.au.bb.gin.ntt.net [129.250.2.53]
13 152 ms 151 ms 151 ms ae-3.a00.sydnau06.au.bb.gin.ntt.net [129.250.4.28]
14 153 ms 151 ms 151 ms 199.245.24.25
15 153 ms 151 ms 151 ms 202.68.69.101
16 152 ms 151 ms 151 ms 153.254.80.103

Due to security and privacy reasons. The first IP address is partially redacted but all other relevant information is there.

P.S By the looks of it. It routes from my country ISP to HK to Square-enix JP and then to US and then to EU and then back to US and then it finally travels to AUS where the data center is. So it's traveling around the world (all the other data center location) just to sent a packet of data to a place where it should be right next to it lol.

[Exmo]

That's pretty funny

But looks like hop 6 is the interesting thing here. Would your ISP shed light on this?

[SoloD007]

That's pretty funny

But looks like hop 6 is the interesting thing here. Would your ISP shed light on this?

As far as I know. I remember when I use to play on JP data center from Oceania. I did a trace route and the packet of data had to route to Hong Kong first before it can route to Japan data center. So In this case, I believe it's a routing issue in square-enix network setting. But, to why it routes to other data center location after routing to JP such as U.S and EU and then back to AU. I wouldn't have a clue. Lol.

P.S I did ping and tracert to another AU server and I'm getting around 40 - 45 ms ping so. It's definitely not an issue with my ISP.

DNS servers in Australia ; 123.200.168.132, Brisbane, Australia 9723 iseek Communications Pty Ltd

C:\Users\OEM>ping 123.200.168.132

Pinging 123.200.168.132 with 32 bytes of data:
Reply from 123.200.168.132: bytes=32 time=47ms TTL=55
Reply from 123.200.168.132: bytes=32 time=48ms TTL=55
Reply from 123.200.168.132: bytes=32 time=48ms TTL=55
Reply from 123.200.168.132: bytes=32 time=46ms TTL=55

Ping statistics for 123.200.168.132:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 48ms, Average = 47ms

C:\Users\OEM>tracert 123.200.168.132

Tracing route to 123.200.168.132 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.xxx.xx.1
2 * * * Request timed out.
3 6 ms 3 ms 3 ms 203.109.129.97
4 10 ms 3 ms 3 ms 203.109.129.98
5 * * 4 ms 202.50.233.222
6 * * * Request timed out.
7 45 ms 47 ms 47 ms be202.lsr01.bour.nsw.vocus.network [103.1.77.14]
8 46 ms 47 ms 47 ms be801.lsr01.crek.qld.vocus.network [103.1.76.138]
9 * * * Request timed out.
10 46 ms 43 ms 43 ms be1.bdr02.bne03.qld.vocus.network [114.31.194.49]
11 43 ms 44 ms 47 ms static-230.89.255.49.in-addr.VOCUS.net.au [49.255.89.230]
12 45 ms 47 ms 47 ms 123.200.168.132

[SoloD007]

That's pretty funny

But looks like hop 6 is the interesting thing here. Would your ISP shed light on this?

and another ping and trace route to an Australia server located in Sydney.

170.64.147.31 Sydney, DIGITALOCEAN-ASN

C:\Users\OEM>ping 170.64.147.31

Pinging 170.64.147.31 with 32 bytes of data:
Reply from 170.64.147.31: bytes=32 time=33ms TTL=51
Reply from 170.64.147.31: bytes=32 time=30ms TTL=51
Reply from 170.64.147.31: bytes=32 time=31ms TTL=51
Reply from 170.64.147.31: bytes=32 time=30ms TTL=51

Ping statistics for 170.64.147.31:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 33ms, Average = 31ms

C:\Users\OEM> tracert 170.64.147.31

Tracing route to 170.64.147.31 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.xxx.xx.1
2 * * * Request timed out.
3 7 ms 3 ms 3 ms as9500.auckland.megaport.com [43.243.22.92]
4 7 ms 7 ms 7 ms as4826.auckland.megaport.com [43.243.22.18]
5 29 ms 31 ms 31 ms be101.bdr01.akl05.akl.nz.vocus.network [114.31.202.50]
6 * * * Request timed out.
7 32 ms 31 ms 31 ms be1.bdr04.syd03.nsw.vocus.network [114.31.192.115]
8 33 ms 31 ms 31 ms ip-250.71.254.124.static.VOCUS.net.au [124.254.71.250]
9 32 ms 31 ms 31 ms 143.244.224.180
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 31 ms 31 ms 31 ms 170.64.147.31

[Exmo]

I know precious little about tier 1 stuff but this doesn't necessarily sound like a problem in *SE's* network. I wouldn't rule out an error in routes they've contracted with a tier 2 carrier, but since 130ms of the 150ms lag you're experiencing is so close to home, it's likely that addressing that will address the symptoms of the problem you're seeing. It would be interesting if after solving the lag issue your packets still navigated the globe... but it's good for them to get some exercise in so long as it's not hurting anybody.

[SoloD007]

I know precious little about tier 1 stuff but this doesn't necessarily sound like a problem in *SE's* network. I wouldn't rule out an error in routes they've contracted with a tier 2 carrier, but since 130ms of the 150ms lag you're experiencing is so close to home, it's likely that addressing that will address the symptoms of the problem you're seeing. It would be interesting if after solving the lag issue your packets still navigated the globe... but it's good for them to get some exercise in so long as it's not hurting anybody.

Unfortunately, I have no idea what you are talking about. Also, how do you know it's not a problem with *SE* network? Do you work/part of square-enix network team (an official employee)? Because based on test results and past experiences when I use to be on Japan data center, these test results are accurate and there is nothing wrong with the routing from my ISP.

[Exmo]

I doubt you're comparing like to like.
Trace the route to the JP server you used to play on. Check how the path diverges. Find out which hop it starts to go wrong. Find out who owns that router & contact them.

[SoloD007]

I doubt you're comparing like to like.
Trace the route to the JP server you used to play on. Check how the path diverges. Find out which hop it starts to go wrong. Find out who owns that router & contact them.

Upon further investigation on my end after your comment. I understand where you are going with this. Nonetheless, I've contacted my ISP and I'll see where that leads me. Hopefully it's something my ISP can fix.