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

[Jürgen Appel]

Dear John,

On Wednesday, 1 February 2023 19:38:18 CET John Miller via time-nuts wrote:

> Hi Matt,
> This is excellent information, thank you - after reading through all the
> responses in the thread (wow, this is a wild topic!) and trawling around
> online a bit, I think that using the SDP pins on the i210 to feed a PPS
> signal into an x86 PC is what I want to do right now. 
 
> I have read Dan Drown's blog post on using the APU2 to achieve this, and
> while it's more or less exactly what I want to replicate, for now, there
> are a few gaps I need to fill in - and you may be able to help me do so. I
> don't have a PC Engines APU2 board yet, but I suspect I'll order one once I
> have the software side of things ironed out, because I really like their
> form factor.

I'm currently testing an APU6b4 unit and made a small adaptor PCB that gets 
clicked into the Mini-PCIE slot and touches to the main pcb via some pogo-pins:
 No soldering on the main apu board. If you are interested, I can send you 
the gerber-files and BOM. It should also fit the apu3-series (and possibly
yours, too) and allows convenient SMA-access through the front panel to
the SDP pins of two of the NICs.
   
> What I'm using right now is a Portwell NANO-6050[1], and it has i210 and
> i218 NICs. The SDP pins on the i210 aren't broken out into nice pads like
> the APU2 has, but with some magnet wire and a steady hand I was able to
> connect directly to one of the pins. Where I am struggling right now is
> ironing out the software configuration side of things. I'm not interested
> at all in PTP yet, right now the focus is purely on feeding the PPS into
> chrony via the SDP pins. 

> The GNSS I'm using is a Sparkfun uBlox NEO-M9N
> GNSS receiver in its default configuration, connected to the computer over
> USB. PPS pin connected to the i210's SDP0. PPS pulse is 3v3 for 100ms.
That should work fine.

 > I have tried using refclock strings from chrony's examples page[2] as a
> jumping-off point, but it doesn't make much sense to me.

To me it seems that chrony is just using the timestamps on the PHC of that
network interface and not actually locking the PHC to the PPS input. As I
wanted to verify that the lock is working, and maybe later use the PHC also
for PTP, I also wanted the PHC to follow the external time, and running 
both chrony and phc2sys to make the phc follow system time ended in chaos.

Therefore it seems that a two-step approach works better: First I make sure
 that using ts2phc the PHC is locked to the 100ms-1PPS input on SDP0:

# ----------[contents of /etc/linuxptp/ts2phc.conf]-------------------------
# run with ts2phc -c eth3 -s generic -l 7 -f /etc/linuxptp/ts2phc.conf -m -q
[global]
use_syslog              0
verbose                 1
logging_level           6
ts2phc.pulsewidth       100000000
max_frequency           1000000
step_threshold          0.05
[eth3]
ts2phc.channel          0
ts2phc.extts_polarity   both
ts2phc.pin_index        0
ts2phc.extts_correction -32

For this to start up properly, you need to make sure the clocks are roughly correct,
 i.e. you need to set your system time (e.g. with ntpdate, ntp, chrony) and then
 sync your PHC to system time by letting 

# Locking the PHC of eth3 (ptp3) to CLOCK_REALTIME
phc2sys -c eth3 -s CLOCK_REALTIME -O +37 -m -q  

run for a few seconds. 

If you also output the PHC timer on SDP1 by
testptp -d /dev/ptp3 -L1,2 -p 1000000000
you can see a falling edge right when SDP0 has a rising edge input 
 with only a few nanoseconds jitter.
(if anyone know how to invert the 1PPS output on i211 interfaces, let me know...)
Sidenote: The interfaces /sys/class/ptp/* seem to be broken with my kernel. 
I can configure PPS output there, but every time I do that I get random 
frequencies for ~10 seconds before the output actually starts...


When the PCH is locked to the 1PPS, I can have chrony use the PHC as clock input
with this chrony.conf line:

refclock PHC /dev/ptp3 tai refid PTP3 dpoll -4 poll -2

I do _not_ use the "extpps" option here, as ts2phc is already reading and consuming
 the time stamps. If there are two time-stamp readers, my chrony just hangs.

> I have not been able to use the testptp tool on this system yet - building
> it on another machine and running the copied-over executable fails, citing
> too old a version of glibc, and when I try and build it locally it fails
> for reasons that are unknown to me (I am very much not a C developer). 

Maybe try making a static library: gcc -static testptp.c -o testptp
so that it has it's current glibc version linked in.

> I am going to continue to fiddle with this - I think getting testptp working
> such that I can verify that I'm actually getting a pulse on SDP0 is the
> most important thing to confirm right now.

The intel cards always give timestamp events on both pulse edges. The pulse-width and 
the roughly correct clock are necessary such that ts2phc can ignore the wrong pulse edge.