EDIT by Scawen:

Moved 4 posts to this new thread as they aren't really about the test patch but are about an investigation into the super-slow downloads experienced by some people. By the way, test patch D20 works with our web server to download mods from USA or Japan if you are in America/Asia/Oceania, which appears to work well for those who have tested it. But geographical distance doesn't explain the *extremely slow* downloads that some people have experienced. If you do get that, we may get a clue from MTR (My Traceroute) results, if you could post them here.

Please test to our different servers, along with some kind of rough estimate for how long mods usually take to download, in the official version D (and if it has improved in version D20).

188.122.74.149 - NL
103.194.164.52 - JP
162.244.55.54 - US

Quote from Scawen :

Thanks for the tracert. If you enable the new option in game, are you redirected to Japan? Does Kazakhstan count as "Asia" in this case, and if so, do mods arrive more quickly? Though it's a massive country, half way between Rotterdam and Japan...

I can't test right now, because of issues with Nvidia Linux driver. KZ is mostly connected to Russia, which is connected to Netherlands, Finland and Sweden. So I bet directing it to Japan will make things worse here.

If you have a set of addresses to test, I can sketch a simple Python script to ping/download things and show statistics.

Quote from detail :

I can't test right now, because of issues with Nvidia Linux driver. KZ is mostly connected to Russia, which is connected to Netherlands, Finland and Sweden. So I bet directing it to Japan will make things worse here.

If you have a set of addresses to test, I can sketch a simple Python script to ping/download things and show statistics.

103.194.164.52 - JP
162.244.55.54 - US

Ping won't work, but you can perform an MTR towards them.

Quote from Victor :

103.194.164.52 - JP
162.244.55.54 - US

Ping won't work, but you can perform an MTR towards them.

Mobile 4G in city center:



Apparently, the route to Japanese IP goes over Hong-Kong. US is routed via Moscow internet exchange (MSK-IX).

Give me please European server IP, to test it too. (And Turkish, if possible.)

Thanks for the MTR results (not that I know what do do with it).

Maybe the Rotterdam one could be useful if it gives a clue why ordinary downloads are slow for you.

I got the Rotterdam IP from 'ping lfs.net' : 188.122.74.149


It's a funny thing, the 'extremely slow downloads for some people' issue. Yesterday I used a VPN to do LFS downloads via a server in Japan. One reason: to test redirected downloads from Japan. But, on topic, I also ran 0.7D (no redirection) over the VPN to download mods from Rotterdam via Japan, and it's (of course) slower than usual but still quick, just a few seconds for a mod, nothing like these reported several minute downloads. It makes me think that geographical distance isn't the main reason, and it must be something to do with people's internet connections, due to their ISP or country connections.

Victor mentioned MTR (My Traceroute) above and has done to me before. Maybe we could get a clue, from people who experience super-slow in-game downloads, MTR results to these IP addresses:

188.122.74.149 - NL
103.194.164.52 - JP
162.244.55.54 - US

Here's another test: mtr to 188.122.74.149 takes on average 101ms on Ethernet provider, and 260ms on mobile.

I tried downloading this image (2.5 Mb) and it takes ~3s on Ethernet and ~15..20s on mobile.

I don't think that hosting provider throttles the mobile one, because I can be the only one in the whole country who downloads the image today.

2.5Mb will take at least 40 packets on IPv4 (max packet size is 65K). If they're downloaded in syncronous way, ping time plus slower download speed on mobile explain everything:

40 * 100ms = 4s
40 * 260ms = 10.4s

Add some seconds for download (on mobile it's ~1Mb/s, on ethernet it's like 5Mb/s), and this explains the difference. (If I'm correct about syncronization.)

Ethernet. 100ms. KZ is much better connected to NL (100ms) than to JP (2000ms). Plus, I don't see Moscow IX IPs in the route.


Mobile internet:

Thanks. One question: If you use D20 and click to download a mod, do you get the yellow chat message "Redirect : JP" in LFS?

Here's my MTR result of NL server, which seems... rather problematic?

Quote from detail :

Give me please European server IP, to test it too. (And Turkish, if possible.)

LeaseWeb is not i3D.net but download speeds should be tested like this;

https://kb.leaseweb.com/network/link-speeds

---
Hmm funny i3D has it too;

Hong Kong: http://hkhkg1-cache1.sys.i3d.network/
Poland Warsaw: http://188.122.80.54/
Russia Moscow: http://188.122.82.54/
Netherlands Hengelo: http://5.200.31.254/
Netherlands Rotterdam: http://mirror.i3d.net/1000mb.bin (for some reason cannot find webpage)
US Chicago: http://138.128.140.54/
Australia Sydney: http://109.200.215.214/

This is what I quickly could find with Google, I am sure there is more but for now it should be OK I think to test?

If you can outperform LFS with a browser download then most probably the problem is LFS itself but first there needs to be proof for that.

Quote from Scawen :

Thanks. One question: If you use D20 and click to download a mod, do you get the yellow chat message "Redirect : JP" in LFS?

No! I am using D21 but I do not see any yellow message although it clearly redirects to JP if I watch the freeware CurrPorts tool (run as admin to see packet and size data)

Because the feedback is too slow to my liking I started myself with experiments;

https://streamable.com/hb2y8f (this video gets removed over time.. 90 days I believe, free account)

The problem is I do not get across 1.5 Mbit/sec unless I start multiple testbin downloads out of Australia in different browsers and dif[..]

update: Hmm interesting "cmd" netsh int tcp set global autotuninglevel=normal seems to fix this 1.5 Mbit limitation problem. I disabled this autotuninglevel during earlier testing (I think).

https://streamable.com/evmp70 => a lot faster, although notice it needs to setup a new connection for every mod and this costs the most time and is inefficient. Try https://curl.se/libcurl/c/10-at-a-time.html or https://curl.se/libcurl in general if you like to improve this bit.

What can also help is compression. I noticed that more then 50% of bandwidth can be saved with compression (zip). But, I think this is actually already happening and LFS is unpacking the mods download after download. On older machines this can cause more network delay then desired. Use less compression or start unpacking after all downloads are completed?