Manuel Beicht wrote: > > I have some questions regarding synchronization and the output of "ntpq -p". > For example what is the significance of the "*" for example when you run ntpq > -p. Is this star a must because I have seen the polling sometimes and the time > mostly accurate but the "*" is missing. So does the server have to have a "*" > to be synched? In ntp documentation I read it just means that "*" denotes the
The *client* has to have a "*" against one of its servers to be synchronised. > server that the NTP client is synching to but not necessarily that they are IN That's an over-simplification. It is the server that determines the stratum and root distance/dispersion reported to downstream clients, but the time is, normally, synchronised to a combination of all servers with * or +. > synch. I am asking so far I considered any server without a "*" out of synch. > > Then I noticed the polling is dynamic but it seems to be too long with some > intervals and in particular too long when there is an offset. For example if > we have an offset of 1000 the polling is at 128 or at 256 instead of 64 or a If you have an offset of 1000, you need to fix the network/software/hardware problem that is causing that. Although a lot of people feel that ntpd fails to respond adequately rapidly to obvious error conditions, an offset of 1 second is too high to put any credence at all on the time source, except on start up. Either you have lost interrupts, which you need to address outside of nptd, or you have very large asymmetric network delays, and the measured "offset" bears little resemblance to the error in the internal time, and much more to the difference between uplink and downlink propagation times. > > Also what is acceptable offset and jitter? We currently experience 20-40ms < 128ms at the 99 percentile. Apart from that it depends on the structure of your timing network. For a PPS connected GPS timing receiver, it should probably be +/-500ns at the 95 percentile. For a consumer ADSL connection with only light traffic, maybe +/-10ms at the 90 percentile, dropping to maybe +/- 1ms for an essentially idle one at a quiet time of day. If there is a w32time system upstream, I suspect that +/- 40ms at the 95 percentile might be quite reasonable. > offset and 20-30ms jitter. sometimes it is up to 100-120ms offset. > Typically, you should compute the statistics over at least a day. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
