[ntp:questions] Win7: ntpd adjusting time backwards

David Taylor david-taylor at blueyonder.co.uk.invalid
Wed Dec 12 22:40:29 UTC 2012


On 12/12/2012 20:58, Jeroen Mostert wrote:
[]
> Here's some loopstats from a brand new machine running Windows Server 2012:
>
> 56273 56211.040 -0.000185248 20.113 0.000065610 0.002127 8
> 56273 57117.052 0.000487392 20.115 0.000245606 0.002073 8
> 56273 57381.058 0.000771702 20.115 0.000250771 0.001958 8
> 56273 58424.072 0.000542051 20.118 0.000248229 0.001977 8
> 56273 59490.107 0.000320045 20.119 0.000245105 0.001903 8
> 56273 61613.141 0.000101314 20.120 0.000241965 0.001801 8
> 56273 62411.152 -0.000139791 20.119 0.000241858 0.001691 8
> 56273 63476.176 -0.000219043 20.118 0.000227966 0.001611 8
> 56273 65585.223 -0.000361511 20.116 0.000219111 0.001795 8
> 56273 66112.226 -0.000879125 20.114 0.000274771 0.001787 8
> 56273 66382.233 -0.000775453 20.113 0.000259625 0.001694 8
> 56273 66645.246 -0.000818638 20.112 0.000243336 0.001610 8
> 56273 68744.282 -0.000901985 20.105 0.000229520 0.002861 8
> 56273 69007.289 -0.000850863 20.105 0.000215455 0.002693 8
> 56273 69542.304 -0.000541853 20.103 0.000229247 0.002548 8
> 56273 69801.304 -0.000579627 20.103 0.000214857 0.002391 8
> 56273 70070.309 -0.000507633 20.102 0.000202585 0.002244 8
> 56273 70335.311 -0.000527417 20.102 0.000189630 0.002107 8
> 56273 72431.353 -0.000577564 20.097 0.000178267 0.002512 8
> 56273 72968.365 -0.000503697 20.096 0.000168786 0.002377 8
>
> This is syncing with Internet time through the NL NTP pool.
>
> I've set up four other machines to sync with this server, two virtual
> and two physical. The virtual machines are running NT 6.0, the physical
> machines 6.1 (client/server flavors not relevant here). The virtuals do
> not have the multimedia timer enabled, since I've read that this can
> negatively affect performance of the host (which makes sense, since
> driving all virtuals with 1000 interrupts/sec can't be easy). Even so,
> ntpd achieves sub-millisecond sync with the local server on all of them
> almost all of the time. I've registered three spikes on the virtual
> machines so far, of 2, 5 and 10 ms.
>
> To say I'm pleased with the results would be an understatement. In fact,
> I'm now tempted to try and solve the second problem, which is that no
> matter how accurately ntpd syncs the clock, there is no Windows API
> which will allow me to read its value with that accuracy! On the 2012
> Server, GetSystemTimePreciseAsFileTime() is available, but most of our
> machines are still Windows Server 2008/2008 R2 (even with some 2003
> server still hanging around). On the physical machines,
> GetSystemTimeAsFileTime() will get the time with 1 ms resolution since
> the MM timer will be enabled, which is good enough. On the virtual
> machines, however, GSTAFT cannot do better than the 15.625 ms resolution
> it has by default.
>
> I suppose it ought to be possible to expose enough of ntpd's internal
> state through shared memory to reconstruct what it thinks of the time on
> demand. There are obvious challenges (like appropriate locking and
> quickly detecting if ntpd has gone away so we can switch back to
> GSTAFT). I don't suppose anyone has experience with this? :-)

Yes, that's looking better!  I have tried two Win-8/Server-2012 PCs, but 
only one showed that better performance.  At least you can get that 
performance without needing a Linux or FreeBSD box.

There is an issue with getting the time more precisely, and I found some 
code on the Internet which I translated to Delphi and had a play with. 
Results are here:

   http://www.satsignal.eu/ntp/TSCtime.html

original page:

   http://www.lochan.org/2005/keith-cl/useful/win32time.html

Perhaps something like that will help you?  But please check it 
carefully!  Virtual PCs are another issue altogether, of course.
-- 
Cheers,
David
Web: http://www.satsignal.eu



More information about the questions mailing list