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

Jakob Bohm jb-usenet at wisemo.com.invalid
Tue Aug 13 11:32:14 UTC 2019


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?
> 
>> 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.

> 
>> 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.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



More information about the questions mailing list