Unruh, As you can see from the Allan deviation plots in the briefings on the NTP project page, it does no good whatsoever to average over ten hours; the observations are completely uncorrelated over that lag. The Allan intercept, or best averaging time, is more like twenty minutes to two hours, depending on the whims of fate and the cut of the rock.
It is a matter of physics that the NTP offsets will truly average out to zero in the long term unless there is an intrinsic bias in the timestamp calculations and, believe me, these calculations are very carefully done to reduce residual bias to essentially zero. In principle, assuming a precision source is available, this puppy can hold better than one picosecond. If you see a persistent nonzero offset, there very likely is an oscillator frequency problem or the adjtime() or equivalent system call has an inherent bias. In any case, even if it does, and unless there is a huge frequency error in the order of several hundred PPM, the long term average offset will be very close to zero. In principle, comparing ntpd and chrony or any other vehicle is meaninful only if using the same hardware, operating system and poll interval. I assume chrony has done its homework and optimized the time constant for the given poll interval. I am on a limb here, because nobody has confirmed that chrony does in fact discipline the clock using some sort of feedback loop sensitive to both time and frequency offset. If in fact it does not, then why are we having this discussion? Dave Unruh wrote: > [EMAIL PROTECTED] (David Woolley) writes: > > >>In article <[EMAIL PROTECTED]>, >>Unruh <[EMAIL PROTECTED]> wrote: > > >>>No, the offset is the value reported in loopstats. > > >>Same thing. If chrony is reporting the same measurements, neither set of >>measurements is particularly valid. You need to measure the actual > > > I am sorry but I do not understand what you are saying. The best estimate > of the time error of the clock is the measurement that you make of that > error. Now, you might argue that if the drift never changed, and the clock > never changed then one could get a better estimate by averaging the > measurements. But the hypothesis that the time reported by the ntp process > is the true time plus random uncorrelated errors is simply wrong, as > looking at the plot of the offsets will rapidly convince you. The offsets > oscillate with a period on the order of an hour or so. Chrony does this. > ntp does this. The errors are NOT gaussian uncorrelated random errors. > > Thus most of that error budget is in such correlated errors, and ntp does > NOT do many orders of magnitude better ( even with uncorrelated random > errors you would need to average 100 samples-- collected over 10 hours at > poll 7 to get one order of magnitude, and by then the drift errors would have > gotten you.) > > Anyway, I am comparing like with like in the two programs. Chrony is much > "better" in offsets, which implies that at least half of the error in ntp > is internal error. Ie, it is errors which do NOT average out. ( and I do > not believe that chrony's errors are the minimal uncorrelated random errors > either.) > > >>offsets, using something that has a repeatability a couple of orders > > > Of course that is the best way. Unfortunately I do not have that. I might > extend the line running the main server to also give me the "true" offsets > for the machine. However one can also get an estimate of the errors by > looking at the measured offsets using the ntp exchange. > > >>of magnitude better. Certainly for ntpd, offset should be much larger >>than the error, when locked. Is the server running ntpd? > > > I do not believe this. > Yes, the server is running ntp and its offset errors are of the order of > 3usec-- again correlated as you can see from the "string" graph near the > bottom of the page. > > For example, if I take a 10 element running average and subtract it from > the raw output of ntp for the server , the standard deviation goes from > 3usec to .5usec. Ie, the errors are highly correlated. Averaging may be > able to "get > rid" of that .5usec, but not the rest of the standard deviation (3usec) > which is some sort of highly correlated noise. IF the errors were really > uncorrelated random errors then subtracting off the running average would > make no ( well, little) difference to the standard deviation.( it would > decrease it by something like sqrt(N-1/N) where N is the length of the > running average) > > Ie, it is simply not true that the measured offsets reported by ntp, or > chrony, > are simply some independent gaussian random process around the "true time". > > > > >>Anyway, as I said, arguing by proxy is difficult and I'm rather hoping that >>Dave Mills will take over. Certainly it is Dave Mills you have to >>convince if ntpd is going to change. > > > I do not know if I am trying to "convince". I am trying to report the > outcomes of some experiments. Now if one (Mills) wants ntp to behave > differently than the experiments show it does, then I guess he will change > it. If not, then not. > > All I say is that the experiments I have carried out show that ntp is slow > to converge if it starts of badly, and leaves the offset scatter larger > than chrony does. It does have a smaller scatter in the rate. > > One of the great advantages of two different people-- Mills and Curnoe-- > trying to impliment the same ideas in different ways is that one can learn > by studying the difference between their results. > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
