WinUAE and Windows timer resolution

[mark_k]

I read a blog post titled Windows Timer Resolution: Megawatts Wasted. The gist of it is that many programs increase the timer resolution used by Windows, thus increasing the frequency of timer interrupts. Which uses more power since the CPU can't enter the lowest-power states, and has a small but measurable performance impact on other programs. In some cases that's needed (for example a media player when playing), but in others it isn't (e.g. media player when paused).

I thought I'd see what WinUAE does to the timer interval on Windows Vista SP2. Before running WinUAE, clockres reported:
Maximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 15.600 ms

After running WinUAE (settings window open, before starting emulation):
Maximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 1.000 ms

The reported current timer interval stays at 1.000 ms regardless of whether emulation is running or paused. After exiting WinUAE the current interval returns to 15.600 ms.

So, I'm just wondering: would it be feasible to have WinUAE only reduce the timer interval when emulation is actually running, not when paused or the settings window is opened?

[Toni Wilen]

I thought it already did it. Not the first time it happened

Now done, only active when emulation is running.

[mark_k]

Thanks. Testing today's winuae.exe (16:27 time) the current timer interval stays at 15.6ms after launching WinUAE. However once I start emulation, the timer interval stays at 1ms even when paused or with settings window open.

[Toni Wilen]

What about now? (But pause should have already worked)

[mark_k]

No change with today's winuae.exe (date 2015-04-01 15:25).

I wonder if there's something about my system or Vista that causes timer resolution to be increased, for example when you initialise/open DirectX perhaps some Windows component increases the resolution?

[Toni Wilen]

I am not sure if the program works in Vista or later (at least in 8 and later when timer stuff changed). For example Windows 10 TP always shows 1.0ms.

I only made sure timeBeginPeriod() and timeEndPeriod() are called when needed.

[mark_k]

I might have figured out the cause of the problem.

When emulation is paused, do you always undo the effect of any previous DwmEnableMMCSS(), AvSetMmThreadPriority() and AvSetMmThreadCharacteristics() calls?

From the MSDN Multimedia Class Scheduler Service page:

The MMCSS settings are stored in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile
...
The key also contains a subkey named Tasks that contains the list of tasks. By default, Windows supports the following tasks:
...
Each task key contains the following set of values that represent characteristics to be applied to threads that are associated with the task.
...
Clock Rate REG_DWORD A hint used by MMCSS to determine the granularity of processor resource scheduling.

Windows Server 2008 and Windows Vista: The maximum guaranteed clock rate the system uses if a thread joins this task, in 100-nanosecond intervals. Starting with Windows 7 and Windows Server 2008 R2, this guarantee was removed to reduce system power consumption.

On my system all tasks in the registry have a Clock Rate value of 10000 (i.e. 1000000ns = 1ms). Thus when you call DwmEnableMMCSS(), AvSetMmThreadPriority() or AvSetMmThreadCharacteristics() the timer resolution is changed to 1ms.


On a related note, how about adding an option to not call DwmEnableMMCSS(), AvSetMmThreadPriority() or AvSetMmThreadCharacteristics()? If the user is using some Workbench app (not a game or demo) and not playing sound, they may prefer power saving over smooth-as-possible graphics updates.

[Toni Wilen]

None of those are used. I tried them in Vista era or so but there was some issues and there was also no gain vs time*period calls.

It is very bad idea to have longer waits unless mode is fastest possible without sound (which is useless from power saving point of view..). In all other modes emulation will always attempt to sleep 1ms-10ms when possible to reduce CPU use. If sleep takes longer (~2-3ms longer), you will get extreme bad performance.