In article <[EMAIL PROTECTED]>, Rob van der Putten <[EMAIL PROTECTED]> wrote: > Olivier Bornet wrote:
> > Thanks for the link. If setting the HZ don't resolve my problem, I will > > try to adjust the drift. > AFAIK NTP can't handle asymmetrical link speeds. So if you have a busy NTP cannot handle asymmetrical link delays, asymmetric speeds don't necessarily produce these because they tend to be used in contexts where the downlink traffic is much higher than the uplink traffic. In fact they are likely to produce errors in the opposite direction to what you might expected if you judged by link speed alone. Also, it is variability in the delay difference, not the mean value, that matters. (Actually, I'm not sure how any protocol could fully account for assymmetric delays.) In any case, this issue doesn't seem to be relevant in this case, as I believe he had unidirectional stepping, and if you have unidirectional stepping, it normally means that you would have to slew faster than 500ppm to catch up. > I solved the problem with the '-x' option; The option that is intended to deal with this case is the huff and puff tinker option. I believe, that in recent versions, -x sets the step limit high, but not infinite, and that high step limits cause the kernel PLL to be disabled. Given that almost all consumer links and probably many service provide links are assymmetrically loaded, I don't think it a good idea to advise -x in all such cases. A lot of people are continually trying to advise people against using it when they think they have a problem with databases. > At boot the clock is synced with ntpdate, so the above doesn't cause any > problems. ntpdate is deprecated. More interestingly, it seems that certain optimisations to achieve fast initial convergence only work if the initial time is outside the step limit! _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
