[time-nuts] Re: Network interface cards that support timestamping

[Keenan Tims]

>
> Despite hardware timestampers being common on microcontrollers, SoCs that
> can run Linux never seem to have them.


BeagleBone Black does run Linux and has timer capture hardware, though it's
a bit 'slow' it's still available. Dan Drown (originally) also wrote a PPS
module targeting it, though it's been unmaintained (
https://github.com/thinkfat/pps-gmtimer was the closest fork to working for
me, but it still required some fiddling around with DeviceTree etc. ). It
tries to pull the somewhat clever trick of switching the system's clock
source to the capture timer, and then copying the capture value directly
into the PPS report, which in theory should be about as good a capture as
you could get - no polling the kernel timestamp or the input pin. I've been
running this for a while with a GPSDO as PPS source, and while the average
offset reported by chrony is single-digit ns, there are occasional spikes
to 100s of ns.

The NIC also does have hardware timestamping functionality for PTP.

On Mon, 30 Jan 2023 at 18:26, Trent Piepho via time-nuts <
time-nuts at lists.febo.com> wrote:

> Even if you have a real serial port, still common in embedded SoCs that run
> Linux if not on PCs, and even if it still has a CD line to generate an
> interrupt, there are still issues.
>
> Modern CPUs are complex, and while the serial port might even be on the
> same chip as the CPU, they are connected through an internal network like
> an AXI bus that adds latency and jitter.  A PCI-E network card generating
> an interrupt still needs to send a MSI packet over the PCI-E network bus to
> the PCI-E controller, which then needs to send it on the CPU through some
> other kind of internal network.
>
> But that's not even the bad part.  Once the CPU gets an interrupt, there is
> still a lot of stuff that needs to happen in software before a timestamp is
> generated.  The CPU must context switch, new cachline loads from RAM for
> data and code, the base kernel interrupt dispatching, etc.
>
> With tests I did a while back with GPS PPS on an embedded Linux board, this
> was the largest source of error.
>
> Despite hardware timestampers being common on microcontrollers, SoCs that
> can run Linux never seem to have them.
>
> I wonder if one could make a useful USB timestamper with a common USB
> microcontroller board.  These have hardware counters that can timestamp a
> PPS.  It would be easy to send these timestamps over USB.  Not sending
> events about a PPS, but sending the actual timestamp of the PPS.  USB has,
> comparatively, terrible timing jitter, so timestamping the arrival of a USB
> packet is of course no good.
>
> With a bit of thought, we might think this is a step back.  We have GPS
> with an accurate clock that sends NMEA timestamps to us over an inaccurate
> UART.  Now we have a microcontroller with a semi-accurate clock sending
> timestamps to us over an even more inaccurate USB interface.  Same problem,
> but worse.
>
> But there is a difference!  Typically the clock in an USB connected
> microcontroller can use USB clock recovery.  It's disciplined to the 1kHz
> USB SOF signal from the host computer.  This lets them meet the USB timing
> spec with a cheap internal resonator.
>
> So the clock in the microcontroller that gives us timestamps is in fact
> tracking our clock.  Does that make a difference?  We can infer that the
> error in the timestamps we get reflects a matching error in the host clock
> we are trying to discipline with the PPS.
>
> On Mon, Jan 30, 2023 at 4:01 PM S McGrath via time-nuts <
> time-nuts at lists.febo.com> wrote:
>
> > Driving Pin1 only works with a ‘real’ serial port on a dedicated IRQ.  a
> > USB interface will add unpredictable latency
> >
> > On Mon, Jan 30, 2023 at 6:16 PM Lux, Jim via time-nuts <
> > time-nuts at lists.febo.com> wrote:
> >
> > > On 1/30/23 12:28 PM, S McGrath via time-nuts wrote:
> > > > Most common way of getting 1PPS into a computer without a dedicated
> > 1PPS
> > > > interface is to drive a RS-232 port’s Carrier Detect pin (pin 1 on
> > DB-9)
> > > > with the 1PPS signal
> > >
> > >
> > >
> > > back in the day when that tied directly to an interrupt with consistent
> > > latency, that works pretty well.
> > >
> > >
> > > These days, though, there's often USB hosts in the way, or some other
> > > intermediate interfaces that increases the uncertainty in timing of
> > > "when software does something" in response to "external event"
> > >
> > >
> > > _______________________________________________
> > > time-nuts mailing list -- time-nuts at lists.febo.com
> > > To unsubscribe send an email to time-nuts-leave at lists.febo.com
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe send an email to time-nuts-leave at lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com