[time-nuts] Raspberry Pi NTP server

[jimlux]

On 7/15/20 5:16 AM, Petr Titěra wrote:
> On 15.07.2020 0:13, Trent Piepho wrote:
>> On Mon, Jul 13, 2020 at 4:52 PM Hal Murray <hmurray at megapathdsl.net> 
>> wrote:
>>>> Is there any way for a USB device to synchronise with the CPU clock 
>>>> (perhaps
>>>> via the USB framing) so that a special-purpose device could 
>>>> timestamp the PPS
>>>> occurrence with respect to CPU time ?
>>
>> It seems maybe this was thought about in USB 1.1.  From the UHCI spec:
>>
>>          Minor adjustments can be made to this value [ 1-ms frame time]
>> ...  This feature permits minor changes to be made to the frame time
>> period, if necessary, to maintain real-time synchronization throughout
>> a USB system.
>>
>> It seems like it would not be that hard to get the USB frame sequence
>> phase locked to the system clock.  One would need a way to measure the
>> phase offset of the USB S-o-F vs the system clock, and then it's a
>> standard process to phase lock, with the necessary control to do this
>> described above.
> 
> I think you can have problems with that. At least in general. Look at 
> this specification of system clock generation chip:
> 
> https://datasheet.datasheetarchive.com/originals/distributors/Datasheets-DGA19/372682.pdf 
> 
> 
> It seems to two independent PLLs to generate USB clocks and system 
> clocks. Is common frequency source enough to synchronize these two?
> 
> There are more recent generators which claim that they use one common 
> source for all generated frequencies but generally you can have separate 
> timing of USB and rest of the system.
> 
> Petr Titera
> 
>>

Yeah, but in the case of a USB-Serial dongle, they're not going to use a 
chip like that.

https://www.ftdichip.com/Products/ICs/FT231X.html is a typical simple 
USB-Serial part
It has a single 12 MHz internal clock (see fig 2.1 of datasheet) that's 
multiplied up to 48 MHz - of course they say nothing about anything else 
inside the chip.

It kind of depends on how they implemented the serial to USB functions - 
I'm going to guess it's simple software on a microcontroller (since FTDI 
makes microcontrollers too) and it's unlikely that the software is 
running an RTOS with multiple threads. More likely, it implements some 
sort of state machines, or possibly, a "big loop" polling scheme.  So I 
suspect the timing from Serial Port events to USB events is fairly 
consistent.