Re: Correlating SOF with host system time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 4 Dec 2012, Stefan Tauner wrote:

> Hi!
> 
> My broad goal is to transmit the current system time somewhat
> accurately to devices (namely fullspeed microcontrollers).
> 
> I'd like to be able correlate some instant of a USB frame (i.e. a point
> in time with a known offset to the SOF) with the host's system time. 
> The host PC can then create a snapshot containing the frame number, a
> timestamp (corrected by the offset to the frame's SOF if applicable)
> and send this in a normal data packet to the device(s). On the devices
> I can use SOF interrupts to take note of a local clock and compare that
> to the measurements of the host to derive real time.
> 
> These are the notes of my research in respect of standards:
> - UHCI does not define any interrupts that are related to the SOF/frame
>   borders.
> - OHCI defines a SOF interrupt (7.1.4 HcInterruptStatus Register).
> - EHCI does only define a Frame List Rollover Interrupt (2.3.2 USBSTS),
>   but that should suffice too for my purpose.
> - USB 3.0 is not my main concern, but there are some interesting bits:
>   * MFINDEX Wrap Events seem to be similar to the rollover interrupts.
>   * there exist Isochronous Timestamp Packets (8.7) to compensate for
>     the missing SOF packets.
>   * a special field in the hub descriptors (wHubDelay) allows to take
>     delays due to different hierarchies into account of synchronization
>     schemes.
>   * "Set Isochronous Delay" requests informs devices about transmission
>     delays.
>   see also http://www.usb.org/developers/presentations/SuperSpeed_USB_DevCon_Isochronous_Froelich.pdf
> 
> Regarding existing code i have seen a few references to the features above.
> EHCI code seems to just ignore/mask away the rollover interrupt
> STS_FLR (apart from debug prints).
> OHCI code uses the SOF interrupt (OHCI_INTR_SF) just for quirks and
> queue management(?).
> I have not really looked at XHCI code.
> (TBH i have looked at 3.2 code only yet, please flame me, if there have
> been any major related changes since ;)
> 
> From a user's perspective there is AFAIK only
> usb_get_current_frame_number() which is not very useful for my use case
> due to its polling nature. libusb does not even expose that:
> http://marc.info/?t=128477632000002&r=1&w=4
> 
> What do you think would be a reasonable approach to make userspace
> aware of SOF-related events/timestamps and/or achieve my goal? Do you
> think this might be useful/generic enough to be merged upstream? Do
> think i should instead just implement something vaguely similar to
> NTP/PTP on top of normal USB pipes? I am a complete linux kernel newbie
> (apart from applying existing patches, staring a bit at foreign code and
> compiling it), but I have always wanted to start hacking it... :)

I don't think referencing times to SOF packets is the best approach, 
although it probably is the approach that would yield the most 
precision.  How precise do you want your synchronization to be?

Running NTP over a USB-based network link would certainly be the 
easiest solution, if your device can support it.  Over the long run, it 
might even be more accurate on average than using SOF packets.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux