[ntp:questions] Bad Synchronization with NTP 4.2.7p285 under Windows 7

Dave Hart hart at ntp.org
Fri Jun 29 15:53:01 UTC 2012


On Thu, Jun 28, 2012 at 11:53 UTC, Robert Hegner wrote:
> I built NTP 4.2.7p285 with Visual Studio 2010 and I'm trying to synchronize
> my Win7 box to some public time servers.
>
> It works really bad. The offset jumps around like crazy (-0.559s ... 0.174s)
> and quite often it loses all its servers (all entries are white in NTP Time
> Server Monitor).

By design, ntpd clears all its stats for all peers when stepping
(setting) the clock, as opposed to changing its rate (slewing).  When
operating correctly, stepping is rare after first synchronization.
The clearing of stats is required as they are invalidated by the clock
step.

> I'm not experienced with NTP so maybe it's just the configuration I use
> which is bad.
>
> I start the ntpd with the following command line:
>
> C:\Program Files (x86)\ntp-dev-4.2.7p285 build\bin\ntpd.exe -U 3 -M -g
> -c "C:\Program Files (x86)\ntp-dev-4.2.7p285 build\etc\ntp.conf"
> -f "C:\Program Files (x86)\ntp-dev-4.2.7p285 build\etc\ntp.drift"
> -l "C:\Program Files (x86)\ntp-dev-4.2.7p285 build\etc\ntp.log"
> -s "C:\Program Files (x86)\ntp-dev-4.2.7p285 build\stats"

Though I don't expect it will help, I'd remove -U 3 and -M for now.
The latter instructs ntpd to reiterate the local network addresses
every three seconds.  Unless you're using terrestrial WiFi from a
moving vehicle, that is excessive and could degrade ntpd performance.
-M instructs ntpd to crank the system scheduling precision up to the
maximum precision of 1 millisecond, to avoid clock anomalies seen in
Windows XP and earlier versions when that scheduling precision changed
with the coming and going of interactive apps.  I suspect -M is not
helpful on Windows Vista and later.

> Below you can also find my ntp.conf, and some lines of ntp.log and
> peerstats. Does anyone have an idea on what's wrong here??

> 28 Jun 09:00:55 ntpd[7968]: ntpd 4.2.7p285 at 1.2483-o Jun 22 16:14:40.96
> (UTC+02:00) 2012  (1)
> 28 Jun 09:00:55 ntpd[7968]: Raised to realtime priority class
> 28 Jun 09:00:55 ntpd[7968]: Clock interrupt period 15.600 msec
> 28 Jun 09:00:55 ntpd[7968]: Performance counter frequency 3.118 MHz
> 28 Jun 09:00:55 ntpd[7968]: MM timer resolution: 1..1000000 msec, set to 1
> msec

-M applied

> 28 Jun 09:00:55 ntpd[7968]: Windows clock precision 1.000 msec, min. slew
> 6.410 ppm/s
> 28 Jun 09:00:55 ntpd[7968]: using Windows clock directly
> 28 Jun 09:00:55 ntpd[7968]: proto: precision = 1000.000 usec (-10)

ntpd detected the system clock precision is better than 4 msec and so
is not attempting to synthesize a higher-precision clock from the
ticking system clock plus the performance counter.  The OS clock ticks
forward every millisecond.

> 28 Jun 09:00:55 ntpd[7968]: proto: fuzz beneath 0.098 usec

It takes only 98 nanoseconds to read the clock.  Each reading ntpd
takes of the system clock has random noise added below that magnitude,
to make timestamp prediction difficult.

[network goop]
> 28 Jun 09:00:55 ntpd[7968]: peers refreshed
> 28 Jun 09:00:55 ntpd[7968]: 0.0.0.0 c012 02 freq_set ntpd 0.000 PPM
> 28 Jun 09:00:55 ntpd[7968]: 0.0.0.0 c011 01 freq_not_set
> 28 Jun 09:00:55 ntpd[7968]: 0.0.0.0 c016 06 restart
> 28 Jun 09:00:55 ntpd[7968]: DNS 0.ch.pool.ntp.org -> 212.101.0.10
> 28 Jun 09:00:56 ntpd[7968]: DNS 1.ch.pool.ntp.org -> 81.94.123.17
> 28 Jun 09:00:56 ntpd[7968]: DNS 2.ch.pool.ntp.org -> 192.33.96.102
> 28 Jun 09:00:56 ntpd[7968]: DNS 3.ch.pool.ntp.org -> 217.147.208.1
> 28 Jun 09:01:02 ntpd[7968]: 0.0.0.0 c614 04 freq_mode

There is no saved drift value to set the initial clock rate
correction, so ntpd allows the clock to run at its uncorrected rate
for at least 5 minutes to estimate that frequency error.

> 28 Jun 09:06:34 ntpd[7968]: 0.0.0.0 0612 02 freq_set ntpd 506.206 PPM
> 28 Jun 09:06:34 ntpd[7968]: 0.0.0.0 061c 0c clock_step +0.168060 s
> 28 Jun 09:06:34 ntpd[7968]: 0.0.0.0 0615 05 clock_sync
> 28 Jun 09:06:34 ntpd[7968]: frequency error 506 PPM exceeds tolerance 500
> PPM
> 28 Jun 09:06:35 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer

After 5.5 minutes the difference between the initial offset estimate
and the latest suggests your system clocks runs 506 parts-per-million
slow, so the correction needed is +506 PPM, which exceeds ntpd's
design limit of +/-  500 PPM.  ntpd adjusts the clock rate by the
maximum +500 PPM.

> 28 Jun 09:06:56 ntpd[7968]: 0.0.0.0 c613 03 spike_detect +0.163921 s

