From my side the ping of Asian server is around 110-120ms, which is good. Both Eu and US servers are around 300ms+
However the download of mods are rarely timed out... probably because of ping, tested on Eu server. A timed out model downloading may causing LFS crash.
Another thing. When downloading new mods it is unable to join with mod car.
The suffix number ~005 is just the version number of that mod. It will only go to ~006 for that mod, if the creator uploads a new version of the mod (for example with some changes or updates).
We use the version number, so that for example, the creator may upload a new update while people are already online with their mod. Then the new version has a different name so does not get a synchronisation problem. Both versions can exist on the same server.
It's 12:00 in the noon so I have another result. Not very optimstic. Usually 0-4 server randomly shows in the list with 120-200ms+ and may have few chance of lost connection, not 100% okay for racing. After 13:00 it seems stable with few 500ms jumps.
I believe it is because QOS by our internet provider that limited oversea bandwidth of nearby countries. It also does hard to choose because we have tons of gaming accelerater use for shorten the latency. EU and US server are stable even with 230-280ms+ latency and I may rather would choose them.
Last time when patch just came out it was 3-4am so it shows the best result. However I believe the worst will come at 13:00-15:00 UK time, when will have highest demand on international bandwidth in Asia.
Since it's happening too far and really relative to the future, I think it is reasonable to still post here.
I have not much confidence on Asian server by now...At 9-10pm the server will have a ping similar to EU server. Sometimes the server list will show like there is no Asian server available.
@Scawen This made me worrying. So the result of last afternoon(your time) really showed the situation when everybody was sleeping and the demand at that time was not that high.
It is disappointing that you have better results to Europe than to Japan. What is the reason for this? Is it done deliberately by your government? I can't understand why they would throttle internet to Japan while allowing good connection to Europe.
Anyway... something to try. Not for the Japan problem, but I have tried to make the in-game mods download faster, in case it might help your skin and mod downloads. I really don't know if it might help, but I have not become much wiser by trying to read about WSAECONNABORTED. So I thought I'd try something anyway.
Changes from W43 to W44:
Updated help text on Start New Host screen
Increased size of file transfer buffer - may download mods faster
It's mainly because there are so many network traffic just to bypass the GFW to Japan/Singapore/US (not many to EU even with normal traffic) via some kind of tunnel tech so people can access Youtube or other things,this tooks most of bandwidth, plus the total bandwidth is actually limited per each person/device. We only have 6 oversea cables and cables to Japan are less than half, more to Taiwan, South Korea and US, most bandwidth are to Hong Kong of course.
So in the daytime I do have some difficulty on browsing lfs.net because it's so slow. Cross country traffic usually in lowest priorty. This is the reason I'm worrying of cancel dedi usage and it does hard to truely solved.
Right now the traffic is low so my ping of Asian server is 80ms atm. I've check the 0.6V and the low latency server are coming from Russia/Korea 150ms+. There is no Hong Kong or Taiwan server so I'm not sure.
Watching Mex GP so I can have some testing before dawn.
Somehow I have both faster or slower result with each try. Maybe it is about file size, the longest one is RB4 T5. Maybe can show a progress indicator just like downloading official patch.
Can you try pinging the following IP addresses? I'm curious what the results are for you:
Japan: 103.194.166.91
Hong Kong: 43.239.136.59
Singapore: 213.179.200.59
United Arab Emirates: 185.179.202.59
Russia: 188.122.82.59
West US: 162.244.52.59
Japan: 103-196ms have packet loss of 55%, ntt
Hong Kong: 139-268ms have packet loss of 17% via Tokyo, ntt
Singapore: 283-301ms have packet loss of 14% via Tokyo/Hong Kong, ntt
United Arab Emirates: 329-350ms via US/UK/France
Russia: 275-279ms via US/Denmark/Sweden
West US: 283-284ms
I found these IPs are from i3d.net, so I did some extra test from https://www.i3d.net/resources/tools/myip/, it turned out India have the best result of 139-153ms with perfect connectivity.
India:139-153ms via Singapore,TATA communications (directly Beijing->Guangzhou->Singapore->India, without Tokyo/Hong Kong)
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.
These above are the result with China Unicom.
China Telecom have a different result. See next thread.
Japan: 78-84ms have packet loss of 40%, ntt
Hong Kong: 322-331ms have packet loss of 37% via Tokyo, ntt
Singapore: 319-345ms have packet loss of 34% via Tokoy/Hong Kong, ntt
United Arab Emirates: 338-380ms via Netherland/France
Russia: 264-284ms via Netherland
West US: 159-229ms
India:369-509ms via US, TATA communication
Both Unicom's and Telecom's not lost packet result are via their owned oversea servers. It looks like bandwidth via NTT.com is very limited. So far the best overall result is from Chicago.
I also looked into i3D deeper because i3D is a server privider of Battlefield and Rainbow Six and many people have the same connection issue. By using gaming accelerator (which also create a virtual tunnel) Hong Kong server can do 18ms with Guangzhou telecom, but this method requires extra cash per month.
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.
Yeah it's kind of a mess. So I think NTT at the middle have some issue on it.
I ignored China Mobile because that is just another story. For example Japan server is via Hong Kong, Singapore, then Tokyo so average 250ms, which means Hong Kong are at 85ms (China Mobile have CMHK in HK),and Singapore are at 112-114ms.
What does LFS do when some users have the LAG(secs) on their name space while some other users are visible and driving normaly? In this situation all the command seems need to waiting those Lag users packets finally arrive or LFS can ignore certain packets till the lastest comes?
Pinging 103.194.166.91 with 32 bytes of data:
Reply from 103.194.166.91: bytes=32 time=186ms TTL=54
Reply from 103.194.166.91: bytes=32 time=307ms TTL=54
Reply from 103.194.166.91: bytes=32 time=187ms TTL=54
Reply from 103.194.166.91: bytes=32 time=204ms 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 = 186ms, Maximum = 307ms, Average = 221ms
No, there is no waiting. With good TCP connection to the server, your game continues as normal. Lag on cars is to do with UDP packets which can go missing or be discarded. You could see lag on a remote car for two reasons - either their UDP (position packets) didn't arrive at the server, or they didn't get from the server to your computer. It's separate from the game packets, which are dictated by the server.
Okay. So if I can see everybody visible and I have a red lag indicator in the left lower corner, is that means an uplink fault myself? After back to normal condition I can see all the talk during this period sudden burst out.
And I just experienced an crazy moment.. It's in EU server.
That sounds like the UDP packets are going on OK (maybe some missing - we'll never know) but the TCP connection is struggling due to the packet loss.
Presumably the TCP, as it is guaranteed delivery, is trying for some some to restore the missing packets (game packets) and struggling due to packet loss. All the while, the UDP packets are still being sent and you are receiving enough of them, not to see lag cars.
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).
I'm not certain but I believe NZ uses a different backbone that goes up through PNG and Micronesia to Tokyo, whereas my signal goes to Sydney, then west across to Perth, then up to Singapore then to Tokyo. So the results from this part of the world could be a bit different for different people. It's a big country
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
From my knowledge, due to the switching strategy of overseas operators and the sufficient number of peers and users of overseas operators, the switch ports between them and Chinese operators are prone to congestion, that is, they have not yet entered the network in China has begun to block, because their switch ports with China are blocked.
So that's why EU servers perform better than As servers, the bandwidth consumption in the European direction is relatively low.
That's what Eastern Area of the earth always happen. For whom have no idea, you see, In America, Europe, Africa most of the countries at each area are basicly connect to their neighbour either by fiber optic cables paved on land or undersea but very closely so the ping won't go high, so it is relatively simple. For Asia and AUS/NZ, the main network communication method is through submarine fiber optic cable, and at the peak time there will always be a shortage. This way there are many fiber optic cables for each country to use and the communication routing will be very complicated. Look at the different results above, there are a lot of different routings for Asian/AUS/NZ operators to access different server rooms. You can even see From Beijing to Japan go through Singapore.
Posting these if its any useful.
I'm from southern part of India.
Also it would be bit worse than usual since I'm currently using LTE.
Japan:
Ping statistics for 103.194.166.91:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 142ms, Maximum = 185ms, Average = 156ms
Hong Kong:
Ping statistics for 43.239.136.59:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 125ms, Maximum = 145ms, Average = 136ms
Singapore:
Ping statistics for 213.179.200.59:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 83ms, Maximum = 114ms, Average = 100ms
United Arab Emirates:
Ping statistics for 185.179.202.59:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 197ms, Maximum = 234ms, Average = 212ms
Russia:
Ping statistics for 188.122.82.59:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 194ms, Maximum = 226ms, Average = 211ms
West US:
Ping statistics for 162.244.52.59:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 280ms, Maximum = 306ms, Average = 291ms
.
.