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

[Trent Piepho]

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