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

unruh unruh at invalid.ca
Fri Oct 11 21:28:09 UTC 2013


On 2013-10-11, mike cook <michael.cook at sfr.fr> wrote:
>
> Le 11 oct. 2013 ? 19:36, Brian Inglis a ?crit :
>
>> 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?
>
>    Good point. It seemed self explanatory at the time. 
>  offset  :  seconds as reported by ntpdate -d.
>  delta t : difference in time between 2 samples
>  delta t(s): the same in seconds 
>  delta offset : difference in offset between two samples
>  frequency:  drift per second.
>  average:  all values reduced to ppm
>  
>  
>> 
>> 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.
>> 
>
>   The first line is the ntp calculated drift of the raspberry when disciplined with internet servers.  This is historically around 36ppm since I have had it, varying just a couple of ppm with temperature.
> The table is data taken with the raspberry "disciplined" by its local clock (127.127.1.1) and the data shows that resulting drift is the same whether or not the system clock is disciplined by NTP.
>
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> *127.127.1.1     .;-).           10 l   29   64  377    0.000    0.000   0.002
>  127.127.20.0    .NMEA.          15 l    -   16    0    0.000    0.000   0.000
>  127.127.28.0    .GPS.           15 l    -   16    0    0.000    0.000   0.000
>  127.127.22.0    .PPS.            0 l    -   16    0    0.000    0.000   0.000
>  145.238.203.14  .TS-4.           1 u   42   64  377    3.501  -3618.9   5.915
>  145.238.203.10  145.238.203.14   2 u    3   64  377   13.389  -3615.4   5.950
>  193.224.45.106  40.179.132.91    2 u   43   64  377   82.689  -3639.8   5.222
>
> the internet servers are flagged noselect and the other ref clocks are disconnected

Now, stop ntp. erase the drift file. and restart ntp and see what
happens. THIS is the situation your users will find themselves in. 
Also do this now for a week, not an hour, or 10 min.

If you want to see the fluctuation in rate of a clock, look at
www.theory.physics.ubc.ca/chrony/chrony.html
for a plot of the offset and drift on some typical desktop PCs. I use
chrony rather than ntp since the control of the clock is many times more
accurate than ntpd, but that is irrelevant. It shows what the
correction tothe drift rate of typical clocks is, and also shows the
variability of that drift rate over the days (I have about 6 years worth
of data). 

In your case, the clock will be off by 35PPM (why do you use commas as
the decimal point sometimes and periods at other times?)
which, is about a half minute per day without correction. And there will
be significant variability in that which will cause additional time
accumulation. Of course some people do not care if their clock is out by
an hour a year. ntp is not for them. 




More information about the questions mailing list