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

On Mon, Jan 30, 2023 at 3:19 PM John Miller via time-nuts <
time-nuts@lists.febo.com> wrote:

John Miller via time-nuts writes:

We used Intel '599 chip based cards in the ELT adaptive optics prototype
compute cluster, and it has both hardware timestamping of packets and
a couple of external signals.

Unfortunately the boards we used had not wired those external signals
to anything reachable by me.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Hey John,

as far as I'm aware, there are a few Ethernet ICs which do have hardware
pins for PTP purposes. The Broadcom BCM54210PE comes to mind as used on
the Raspberry Pi CM4 (not the regular Raspberry Pi 4, the Compute
module, they use different Ethernet PHYs). I believe the Intel i225 also
has dedicated Pins for PTP, but can't find the datasheet I once obtained
to make sure. IF these pins however are accessible on the typical NIC
(as in plugin card, not just the silicon chip itself) depends very much
on who did the design. The abovementioned Raspberry pi CM4 has two
dedicated pins available, directly wired to the appropriate pins of the
PHY chip, but driver support is not entirely there yet last I heard.

For generic off-the-shelf i210/i225 cards, I have yet to come across one
which has documented hardware pins for PTP purposes, but the sample size
is rather small (four or five different cards in total...).

Judging from a "grep -r TX_HARDWARE ./*" in Linux kernel tree there seem
to be a few drivers which support hardware timestamping of some sort, so
my first guess would be that those coming up there could potentially
have pins which can be used for timestamping purposes. There might be
more as not everyone is publicly documenting their chips in a way that's
actually useful, but at least it's a start.

HTH,
Florian

On 30.01.23 19:15, John Miller via time-nuts wrote:

Hi

There are PTP specific cards that bring out various PPS pins. They are pretty
far from what I’d call a “normal” interface card. They show up on eBay from time
to time. It’s not clear what sort of a tangle one gets in finding drivers for those cards.

Bob

Poul-Henning Kamp via time-nuts writes:

I should probably mention a couple of things we learned the hard
way, even though I dont know if this applies to just the '599 chip:

1. The timestamping facility is very obviously a "bolt-on" and as such
   the documentation was severely lacking.

2. The timestamping counter runs at the RX-clock rate.

That means:

a) You want something 10GE plugged into the port for max resolution.

b) If you unplug it or it resets or reboots, your timescale jumps.

c) You timescale is the Xtal at the /far/ end of the cable.

This can probably all be mitigated with a loop-back, but then you cannot
timestamp packets.

3. To timestamp packets, they have to look "sufficiently" like certain PTP
   packets.  This was not documented then, could be now.

Poul-Henning

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

On 1/30/23 12:28 PM, S McGrath via time-nuts wrote:

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"

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@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@lists.febo.com> wrote:

All your points are good ones,  My point was this is the common lowest
cost approach,  better approaches exist and they range from tens of dollars
to thousands depending on the accuracy needed.

Driving the CD line with a ‘real’ serial port is good enough for ‘standard’
NTP timing applications,  its not good enough for a ‘time nuts’
implementation

Scott

On Mon, Jan 30, 2023 at 8:15 PM Trent Piepho tpiepho@gmail.com wrote: