You can stick to your design. You only need to set the system interrupt frequency to run at its maximum frequency. In order to obtain this, you just have to execute the following code anywhere in your code:
#define TARGET_RESOLUTION 1 // 1-millisecond target resolution
TIMECAPS tc;
UINT wTimerRes;
if (timeGetDevCaps(&tc, sizeof(TIMECAPS)) != TIMERR_NOERROR)
{
// Error; application can't continue.
}
wTimerRes = min(max(tc.wPeriodMin, TARGET_RESOLUTION), tc.wPeriodMax);
timeBeginPeriod(wTimerRes);
This will force the systems interrupt period to run at maximum frequency. It is a system wide behavior, thus it may even be done in a separate process. Don't forget to use
MMRESULT timeEndPeriod(wTimerRes );
when done to release the resource and reset the interrupt period to default. See Multimedia Timers for details.
You must match each call to timeBeginPeriod
with a call to timeEndPeriod
, specifying the same minimum resolution in both calls. An application can make multiple timeBeginPeriod
calls as long as each call is matched with a call to timeEndPeriod
.
As a consequence, all timers (including your current design) will operate at higher frequency since the granularity of the timers will improve. A granularity of 1 ms can be obtained on most hardware.
Here is a list of interrupt periods obtained with various settings of wTimerRes
for two different hardware setups (A+B):

It can easily be seen that the 1 ms is a theoretical value. ActualResolution is given in 100 ns units. 9,766 represents 0.9766 ms which is 1024 interrupts per second. (In fact it should be 0.9765625 which would be 9,7656.25 100 ns units, but that accuracy obviously does not fit into an integer and is therefore rounded by the system.)
It also becomes obvious that i.g. platform A does not really support all the range of periods returned by timeGetDevCaps
(values ranging between wPeriodMin
and wPeriodMin
).
Summary: The multimedia timer interface can be used to modify the interrupt frequency system wide. As a consequence all timers will change their granularity. Also the system time update will change accordingly, it will increment more often and in smaller steps. But: The actual behavior depends on the underlaying hardware. This hardware dependency has gotten a lot smaller since the introduction of Windows 7 and Windows 8 since newer schemes for timing have been introduced.