On 12/12/2011 5:22 PM, Joe Wulf wrote:
I wanted to add to the conversation.
Harlan wrote:
From: Harlan Stenn<[email protected]>
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<[email protected]>
To: [email protected]
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<[email protected]>
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!
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
