These 2 pics are the funniest thing in this build

Quote from kagurazakayukari :

*snip*

Further test shows it straight through Singapore so I was wondering why Singapore itself have a bad result, then I found Singapore is via Tokyo and Hong Kong, so no wondering why.

Never knew this, now I know why my ping is horrendous in comparison to nearby countries. Always thought it was my ISP.

Posting to help :
Jap Server :
Pinging 103.194.166.91 with 32 bytes of data:
Reply from 103.194.166.91: bytes=32 time=69ms TTL=54

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

HK Server :
Pinging 43.239.136.59 with 32 bytes of data:
Reply from 43.239.136.59: bytes=32 time=39ms TTL=55

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

UAE Server :
Pinging 185.179.202.59 with 32 bytes of data:
Reply from 185.179.202.59: bytes=32 time=263ms TTL=51

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

Rus Server :
Pinging 188.122.82.59 with 32 bytes of data:
Reply from 188.122.82.59: bytes=32 time=197ms TTL=51

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

West US Server :
Pinging 162.244.52.59 with 32 bytes of data:
Reply from 162.244.52.59: bytes=32 time=232ms TTL=55

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

Quote from Victor :

Thank you for these tests! So ping wise Tokyo isn't that bad, but it's all ruined by huge packet loss.
I'm going to forward this to the network people at i3d and see if there is anything we / they can do about it.

I've found i3d AS49544 have two routing access to China, NTT AS2914 and TATA AS6453. Right now our AS4134(China Telecom) and AS4837(China Unicom) are both via AS2914.

Quote :

remarks: Japan
export: to AS2914 announce AS-INTERACTIVE3D
import: from AS2914 accept ANY AND NOT {0.0.0.0/0}
mp-export: to AS2914 announce AS-INTERACTIVE3D
mp-import: from AS2914 accept ANY AND NOT {::/0}
export: to AS6453 announce AS-INTERACTIVE3D
import: from AS6453 accept ANY AND NOT {0.0.0.0/0}
mp-export: to AS6453 announce AS-INTERACTIVE3D
mp-import: from AS6453 accept ANY AND NOT {::/0}

I've did some traceroute and found out the link to China is very congestion.

From JP server to home via i3d.net glass look:

Quote :

10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 299.538/310.854/325.741/7.369 ms

From home to JP server:

Quote :

Packets: Sent = 10, Received = 5, Lost = 5 (50% lost)
Estimated time (in milliseconds) of round-trip travel:
Minimum = 151ms, Maximum = 175ms, Average = 162ms

target IP: 103.194.166.91

1 192.168.0.1 0 ms 0 ms 1 ms LAN *
2 192.168.1.1 0 ms 1 ms 1 ms LAN *
3 * 2 ms 3 ms 3 ms Beijing chinaunicom.com AS4808
4 61.148.177.145 2 ms 3 ms 7 ms Beijing chinaunicom.com AS4808
5 125.33.186.117 3 ms * * Beijing chinaunicom.com AS4808
6 219.158.8.242 25 ms 25 ms * Shanghai chinaunicom.com AS4837
7 219.158.8.202 29 ms 29 ms 31 ms Shanghai chinaunicom.com AS4837
8 219.158.8.174 25 ms 32 ms 61 ms Shanghai chinaunicom.com AS4837
9 129.250.8.37 109 ms 112 ms 122 ms Tokyo ntt.com AS2914 xe-0-12-0-3-9.r03.tokyjp05.jp.bb.gin.ntt.net
10 129.250.3.57 86 ms 111 ms 156 ms Tokyo ntt.com AS2914 ae-4.r31.tokyjp05.jp.bb.gin.ntt.net
11 129.250.7.62 129 ms 141 ms 158 ms Tokyo ntt.com AS2914 ae-1.a01.tokyjp09.jp.bb.gin.ntt.net
12 120.88.53.74 86 ms 104 ms 163 ms Tokyo ntt.com AS2914 ae-0.interactive-3d.tokyjp09.jp.bb.gin.ntt.net
13 103.194.166.91 100 ms 101 ms 213 ms Tokyo i3d.net AS49544 hosted-by.i3d.net

