[ntp:questions] NTP with GPS and RTC
unruh at invalid.ca
Fri Apr 26 15:41:10 UTC 2013
On 2013-04-26, Biebaut Sven <sven.biebaut at be.thalesgroup.com> wrote:
> thank you for these enlightening explanations.
> The idea behind using the RTC as reference clock was that it would drift less than the local clock for the periods without external synchronisation.
Depends on the rtc you have. Bog standard rtc's-- no, they will drift
far more, not least because they are not being disciplined ( for the
system clock, ntpd has removed most of the drift from the local clock,
and all that is left is that due to temp veriations, crystal creep,
etc.) The rtc runs at whatever drift it was manufactured with ( and
there is absolutely not urgency for anyone to make it better). But then
you have a specialised rtc, so it may be better. For example some people
have cesium or rubidium controlled, temperature stabilised, "rtc"'s and
clearly they ARE better than the computer system clock.
> 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)
No idea what the DS3231 is, so cannot say. The computer system clock
will drift at a few PPM after having been disciplined by ntpd
previously. So if your rtc does better than that, then you are right.
It is effectively your "atomic clock" but you will probably have to be
the one to write a driver for it.
> - the kernel stops updating the RTC
The kernel update of the RTC (if that even works for your particular
version-- the kernel source is designed for interfacing with the bog
standard rtc on commercial grade computers.) throws it entirely out of
whack. chrony is a much better option. It does not step the rtc. It
measures the rtc and determines what its drift rate error is and its
offset error is, and uses that on next bootup, but could also be
designed to be used as a refclock.
> - there is no other existing mechanism that disciplines the local system clock
As with kids, let the system do what it wants. ntpd has already
disciplined it to take out the major drift and offset. As I said, it
will be maybe a few PPM out (depending on the temperature history, etc)
from 1-1 rate.
> Thanks in advance,
> Sven Biebaut
> Senior Software Engineer
> THALES BELGIUM, S.A.
> Rue Freres Taeymans 28
> B-1480 Tubize
> -----Original Message-----
> From: questions-bounces+sven.biebaut=be.thalesgroup.com at lists.ntp.org [mailto:questions-bounces+sven.biebaut=be.thalesgroup.com at lists.ntp.org] On Behalf Of unruh
> Sent: 26 April, 2013 03:22
> To: questions at lists.ntp.org
> Subject: Re: NTP with GPS and RTC
> On 2013-04-25, Harlan Stenn <stenn at ntp.org> wrote:
>> I gather it returns time to the nearest second - that will not be very
>> useful for OS or NTP timestamps. If you have to set the time to the
>> nearest second you will also need to take special care to make sure that
>> you set the clock at the "correct" moment of the second in order to get
>> the "seconds" transition to happen ar the right time.
> Well, actually, If you could set it so that it really kept the second
> properly, and it had an interrupt when the second turned, that would be
> just like a PPs clock with the seconds also delivered. Of course those
> careates are pretty big ones. I know with the normal rtc, you have to
> send it the set signal exactly .5 sec before the second transition
> actually occurs.
>> As I said above, I do not know if the OS is that careful about setting
>> the time of the RTC every 11 minutes.
> That of course makes is a very jumpy clock. every second its time
> suddenly jumps. You would be far better off disabling the 11 min process
> (chrony does that for you for example).
> questions mailing list
> questions at lists.ntp.org
More information about the questions