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 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. >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. >> 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. Yes, I can say that. Elementary clock measurement techniques tell you which of the two clocks is better, even if you do not know which. How in the world do you think the people who run the national time standards know which the better or worse clocks are? They have no clock that is better than the ones they have to act as a standard. They have the best in the world, and they can tell which is better or worse. If A and B both using the same time standard C and if A compared to C has much less variance than B when compared with C, then A is better. You do not know exactly how much better, but you know it is better. ( C does not have to be better than A and B, just not much worse. But in my case, string (C) is much better ( NTP controlled by ai GPS PPS) than A (flory on chrony) or B(flory on ntp).) >> 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. I have no idea why a mixed strategy is needed. Even in steady state, chrony does at least as well as, if not significantly better than NTP. Stubborness is good. As long as it is allied with a willingness to listen and reexamine his own preconceptions. Scientific progress is made by people defending their position but being willing to give it up if it becomes clear that it is wrong. I am not arguing that chrony's approach is the be all and end all. I think that there are problems. One of the reason I did the comparison was to see if ntp did things better. I see "oscillations" with chrony, but I am not sure if they are real ( ie correspond to real variations in the drift rate of the clock) or are somehow generated by chrony. The oscillations in the frequency seem to be less in ntp but the offsets worse. You can of course make the changes in the frequency zero, by never changing it. That will of course make the offsets attrocious. That tradeoff may be what is happening with NTP. But, so far the evidence is that chrony does better on almost all fronts than ntp does as a clock control mechanism, whether on transients or in steady state. Of course I have only tested things in a limited range of situations. If there are areas where it is worse, I would be anxious to find out what they are. 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
