[ntp:questions] Extracting ntpq like information programmatically

unruh unruh at invalid.ca
Sun Mar 31 01:29:15 UTC 2013


On 2013-03-30, Claudio Carbone <erupter at libero.it> wrote:
> Thank you to those who answered, I'm learning a great deal about network 
> time compensation.
>
>
> On 30/03/13 07:55, David Taylor wrote:
>> Claudio,
>>
>> I offer you three monitoring techniques - two programs and MRTG. The 
>> programs are listed here:
>
> Thank you David, I had already spotted your site in another message to 
> this list/ng, unfortunately I work under linux, so can't use your 
> programs. But it was really interesting none the less.
>
>
>
> On 29/03/13 21:20, John Hasler wrote:
>> NTP has already used the offset to correct the system clock. You don't 
>> need or want to do anything. When NTP says that the clocks are 
>> synchronized they are as close as it is possible to get them over the 
>> network. 
>
> Then why does NTP give a number to the offset and delay?
> If the algorithm knows that it's lagging by X s, why doesn't it correct 
> for that lag?

BEcause it does not know it is lagging by X. All it knows is that on the
last measurement there was a certain offset. But it has no idea if that
is because the local clock is out, or because the network packets got
routed through China instead of through Texas on that particular measurment. 
> Alternatively, from my point of view, it ought to say that the clocks 
> are synchronized to the best of its knowledge without providing delays 
> and offsets.

You do not have to look at those figures. You seem to be saying you
would be happier if you did not know what the possible uncertainties in
the measurements are. Stop looking at the output of ntpq. 


>
>
>
> On 29/03/13 21:12, Chuck Swiger wrote:
>>> If so why doesn't the offset oscillate?
>> It usually does, although the most common type of cyclical offset variations occur with a period of 24 hours, resulting from day/night temperature changes affecting the quartz crystal.
> I may have much faster temperature variations in my case: embedded 
> boards do vary their core temperature a lot according to their loading. 
> No air conditioning can solve this, as my embedded boards are inside a 
> very small case and near batteries and motors (as I said previously I'm 
> managing a fleet of small robots).

One way is to put in a thermistor, and have ntpd monitor that, and
calculate the rate drift due to temp variations. There are a number of
suggestions for doing that, and even rewritten ntpd's to do that. 

Why don't you record your temperatures, and the rate at which ntpd or
chrony ( since you have linux) believes the clock is out, to see how
much of a worry temperature is. It is typically a few PPM. 

>
>> A well-designed compensation system doesn't over-force the corrective adjustment being made and thus avoids overshooting and then "ringing" back and forth across the setpoint.
> Sure but a well-designed compensation system should also keep lagging or 
> leading to avoid oscillation.

Yes. and you are telling it not to. It should use the immediate offset
to immediately correct the clock. That can give instability. Since it is
really really hard to predict the future, leading is rather hard to do. 


>
>
>
> I'm trying to understand here.
> If I send a message through a route, each machine adding their own 
> timestamp (kernel provided timestamp) at the time of processing, let's 
> say that between machines 2 and 3 there is a lag of 3.5ms.
> Now if I knew that the clock of machine 2 was lagging the time server by 
> 2ms and the clock of machine 3 was leading the time server by 0.5 ms, 
> why does this not mean that my real lag is 1ms ?

??? That is not how ntp works and is also not something you know. 
And how do you know that those times were due to their clocks being out,
or due to network delays. Maybe the packet took 1 sec to get to machine
2 and its time is out by 997 ms.
Ie, you are assuming knowledge you simply do not have. 



More information about the questions mailing list