>>> In article <[EMAIL PROTECTED]>, David Woolley <[EMAIL PROTECTED]> 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 phases. 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 are describing. 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 David> configuration. 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 <[EMAIL PROTECTED]> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
