[time-nuts] Raspberry Pi NTP server

[Petr Titěra]

Just one note. Most USB to serial chip claim USB2.0 support but they 
only provide Full-Speed data transfers. That is data communication 
protocol based on USB1.1 parameters with 1ms polling interval. You have 
to specifically look for High-Speed (i.e 480mbps) transfers when going 
trough chip specification. Not all manufacturers have such chips and no 
all chips from manufacturers who provide them have such capability.

To this day I was able to find only one such chip family and that is 
FTDI FT232H (that H suffix specifies High-Transfer rate).

Petr Titera

On 08.07.2020 22:02, Steven Sommars wrote:
> My RPi4 (Raspbian Buster) has a GPS+PPS/USB.  Serial->USB uses Prolific
> PL2303, which supports USB 2.0
> The PPS jitter is 1 msec (e.g., using ppstest).  lsusb -v shows:
> 
> Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
> Port
>          bInterval               1
> 
> which means 1 msec polling of the PPS signal.   I've been unable to poll
> more frequently, that seems to require driver changes.
> Petr, what polling rate do you see?    Has anyone been able to poll USB @
> 125  µsec on a stock RPi?
> 
> With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in an
> unpredictable pattern.    Although the PPS jitter is 1 msec, ntpd/chrony on
> my RPi4 typically reports low dispersion:  50-150  µsec.  The zero-mean
> assumption Achim mentioned is unlikely to be valid. Running chrony +
> GPS+PPS/USB I see a ~640µsec offset compared to a GPS+PPS directly
> connected to the GPIO pins.  That offset will fluctuate, of course.
> 
> Steve Sommars
> 
> 
> 
> 
> 
> On Wed, Jul 8, 2020 at 12:57 PM ASSI <Stromeko at nexgo.de> wrote:
> 
>> On Dienstag, 7. Juli 2020 18:27:01 CEST Petr Titěra wrote:
>>> Timing on USB need not to be so horrible. Below is stats from my server
>>> with GPS connected using FT232H chip (supporting high speed transfers on
>>> USB). Yes, the jitter is far greater than on other computer where PPS is
>>> connected directly but it is a lot less than that 500microseconds you
>>> get with common USB convertors.
>>>
>>>        remote          refid     st t when poll reach delay offset jitter
>>> =======================================================================
>>> o127.127.22.0   .PPS.           0 u    7   16  377  0.000 -0.019  0.033
>>> *192.168.3.240  .GPSD.          1 u   24   64  377  0.377  0.187  0.026
>>> +192.168.3.246  .PPS.           1 u   28   64  377  0.643  0.181  0.028
>>
>> The reason you're seeing this with the newer FTDI chips that support
>> USB2.0
>> highspeed rates is that the frame rate got increased 8x for highspeed USB,
>> so
>> the expected frame jitter is now 125µs when and if the interface as well
>> as
>> the full protocol stack support and enable it.  But you seem to have
>> missed
>> the point that Hal was trying to make: The jitter you are going to see has
>> deterministic components and some of these can create bias when you try to
>> filter with the usual assumption of a stationary zero-mean random
>> sampling.
>> In other words, you don't necessarily converge to the true time and where
>> your
>> filter tries to converge varies over time.
>>
>>
>> Regards,
>> Achim.
>> --
>> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>>
>> DIY Stuff:
>> http://Synth.Stromeko.net/DIY.html
>>
>>
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>