On 2010-11-05, David L. Mills <mi...@udel.edu> wrote: > Bo;;. > > At the time the clock is read and the adjustment has not completed, the > current offset is known, regardless of the residual offset not yet > amortized. At this point there is no need to consider the residual > offset, as a new offset has been determined regardless of the residual > offset. Therefore, the algorithm ignores the residual offset and starts > again with the new offset. If this is contrary to your belief, get used > to it. We are talking right past each other and need not continuje this > dialog.
No, it is not contrary to my understanding of how ntp works. It is contrary to my understanding of how to get the best clock discipline out of the measurements that have been made, but that is an issue that we have argued about before. You are a proponent of minimal Markovian control, I have become one of using the measurements that have been make in such a way as to discipline the clock to the best possible extent given those measurements. Whether or not chrony does it in the best possible way I do not know, but it sure is better than ntpd. > > If linux does not agree with the standard Unix semanitcs, which I know > for a fact has been in BSD Unix since 1986 at least, Linux will not work > properly. However, absent second-order effects, performance will be no > worse than if the training period was not used. However, Miroslav's > experience suggests second order effects do occur due unknown cause. In > that case, the only suggestion I can make is either find the cause, > abandon NTP or abandon Linux. Miroslav has of course been one of the chief people in improving chrony, so to some extent hae has gone down your second route. But I find it incredible that you would have the attitude you do toward a potential bug in the software you have spent so much time on. Linux is a far more popular piece of operating system than any of the BSDs, or even then UNIX, and to simply dismiss it as you do here is to me incredible. Now it may be that the bug is in Linux and not in ntpd, but that would also be good to find out. Lichvar is trying to help you, and your dismissal of that help is weird. Perhaps a better closing sentence would be "I do not have any Linux machines on which I can test ntpd, so please keep me informed as to what you find so I can fix ntpd (either due to a bug in ntpd, or to put in a workaround for a Linux bug)." > > Dave > > unruh wrote: > >>On 2010-11-05, David L. Mills <mi...@udel.edu> wrote: >> >> >>>Bill, >>> >>>You have absolutely no idea what you are talking about and you do reveal >>>an abysmal lack of understudying of control theory. To incorporate past >>> >>> >> >>Not if done properly. >> >> >> >>>history in future controls when the current control variable is measured >>>violates the time delay constrain. Go back to the books. >>> >>> >> >>I am afraid this is just wrong. >>The past history contains lots of information which can be used to >>predict the future behaviour. Of course you have to do it properly so as >>not to get instabilities, but that is always true. >> >> >> >> >> >>>Dave >>> >>>unruh wrote: >>> >>> >>> >>>>On 2010-11-04, David L. Mills <mi...@udel.edu> wrote: >>>> >>>> >>>> >>>> >>>>>Miroslav, >>>>> >>>>>The NTP daemon purposely ignores the leftover from adjtime(). To do >>>>>otherwise would invite massive instability. Each time an NTP update is >>>>>received, a new offset estimate is available regardless of past history. >>>>>Therefore, the intent is to ignore all past history and start with a >>>>>fresh update. Note that the slew rate of adjtime() is not a factor with >>>>>the kernel discipline. >>>>> >>>>> >>>>> >>>>> >>>>That is of course a philosophical position, and a strange one. Clocks >>>>are largely predictable systems ( that is why they are used as clocks). >>>>Thus the past history is strongly determinative of what the future >>>>behaviour will be. To act as if this is not true, that each now >>>>measurement should be treated as if it completely disconnected with the >>>>past is a strange way of treating a highly predictable system. That is >>>>of course one of the key places where ntpd and chrony differ. The >>>>evidence is that properly taking account of the past does not create >>>>"massive >>>>instability" but rather creates far more accurate discipling of the >>>>clock than does past amnesia. >>>> >>>> >>>> >>>> >>>>>Dave >>>>> >>>>>Miroslav Lichvar wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>On Wed, Nov 03, 2010 at 04:06:39PM +0000, Dave Hart wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar <mlich...@redhat.com> >>>>>>>wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>On Tue, Nov 02, 2010 at 10:03:30PM +0000, David L. Mills wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>I ran the same test here on four different machines with the >>>>>>>>>expected results. These included Solaris on both SPARC and Intel >>>>>>>>>machines, as well as two FreeBSD machines. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>[...] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Ok, I think I have found the problem. The adj_systime() routine is >>>>>>>>called from adj_host_clock() with adjustments over 500 microseconds, >>>>>>>>which means ntpd is trying to adjust the clock at a rate higher than >>>>>>>>what uses the Linux adjtime(). It can't keep up and the lost offset >>>>>>>>correction is what makes the ~170ppm frequency error. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>Congratulations on isolating the problem. If adjtime() is returning >>>>>>>failure, ntpd will log that mentioning adj_systime. Do you see any of >>>>>>>those? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>No, it's not an error in usage, adjtime() just don't have enough time >>>>>>to apply whole correction and ntpd doesn't check the leftover, so >>>>>>the offset is adjusted actually slower than what ntpd is assuming. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Is it a feature or a bug that FreeBSD and Solaris can apparently slew >>>>>>>faster than 500 PPM using adjtime()? >>>>>>> >>>>>>>If it's a feature, is there a way we can detect at configure time what >>>>>>>the adjtime() slew limit is without actually trying it? We don't want >>>>>>>to require root for configure. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Probably not. I think I saw on one BSD system only 100ppm rate, so it >>>>>>will have to be clamped to either the lowest rate from all supported >>>>>>systems or to a constant defined in the configure script based on >>>>>>the system and version. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>_______________________________________________ >>>>questions mailing list >>>>questions@lists.ntp.org >>>>http://lists.ntp.org/listinfo/questions >>>> >>>> >>>> >>>> >> >>_______________________________________________ >>questions mailing list >>questions@lists.ntp.org >>http://lists.ntp.org/listinfo/questions >> >> _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
