[ntp:hackers] Non-monotonic time on NT

David L. Mills mills at udel.edu
Tue May 15 16:59:05 PDT 2007


Peter.

My suggestion was based on the observation that it doesn't matter when 
during the tick the clock is read. At each tick interrupt I assume NT 
adds the tick period, whatever odd value that might be, to the system 
clock value and handles the overflows. So far as users are concerned, 
they just get the current value and, I assume, without the benefit of 
interpolation.

What I suggested amounts to using the scaled TSC plus offset as the VFO 
and disciplining that with NTP. Use a second loop, acutally the existing 
loop, to discipline the system clock to NTP just as it is now.

With this technique you have to be careful about the TSC gain and phase, 
just factors as in the existing loop. The frequency gain is the divisor 
to make the TSC come out at some value that divides the second. The 
phase gain is an exponential average with determined time constant.

Dave

Peter Rosin wrote:

> David L. Mills wrote:
>
>> I am relieved. Having said that, is there any reason the scheme I
>> suggested some time back could not be used? The scheme calls
>> for a read of the system clock and TSC maybe once per second,
>> calibrating the TSC to read in nanoseconds and using it to
>> interpolate between calls. This is how the stock nanokernel
>> does it and the way the Alpha works. It gets a little more
>> juicy because the Alpha supports SMP. It would seem to
>> avoid much of what seems like overkill in the Windows
>> implementation.
>
>
> Hi Dave,
>
> I will try to explain why it doesn't work one more time. Since
> you are not stating how you do "a read" above, I assume that
> you just blindly read them once a second. This is not good
> enough. Further, I think you think it is enough because you
> assume the read will happen at the time when the system clock
> has just been updated. But - Windows is Windows - and noone has
> come up with a way to get work done right after the system
> clock has been updated, short of spinning the CPU. So, all the
> complexity in the Windows code is there to get a sample as good
> as possible, i.e. to read the TSC (or whatever) from as early
> as possible after the system clock update. The current code
> gets within 1 ms at best.
>
> My fault and the root cause of my frustration was that I
> assumed "everybody" was aware of this.
>
> Terje is now working on code that spins the CPU to get good
> samples.
>
> Cheers,
> Peter




More information about the hackers mailing list