[ntp:questions] ntpdate removal is coming

Harlan Stenn stenn at ntp.org
Tue Dec 13 00:14:26 UTC 2011


Joe wrote:
> There are environments where uptime is critical.=A0 A premium is
> placed on resolving down systems and restoring them to operational
> production in the minimal amount of time.=A0 Various applications,
> databases, and audit/security logging infrastructures (especially for
> post-analysis) require accurate time throughout the enterprise.=A0
> Emphasis is placed on standing up new systems (with improved baseline,
> apps, etc...) as soon as possible.=A0 Etc...

Agreed.

> 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.=A0 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

Yes, agreed, mostly.  Ntpd will track time by slewing corrections of up
to 128ms.  If you want something "better" than that it's worth
monitoring to see what sort of behavior you see, and then understand
what the issues are and how best to mitigate them.

> 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.=A0 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.=A0 ntp is expected to keep the time accurate (or
> accurate enough) from then on.

I suspect Bruce's definition of "accurate" and "stabilized" are
different from mine.

My discussion relates to what I belive ntp's defiinitions are (or
perhaps should be).  I suspect Steve or Dave Hart might have different
or clarifying suggestions.

The goal I'm aiming for is:

- as quickly and efficiently as reasonably possible
- get ntpd to the point where 'leap != 11'

Related items:

- it takes some time to get a good idea of the drift.  We have seen that
  we can get the drift calculated to 3ppm or better in 300 seconds, so
  we should be able to get the drift calculated to 30ppm or better in 30
  seconds' time.  Miroslav says that from lan-based sources chrony can
  get <3ppm with about 10 seconds' worth of samples, but it takes 10s of
  minutes to do the same thing on a wireless network. 

- as far as ntpd is concerned, if the underlying clock has an intrinsic
  drift of less than 500ppm (as measured against "nominal" time) it should
  be able to keep the clock sync'd (monotonic time, no steps).

- If the reference time(s) that ntpd follows do not jump around by more
  than ~128ms, ntpd will not 'step'.

ntpd considers itself "syncd" when it has what it considers to be a
good idea of the drift and knowledge of the correction needed.  Once
this is known, ntpd will step or slew the correction and shift from
leap==11 to leap!=11.  (This sentence is pretty lame - with more
research I could do better.)

"ntpd considers itself syncd" does not mean that:

- its idea of the drift is accurate/precise to better than a few ppm
- the offset to reference time is any better than 128ms
- the jitter or dispersion values are particularly "good"

Under some circumstances it may take may hours to achieve this level of
stability.  But in the interim, assuming the above constraints have been
met, the clock is sync'd and has stayed that way.

> 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!=A0 NTPD can, and sometimes does, take ten hours
>>> to reach "steady state".=A0 It needs about thirty minutes to find a
>>> reasonable facsimile of the correct time.=A0 For the next nine hours
>>> and thirty minutes, it will refine that value until it's as good as
>>> it's going to get.

Again, I think Richard's idea of "steady state" any ntpd's idea of
"syncd" are different.

> 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).

Again, it depends heavily on the definition of "operational".

If you have systems that need great, stable time ASAP, you may need to
do some additional work (like feed them a PPS signal, have sufficient
numbers of LAN-based time sources, tweak some loop variables, etc.).

H


More information about the questions mailing list