[ntp:hackers] ntpd's sync state

Danny Mayer mayer at ntp.isc.org
Sun Jun 1 21:49:20 UTC 2008

Colby Gutierrez-Kraybill wrote:
> On May 31, 2008, at 6:39 PM, Danny Mayer wrote:
>> Harlan Stenn wrote:
>>> Dave (et al),
>>> There is a need to be able to easily and consistently determine if
>>> system clock and/or ntpd's idea of its internal state and the system
>>> clock are "correct" (for some definition of correct).
>>> To offer this ability, it seems to me that the first thing we need to
>>> nail down is the definition and specification of "correct".
>> The real problem with this is that there is no such thing as "correct"
>> since all the results are statistical in nature. That's the true nature
>> of things like offset and error budget. You have no hope of defining
>> such "correctness".
> I respectfully disagree,
> Correctness in this case can assume a practical epsilon in terms of how 
> much error is tolerable which could potentially be user adjusted for the 
> return state.

Yes, but that's a bound condition of the error limits that you want to 
allow not a definition of correctness. The best you can do is define the 
maximum size of the error and ntp already does that for you.

>> You also have the problem of define what the official reference time is
>> since different countries have the own standards and reference points.
>> In the US it's NIST in Boulder, Colarado, in the UK it's NPL in
>> Teddington (I think), in France is the standards lab in Paris (I forget
>> where), and so on.
> While also, true, that is a matter for the user to decide.  Not allowing 
> users to define this with useful tools only ducks the issue.  The 
> correctness in terms of NTP is that it is attempting to lock to UTC.
> It seems the issue here is that it would be convenient to have this 
> check returned via an ntp tool, with room for defining what correct 
> means.  Documentation can provide for highlighting the pitfalls of 
> defining what is correct and not correct time keeping.

Since there's no way of define correct there is no hope of documenting 
this. All time is relative (see Einstein) and there are no absolutes 
despite what some people on this mailing list seem to assume. I'd 
suggest sending an alert if the server becomes unsynchronized. It's the 
only time you need to worry about it. If Judah has some additional alert 
points, I'm all for it.


More information about the hackers mailing list