[ntp:questions] ntp-4.2.6p5 on Win 7 x64
elliott.ch at comcast.net
Fri Jul 18 10:50:22 UTC 2014
If the reach is not 377, have you used WireShark or another TCP/IP
monitoring program to find out what is happening to the NTP packets? It is
not all hard to use.
> -----Original Message-----
> From: questions-bounces+elliott.ch=comcast.net at lists.ntp.org
> [mailto:questions-bounces+elliott.ch=comcast.net at lists.ntp.org] On
> Behalf Of Nick
> Sent: Thursday, July 17, 2014 1:08 PM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] ntp-4.2.6p5 on Win 7 x64
> thank you for your reply.
> Please see comments below.
> On Wed, 16 Jul 2014 05:32:59 +0000, Brian Inglis wrote:
> > It is easier to change the registry to have Windows manage the
> > clock in UTC, and necessary when you dual boot with Unix; you can
> > 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
> >> to 'diverge' again.
> > NTP requires system time to stay within 128ms of UTC (except at
> > 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
> > 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
> > 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
> +220.127.116.11 18.104.22.168 3 u 22 64 17 29.272 1678.03
> +22.214.171.124 126.96.36.199 3 u 26 64 17 33.001 2234.68
> +188.8.131.52 184.108.40.206 2 u 29 64 17 29.231 2096.80
> *220.127.116.11 18.104.22.168 3 u 35 64 7 30.169 2057.24
> 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
> processor="x86", system="Windows", leap=11, stratum=4, precision=-10,
> rootdelay=40.347, rootdisp=2373.606, refid=22.214.171.124,
> reftime=d7725e20.9a026670 Thu, Jul 17 2014 15:37:20.601,
> clock=d7725e90.71d4a9d9 Thu, Jul 17 2014 15:39:12.444, peer=21225,
> 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
> > as ntpd will never be able to sync, and just restarting ntp service
> > 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
> > clock drift rate and network jitter, you have your clock drift rate
> > 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
> 15 minutes or so.
> > You can improve the consistency of your time by pinning/setting
> > 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
> questions at lists.ntp.org
More information about the questions