In article <[EMAIL PROTECTED]>, Unruh <[EMAIL PROTECTED]> wrote:
> but the offsets are still over 100 times worse than I was getting with > chrony. (Yes, I know, one suggestion is-- go back to chrony-- but the Note that chrony seems not to have been updated for several years and its knocking copy on ntpd refers to an obsolete version and isn't, I think, entirely true even for that. It has never been supported on this newsgroup, and I'm not aware that its author has ever contributed here. It's based on NTP version 3, but looks as though it has a completely different local clock discipline algorithm. The local clock discipline algorithm is an appendix, and appears to be non-normative in NTPv3, but there isn't enough information, in the documentation, to establish whether the rest of it is compliant with the RFC. It does look to be rather more than the typical SNTP client, as it seems to support multiple servers and seems to maintain a frequency correction. I get the impression that it uses a statistics based, linear regression, approach, rather than the engineering based, phase locked loop on in the reference implementation, but again the documentation is not explicit on that. It's main claim to usefulness is for systems that only get occasional and irregular NTP readings, particularly systems that are on dialup, or which are primarily updated by wristwatch and eye. > I would assume that ntp is giving these samples with long round trip very low > weight, or even > eliminating them. Note: if these spikes are positive, they may be the result of lost ticks. Pop corn spikes of less than 128ms are not ignored in the default configuration. If, as I suspect, you only have one time source, they will get full weight (for multiple sources, I think delay may be used to weight the contribution between different sources). There are two possible approaches to such excursions. It might be possible to reduce the 128ms to whatever your 95 to 98 percentile figure is. However, I suspect that this will seriously compromise the ability to get initial lock and to recover from major disturbances. You could also use the huff and puff filter, if they are the result of asymmetric delays. I'm not sure how well that works on short timescales and whether it assumes a particular sense for the asymmetry. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
