[ntp:questions] C api to ntpd

David Woolley david at ex.djwhome.demon.invalid
Sat Dec 7 12:55:41 UTC 2013

On 07/12/13 11:54, Patrik Arlos wrote:
> On Friday, December 6, 2013 11:53:02 PM UTC+1, David Woolley wrote:

> The program just needs to keep track/detect when the synchronization is lost. Its used to correlate measurements at multiple locations, and the measurements include time. So, as long as the system is synchronized everything is assumed
> fine.

You need to define what you mean by the synchronisation being lost.  It 
is not a well defined concept.  The system will tolerate quite a few 
missed polls without complain, and even when responses completely dry 
up, the time will remain reasonably accurate for many hours.

> You are probably right with offset, but it provides a number. Would root distance be better? I'd like to compare time stamps (t1,t2) from two different locations (L1,L2). I was thinking to use the offset from each
> location (O1, O2) to a common server(t0), in order to have an idea of how close the time stamps are to each other.

If ntpd is working well, this will not give you that information.  It 
will only give you an indication of the variability in individual 
measurements.  It will also give you no indication as to the effect of 
systematic errors.

A node with an RMS offset of 5ms may have a systematic error of 15ms and 
an RMS error, in its internal time, from that 15ms offset of under 1ms.

>> Most people use ntpq and parse the output.  ntpd itself uses a limit on
>> root dispersion.
> Is there a C api for ntpq? or is the only solution to read the ntpq code, and extract the needed 'bits'?

Or read the specification of the relevant management requests.

On systems with kernel support, there is an API (adjtimex) that will 
give an estimated time error and a maximum time error, although even the 
former is usually pessimistic, as long as there is no systematic error. 
  I believe that ntpd no longer sets the TIME_BAD status, so you cannot 
use that as a loss of synchronisation indicator.

More information about the questions mailing list