Factorio Forums

I'm running headless Factorio on a 6-core container on Proxmox on a LAN, and max out downloading the map at between 7 and 8 MB/s. I was wondering if this is expected, or if I should be seeing something faster? The server doesn't look too heavily loaded, and I'm the first person joining.

Happy to do more performance testing or any testing as desired.

I completely forgot we had another thread for 1.1.39, but same issue. viewtopic.php?f=49&t=64312&p=552651#p552651

This might be difficult issue to debug. Testing on my LAN with a semi large map it goes at 40 MB/s. I tried adding delay and loss but it did not reduce download speech much, only the time to reach it. Then I tried adding packet reordering and it slows the downloading speed substantially. Even removing the reordering afterward the download speed remains slow.

To get this result I simulated the link conditions with netem using my easynetem script on my Linux server. I set it to "delay 10ms 0ms reorder 100% 50% gap 2" and it wouldn't go faster than about 0.8 MB/s. Even removing the reordering while downloading by setting it to "delay 10ms 0ms reorder 0% 0%" didn't make the speed go up, instead it went down to 0.5MB/s and stayed there. Cancelling and reconnecting caused it to slowly go up 40 MB/s like all the other delay and loss tests I did.

Using "delay 10ms 10ms" saw similarly slow download speeds (the second number is jitter and causes packet reordering). And it also failed to reach the full speed it normally does when the jitter was removed, though not as bad as the explicit reordering did. It seems to me that whatever algorithm is in use for the map downloading does not handle packer reordering correctly.

That's fascinating-- were you able to bring the speed back after a reboot or link reset (down/up)? I'm going to try this locally

Derim422 wrote: ↑Fri Dec 31, 2021 3:24 am That's fascinating-- were you able to bring the speed back after a reboot or link reset (down/up)?

Hornwitser wrote: ↑Fri Dec 31, 2021 2:56 am Cancelling and reconnecting caused it to slowly go up 40 MB/s like all the other delay and loss tests I did.

It only affects the active download, reboot or link reset is not required nor would it make sense as there's nothing on the system that would remember that packets were reordered in the past.

Thanks for the highlight of that note -- much appreciated. I still see this as more of a bug than technical help at this point.

I want to add that when starting the client with the --verbose flag the log is spammed with this message when I do the packet reordering:

3092.713 Verbose TransferTarget.cpp:201: Received block 34675 that we didn't request