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

Nick me at privacy.net
Thu Jul 17 17:08:10 UTC 2014


Brian

thank you for your reply.

Please see comments below.

Nick

On Wed, 16 Jul 2014 05:32:59 +0000, Brian Inglis wrote:

> It is easier to change the registry to have Windows manage the hardware
> clock in UTC, and necessary when you dual boot with Unix; you can then
> use any timezone setting you prefer in regional settings and the
> hardware clock will stick on UTC.

I did the tz change to the registry, and confirm that it works.  But it 
made no difference to the original problem i.e.

>> Restarting the service 'fixes' it for a few minutes, then it all begins
>> to 'diverge' again.
>>

> NTP requires system time to stay within 128ms of UTC (except at startup
> if you use the -g (panicgate) option, otherwise it steps the system
> clock to correct it. Ensure you have iburst on all your pool or server
> lines in ntp.conf.

Understood.  The RTC on the motherboard is capable of this because ntpd 
works well under Mint 17 on the same machine.

> Wait until all reach values show 377 and check the system status with
> ntpq -c rv, which should show something like (taken from a leap second
> example on the web, leap is normally 00):

Reach never gets anywhere near 377...

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

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


> If the precision estimate is -10 (MM timer frequency), restart Windows
> as ntpd will never be able to sync, and just restarting ntp service does
> not seem to help.

Starts off OK but soon diverges again.

> When the frequency stops changing in one direction, and starts
> oscillating, which may take hours on Windows, depending on your hardware
> clock drift rate and network jitter, you have your clock drift rate and
> your offset should be about as close as it will get to UTC, normally
> single or low double digits, about 10ms.

My old XP box with the Meinberg release on it shows offsets of < 10ms in 
15 minutes or so.

> You can improve the consistency of your time by pinning/setting affinity
> on the ntpd process to your last (highest numbered and least used)
> processor if you have moe than one core.
> You can do this on Windows in Task manager, by showing all processes,
> right click on ntpd, choose Set Affinity, and select the bottom check
> box; you can automate this with a PowerShell script run at startup,
> those run after services like ntpd are started.

Good idea, but there's something else going on here that needs to be 
fixed first.  Are there any issues running a 32 bit executable on Win 7 
x64 in your experience?



More information about the questions mailing list