It either lost packet or have a high latency.

About this loss packets, I'm going to let AI run for serveral hours in Asian server to see what will happen.



China Mobile is an exception. It is benefitting from CMHK's unique routing [Guangzhou->Hong Kong] that can directly access i3d Hong Kong via HKIX, then Singapore, Tokyo, by AS49544 itself I think.

The following result are using LTE so could have more latency.

Quote :

1 */*/*
2 */*/*
3 */*/*
4 */*/*
5 */*/* <- some wireless thing
6 211.136.63.57 65.72/67.22/68.31(ms) Beijing chinamobile.com
7 111.24.3.13 40.75/41.88/42.77(ms) Beijing chinamobile.com
8 111.24.2.146 */69.67/71.60(ms) Guangzhou chinamobile.com
9 111.24.5.190 89.06/93.40/98.90(ms) Guangzhou chinamobile.com
10 221.176.22.158 70.44/73.08/75.01(ms) Guangzhou chinamobile.com
11 221.183.25.117 */84.14/98.06(ms) Guangzhou chinamobile.com
12 221.183.68.126 92.44/106.61/106.66(ms) Guangzhou chinamobile.com
13 */*/*
14 223.120.2.54 */100.04/103.71(ms) Hong Kong chinamobile.com
15 123.255.92.15 */*/101.61(ms) Hong Kong hkix.net i3dnet1-lacp-10g.hkix.net
16 109.200.218.6 */*/109.70(ms) Hong Kong i3d.net hkhkg1-rt001i.i3d.net
17 */*/*
18 109.200.218.5 */*/146.48(ms) Singapore i3d.net sgsin1-rt002i.i3d.net
19 109.200.219.79 180.47/197.56/199.41(ms) Tokyo i3d.net jptyo1-rt002i.i3d.net
20 103.194.166.91 156.37/156.85/157.21(ms)Tokyo i3d.net hosted-by.i3d.net

This let me think if I connect via TATA Japan then what would happen.

From OVC,Tokyo via TATA AS6453 looking glass to home: http://lg.as6453.net/bin/lg.cgi

Quote :

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 196/206/217 ms

traceroute to 114.244.89.1(--), max hops: 30 ,packet length: 40,press CTRL_C to break
1 116.0.90.21(if-et-1-2.hcore2.ovc-tokyo.as6453.net)[MPLS Label=53929 Exp=0 S=1 TTL=1] 3 ms 2 ms 2 ms
2 180.87.180.57(if-ae-14-2.tcore1.tv2-tokyo.as6453.net)[MPLS Label=684923 Exp=0 S=1 TTL=1] 95 ms 99 ms 106 ms
3 180.87.180.13(if-et-23-2.hcore1.kv8-chiba.as6453.net)[MPLS Label=50824 Exp=0 S=1 TTL=1] 5 ms 4 ms
120.29.217.67(if-et-21-2.hcore1.kv8-chiba.as6453.net)[MPLS Label=50824 Exp=0 S=1 TTL=1] 9 ms
4 *
209.58.86.142(if-ae-5-2.tcore2.sv1-santaclara.as6453.net)[MPLS Label=129422 Exp=0 S=1 TTL=1] 99 ms 101 ms
5 63.243.205.72(if-ae-18-2.tcore1.sqn-sanjose.as6453.net) 94 ms
209.58.86.37(if-ae-26-2.tcore1.sqn-sanjose.as6453.net) 100 ms 100 ms
6 63.243.205.90(--) 199 ms
63.243.205.94(--) 201 ms
63.243.205.46(--) 207 ms
7 219.158.98.9(--) 205 ms 198 ms 212 ms <- start from this line enterd China
8 219.158.3.145(--) 200 ms 200 ms 196 ms
9 219.158.5.145(--) 205 ms 194 ms 203 ms
10 *
124.65.194.158(--) 197 ms
202.96.12.178(--) 203 ms
11 61.148.177.146(--) 187 ms
123.126.27.46(--) 155 ms
114.244.94.74(--) 164 ms
12 * * * <-my router
13 * * *

