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

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed Jul 16 05:32:59 UTC 2014


On 2014-07-15 05:07, Nick wrote:
> This machine dual boots Mint 17 x64 and Win 7 SP1 x64.
>
> I have set the hardware clock to UTC.
>
> Mint 17 and Win 7 run on local time.
>
> I need reasonable time sync for WSJTX < 1 second.
>
> On Mint 17 ntp from the repo works well with offsets in the low
> tens of milliseconds, sometimes < 10ms.
>
> On Win 7 I have installed ntp-4.2.6p5 at spider-man-2-win32-setup.exe.
>
> This does not seem to work properly.
>
> The jitter and offset 'diverge'...

Unix always uses UTC internally and runs the hardware clock on UTC,
Windows always uses UTC internally but normally runs the hardware
clock on local time set in regional settings, which can be set to
"UTC (Coordinated Universal Time)", so your system and hardware clock
both run on the same timescale.
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.
To make Windows do so, save the lines below in a Windows text file e.g.
WindowsUTC.reg, using e.g. notepad, import it into regedit, restart
your system, get into the BIOS and check the clock is still showing UTC
time, then restart Windows and ntpd.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
      "RealTimeIsUniversal"=dword:00000001

> C:\Users\nick>ntpq -p
>       remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> +head1.mirror.ca 195.66.241.2     2 u   19   64   77   33.361  1150.37
> 398.012
> +rad.22pf.org    164.47.15.177    3 u   10   64  377   30.518  1146.44
> 381.704
> +ntp.oceanmediag 140.203.204.77   2 u   13   64   77  138.709  1201.64
> 438.477
> *ntp0.sccis.net  193.62.22.74     2 u   18   64   77   36.415  1147.99
> 385.595
>
> These are not the worst offsets I've seen; 3 seconds is not unusual.
>
> Restarting the service 'fixes' it for a few minutes, then it all begins to
> 'diverge' again.
>
> Using the default ntp.conf except for "pool uk.pool.ntp.org iburst".
>
> What have I missed?

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.
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):

associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p5 at 1.2349-o Sat May 12 09:54:55 UTC 2012 (1)",
processor="x86_64", system="Linux/3.2.0-2-amd64", leap=01, stratum=3,
precision=-23, rootdelay=188.939, rootdisp=125.721, refid=163.73.58.221,
reftime=d399a552.23661694  Sun, Jul  1 2012  2:18:26.138,
clock=d399a644.106215cf  Sun, Jul  1 2012  2:22:28.063, peer=60722, tc=7,
mintc=3, offset=-8.826, frequency=27.933, sys_jitter=11.106,
clk_jitter=10.861, clk_wander=3.028

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.

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.

With the above server stats, I am surprised the 138ms delay source is considered
a sync candidate and included in the offset calculation (tally flag +).
If it is not a pool server, you would do better by dropping it from your config,
as the other sources have much lower delay, and their delays and offsets are within
a few ms of each other, which will allow ntpd to get a better estimate  and faster.
I have found network sources with delay < 100ms, and offset and jitter < 10ms give
more consistent and better results.

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.

-- 
Take care. Thanks, Brian Inglis


More information about the questions mailing list