[ntp:questions] ntpdate removal is coming

Richard B. Gilbert rgilbert88 at comcast.net
Tue Dec 13 18:14:22 UTC 2011


On 12/12/2011 5:22 PM, Joe Wulf wrote:
> I wanted to add to the conversation.
>
>> Harlan wrote:
>>> From: Harlan Stenn<stenn at ntp.org>
>>> Sent: Wednesday, December 7, 2011 6:56 PM
>>>
>>> OK, and exactly why do you need "the time offset in the ballpark before ntpd starts"?
>>     <snip>
>>> I believe we're gonna have both "ntp-wait" and "ntpd --wait-sync" behave as before, but we will also have a way to say
>>> "sync means XXX" as well, because some folks are fine with sync meaning "We do not expect the clock to step backwards,
>>> but we're still homing in on the steady-state" and others want this steady-state.  There may be more choices...
>>
>>
>> Bruce wrote:
>>> From: Bruce Lilly<bruce.lilly at gmail.com>
>>> To: questions at lists.ntp.org
>>> Sent: Wednesday, December 7, 2011 6:03 PM
>>> Also, I have not seen machines "fully sync'd" in anywhere near as quickly as 11 seconds, but my interpretation of "fully sync'd" may
>>> differ from yours; I consider a machine "fully sync'd" only when time offset, frequency offset, and jitter (as reported in
>>> loopstats) have all stabilized, which may take a few hours.
>
>
> I've another perspective, albeit presented generically, and something that is related to those points I think.  Harlan's specific question isn't exactly what I'm trying to answer (nor do I think I know how to), but it sparked my train of thought about relevant issues.
>
>
> There are environments where uptime is critical.  A premium is placed on resolving down systems and restoring them to operational production in the minimal amount of time.  Various applications, databases, and audit/security logging infrastructures (especially for post-analysis) require accurate time throughout the enterprise.  Emphasis is placed on standing up new systems (with improved baseline, apps, etc...) as soon as possible.  Etc...
>
>
> Setting aside for the moment all the other system building and/or troubleshooting activity that occurs---when a boot/reboot is called for, one of the essential elements is establishing accurate time and ensuring it remains accurate through to the end of the life of the current boot.  The resultant environment, whatever it is, needs to get functional (and thus productive) as soon as possible.
> -- accurate, around here is generally agreed upon, when 'correct to within 10-15 ms'; though certainly not more than 1 second
> -- 'life of the current boot' can be upwards of 6-9 months
>
>
> Due to latencies experienced (similar to the 'few hours' predicament Bruce refers to above) getting the system time to be accurate, it simply isn't acceptable to have systems/applications/databases wait 'a few hours' for time to stabilize, and remain accurate, before bringing the functional applications/databases of the systems online.  The end need is for systems to boot, time to get set accurately, or accurately enough (and quickly!) and then bring the system online for production use.  ntp is expected to keep the time accurate (or accurate enough) from then on.
>
> We've struggled with this issue, numerous times, especially when lack-of-time-accuracy has bitten.  ntp is something I'd like to better understand, if not master.  However.....
>
> borrowing a relevant post from a recent, though different thread:
>>> From: Richard B. Gilbert<rgilbert88 at comcast.net>
>>> Sent: Tuesday, November 29, 2011 5:26 PM
>>> Subject: Re: [ntp:questions] Ginormous offset and slow convergence
>>>
>>> On 11/29/2011 1:42 PM, Pete Ashdown wrote:
>>>>    Is there anything I can do to decrease the convergence time?
>>>
>>> Little or nothing!  NTPD can, and sometimes does, take ten hours to reach "steady state".  It needs about thirty minutes to find a
>>> reasonable facsimile of the correct time.  For the next nine hours and thirty minutes, it will refine that value until it's as good as it's
>>> going to get.
>
> An IT tech in my world would be fired, probably on the spot, for giving the above answer as justification for why getting a system operational takes so long (and we don't have near enough people as it is).
>
> I am certainly not an ntp guru; most of us where I work know a little bit, some don't know that much (about ntp  :) ).  I've tried to keep up on the ntp website and mailing list in order to learn something.  I work on NTP when I have to, as one of many duties.  The underlying essence of what Pete asked is really relevant.  I've come to learn enough, that there is underlying truth behind what Mr. Gilbert said---but don't understand enough so that I know why, much less what to practically do about it.  There is a compelling desire to have ntp expeditiously get time accurately and promptly, with little to no fuss and without the steep learning curve to get there.  I think I can handle ntpdate itself going away, as long as I have a reliable mechanism to learn, use well and apply to numerous, various, different environments and achieve consistent results.
>
> So, my intent isn't to fan flames---I'm characterizing one situation for further consideration, documentation and/or exploration.
>
> R,
> -Joe Wulf

Like it or not, NTPD, when started, will need up to TEN HOURS to settle 
down with the best time that you are going to get!  This is not a 
hardship if you run NTPD 24x365 (366 in leap years).  If you have to 
shutdown frequently and can't wait for NTPD to reach steady state then 
NTP is the wrong tool for you!

There is at least one other program that offers faster startup.  To 
really understand the trade offs you would need to understand control 
system theory.  If you can follow the math, Dave Mills wrote the book on 
NTP.

BTW, is your return key broken?  The paragraph beginning
"An IT tech . . ." is rendered by my news reader as a single line, 
several hundred character long!



More information about the questions mailing list