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

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



More information about the questions mailing list