[ntp:questions] NTP on CubieBoard
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
> 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