21 seconds after stepping the clock forward 168 ms, the latest offset
estimation is disturbingly similar and is discarded as a "popcorn
spike" (presumed measurement noise).  Adding +peerall to your
logconfig line in ntp.conf would enable entries each time a current
best source is selected.

> 28 Jun 09:09:01 ntpd[7968]: 0.0.0.0 c615 05 clock_sync
> 28 Jun 09:22:17 ntpd[7968]: 0.0.0.0 0613 03 spike_detect -0.194519 s
> 28 Jun 09:27:02 ntpd[7968]: 0.0.0.0 061c 0c clock_step -0.291333 s
> 28 Jun 09:27:02 ntpd[7968]: 0.0.0.0 0615 05 clock_sync
> 28 Jun 09:27:03 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 09:32:50 ntpd[7968]: 0.0.0.0 0613 03 spike_detect -0.151563 s
> 28 Jun 09:36:08 ntpd[7968]: 0.0.0.0 061c 0c clock_step -0.199364 s
> 28 Jun 09:36:08 ntpd[7968]: 0.0.0.0 0615 05 clock_sync
> 28 Jun 09:36:10 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 09:38:59 ntpd[7968]: 0.0.0.0 c613 03 spike_detect -0.191208 s
> 28 Jun 09:46:28 ntpd[7968]: 0.0.0.0 c61c 0c clock_step -0.246502 s
> 28 Jun 09:46:28 ntpd[7968]: 0.0.0.0 c615 05 clock_sync
> 28 Jun 09:46:30 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 09:49:20 ntpd[7968]: 0.0.0.0 c613 03 spike_detect -0.182278 s
> 28 Jun 09:52:27 ntpd[7968]: 0.0.0.0 c61c 0c clock_step -0.276819 s
> 28 Jun 09:52:27 ntpd[7968]: 0.0.0.0 c615 05 clock_sync
> 28 Jun 09:52:28 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 09:55:33 ntpd[7968]: Detected positive leap second announcement for
> 2012-07-01 00:00:00 UTC
> 28 Jun 09:57:36 ntpd[7968]: 0.0.0.0 0613 03 spike_detect -0.162238 s
> 28 Jun 10:00:46 ntpd[7968]: 0.0.0.0 061c 0c clock_step -0.215302 s
> 28 Jun 10:00:46 ntpd[7968]: 0.0.0.0 0615 05 clock_sync
> 28 Jun 10:00:47 ntpd[7968]: Leap second announcement disarmed
> 28 Jun 10:00:47 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 10:00:54 ntpd[7968]: Unable to remove prior drift file C:\Program
> Files (x86)\ntp-dev-4.2.7p285 build\etc\ntp.drift, No such file or directory
> 28 Jun 10:29:10 ntpd[7968]: 0.0.0.0 0613 03 spike_detect -0.166497 s
> 28 Jun 10:35:47 ntpd[7968]: 0.0.0.0 061c 0c clock_step -0.478724 s
> 28 Jun 10:35:46 ntpd[7968]: 0.0.0.0 0615 05 clock_sync
> 28 Jun 10:35:47 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 10:35:54 ntpd[7968]: 0.0.0.0 c613 03 spike_detect -0.190668 s
> 28 Jun 10:49:19 ntpd[7968]: 0.0.0.0 c61c 0c clock_step -0.275107 s
> 28 Jun 10:49:19 ntpd[7968]: 0.0.0.0 c615 05 clock_sync
> 28 Jun 10:49:20 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 10:49:26 ntpd[7968]: 0.0.0.0 c613 03 spike_detect -0.286189 s
> 28 Jun 11:04:42 ntpd[7968]: 0.0.0.0 c61c 0c clock_step -0.306810 s
> 28 Jun 11:04:41 ntpd[7968]: 0.0.0.0 c615 05 clock_sync
> 28 Jun 11:04:42 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 11:04:48 ntpd[7968]: 0.0.0.0 c613 03 spike_detect -0.235016 s
> 28 Jun 11:13:30 ntpd[7968]: 0.0.0.0 c61c 0c clock_step -0.264298 s
> 28 Jun 11:13:30 ntpd[7968]: 0.0.0.0 c615 05 clock_sync
> 28 Jun 11:13:31 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 11:31:17 ntpd[7968]: 0.0.0.0 0613 03 spike_detect -0.177049 s
> 28 Jun 11:35:55 ntpd[7968]: 0.0.0.0 061c 0c clock_step -0.273984 s
> 28 Jun 11:35:55 ntpd[7968]: 0.0.0.0 0615 05 clock_sync
> 28 Jun 11:35:56 ntpd[7968]: 0.0.0.0 c618 08 no_sys_peer
> 28 Jun 11:36:03 ntpd[7968]: 0.0.0.0 c613 03 spike_detect -0.381124 s
> 28 Jun 11:49:22 ntpd[7968]: 0.0.0.0 c61c 0c clock_step -0.400168 s
> 28 Jun 11:49:22 ntpd[7968]: 0.0.0.0 c615 05 clock_sync
>
> and so on ...

With the +500 PPM adjustment, your clock is running faster than your
sources' clocks.  This suggests the initial frequency estimate was too
fast.  Each time ntpd believes it has a useful offset estimate, it
exceeds the default 128ms step limit and so the clock is stepped and
peer stats are cleared.

You might simply remove the driftfile and restart ntpd to see if the
problem cures itself.  If not, remove or # comment out all but one
server line in ntp.conf, so that a single remote source is used,
eliminating the possibility that the frequency measurement was thrown
off by using different sources for the starting and ending offset
estimates of the frequency calibration.  Remove the driftfile again
and restart ntpd.

Cheers,
Dave Hart


More information about the questions mailing list