[ntp:questions] NTP on CubieBoard

William Unruh unruh at invalid.ca
Mon Oct 13 18:13:25 UTC 2014

On 2014-10-13, David Woolley <david at ex.djwhome.demon.invalid> wrote:
> 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.

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.

More information about the questions mailing list