[ntp:questions] ntpdate.c unsafe buffer write

David L. Mills mills at udel.edu
Tue Feb 12 14:53:34 UTC 2008


Martin,

The time constantis automatically adjusted for prevailing network jitter 
and oscillator wander. THe question is what choice in the configuration 
file. In the latest snapshot you can use the discard average command to 
override the minimum poll from 4 (15s) to 3 (8s), which results in a 
risetime of about 250 s. It might not be well known that the clock 
filter uses only the latest sample before the clock is set. You can 
reduce the number of samples required using the tinker maxdist command. 
Effectively, you can disable all ntpd algrotihms and set the clock on 
the first xample.

Now, having reduced the poll interval to 8 s, you should try using a 
typical pool server, say across the Atlantic. The frequency will usually 
bounce alll over the place. It works just fine on a LAN and the poll 
interval usually ramps up to 10 (1024 s) in an hour.

Dave

Martin Burnicki wrote:

> Dave,
> 
> David L. Mills wrote:
> [...]
> 
>>The ntpd time constant is purposely set somewhat large at 2000 s, which
>>results in a risetime of about 3000 s. This is a compromise for stable
>>acquisition for herky-jerky Internet paths and speed of convergence for
>>LANs. For typical Internet paths the Allan intercept is about 2000 s.
>>For fast LANs with nanosecond clock resolution, the Allan intercept can
>>be as low as 250s, which is what the kernel PPS loop is designed for.
> 
> 
> Wouldn't it make sense to adjust the time constant depending on the time
> after startup, and/or the quality of the responses from the upstream
> servers?
> 
> I.e. the time constant could be smaller after startup to get a fast initial
> correction, and then increase depending on the requirements.
> 
> The packet delay and jitter should also give a good indication whether an
> upstream server is on the local LAN, or on the internet. So the settings
> used to make ntpd work well for the worst cases could be used if those
> cases apply, but the limitations could be reduced in non-worst cases.
> 
> Martin




More information about the questions mailing list