On 2012-02-03, David Woolley <david@ex.djwhome.demon.invalid> wrote: > unruh wrote: > >> >> The delays from refclocks are almost always all zero. Thus there will be >> no info in the delay as whther a problem occured. ntpd will simply >> assume it is as good as any other sample, and use it (the clockfilter >> uses delays to select samples) > > Even if all the samples are used, taking only one sample within the > glitch, and using a long time constant, will disturb the clock less than > taking multiple samples with a short time constant.
Well, it will distribute that error over a longer time as well. During that long time, the clock's frequency having been pulled away from the "true value" by the large error, will drift more. By the way, the impression I left that the a single glitch in the refclock would cause trouble is probably not right since I believe there is a median filter which throws away large offsets. > > >>> Offset is not a direct measure of the timekeeping error. >> >> It my not be a direct measure, but it is the only measure you have. And >> since ntpd is blind to history, it cannot even use history to determine >> such errors. >> > The point was that you need to understand whether you are getting high > offsets because the clock is wrong (e.g. temperature) or because the > offset measurements are wrong (e.g. interrupt latency). Agreed. Unfortunately ntp cannot help there. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
