In article <vfmdnqnkujoias_anz2dnuu78yfnn...@giganews.com> Jakob Bohm <jb-use...@wisemo.com.invalid> writes: >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?
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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
