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

David L. Mills mills at udel.edu
Wed Oct 27 23:55:22 UTC 2010


Miroslav,

See the most recent ntp-dev. It needed some tuning.

Dave

Miroslav Lichvar wrote:

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




More information about the questions mailing list