[ntp:hackers] ntpd's sync state

Colby Gutierrez-Kraybill colby at astro.berkeley.edu
Sun Jun 1 04:30:59 UTC 2008

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.

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

- Colby

More information about the hackers mailing list