[ntp:questions] ntpdate.c unsafe buffer write
stenn at ntp.org
Sun Feb 10 21:30:14 UTC 2008
>>> In article <47aed826$0$509$5a6aecb4 at news.aaisp.net.uk>, David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
David> Harlan Stenn wrote:
>> In the case I describe, at the end of that O(11 second) period the clock
>> is Real Close (ie, the offset is "low enough"), the frequency drift is
>> known and compensated for, and ntpd is in "state 4".
David> As I read 4.2.4p4, for a warm start, the clock is within 128ms on
David> exit. However, if it wasn't stepped, because it was already within
David> 128ms, it will be slewing at maximum rate. Allowing 100ppm for
David> motherboard tolerances, that means that it can take up to a further
David> 320 seconds to reach the low milliseconds. I don't believe it would
David> be safe to start ntpd in normal mode within that period.
Why would ntpd be exiting during a warm start?
For the case I'm describing the startup script sequence is to fire up 'ntpd
-g' early. If there are applications that need the system clock to be
on-track stable (even if a wiggle is being dealt with), that's 'state 4',
and running 'ntp-wait' before starting those services is, to the best of my
knowledge, all that is required.
I have not seen a situation that requires 'ntpd -q', and I am not talking
about it here, either.
David> For a cold start, it won't reach state 4 for a further 900 seconds
David> after first priming the clock filter.
If the system has a good drift file, I disagree with you.
David> The 128ms is the tinkerable clock_max value, so it would be possible
David> to configure for a tighter tolerance, but that probably means using
David> different config files for start and run.
And what is the big deal with using different config files? The config file
mechanism has "include" capability so it is trivial to to easily maintain
common 'base' configuration with customizations for separate start/run
But the bigger problem is why are you insisting on separate start/run
phases? This has not been "best practice" for quite a while, and if you
insist on using this method you will be running in to the exact problems you
David> The 900 is also the
David> tinkerable clock_minstep. Note that setting clock_max to zero really
David> sets it to infinity.
David> Tinkering comes with the comment:
David> Special tinker variables for Ulrich Windl. Very dangerous.
David> The best advice for someone trying to simulate ntpdate -b is probably
David> to make sure that the clock is wrong by at least 128ms before
David> starting. That way, you should get a step, even with the default
No, the best advice is to understand why you have been using ntpdate -b so
far and understand the pros/cons of the new choices.
You seem to be going for a "locally optimal" solution here and the 2nd order
effects of this locally optimal solution are biting you.
Get a bit more altitude and I believe you will find a "more optimal" solution.
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org - be a member!
More information about the questions