Unruh wrote: > David Woolley <[EMAIL PROTECTED]> writes: > >> 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 am sorry, but this is idiotic. The ONLY requirement should be that the > communication protocol is implimented properly and that the clock is > disciplined properly. Anything else is none of the network's business ( and > furthermore they have no way of knowing-- the packets are fully ntp > compliant). >
I agree. I don't see how it can be a specification violation. The biggest factor is how well it keeps time. A caesium clock keeps good time but you wouldn't say that it violates the specification. > I have no idea what you mean that it is only an SNTP implimentation. > Chrony does nothing to upset the end to end response of the network. > While the NTPv4 draft does discuss the difference between SNTP and NTP it is not as clear as it might be. It might be a good idea to clarify this. > >> 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. > > They have no idea unless I tell them. And if it actually disciplines the > clock better, then they would be idiots if they took that attitude. Of > course convincing that it actually does discipline it better might be the > challenge. > The quality of the packets should be what counts here rather than the specific implementation and I have seen nothing here that indicates that chrony is not a good candidate for the pool. The last discussion on openntp indicated that there were many issues with it but we don't know what has changed since then. For the pool, being able to query the server is important to review the quality of each packet but to my knowledge only ntpd has implemented the query capability. That should not stop an implementation being a good candidate for the pool. > The purpose of ntp is not to be a monument to Dave Mills. It is to get the > best > control of computer clocks on the network possible. I am positive that he > agrees with that. Then the question is how to do that. That is what I am > trying to investigate. > > > Note that the attitude might be "who gives a damn. NTP computer clock > control is better than anyone has need of anyway." That is of course an > impregnable argument. It was also an argument that I am sure came up when > Dave developed ntp. rdate even now is pleanty good enough for almost all > purposes. Well there are plenty of situations where a very accurate clock is *very* important and rdate and company are not good enough. I will tell you that Dave is never satisfied with his own algorithms and is constantly reworking them to have them work better over a very wide range of conditions. Like everything else there are compromises that must be made in order that the best results are obtained over such a wide range of conditions. I don't think I have ever seen a document which enumerates and discusses all of those conditions though it certainly does exist inside Dave's head. Danny _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
