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 [email protected] 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?
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
