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

Jakob Bohm jb-usenet at wisemo.com.invalid
Tue Aug 13 13:54:27 UTC 2019

On 13/08/2019 13:50, Per Hedeland wrote:
> 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...

No, I do not know that.  What I know from the BSD thread is that the USB
bit clock is probably running from the crystel, not that the USB frame
clock is running from that crystal.  And the USB frame clock is what
would affect the lock-step issue.

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

The original BSD post is that 0.2ms is what he considers "good enough".


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