On 2014-10-13, David Woolley <david@ex.djwhome.demon.invalid> wrote: > On 13/10/14 17:28, William Unruh wrote: >> On 2014-10-13, David Woolley <david@ex.djwhome.demon.invalid> wrote: >>> On 13/10/14 09:23, Rob wrote: >>>> On the PC platform, with a recent development ntpd I can achieve >>>> PPS sync with offset within a couple of us on systems in normal >>>> environment, and well within 1us in a temperature conditioned room. >>> >>> The correct quality measure is jitter, rather than offset. offset >>> varies from sample to sample but still doesn't tell you the systematic >>> error in the time. >> >> Not sure you meant to say that as nothing tells you the systematic error >> in time. If something did, ntpd would use it to get rid of that >> systematic error. But also, offset is the only measure you have of the >> error, and is what ntpd uses to control the clock. Or did you mean >> something else? > > I meant that offset contains a lot of measurement noise, but as you say, > it doesn't tell you how wrong the time is. jitter gives a measure of > the level of measurement noise, and should be fairly stable once lock is > acquired, rather than offset's random jumping around zero.
AGreed. > > Offset is only a useful measure when lock hasn't been acquired. Once > lock is acquired, jitter is a much better measure of the measurement > error. Even then, most of the jitter figure will be due to the network, > not the local clock. He was talking about a system with a refclock, but yes, most of the jitter, and the long term offset are from the way the system handles interrupts, etc. > > In this case, he is quoting a low jitter, which means that the offset > should also be low, unless ntpd has not yet acquired lock. If it can > measure a stable jitter of around a microsecond, I think you can almost > certainly rule out a pure interrupt driven clock. If the jitter > occasionally spikes, it could be that things are being synchronised to > ticks, but you would then see unusually high delays. > > Even if it events are being delayed until a tick, as long as the tick > frequency is fairly accurate, there could still be a very low offset, > even though the events are being delayed. If there isn't a good > frequency match, you would see an obvious sawtoothing in the offset, in > this case. > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
