[time-nuts] Raspberry Pi NTP server

[Manfred Bartz]

USB:
The raw BPS are between the device and the host controller - all of
this is implemented in hardware.

USB Low-Speed, Full-Speed and Hi-Speed use a single twisted pair in
half-duplex operation. The half-duplex link multiplexes all
implemented EPs (End Points).  EP0 is for link management and HID
(Human Interface Device).  A serial port emulator uses EP1 and EP2 to
implement the serial port RX and TX functions.  Different devices can
implement additional EPs like an interrupt EP which is still polled
because the USB device cannot initiate a packet transfer.  Streaming
devices such as cameras and audio use (lossy) isochronous comms.

USB SuperSpeed is basically the USB consortium's implementation of
Firewire and uses 2 additional twisted pairs in full-duplex operation.
SuperSpeed USB-3 cables are required or your device will fall back to
a lower speed.

The version of the USB standard does not equate to the actual speed in
operation.  E.g. a HID (Human Interface Device) like a mouse typically
runs at 1.5MBps and can claim USB 3.1 standard compliance.  Also, if
link negotiation at a high speed fails then many devices are capable
of a fallback to a lower speed.  There are heaps of USB 2.0 devices
which only support 12MBps (I wrote the firmware for one).
Actual speeds can be read out from the USB root hubs and downstream hubs.

The best USB net throughput you can expect for Full-Speed and Hi-Speed
is about 80% of the HW bit rate.

Linux interrupts:
Hardware interrupts can really only be handled inside a kernel driver
because the switch to user-space has too many overheads and is highly
subject to scheduling constraints dictated by the system load factor.
I have not configured any recent Linux kernel, but enabling the RT
(Real Time) flags speeds up the interrupt latency but may actually
delay the full interrupt handling because it imposes scheduling
overheads - YMMV.

PPS signal:
If available the NTP kernel driver should be configured to use it as a
hardware interrupt - this will give you the lowest possible latency
and jitter.  And in this case there is no need to worry about polling
a serial port.



On Thu, Jul 9, 2020 at 4:44 PM Steven Sommars <stevesommarsntp at gmail.com> wrote:
>
>  I don't want to hijack Andrew's thread.  Just wanted to add to Achim's
> comments about jitter and offset.
>
> USB2 devices should accept polls every 125 microseconds.  [My USB knowledge
> is limited.]
>
> I have two devices.  One is the Navisys GR701 which I suspect you're
> familiar with; it is an integrated GPS + Serial->USB.  The other is a
> Garmin LVC18x connected to a Sabrent USB 2 to serial cable.
> Both devices report having a PL2303.  Both poll at 1 msec.  The GR701 has a
> thin cable.  The Sabrent USB->Serial has a thick cable.
>
>
>
>
>
>
>
> On Wed, Jul 8, 2020 at 6:53 PM Hal Murray <hmurray at megapathdsl.net> wrote:
>
> >
> > stevesommarsntp at gmail.com said:
> > > My RPi4 (Raspbian Buster) has a GPS+PPS/USB.  Serial->USB uses Prolific
> > > PL2303, which supports USB 2.0
> >
> > > which means 1 msec polling of the PPS signal.   I've been unable to poll
> > more
> > > frequently
> >
> > As far as I know, the PL2303, 067b:2303, is an old/slow chip.  (I forget
> > the
> > right magic USB terms)  Why do you expect it to go faster than 1 ms?
> >
> > It and the FTDI chip(s) are popular and widely known to be well supported
> > on
> > Linux.  I'll be very surprised if it goes faster.
> >
> > What sort of device are you using?  One way to tell if it is likely to go
> > faster than 1 ms is the thickness of the wire.  Faster speeds need more
> > shielding for EMI reduction (or something like that) which turns into
> > fatter
> > cables.  It's pretty easy to tell if you have samples of both in front of
> > you.
> >  I think you can only use the thinner cable if t runs at 1 ms and you hard
> > wire the chip to the end of the cable as is typical of a GPS mouse.
> >
> >
> >
> > --
> > These are my opinions.  I hate spam.
> >
> >
> >
> >
> > _______________________________________________
> > 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.



-- 
--
Manfred
VK3AES