[ntp:questions] PPS via USB-to-serial adapter

Per Hedeland per at hedeland.org
Tue Aug 13 11:50:08 UTC 2019


In article <vfmdnQnkuJoiAs_AnZ2dnUU78YfNnZ2d at giganews.com> Jakob Bohm <jb-usenet at wisemo.com.invalid> writes:
>On 13/08/2019 13:24, Per Hedeland wrote:
>> In article <P42dnZkcsZtZH8zAnZ2dnUU78RHNnZ2d at giganews.com> Jakob Bohm
><jb-usenet at wisemo.com.invalid> writes:
>>> On 11/08/2019 15:44, Per Hedeland wrote:
>>>> Hi,
>>>>
>>>> Since the idea of using a USB-to-serial adapter for PPS is often
>>>> dismissed here as more or less pointless/useless, (due to the inherent
>>>> delays in the USB communication AFAIU), I found this recent post to a
>>>> couple of FreeBSD mailing lists quite interesting:
>>>>
>>>> https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html
>>>>
>>>> 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.
>>>>
>>>> In subsequent discussion he pointed out that it is significant that
>>>> the test was done on FreeBSD - while he would expect similar results
>>>> on Linux, performance on Windows would be "all bets off" due to
>>>> varying driver quality.
>>>
>>> One of the hard parts is that the USB protocol is essentially polling at
>>> either 1kHz (USB 1.1 speeds) or 4kHz (USB 2.0 ~280Mbps speed).  This may
>>> be suitable for syncing around ms range.
>>>
>>> Thus if the USB controller clock in the computer is running close to
>>> its nominal speed, the delta between actual PPS pulse and USB event
>>> reaching the computer will be almost constant, varying only by the
>>> jitter and speed error of the USB controller clock, wrapping at 1000 or
>>> 250 usec.
>> 
>> Hm, I certainly don't know much about these details, but I have a hard
>> time seeing how this "almost constant" delta could explain the results
>> in the linked message. I'm not sure I'm getting the math right here,
>> but as far as I can see, assuming a clock that is only 1 ppm off,
>> (e.g.) the 1kHz clock would accumulate a full period of "offness" in
>> 1000 seconds, and during those 1000 seconds the delta would vary
>> across the whole 1000 usec interval.
>> 
>> If this is really the case, wouldn't this show up as a very high
>> jitter from ntpd's point of view? And/or an offset that was at least
>> half the 1000 usec interval, or possibly varying across that interval?

No comment on that?

>>> I haven't checked the iMX.6 datasheet for its USB controller internals
>>> (for example, does it take the frame clock from the 24MHz-derived bit
>>> lock or the from another clock that is closer to the PPS-synced clock in
>>> his experiments).
>> 
>> A subsequent message in the FreeBSD list thread
>> (https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016082.html)
>> states that the USB clock in the test case is not *derived* from the
>> 10 MHz clock that was used to generate the PPS signal, which could
>> otherwise explain the low jitter I guess - per above, I can't see how
>> the clock being "close" could do it.
>
>Hence my note that I don't know if the iMX.6 chip uses the USB bit clock
>crystal or the rubidium reference clock to control the USB frame rate.

OK, but now you know that the rubidium reference clock is *not* used
for that...

>>> I also haven't grabbed a copy of the serial port adapter USB subclass
>>> specification to check if there is something not happening at frame
>>> boundaries somehow.
>> 
>> This sounds very interesting, but again my knowledge is limited...
>> 
>
>Also note that the original post essentially argues that "if you only
>want 0.2ms accuracy, this is plenty good" (paraphrased), which could
>have been concluded without that experiment.

I'm not sure that I would call 0.2 ms "ms range", but of course it's
not *really* good - but as I noted earlier, ntpd can correct for a
(semi-)constant known offset (via 'fudge time1'), and the reported
jitter is definitely *not* "ms range".

--Per



More information about the questions mailing list