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

mike cook michael.cook at sfr.fr
Fri Oct 11 20:33:17 UTC 2013


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


> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


More information about the questions mailing list