[ntp:questions] NTP on CubieBoard

David Woolley david at ex.djwhome.demon.invalid
Mon Oct 13 16:51:34 UTC 2014

On 13/10/14 17:28, William Unruh wrote:
> On 2014-10-13, David Woolley <david at 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.

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.

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.

More information about the questions mailing list