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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
