Bill wrote: > On 2011-08-27, Chris Albertson <albertson.ch...@gmail.com> wrote: >> Use some logic. Assume you want to set a mechanical clock's speed by >> moving the "slow/fast" lever and you can see the time only to the nearest > > Ah yes, but why a) would you want to only adjust it that way, an b) > why not do a fit and figure outexactly what the rate of the clock is > and how far out it is, and correct that, rather then simply "shove the > rate a bit higher if you see the clock time is behind time now, and a > bit slower if you see the clock is ahead." (which is what ntp does).
Using phrases like "shove the rate a bit" seems pretty disingenuous to me, Bill. >> second by eye. If you want the clock to lose/gain one second per >> day then it will take you one day (at best) to adjust the time as it >> would take that long to detect an error. It may take a day for the error to be out by a full second, but that in no way means it takes 24 hours' time to discover that the local clock is running at a rate that is off by 1 sec/day. If the time is usefully measurable to, say, 1 msec (just to pick an easy target), then we'll "notice" an error of this rate in about a minute and a half. If we can get usefully measurable time to .1 msec, then we can notice that error in less than 8.7 second's time. >> If you want to adjust the rate such that it only gains one second per >> month it would take a month before you'd know if you got it right. No... see above. >> You have to remember that NTP works be adjusting the rate, faster or >> slower and tried hard to never "jump" the time. The only why for >> anyone to know if the rate is right is to wait, greater accuracy >> requires longer a wait. > > But ntpd has no compunction about jumping the time if it is out by 125 > ms. It does not try very hard not to jump the time at all. 128 ms. ntp is designed to work well in a pretty wide variety of circumstances. The model says that we adjust the time at a rate that does not exceed 500ppm, and that the computer's clock will keep time at a rate that is not more than 500ppm away from "correct" time. It is usually much better than that. Once ntpd has gotten the local clock sync'd, there should be no cases where the clock diverges by 128ms - if it does there is another problem, and that problem should be found and fixed. Given the time it takes to "amortize" a correction of 128ms, do you feel it is better to not "step" that correction? If you don't like the 128ms value you can change it. This is not to say that different algorithms would not do "better" for some folks, and we're taking steps to make it easier to deploy and test different algorithms. >> NTP works kind of like this. Small errors take a long time to detect >> and smaller errors take even longer to detect. So up to a point >> NTP's error > > no, an error in offset of 1 usec can be detected immediately if you > have a good reference (and almost never if you do not) . And an error > in rate of 1 usec/s can be detected easily within a minute. Yup. >> So the conservative answer is "24 hours" but for most practical >> purposes you are "good enough for file system time stamps and the >> like" after 1 or 2 hours. > > Depends on your accuracy requirements. and as I mentioned elsewhere, it is "normal" for this stability to be had within 11 seconds' time of ntpd starting. And if no good drift file is available, I believe that number increases to around 15 minutes' time (more or less). If you have sufficiently-motivating need for even better time stability, then relying exclusivelyl on internet time servers doesn't seem ... appropriate. H _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
