[ntp:questions] ntp-4.2.6p5 on Win 7 x64

Martin Burnicki martin.burnicki at meinberg.de
Mon Jul 21 14:15:10 UTC 2014


Nick wrote:
> Martin
>
> thanks for the reply.  Please see comments below.
>
> Nick
>
> On Wed, 16 Jul 2014 12:46:38 +0200, Martin Burnicki wrote:
>
>>> Restarting the service 'fixes' it for a few minutes, then it all begins
>>> to 'diverge' again.
>>
>> Please see an earlier post from me
>> http://lists.ntp.org/pipermail/questions/2013-November/036676.html
>>
>> which describes why (and how) you should upgrade the NTP version, and
>> why (and how) you should use different minpoll/maxpoll values.
>>
>> Please let us know if my suggestions fix your problem.
>
> Sorry, no.
>
> Tried http://people.ntp.org/burnicki/windows/ntp-4.2.7p348+patches-
> release.zip and http://www.satsignal.eu/ntp/x86/ntp-4.2.7p450-win-x86-
> bin-djt.zip.
>
> Here is the ntp.conf
>
> restrict default nomodify notrap nopeer noquery
> restrict 127.0.0.1
> restrict -6 ::1
> driftfile "C:\Tools (x86)\NTP\etc\ntp.drift"
> server 0.uk.pool.ntp.org iburst  minpoll 6 maxpoll 6
> server 1.uk.pool.ntp.org iburst minpoll 6 maxpoll 6
> server 2.uk.pool.ntp.org iburst minpoll 6 maxpoll 6
> server 3.uk.pool.ntp.org iburst minpoll 6 maxpoll 6
>
> Both behaved the same.  Starts off OK but then diverges within 10-15
> minutes...
>
> C:\Users\nick>ntpq -pn
>       remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> +83.170.75.28    129.215.42.240   3 u   22   64   17   29.272  1678.03
> 502.466
> +91.212.90.20    212.83.131.33    3 u   26   64   17   33.001  2234.68
> 866.070
> +94.125.129.7    195.66.241.10    2 u   29   64   17   29.231  2096.80
> 754.306
> *87.117.251.3    129.215.42.240   3 u   35   64    7   30.169  2057.24
> 721.950

Except what I've mentioned before I have had rare cases where the 
Windows timekeeping was generally broken due to some drivers.

If I remember correctly then one case was a hard disk driver, and a some 
latency checker program was used to show that the driver had blocked 
IRQs for too long, so the timekeeping was strongly degraded.

In a different case the problem was in a graphics driver, with similar 
results.

Only after these drivers had been removed or replaced the Windows 
timekeeping was such that the NTP service was capable of disciplining 
the system time.

This has been quite some time ago, and I doubt that the same drivers are 
still around, but there can be other drivers causing such problems, and 
it't really hard to figure out which one this could be. :-(

>
> C:\Users\nick>ntpq -c rv
> associd=0 status=c613 leap_alarm, sync_ntp, 1 event, spike_detect,
> version="ntpd 4.2.7p450 at 1.2483-o Jul 17 7:20:46.78 (UTC+01:00) 2014  (1)",
> processor="x86", system="Windows", leap=11, stratum=4, precision=-10,
> rootdelay=40.347, rootdisp=2373.606, refid=87.117.251.3,
> reftime=d7725e20.9a026670  Thu, Jul 17 2014 15:37:20.601,
> clock=d7725e90.71d4a9d9  Thu, Jul 17 2014 15:39:12.444, peer=21225, tc=6,
> mintc=3, offset=0.000000, frequency=441.549, sys_jitter=333.000556,
> clk_jitter=0.977, clk_wander=0.210
>
> This is a Windows 7 problem but I don't think it is the http://
> support.microsoft.com/kb/2537623 one.
>
> It's a clean install of Windows 7 + SP1.
>
> ntpd works so well under Linux on the same machine.  I also installed the
> Meinberg release on an old XP box on the same subnet and it was showing
> offsets of 5ms or less within 15 minutes.
>
> Could this be caused by running a 32 bit executable on a 64 bit OS?  Is
> there a 64 bit binary available?

I've never heard of any problems due to the fact that NTP is 32 bit 
only, even on 64 bit machines.

Some time ago I've tried to build a native 64 bit version of the NTP 
software, but even though the NTP core routines compile fine in native 
64 bit *ix environments, the Windows port uses versions of some ISC 
libraries which don't compile for 64 bit. It would require quite some 
effort to get this working, and I doubt it would fix the problems wee 
see on Windows.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list