[ntp:questions] Extracting ntpq like information programmatically
unruh at invalid.ca
Sun Mar 31 01:07:40 UTC 2013
On 2013-03-29, Claudio Carbone <erupter at libero.it> wrote:
> On 29/03/13 18:04, David Woolley wrote:
>> Single PPS source with equal length cables to each machine.
> Machines are moving robots, and we operate indoor.
Well, equal depends on your requirements. Thus, equal could mean 300km
difference if you demanded only ms accuracy. or 300m for us accuracy (
which is really hard to do better than for a PC).
>> If the clocks are already synchronised by NTP, none of these will give
>> you a better time; all they will do is given you an idea of the error
>> bounds of the measurements. NTP offsets measured at the same time as
>> propagation time measurements for other messages will typically have
>> the same errors, and should be completely ignored.
> I measured and plotted the offset for a few minutes and it hovered
> around -2ms for a certain machine with respect to the master.
> Isn't this a decent estimate? Why can't I use a moving average of this
> offset to correct the other measurements?
Because ntp is already doing that.
Now, ntp has a time constant. It also throws away 7 of the last 8
measurements (keeps only the one with the shortest roundtrip). and it
slowly drifts the clock back to on time status. So, in the short term
you may be able to do better. But then suddenly there is a glitch on
your internet. The packet now takes 100ms to get back to you (all on one
direction of the path). You are going to use that 100ms offset to
correct your clocks? You can have ntp respond faster by using a shorter
poll interval if you want.
> I mean that, when I have certain timings from different machines, if I
> correct them by their average offset from a common source, doesn't this
> augment the precision of the measure?
Sometimes, and sometimes not. ntpd is really designed to keep the rate
of the clocks accurate, not the offset as much. Thus it tends to longer
poll intervals, and does not mind chucking 80 percent of the
> I'm using a single external source to compare all other clocks.
And if that single source goes bad?
> Since we're talking ms here, I can't put a blind eye to a 2ms offset: it
> may be even bigger than the measure itself.
> What I'm talking about is: if I measure the lag between a request and a
> replay between two machines, and this time is in the ms range, the clock
> offset may well represent 50% or more of the whole measure.
> I have to find a way to account for that or at least have an estimate.
You also want stability (ie not finding that the system jumps around)
etc. If you understand exactly what you want, and if that is different
from Mill's design requirement, you might be able to do somewhat better.
But you had better really know what you are doing.
There is a program, chrony, which responds to changes (eg temp
fluctuations) faster than does ntpd. It has a somewhat different design
philosophy. Its offset fluctuations are smaller than ntpd's by about a
factor of 3. But its rate fluctutions are similar.
More information about the questions