[ntp:questions] Odd reachability with local clock on XP

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Fri Oct 11 17:36:52 UTC 2013


On 2013-10-11 02:14, mike cook wrote:
>
> Le 11 oct. 2013 à 00:18, David Woolley a écrit :
>
>> On 10/10/13 16:57, mike cook wrote:
>>>
>>
>>>
>>> Well, that isn't as easy as it sounds because you get different offsets for each of the associations and you have do the sums yourself. NTP does it for you in calculating the system clocks' drift rate. It shouldn't matter whether you let NTP discipline the system clock or not. That is not something that I have tried though. I'll start up a raspberry pi and check it out.
>>>
>>
>> The system clock and the "local clock" are the same thing.
>>
>> The application here specifically requires that the system clock not be disciplined.  Ideally it would require ntpd to maintain a virtual system clock (i.e.  maintain the offset from the actual system clock to the one used by ntpd).

> Difference in system clock drift between NTP disciplined raspberry and an undisciplined one. As you can see it makes no difference.
> So for your customer you just have to convert his drift as calculated by NTP into an expected accumulating daily offset to frighten him.
>
>
> ntp disciplined system clock    frequency  35,838 ppm
>
> date              time           offset           delta t        delta t(s)       delta offset      frequency
> 10/10/13   18:55:03  -0.054971
> 11/10/13   00:33:48  -0.779718   05:38:45      20325          -0,724747    3,56579089790898E-005
>                    00:35:14  -0.782706   00:01:26             86          -0,002988   -3,47441860465128E-005
>                    01:35:20  -0.911900   01:00:06        3606           -0,129194   -3,58275097060455E-005
>                    02:35:26  -1.041195   01:00:06        3606           -0,129295   -3,58555185801442E-005
>                    03:35:32  -1.170547   01:00:06        3606           -0,129352   -3,58713255684969E-005
>                    04:35:38  -1.300116   01:00:06        3606           -0,129569   -3,59315030504714E-005
>                    05:35:45  -1.429946   01:00:07        3607           -0,12983      -3,59939007485445E-005
>                    06:35:51  -1.559755   01:00:06        3606           -0,129809    -3,59980587909041E-005
>                    07:35:57  -1.689703   01:00:06        3606           -0,129948    -3,60366056572379E-005
>                    08:36:03  -1.819713   01:00:06        3606           -0,13001      -3,60537992235163E-005
>
>                                                                                                            average    -35,797  ppm

This does not say what unit magnitude your offsets are - s, ms, us?

NTP will always show you its current estimate for your system drift. That is its 
first order of magnitude correction. NTP drift initially approaches the hardware 
value along a negative exponential curve.

It looks like your NTP is still trying to figure out its corrections, as the 
offset and drift deltas are monotonic, not oscillating. Getting there can take 
from less than three hours to more than three weeks depending on your time 
sources. Once the values are oscillating, the mean, deviation, and RMS values 
become meaningful.



More information about the questions mailing list