Sleep cycles on win32

[Tino]

With #5852 Nasenbaer introduced some sleep cycles to reduce CPU usage. While usleep(200) is used on linux, Sleep(200) is used for windows.
Because usleep() does wait the amount of time in microseconds, Sleep() does wait for milliseconds (1000 microseconds = 1 millisecond).

1.) so it should be Sleep(0.2)

2.) Sleep() is not interuptable

[Nasenbaer (nasenbaer)]

Thank you, for fixing this bug Tino! :)

[Tino (tino79)]

I've reopened this bug due to the changes by Jari in #5868:

Now the windows code does wait or 10ms.
But the "original" calls for linux are usleep(200), which are 200 microseconds.

Can anyone else confirm/disprove, that :

       - usleep(n) does wait for n microseconds (i also did find n cpu cycles....)
       - Sleep(n) does wait for n milliseconds

Then we should also decide why we sleep only 200 microseconds on linux platforms, but 10 milliseconds = 10000 microseconds on windows.

[Nasenbaer (nasenbaer)]

I have no way to test this on Windows - the 200 µs on Linux seemed like a great way between cpu usage and speed - I tested some bigger games with 500 µs sleep steps and the server sometimes took too long to handle all playercommands - thus I lowered the sleep value to 200 µs and tested some more maps - never noticed any problems during the games (even on 192 x 192 maps) - the server still did only use 1/5 of the cpu the widelands clients needed.

So to come back to the question:
Jari wrote something with "no real milliseconds anyways" - perhaps he can tell us more? Does the function indeed wait less? Is that the reason for the change?
However the big question is: is there an equivalent function like the usleep funktion on windows systems?

[Nicolai Hähnle (nha)]

I realize I am somewhat late to the discussion, but all this back and forth about sleep times to me really indicates a bigger underlying issue, which is that this kind of busy-wait sleeping is Wrong(tm) on a fundamental level.

Why doesn't the dedicated server simply wake up only when it is needed, using select() or poll() or some equivalent call to sleep until a network message arrives. During the game, select() or poll() combined with some timeout value (e.g. one second) could be used to ensure that we cannot get stuck when clients hang.

[Jari Hautio (jarih)]

Sleep resolution on windows in windows is around 10-50 millisesonds. Sleep function takes integer argument, so using values 0.2 leads to Sleep(0), which just yields rest of the time slice. But thread itself remains active and will be scheduled to run immediately if now other same or higher priority thread is ready to run. This could be used if performance is really required.

There are some other approaches that can be used on windows. I suppose best would be to use same kind of frame limitter that is used when UI is running. SDL_GetTicks and SDL_Delay are used control sleep times and sleep only if there's time for it. I suppose server should be quite fine running with 25 fps.

[Nasenbaer (nasenbaer)]

I agree with #4 and #5. However those changes are more than a bug fixes. I changed the value of Sleep() to 1 to behave at least a bit more similiar than the Unix version.
All other changes, especially better handling of "sleep" vs. "wake me up "once a message is received + send sync report requests and computer commands from time to time": retargeted to Build17 :)

[Jari Hautio (jarih)]

I have to revise my comment on sleep resolution. Sleep resolution on windows seems to have improved on newer hardware. I noticed that Sleep(1) actually sleeps 1ms on win7/CoreI7. So recent platforms have no problem with Sleep(1). My older machine was limited to around 10ms resolution.

[Nasenbaer (nasenbaer)]

I close this report for now, as:
* in current code the sleep cycles are only used during setup time
* in game the game is simulated in real time like Widelands with front end does, and once the game is simulated to the current time it waits anyway for an answer of the other players that they reached the time to continue... etc...

So if anyone is using the dedicated server feature under Windows and if (s)he notices any problems during setup time with responses from the server, please reopen.

For now -> Won't fix!