[opensuse] Re: chrony and hwclock
Per Jessen wrote:
I don't use NetworkManager, and my systems run all the time. The hardware clock is of course UTC, local time is CET/CEST.
So, did you ever run systems with intermittent and unreliable time-delivered-by-GPS situations and used NTPD in such or similar environments? This reads more as in "my systems are almost always on-line and ntpd works there; it can handle the occasional drop in Internet connections". It's quite clear that ntpd works there like a charm. I had big problems in the past when ntpd decides that a time source is too unreliable and either drops it, or maybe even terminates itself because all time sources are too much off. I hope that it's clear that this is not handled by the ntpd service start when the servers are *not reachable at all* during startup. When they suddenly appear later on and are off completely, ntpd may lose its mind. ntpd has also great difficulties when time sources disagree massively what the time is. ntpd works great if you have multiple time-sources that are almost always available and where only quality of connection is managed by ntpd. The more spurious your connection becomes, and especially the more bad time source data quality is, the more problematic is its behavious -- and analysing "why for heaven's sake" the time got wrong this time is a herculean task that I wouldn't want to do for an embedded system that is literally off-roads. In the case of Roger, there is the additional problem that ntpd uses inherently a polling model for its time sources, with staggering polling intervals that shall spare the time servers from overload. AFAIU, Roger needs the complete opposite, a triggering model that takes into account each available PPS signal. Since I don't know chrony, I don't know if it delivers that -- but if it does so, if it is robust, and if the code looks good, I would go with chrony in the use case that Roger describes. Cheers, Joachim PS: In case this isn't clear: I fought with error analysis in big ntpd installations over several continents more often than I care to remember; at least if I want to sleep good at night. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Joachim Schrod wrote:
Per Jessen wrote:
I don't use NetworkManager, and my systems run all the time. The hardware clock is of course UTC, local time is CET/CEST.
So, did you ever run systems with intermittent and unreliable time-delivered-by-GPS situations and used NTPD in such or similar environments?
No, never with GPS, but with less-than-100% active connections, yes.
This reads more as in "my systems are almost always on-line and ntpd works there; it can handle the occasional drop in Internet connections". It's quite clear that ntpd works there like a charm.
It is also clear that the switching of time servers according to availability and quality works very well, just as it is (fairly) clear that Roger's problem is more of a timezone issue than an ntp ditto.
I had big problems in the past when ntpd decides that a time source is too unreliable and either drops it, or maybe even terminates itself because all time sources are too much off.
But localhost would surely always be available?
I hope that it's clear that this is not handled by the ntpd service start when the servers are *not reachable at all* during startup.
That is no doubt true, but when would localhost not be reachable?
When they suddenly appear later on and are off completely, ntpd may lose its mind. ntpd has also great difficulties when time sources disagree massively what the time is.
So do I. :-)
ntpd works great if you have multiple time-sources that are almost always available and where only quality of connection is managed by ntpd. The more spurious your connection becomes, and especially the more bad time source data quality is, the more problematic is its behavious -- and analysing "why for heaven's sake" the time got wrong this time is a herculean task that I wouldn't want to do for an embedded system that is literally off-roads.
In the case of Roger, there is the additional problem that ntpd uses inherently a polling model for its time sources, with
Yes, typically polling, but broadcast and using a PPS signal are alternatives that also work well (I use broadcast on my local systems). Using a PPS signal should now (as of 2.6.34) be possible directly too. I have not yet played with that. -- Per Jessen, Zürich (18.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (2)
-
Joachim Schrod -
Per Jessen