On 13/08/2019 13:24, Per Hedeland wrote:
In article <p42dnzkcsztzh8zanz2dnuu78rhnn...@giganews.com> Jakob Bohm
<jb-use...@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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