From OVC,Tokyo via TATA AS6453 looking glass to JP server:

Quote :

traceroute to 103.194.166.91(hosted-by.i3d.net), max hops: 30 ,packet length: 40
1 120.29.217.9(if-ae-15-2.tcore2.tv2-tokyo.as6453.net)[MPLS Label=15765 Exp=0 S=1 TTL=1] 2 ms 2 ms 4 ms
2 180.87.181.147(--) 36 ms 45 ms 36 ms
3 103.194.166.91(hosted-by.i3d.net) 38 ms 36 ms 45 ms

--- 103.194.166.91 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 44/44/46 ms

As for India server, China Unicom straightly though TATA Singapore.

I think there is a way can manually order routing. Maybe it slower but a little higher latency is better than regularly loss packets.

Quote from Gunn :

Singapore seems a lot better than Japan for me. Still not fantastic though.

Reply from 213.179.200.59: bytes=32 time=106ms TTL=56
Reply from 213.179.200.59: bytes=32 time=111ms TTL=56
Reply from 213.179.200.59: bytes=32 time=107ms TTL=56
Reply from 213.179.200.59: bytes=32 time=113ms TTL=56

Ping statistics for 213.179.200.59:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 106ms, Maximum = 113ms, Average = 109ms

Maybe you can do a traceroute to see the routing. I also seen AS6453 have access to Sydney.

I'm in China Hiong Kong


Ping 103.194.166.91 (使用 32 位元組的資料):
回覆自 103.194.166.91: 位元組=32 時間=102ms TTL=52
回覆自 103.194.166.91: 位元組=32 時間=103ms TTL=52
回覆自 103.194.166.91: 位元組=32 時間=103ms TTL=52
回覆自 103.194.166.91: 位元組=32 時間=102ms TTL=52

103.194.166.91 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺
大約的來回時間 (毫秒):
最小值 = 102ms，最大值 = 103ms，平均 = 102ms

----------------------

Ping 43.239.136.59 (使用 32 位元組的資料):
回覆自 43.239.136.59: 位元組=32 時間=3ms TT
回覆自 43.239.136.59: 位元組=32 時間=3ms TT
回覆自 43.239.136.59: 位元組=32 時間=3ms TT
回覆自 43.239.136.59: 位元組=32 時間=3ms TT

43.239.136.59 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 =
大約的來回時間 (毫秒):
最小值 = 3ms，最大值 = 3ms，平均 = 3ms

--------------

Ping 213.179.200.59 (使用 32 位元組的資料):
回覆自 213.179.200.59: 位元組=32 時間=37ms TTL
回覆自 213.179.200.59: 位元組=32 時間=38ms TTL
回覆自 213.179.200.59: 位元組=32 時間=38ms TTL
回覆自 213.179.200.59: 位元組=32 時間=37ms TTL

213.179.200.59 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (
大約的來回時間 (毫秒):
最小值 = 37ms，最大值 = 38ms，平均 = 37ms

------------------

Ping 185.179.202.59 (使用 32 位元組的資料):
回覆自 185.179.202.59: 位元組=32 時間=215ms TTL=53
回覆自 185.179.202.59: 位元組=32 時間=212ms TTL=53
回覆自 185.179.202.59: 位元組=32 時間=213ms TTL=53
回覆自 185.179.202.59: 位元組=32 時間=212ms TTL=53

185.179.202.59 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺失)，
大約的來回時間 (毫秒):
最小值 = 212ms，最大值 = 215ms，平均 = 213ms
PS C:\Users\Scania> ping 188.122.82.59

Ping 188.122.82.59 (使用 32 位元組的資料):
回覆自 188.122.82.59: 位元組=32 時間=237ms TTL=48
回覆自 188.122.82.59: 位元組=32 時間=236ms TTL=48
回覆自 188.122.82.59: 位元組=32 時間=236ms TTL=48
回覆自 188.122.82.59: 位元組=32 時間=236ms TTL=48

