On 2013-04-26, unruh <[email protected]> wrote: > On 2013-04-26, Biebaut Sven <[email protected]> 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 >> [email protected] >> http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
