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@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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
