[ntp:questions] What level of timesynch error is typical onWinXP?

Miroslav Lichvar mlichvar at redhat.com
Mon Oct 25 18:35:08 UTC 2010


On Mon, Oct 25, 2010 at 05:31:57PM +0000, David L. Mills wrote:
> For record, a hold timer is started when the first update is
> received after startup and ends when the residual offset is less
> than 0.5 ms or after a timeout of 600 s. During the hold interval
> the PLL loop time constant is set very low and the frequency
> discipline is disabled. With this arrangement, the offset typical
> converges within 600 s, even with initial offsets up to +-100 ms,
> and much less if the initial offset is in the 10-50 ms range. If you
> see different behavior, either with client/server or broadcast
> modes, please report.

I think I see a different behavior. I did few runs and made
offset/time plots. This is with client/server mode, 1ppb/s random walk
frequency noise, zero initial frequency offset, 100ms initial time
offset, 100us jitter (exponential distribution) and no drift file.

http://mlichvar.fedorapeople.org/tmp/ntp_start1.png
http://mlichvar.fedorapeople.org/tmp/ntp_start2.png
http://mlichvar.fedorapeople.org/tmp/ntp_start3.png

The first two are with daemon loop and the third one is with kernel
loop (SHIFT_PLL=4). A negative initial offset doesn't change the
outcome. The first one is particularly bad, looks like it went over
the step limit few times.

 1 Jan 01:00:00 ntpd.new[6319]: ntpd 4.2.7p71 at 1.2297 Mon Oct 25 09:43:53 UTC 2010 (1)
 1 Jan 01:00:00 ntpd.new[6319]: proto: precision = 0.101 usec
 1 Jan 01:00:00 ntpd.new[6319]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
 1 Jan 01:00:00 ntpd.new[6319]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
 1 Jan 01:00:00 ntpd.new[6319]: Listen normally on 1 lo 127.0.0.1 UDP 123
 1 Jan 01:00:00 ntpd.new[6319]: Listen normally on 2 eth0 192.168.123.3 UDP 123
 1 Jan 01:00:00 ntpd.new[6319]: 192.168.123.1 8011 81 mobilize assoc 9201
 1 Jan 01:00:00 ntpd.new[6319]: 0.0.0.0 c016 06 restart
 1 Jan 01:00:00 ntpd.new[6319]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
 1 Jan 01:00:00 ntpd.new[6319]: 0.0.0.0 c011 01 freq_not_set
 1 Jan 01:00:01 ntpd.new[6319]: 192.168.123.1 8024 84 reachable
 1 Jan 01:03:17 ntpd.new[6319]: 192.168.123.1 963a 8a sys_peer
 1 Jan 01:03:17 ntpd.new[6319]: 0.0.0.0 c614 04 freq_mode
 1 Jan 01:08:41 ntpd.new[6319]: 0.0.0.0 0612 02 freq_set kernel -96.799 PPM
 1 Jan 01:08:41 ntpd.new[6319]: 0.0.0.0 0615 05 clock_sync

Looks like the frequency calibration doesn't work correctly here.
Please let me know if you need more information.

-- 
Miroslav Lichvar



More information about the questions mailing list