[ntp:questions] Loopstats jitter field mostly zero?

Dave Hart hart at ntp.org
Sun Nov 25 21:37:27 UTC 2012


On Sun, Nov 25, 2012 at 06:25 UTC, David Taylor wrote:
> On 24/11/2012 20:26, Dave Hart wrote:
>>
>> On Sat, Nov 24, 2012 at 7:56 PM, David Taylor
>> <david-taylor at blueyonder.co.uk.invalid> wrote:
[...]
>>> I really can't imagine that such a low-powered server is /that/ good -
>>> better than a nanosecond.
>>
>> What version of ntpd is the embedded device using?  ntpq -c "rv 0
>> version" <target name/IP>
>>
>> ntpd's internal jitter calculation is done using C floating "double"
>> which is at least 64 bits.  Is the value you see working down to zero
>> over time, or starting and staying at zero?  How close are the
>> exceptions the "most of the values" to 0 nanoseconds?
>
> The version is:
>   ntpd 4.2.7p324 at 1.2483 Mon Nov 19 16:03:37 UTC 2012 (1).

Thanks.

> There are a few non-zero values to start with, but once NTP is near settled
> the values are zero.  This is a stratum-1 device with a PPS feed, running
> Linux.  It starts at non-zero, works downwards, and then drops suddenly to
> zero.  64-bit floating point seconds would have been adequate, I believe.  I
> wonder whether there's a 32-bit truncation somewhere?  Or if two large
> values are being subtracted where the difference value may be of much lower
> precision?
>
> This was, I believe, a start-up on the third line:

Fourth line, it looks like.

> 56255 64514.309 -0.000000340 -42.659 0.000000000 0.000128 4
> 56255 64530.309 -0.000000043 -42.659 0.000000000 0.000120 4
> 56255 64546.308 -0.000000393 -42.659 0.000000000 0.000117 4
> 56255 64596.175 0.000000000 -42.687 0.000001907 0.000000 5
> 56255 64603.148 0.000103553 -42.671 0.000036655 0.005731 5
> 56255 64607.148 0.000045082 -42.670 0.000000000 0.005366 5
> 56255 64613.148 0.000067766 -42.669 0.000000000 0.005049 5
> 56255 64615.160 0.000063706 -42.667 0.000000000 0.004773 4
> 56255 64631.148 0.000050000 -42.654 0.000000000 0.006210 4
>
> The poll of 5 would have been the LAN servers, and the poll of 4 the PPS.
> Could it be a limit in the Raspberry Pi's hardware?
>
> For comparison, here is a Windows system (PC Alta) also running as a
> stratum-1 server with version:
>   ntpd 4.2.7p326 at 1.2483-o Nov 21 15:15:30.79 (UTC-00:00) 2012 (1).
>
> 56255 161.055 -0.000012299 3.400 0.000019057 0.000191 4
> 56255 177.055 0.000010981 3.400 0.000019635 0.000188 4
> 56255 193.056 0.000002021 3.400 0.000018638 0.000176 4
> 56255 209.056 -0.000026469 3.400 0.000020135 0.000218 4
> 56255 225.055 -0.000012419 3.399 0.000019478 0.000215 4
> 56255 241.055 0.000024891 3.400 0.000022494 0.000242 4
> 56255 257.055 0.000017241 3.400 0.000021214 0.000244 4
> 56255 273.055 0.000005821 3.400 0.000020251 0.000231 4

Jitter is a measure of the variability of the phase offset across up
to eight entries in the clock filter register of the selected peer,
the "best" sample of which ends up as the third column of loopstats.
For a LAN peer best is lowest delay.  For PPS, it's the most recent,
as the delays are all zero and older entries accumulate more error
budget.  I expect the Windows PC to have a somewhat higher jitter than
similar hardware running FreeBSD or Linux, but the pattern of exactly
zero jitter recorded by your ARM-powered Pi doesn't look credible to
me.  It's happening right off the bat for the LAN source at startup,
and then shortly after switching to PPS.

I bet you don't see any exactly zero jitter in loopstats on your
FreeBSD PPS server.  I wonder if x86/x64 Linux ntp-dev users see
anything similar?

I'd appreciate others taking a look at their loopstats on Linux
systems and especially non-x86 Linux to see if 0.000000000 shows up in
the jitter (fifth column).  I think we need more information to
understand the problem.

Cheers,
Dave Hart


More information about the questions mailing list