On 2013-04-26, Biebaut Sven <sven.bieb...@be.thalesgroup.com> wrote: > Hello, > > 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 > > 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....@lists.ntp.org > [mailto:questions-bounces+sven.biebaut=be.thalesgroup....@lists.ntp.org] On > Behalf Of unruh > Sent: 26 April, 2013 03:22 > To: questions@lists.ntp.org > Subject: Re: NTP with GPS and RTC > > On 2013-04-25, Harlan Stenn <st...@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@lists.ntp.org > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
