[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