This is a delicate subject. Some months ago, I noticed this time management was not really working as it should, and it has many problems, I suspect so.
I didn't wanted to say anything until I knew more about that part of the code, and I'm still unsure what the problem is, but certainly simutrans has a very exotic way of scheduling the simulation, handle events, and render frames. I wanted to know more about it (and try to fix this problems) before giving an oppinion, but now that you are on this issue:
* If the target is getting 5 simloops per seconds, not more, in the benchmark you posted you report 5.1, 22 - 30 values.Tthat should never happen, as it indicates the world is running faster than it should if I'm not wrong. And specifically a setting named "fps" should never increase it, if the CPU is scarce, the only thing that makes sense is simloops going *under* 5
* The algorithm is based on frame time estimations, if you get to let's say 5 fps (can happen), the game will recover very slowly from this frame time downgrade, it makes no sense.
* This non-cpu greedy behaviour we have is linked ( I suspect ) with the problems we have been reported
to happen in CPU's that downgrade their clocks on speedstep technology. This is a severe problem because most laptops use those kind of CPU's, on desktops it's more usually a disabled feature. It's a very serious problem, since one can wonder how many people has installed simutrans on his ubuntu laptop for the first time, tried to play and closed the program in frustration of the slow performance.
* This is not very important but the program should detect when the debugger has triggered a breakpoint, and not take that frame time into account.
* the fps should just limit the maximum fps the program, and not have any other side effect, setting fps to 50 and getting 36 or to 100 and getting 53 is pretty weird, there is something that doesn't make sense here imho.
* One thing that makes this even more weird is the fact of only processing one event per frame. This is not desired, since the slower the program => the less events we check => more events are generated waiting to get processed => Events can take seconds to be processed => The game feels buggy and unstable.
* If our various backends have problems with dr_sleep as prissi pointed, we need to fix them.