Is it a good idea to use a usb-serial adapter for PPS? Yes, it is.

[Per Hedeland]

On 2019-08-19 09:20, Hans Petter Selasky wrote:
> On 2019-08-18 23:57, Ian Lepore wrote:
>> I think HPS reads the arm@ list, but I'll cc him directly on this
>> reply, just in case he has time to weigh in on this stuff.
> 
> Hi,
> 
> I'm subscribed.
> 
> The behaviour of BULK transfers depend on the actual USB host controller manufacturer.
> 
> USB transfers are executed by priority, typically:
> ISOCHRONOUS, INTERRUPT, CONTROL, BULK
> 
> Depending on the endpoint descriptor, the service rate may vary. The minimum guarantee is to be serviced one time every 125us (for USB2.0).
> 
> Completion interrupts are usually delayed a bit (63-125us for EHCI/XHCI, 1ms for USB 1.0 via UHCI/OHCI).
> 
> The USB stack in FreeBSD does not have any memory allocations in the fast path and so is very quick to complete jobs. Also in user-space.

I'm sorry, I'm afraid I still don't really understand... The question,
at least in my mind, was whether polling was done in a "strictly
periodic" fashion, at most once per 125 us for USB 2.0 - or whether
the host controller would poll "as fast as it could", which could
result in a *much* higher polling rate.

As others too have pointed out, the size of the latency doesn't really
matter for NTP as long as it is more or less constant (i.e. varies at
most a few tens of us, preferably less). I can't see how polling with
an interval of 125 us or more, based on the frequency of a crystal on
the host, could achieve a variation that is smaller than the size of
the polling interval.

> Technically speaking, the time device could make predictions about when the packet is read from the USB buffer and when the USB host issues the completion interrupt.
> 
> These adjustment values could be calibrated by some kind of ping protocol.

This sounds like a method to determine a fixed latency - or am I
misunderstanding?

--Per