[ntp:questions] ntpdate.c unsafe buffer write

David L. Mills mills at udel.edu
Tue Feb 12 03:25:05 UTC 2008


Tom,

With "tinker step .001" in the configuration file, ntpd -q will step the 
clock, unless the residual offset is less than .001 s. This is probably 
more complexity than you can stand. Just keep using ntpdate and be happy.

Dave

Tom Smith wrote:

> "ntdate -b" steps the clock. That's the function under discussion.
> The one that's used nearly universally in boot sequences.
> 
> -Tom
> 
> David L. Mills wrote:
> 
>> Guys,
>>
>> There seems to some misinformation here.
>>
>> Both ntpdate and ntpd -q set the offset with adjtime() and then exit. 
>> After that, stock Unix adjtime() slews the clock at rate 500 PPM, 
>> which indeed could take 256 s for an initial offset of 128 ms. A 
>> prudent response would be to measure the initial offset and compute 
>> the time to wait. The ntp-wait script waits for ntpd to enter state 4, 
>> which could happen with an initial offset as high as 128 ms.
>>
>> 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.
>>
>> Both the daemon and kernel loops are engineered so that the time 
>> constant is directly proportional to the poll interval and the 
>> risetime scales directly. If the poll exponent is set to the minimum 4 
>> (16 s) the risetinme is 500 s. While not admitted in public, the 
>> latest snapshot can set the poll interval to 3 (8 s), so the risetime 
>> is 250 s. This works just fine on a LAN, but I would never do this on 
>> an outside circuit.
>>
>> Dave
>snip




More information about the questions mailing list