188.122.82.59 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺失)，
大約的來回時間 (毫秒):
最小值 = 236ms，最大值 = 237ms，平均 = 236ms

Ping 162.244.52.59 (使用 32 位元組的資料):
回覆自 162.244.52.59: 位元組=32 時間=161ms TTL=50
回覆自 162.244.52.59: 位元組=32 時間=161ms TTL=50
回覆自 162.244.52.59: 位元組=32 時間=162ms TTL=50
回覆自 162.244.52.59: 位元組=32 時間=161ms TTL=50

162.244.52.59 的 Ping 統計資料:
封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺
大約的來回時間 (毫秒):
最小值 = 161ms，最大值 = 162ms，平均 = 161ms

Quote from kagurazakayukari :

Maybe you can do a traceroute to see the routing. I also seen AS6453 have access to Sydney.

I did a Traceroute the other day expecting the hops to go up the east coast through PNG and Micronesia, but instead it goes to Sydney, then Melbourne, then across to Perth, then up to Singapore, then Japan. It's about eight hops. When I ping through my VPN (which is in Sydney) there is an added hop between Singapore and Tokyo via Hong Kong for some strange reason, but I wouldn't be gaming through the VPN anyway. The round trip to Tokyo and back via the Eastern route would be about 20,000KM, the Western route I have to use is much longer than that.

I've played LFS on Japanese servers before and it wasn't great, almost as slow as connecting to a USA server.
To a Sydney server I get about 40, and 60 to Melbourne, 90-ish for NZ. These are all OK for racing with NZ being only just OK. I'm about 1000KM North of Sydney and my packets have to go there before they go anywhere it seems. I don't think I'll be racing on a Japanese server because when players join the server or teleport to the pits it is enough to throw you off the track if you are cornering at the time. I've done most of my racing on US (200-260) and European (300-350) servers over the years and the experience has always been frustrating.

Quote from Scawen :

I don't know if the problem is on your download or upload side. Either could cause a problem with TCP as it requires 2-way communication to maintain guaranteed delivery (though I don't know about the internals of the TCP algorithm).

What could possibly going on when I lost connection(can see others) and trying to connect again but game shows me "The user has already online"? Then when the "online user" timed out can I connect again.

Quote from Gunn :

I did a Traceroute the other day expecting the hops to go up the east coast through PNG and Micronesia, but instead it goes to Sydney, then Melbourne, then across to Perth, then up to Singapore, then Japan. It's about eight hops. When I ping through my VPN (which is in Sydney) there is an added hop between Singapore and Tokyo via Hong Kong for some strange reason.

It is possible to know the provider by checking ip address from each hop. I recommend using BestTrace as it can shows each hop provided by whom automatically.

Quote from kagurazakayukari :

It is possible to know the provider by checking ip address from each hop. I recommend using BestTrace as it can shows each hop provided by whom automatically.

Sure, but that won't change anything.

Quote from Victor :

I'm going to forward this to the network people at i3d and see if there is anything we / they can do about it.

Hi, I've asked some of the server rooms from our side. They are pretty sure it's NTT Japan's problem. Some information below.

Prividers are all agree that NTT Japan is not an good option, which has the worst connection quality from China to Japan. Any provider that uses NTT from China to Japan will experience huge packet loss and latency problems, completely connection failed in the worst case. Some of the providers from Singapore or Hong Kong have the same issue that are hopping via NTT Japan too. AS2914 is really in congestion, especially A4837-A2914.

Also the recommendation. For i3d, it's better to hopping via KDDI, IIJ, telstra(HK), AS4134(NTT though this will be still good because it is Japan native when transfer to AS2914, only Telecom), sg.gs or anything can via their AS49544, avoid NTT Japan AS2914.

Another option is flow transfer.

Attachment is a single test result from some server rooms from different location. The green cells are timed out. Each labels are: location, IP, send, received, loss, longest/shortest/average ping. Some of the server rooms are via NTT(only in Japan native), or i3d in HK, so they have a nice connection.