[ntp:questions] PPS via USB-to-serial adapter
per at hedeland.org
Wed Aug 14 09:35:05 UTC 2019
In article <qiu8c1$1kfg$1 at gioia.aioe.org> Miroslav Lichvar <mlichvar at redhat.com> writes:
>On 2019-08-11, Per Hedeland <per at hedeland.org> wrote:
>> TL;DR^2 The author carried out a pretty sophisticated (IMHO) test with
>> two different USB-to-serial adapters feeding PPS to ntpd, and found an
>> offset of some 200 usec with 20-30 usec jitter. You can of course tell
>> ntpd to correct for the offset (once you know how large it is...), and
>> the jitter doesn't seem too bad to me, although it is of course higher
>> than for more "direct" connections.
>An offset of 200 microsecond is much larger than a typical error of NTP
>in a local network, so maybe that's why people don't like refclocks over
Just to avoid sounding like a broken record, I quote from the post you
point to below:
"The USB PPS has a ~125us static offset which is possibly from the
USB hub buffering the data. Static offsets are easy to deal with,
so I removed it for this graph."
>However, with a custom driver and firmware it's possible to reduce the
>offset and jitter to few microseconds. See this great post from Dan
Very interesting, although I suspect that having a USB "adapter" where
you can modify the firmware, *and* modifying that firmware, is a bit
"out of reach" for most users...
Anyway, back to the FreeBSD post, it seems there are actually two
1) Is the ~ 200 usec offset reported by ntpd really semi-constant (and
thus "easy to deal with")?
2) If it is semi-constant, why?
Interestingly, Dan's post above shows exactly the sawtooth pattern
across 1000 usec for the USB latency that I would expect if the USB
polling was done with a frequency that wasn't exactly an integral
number of periods per second. And he determines that this matches the
system clock error of 2.215 ppm, concluding "This probably means USB
on this system shares the same clock as the system clock".
And, in the FreeBSD post, the system a.k.a. kernel clock is actually
generated from the 10 MHz clock that is used to generate the PPS
signal, in order to achieve the "ideal world":
In an ideal world, there would be no
measurement jitter, or frequency drift in the kernel clock, and thus
all PPS measurements made would be directly comparable to each other
without having to ascribe any part of the differences between sources
to the kernel clock.
So it seems the answers are 1) yes, and 2) because apparently on this
system too "USB shares the same clock as the system clock", and thus
the USB polling frequency is actually locked to the 10 MHz clock
(which is essentially what Jakob suspected in the other subthread, I
guess). I.e. a *real* setup using the normal kernel clock would *not*
have a semi-constant offset.
More information about the questions