Windows' Timer resolution increased to 1 ms

[Weissrolf]

Ahoi.

FG Unity (or maybe the Unity player?) increases Windows' Timer resolution from 15 ms to 1 ms. Unless this is needed for quicker RNG seeds I don't see why FG would need that? It increases power draw and thus decreases battery life on laptops.

[Valyar]

Word. Unity is killing the laptops' batteries of all my players. Only the guy on desktop is not complaining.
It is also general recommendation to MS to revert to the default which is 15.6ms

[Moon Wizard]

We're not specifying any timer resolution in FGU. We're just using the native Unity engine behavior; and have set frame rates to synchronize with the display it is used on. (i.e. VSync)

Regards,
JPG

[bmos]

It appears to be a default of Unity.
Using a full 3D game engine when on battery power is not a great approach to gaming.

[Valyar]

We're not specifying any timer resolution in FGU. We're just using the native Unity engine behavior; and have set frame rates to synchronize with the display it is used on. (i.e. VSync)

Regards,
JPG

Maybe it is worth testing the MS recommendation and see the outcome? Unity is draining battery a lot and while the VSync works by reducing the power consumption, the experience on the lowest setting is like slide-show in PowerPoint.

[Weissrolf]

I am not a coder, but I understand the implications of the Windows timer resolution and searched for other instances of this specific problem. Here is what my search came up with:

- Unity could try to reset the Windows timer resolution back to default, a simple "timeEndPeriod" might be suffient. This seems like the easiest and most safe way to handle this, if it works that is.

- If a simple "timeEndPeriod" is not sufficient then you could try to set your own timer resolution via "timeBeginPeriod". Windows will use the highest precision timer requested by any one program and use it for all other programs as well. So when you set a lower resolution it does not affect other processes negatively (possible exception W10 2004), but setting a higher resolution affects every other process (concerning power consumption).

https://www.albahari.com/threading/part3.aspx


The precision of multithreaded timers depends on the operating system, and is typically in the 10–20 ms region. If you need greater precision, you can use native interop and call the Windows multimedia timer. This has precision down to 1 ms and it is defined in winmm.dll. First call timeBeginPeriod to inform the operating system that you need high timing precision, and then call timeSetEvent to start a multimedia timer. When you’re done, call timeKillEvent to stop the timer and timeEndPeriod to inform the OS that you no longer need high timing precision. You can find complete examples on the Internet that use the multimedia timer by searching for the keywords dllimport winmm.dll timesetevent.

- Using "NtSetTimerResolution" may be another way of setting your own timer resolution, albeit it seems to be a "hidden" API call. In the following thread someone described issues with "Sleep" causing high CPU load in Unity player. Higher CPU activity is expected with higher timer resolutions, because "Sleep" is woken up more often with higher timer resolution. But Unity specifically seemed to have increased CPU load as well. This might or might not have been fixed in Unity since then. This thread also includes a small script to demonstrate how to use "NtSetTimerResolution" to change timers.

https://forum.unity.com/threads/high-cpu-consumption-with-no-explainable-cause.293645/

Here is an article that describes why using "Sleep" is "bad design" to begin with, albeit since FGU seems to be single-threaded only anyway (big disappointment), the article may not be so relevant here.

https://blogs.msmvps.com/peterritchie/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program/

And here is an article that describes how Windows 10 2004 changes the behavior of TimeBeginPeriod in one process affecting Sleep calls in another process (it's not so "global" anymore). If FGU is fetching a new timer based seed every time a roll is made then this may have implications should you decide to decrease the timer resolution back to normal (from its current 1 ms).

https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/

[Moon Wizard]

We are not adjusting the Windows timer resolution in our code. The Unity game engine is apparently adjusting the timer resolution in their engine code. We do not have access to either the code or reasoning for how and why Unity is adjusting the timer resolution. We do not have any plans to somehow attempt to "override" the Unity game engine on this setting; as we do not know what the potential impacts would be.

Regards,
JPG

[RevenantBob]

Unity is a closed source core unless you pay for the source code. Basically, it's a Unity Engine design issue, and it's been that way since 2011. I'm not sure why unity would do this since it's sort of considered bad practice in this age of programming (Yes, I'm a programmer) since there are other high resolution timers that don't muck with the system, but without seeing source code, it's anyone's guess what that would affect in their code.

[Weissrolf]

Still one of the methods outlined earlier could be tried on the test channel to see if adverse effects can be seen or not.

That being said, both Discord and Teamviewer set Windows timer resolution to 1 ms, so in practice it matters less. Not so much of a problem when Discord is used via browser or another voice app is used (that may or may not use 1 ms). Starting from W10 2004 it still could help lower CPU utilization and power draw if FGU regularly uses Sleep calls, though.