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 >> know. > > 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 laptops. 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 seen. I thought that this has been solved with XP SP2, but something David has done seems to have removed that fix. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
