On 2011-01-18, David Woolley <david@ex.djwhome.demon.invalid> wrote: > Miroslav Lichvar wrote: > >> >> Yes, when the jitter is too low or the clock too unstable. Ideally, >> ntp would run a statistic and adjust it in runtime. Chrony counts > > It does. I forget the exact metric, but look for the term poll adjust. > >> number of runs of residuals with same sign, perhaps it could work for > >> >> Linking them makes sense if you want to keep things simple and robust. >> The problem is that even the minimum allowed poll 3 is too long in >> some situations and that it wastes network bandwidth. > > Reducing the poll interval without reducing the time constant will > simply result in oversampling. The time constant will still determine > the loop behaviour. (It may make things worse if network delay > transients no longer fit within the 8 sample filter.)
If the error is random error, then oversampling is exactly what you want. It knocks down the error by the square root of the oversampling. > > >> >> Define error and network wander. > > It looks like you are actually measuring error, but most people assume > that what ntpd reports as offset is the error. > > Network wander is when, for example, an asymmetric load is applied > temporarily. With 3.1 kHz modems, that would result in such a large > wander that ntpd would start ignoring the server entirely, so was rather > benign. With lower speed DSL, it results in clock steps. With higher > speed connections, the peak to peak wander may be under 128ms. In none of my tests-- both ethernet in the university, or adsl/cable modem from home ( over commercial telephone/cable tv lines with their huge variability of load) have I ever seen such behaviour. >> >> Please note that the RMS offset is from the actual clock offset >> maintained by the simulator, not the one reported by ntp. >> _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions