Info overlay reports 60 UPS but Game Runs Slower

[Jap2.0]

If you start the server on a brand new map with nothing built, do you still have the same speed problems? Are there any other applications on the server that could be using substantial CPU time or memory bandwidth?

No. Other multiplayer maps on this server with the same set of mods run very well. As I stated above, only some small daemons and other factorio maps. The server resources are still highly available.

If the map with the most entities is the only slow map, I suspect that it is a problem of resource shortage on the server. If you are running multiple factorio instances, while they can divide work among multiple cores, the still share and compete for the same CPU cache and memory interface. I would think it is just coincidental that the server can only reach 30 UPS when you rediscovered the issue. It's possible that the issues causing the bottleneck earlier on was something intermittent, causing the speed on the server to vary from second to second, but as your factory further grew that has now been well overshadowed by more consistent bottlenecks leaving it at a very steady 30 UPS.

Perhaps. The main thing that made me think something different is going on is that the UPS numbers report that the game is running faster, but the game does not run faster. With issues in the past, the UPS numbers would level off even if the game speed was increased... Is there a way to confirm the UPS value on the server's end? A console command or something?

Can you run the map on the server via either remote desktop or mouse, keyboard, monitor (if you have physical access) and see what UPS you get that way? It should be fairly similar in singleplayer and multiplayer. It getting stuck at precisely 30 does seem weird, though.

[eradicator]

Well, if you really want to see if it's the map, how about destroying all buildings :P?
This will leave only belts:

Code: Select all

/c for k,v in pairs(game.player.surface.find_entities_filtered{type='transport-belt',invert=true}) do v.destroy() end

[Adamo]

If you start the server on a brand new map with nothing built, do you still have the same speed problems? Are there any other applications on the server that could be using substantial CPU time or memory bandwidth?

No. Other multiplayer maps on this server with the same set of mods run very well. As I stated above, only some small daemons and other factorio maps. The server resources are still highly available.

If the map with the most entities is the only slow map, I suspect that it is a problem of resource shortage on the server. If you are running multiple factorio instances, while they can divide work among multiple cores, the still share and compete for the same CPU cache and memory interface. I would think it is just coincidental that the server can only reach 30 UPS when you rediscovered the issue. It's possible that the issues causing the bottleneck earlier on was something intermittent, causing the speed on the server to vary from second to second, but as your factory further grew that has now been well overshadowed by more consistent bottlenecks leaving it at a very steady 30 UPS.

Perhaps. The main thing that made me think something different is going on is that the UPS numbers report that the game is running faster, but the game does not run faster. With issues in the past, the UPS numbers would level off even if the game speed was increased... Is there a way to confirm the UPS value on the server's end? A console command or something?

Can you run the map on the server via either remote desktop or mouse, keyboard, monitor (if you have physical access) and see what UPS you get that way? It should be fairly similar in singleplayer and multiplayer. It getting stuck at precisely 30 does seem weird, though.

Thanks, I think so too. But no. The server only has a command-line interface.

[Adamo]

Well, if you really want to see if it's the map, how about destroying all buildings ?
This will leave only belts:

Code: Select all

/c for k,v in pairs(game.player.surface.find_entities_filtered{type='transport-belt',invert=true}) do v.destroy() end

At least, all the buildings on the main surface, if I'm standing on the main surface. Yeah, I could try that to see if it's just "the map" in terms of the inactive, explored terrain and settings.

[eradicator]

At least, all the buildings on the main surface, if I'm standing on the main surface. :P

I can't have this shame on my name. So here's a version that destroys everything, regardless of where you are.
Except for belts. I like belts.

Code: Select all

/c for _,s in pairs(game.surfaces) do for _,ent in pairs(s.find_entities_filtered{type='transport-belt',invert=true}) do ent.destroy() end end

[Adamo]

OK, so, I've been testing this for a while. I'm not going to go into full detail right now. I learned something very interesting, however. The speed issues seem to at least be related to large use of laser turret walls that are held in a power-off position with a switch connected to a fluid tank connected to flame turrets. When I activated power on all of the turrets in another world exhibiting these same behaviours, the speed of the game immediately shot back to normal. What's very interesting is that it seems to be related to the multiplayer hashing. When the turrets were offline, the CRC compute time was approximately half of the total update time. Now, it's down to something about 1/5, CRC time over update time.

[eradicator]

Don't know for turrents, but everything else (assemblers, inserters) is explicitly optimized for the full power state. If they have full power but nothing to do they go into an inactive state where they consume no cpu power. If they don't have full power though they stay active and wait for power, even if theres's nothing to do. Wouldn't suprise me if that applied to laser turrents too.
Though you saying its CRC related doen't really fit that theory... ;).
Grats that you got it working.

[Adamo]

Don't know for turrents, but everything else (assemblers, inserters) is explicitly optimized for the full power state. If they have full power but nothing to do they go into an inactive state where they consume no cpu power. If they don't have full power though they stay active and wait for power, even if theres's nothing to do. Wouldn't suprise me if that applied to laser turrents too.
Though you saying its CRC related doen't really fit that theory... .
Grats that you got it working.

Unfortunately, this did not solve the problem on my main server, although it may have improved it. It's hard to say without being able to measure UPS accurately. I'm setting up a combinator using the unixtime output from clusterio to try to measure the "real" speed of the server, since the UPS info on the client side is not accurate for the server. I've heard the same about the UPS draw of buildings without power. That is why I tested powering up the laser turrets for this purpose. Seems to me that when a building is out of power, it is safe to assume that it can be turned off in terms of processing the inputs and outputs of the building... oh, Factorio.

[Zavian]

Just hand timing a combinator setup to turn a light on and off every 600 ticks (10 seconds at normal speed) is probably accurate enough to determine if you are getting close to 60 ups.

[edavis6678]

I'm experiencing similar issue here; did you find some solution to this?

[Hathwos]

What i found by accident: i'm running Factorio vanilla (current experimental at date of post) as Linux GSM server on my Synology DS920+ (VM) .. weak CPU for the task, i know ..

Map size is about 30MB and we noticed the server got slower and slower, even with our "small base" (expensive recepies, research x1000, just managed to get half yellow belt purpel science stable) it "felt like 10 fps" :/ slowmotion walking etc.. nearly unplayable

So i tryed to restart the dedicated server, even the virtual machine.. nothing changed, but i had a power outage and the whole DS920 went down.. after powering up and starting everything again as before, Factorio was running again full speed

But it just lasted for about half an hour.. then .. slower and slower came back..

[san]

that sounds like heat throttling for the cpu.
You should get the same effect if you stop the server for 1-2h (maybe takes less time to cool down again), instead of power off.