Unruh wrote: > > Chrony is also a server. The key detraction for me is that it cannot use > hardware clocks.
That would be a specification violation (should level, I think), as chrony is only an SNTP implementation. In some "off list" correspondence with Dave Mills be points out one reason for this is that the end to end response of an NTP network depends on all steps implementing the protocol properly. My impression is that, even though the clock discipline algorithm isn't normative in NTPv3, that includes using the specified discipline algorithm. I suspect this may be enforced in the latest version of the specification. I strongly suspect that the pool server people wouldn't want chroony as a pool server, although it turns out that someone was running optenntpd as one. > are better than NTP's are. The key question is how close to the real time > is the time that the system clock delivers. Chrony is closer by factors of > at least 2 and probably if run at high priority as my ntp is, much better You cannot say that except when the system is clearly out of lock, as you are not measuring the necessary parameter, because to do so would require special instrumentation. > I have seen this both with a chrony controlled clock and an NTP controlled > clock. It is just that the NTP response is not good. As noted in another article, I suspect what might be needed is a mixed approach, using the chrony approach to gain or regain lock (whilst signalling alarm and stratum 16 downstream) with the ntpd approach used when the loop is locked. However Dave Mills can be particularly stubborn. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
