[ntp:hackers] ntpd's sync state

David L. Mills mills at udel.edu
Tue Jun 3 02:14:51 UTC 2008


You got your wish. Virtually the entire error budget is available via 
ntpq. You get to decide from these data whether or not to accept the 
statistics. You do not get to change anything on the server, which might 
be operated by somebody else.


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