[ntp:questions] ntp-4.2.6p5 on Win 7 x64
martin.burnicki at meinberg.de
Mon Jul 21 14:15:10 UTC 2014
> thanks for the reply. Please see comments below.
> 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
>> 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-
> 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
> C:\Users\nick>ntpq -pn
> remote refid st t when poll reach delay offset
> +126.96.36.199 188.8.131.52 3 u 22 64 17 29.272 1678.03
> +184.108.40.206 220.127.116.11 3 u 26 64 17 33.001 2234.68
> +18.104.22.168 22.214.171.124 2 u 29 64 17 29.231 2096.80
> *126.96.36.199 188.8.131.52 3 u 35 64 7 30.169 2057.24
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
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=184.108.40.206,
> 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.
More information about the questions