[ntp:questions] NTP with GPS and RTC

unruh unruh at invalid.ca
Fri Apr 26 16:23:54 UTC 2013


On 2013-04-26, unruh <unruh at invalid.ca> wrote:
> On 2013-04-26, Biebaut Sven <sven.biebaut at be.thalesgroup.com> wrote:
>>
>>>[ Long lines repaired. ]
>> Thanks, I will take better care next time
>>
>>>Biebaut Sven wrote:
>>
>>>> If I drop the idea of the RTC as a reference clock, am I correct in
>>>+ stating that, when there is no external synchronisation:
>>>> - my local clock and my RTC will drift away from each other, but at
>>>+ least my RTC will be closer to the mark (the DS3231 is chosen for its
>>>+ precision)

Just had a look at the DS3231. It is not bad (2PPM/month, 5PPM/year
drifts), and comparable to what you would get from a good onboard sysem
clock after ntp discipline. 
It delivers a square wave output, which you could have tick at once per
second, and put into some triggerable pin on your computer (serial port,
or parallel port for example) and use it as a refclock. There would not
be much benefit from it however over the disciplined local clock. 

Interesting that they would call 2PPM "Extremely accurate". 
Of course, because of its temperature control, it could well be better
than the system clock if you were in an environment with large temp
fluctuations. 


>>
>>>Probably not.  ntpd will continue to apply first order frequency 
>>>correction to the local clock.  
>>
>> Ah, I did not realise that. So a system with ntpd but without an external 
>> reference clock would still be more accurate than a system without ntpd 
>> at all ?
>
> Yes. By far.
> If you look at www.theory.physics.ubc.ca/chrony/chrony.html you can see
> the rate variations on a bunch of commercial grade systems disciplined
> by chrony, either with a local GPS or disciplined from that system.
> The rate varioations are on the order of .2 to 1 PPM over a day, with
> drifts of a few PPM per week. the daily variations are alost certainly
> due to temp variations due to workloads of the machines. The weekly
> drifts due to crystal ageing etc. 
> Note the raw corrections are of the order of up to 50PPM from the rate
> the clock would run at if it had not been disciplined. ( 50PPM is a few
> seconds per day)
>
>>
>>>Assuming the machine temperature was 
>>>reasonably stable, you would need to to trim hte DS3231 several times a 
>>>year to be sure of bettering a coasting local clock.  (2ppm per year, 
>>>maximum of 5ppm over first 10 years.)
>>
>> Unfortunately, access to the device will be impossible after its deployement, 
>> so it seems that just running ntpd with an external reference clock that only 
>> occasionally is present, is the only real option.
>
> Define occasionally. Unfortuneately ntpd requires about 5-10 hours to
> rediscipline a clock to ultimate accuracy when the connection comes up
> again, so if the connection time is shorter than that, chrony (assuming
> you run linux or some unix) is a better choice ( faster lock and
> discipline time). It also allows you to "trim by hand". Ie, if you can
> phone into the device, and find it is say 1 min off, you can tell chrony
> to correct that offset by hand.
>
>
>
>
>>
>>>> - the kernel stops updating the RTC
>>
>>>No.
>>
>> OK I guess, as ntpd will keep disciplining the local clock.
>
> It really makes the rtc almost useless, EXCEPT for reboots. 
>
>
>>
>>>> - there is no other existing mechanism that disciplines the local system clock
>>
>>> You have provided insufficient information about your system to answer this.
>>
>> Agreed. Actually, there is none implemented. I should have asked if there were 
>> any other mechanisms possible, but your answers to the other questions now make 
>> this unnecessary :) 
>>
>> Thank you,
>>
>> Sven
>>
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list