[ntp:questions] Re: Windows timekeeping - sudden degradation- why?
martin.burnicki at meinberg.de
Mon Dec 12 06:59:47 UTC 2005
Danny Mayer wrote:
> David J Taylor wrote:
>> The problems seems to be as (IIRC) Martin Burnicki explained, when
>> switching between "1ms MM timer" and "normal 10/15ms timer", Windows
>> inserts some sort of "adjustment", which causes the steps we've seen.
>> Why I only started seeing this ten days ago on the XP Pro system I don't
> If I understand this right the change in the timer is what causes the
> problem which means that the disciplining is suddenly way off. It is not
> good to have the frequency change when you are trying to keep accurate
> time. That would indicate that laptops which change speed when they are
> unplugged or plugged in.
AFAIK if laptops change speed it's basically the speed of the CPU clock what
is decreased, so this should affect the CPU's time stamp counter (TSC).
On machines which use the SMP HAL the Windows performance counter API uses
the TSC, so if the CPU frequency is decreased the performance counter
values must be evaluated differently unless the changenment is taken into
account by the performance counter API or ACPI.
On machines with uniprocessor HAL the performance counter API uses one of
the hardware timer chips which has a much lower clock rate than the CPU
clock frequency. I'm not sure whether that clock rate is also changed on
However, what has been discussed here before has nothing to do with laptop
power saving, it also happens on old machines which don't even support
power saving. As I see it it is a clear design flaw or faulty
implementation of the Windows system clock, and you have two possibilities
to avoid this effect:
1.) Be absolutely sure that no app is run which changes the MM timer. This
yields the best clock synchronization results. The problem is that you
normally don't know before whether an app changes the MM timer or not.
2.) Have the MM timer running always on high resolution. This yields a clock
synchronization wich is a little bit degraded compared to 1.), but the
sytem time won't have steps back and forth if an MM app starts and stops.
If either the MM timer is constantly high or constantly low this is
transparent to applications which read the system time. The problem arises
if the MM timer resolution is switched, and the time synchronization
suddenly observes an offset of a few milliseconds which it then tries to
compensate. If the MM timer res changes again after the initial offset has
been partly or completely compensated then the result is what David has
I thought that this has been solved with XP SP2, but something David has
done seems to have removed that fix.
More information about the questions