[ntp:questions] Vista NTP tamed, but with a blunt object

Dave Hart davehart at gmail.com
Thu Jan 22 13:06:50 UTC 2009


On Jan 22, 3:41 am, Martin Burnicki <martin.burni... at meinberg.de>
wrote:
> Dave,
>
> Dave Hart wrote:
> > I've since realized that on this Vista laptop, the minimum step
> > observed from the OS clock is 1 msec but only after starting ntpd with
> > -M to use timeBeginPeriod to request 1ms timing service.  Run withouut
> > -M, my hacked ntpd observes the traditional 15.mumble msec clock
> > quantum.  That means the interpolation scheme should have a much
> > better shot at working on Vista without -M specified.
>
> Please see my reply to Terje's posting.
>
>
>
>
>
> > I've also added another fix to the mix, locking both the main thread
> > and the high-priority timer thread to the same (2nd) logical processor
> > on computers with more than one core or processor.  There's already an
> > inadequate call in the source to SetThreadAffinityMask to keep the
> > timing thread locked to the first processor (not the best choice if
> > there is more than one, due to typical interrupt routing,  but easiest
> > to code).  It is inadequate because the main thread compares
> > QueryPerformanceCounter results with the timing thread, and those are
> > known (and observed by me) to diverge across processors by tens to
> > more than 100 msecs worth of ticks.
>
> > As noted in this ancient Microsoft KB article, some hardware
> > (including a 1998-ish Dell PowerEdge 2300 of mine) is known to jump
> > the performance counter values forward out of step with system clock
> > and GetTickCount:
>
> >http://support.microsoft.com/default.aspx/kb/274323
>
> > To observe and clamp QueryPerformanceCounter forward leaps (never
> > backwards, at least so far for me) whether due to changing processors
> > before the affinity fix, or due to hardware or Hardware Adaptation
> > Layer (HAL) bugs, I modified the interpolation scheme to add
> > GetTickCount to the mix alongside the system clock and
> > QueryPerformanceCounter.  It is used as a bounds check on
> > QueryPerformanceCounter and a fallback lower-resolution interpolation
> > when divergence is detected.
>
> Unfortunately I currently don't have much time to go deeper into this.
> Anyway, what you've found out sounds good.
>
> > I could use some help testing from anyone interested in source or .exe
> > files.
>
> If you send me a copy of the modified sources I can also give it a try here.
>
> Martin

http://davehart.net/ntp/testbin/ntp-4.2.4p6-DLH-QPC-20090121-src.zip

Beware I've pissed all over the place and haven't spent a lot of time
cleaning up, thinking about what really should be debug or not, have
made modifications outside the ports directory like switching from the
event log to configured file logging sooner (though still after
startup if using the configuration file to specify the logfile, from
the start if you use the command-line -l switch.  This is just the
latest snapshot of my ongoing work, taken to match binaries no one has
asked for but are available at:

http://davehart.net/ntp/testbin/ntp-4.2.4p6-DLH-QPC-20090121-bin.zip
http://davehart.net/ntp/testbin/ntp-4.2.4p6-DLH-QPC-20090121-debug-bin.zip

Cheers,
Dave Hart




More information about the questions mailing list