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

James Clark jjc at jclark.com
Fri Feb 3 02:01:30 UTC 2023


On Fri, Feb 3, 2023 at 1:57 AM Jürgen Appel via time-nuts
<time-nuts at lists.febo.com> wrote:

Hi Jürgen

I have been experimenting with PTP and the i210 quite a bit, so it's
interesting to compare notes.

> 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.

This sounds really interesting and looks like it would be a nice
option for a small-form factor NTP/PTP server. I would love to be able
to buy one of these.  Are there companies that will take a gerber file
and a BOM and a modest amount of money, and send me a completed PCB?
(I am a software person, and know very little about the hardware side
of things.)

> 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,

I also wanted this.

> 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

I have found it quite tricky to get this approach to startup robustly.
There's a dependency circularity:

- ts2phc -s generic depends on chrony to have set the system clock
- chrony with the PHC refclock depends on ts2phc to have set the PHC

I have tried a couple of approaches to deal with this.

phc2sys has a -E ntpshm option. With this option, instead of phc2sys
modifying the system clock directly, it feeds samples into the SHM
used by the chrony SHM refclock. This provides a bit more flexibility
over using the chrony PHC refclock directly: if phc2sys is not running
then chrony will ignore the SHM refclock.  We can then startup in
stages:

1. Run chrony with the SHM refclock; do not yet start phc2sys -E
ntpshm. Chrony will then set the system time using other NTP servers
or using the NMEA messages from a GPS receiver via gpsd if there is no
network connectivity (which would mean the time is very rough).
2. Run ts2phc -s generic. This will set the PHC very accurately, using
the less accurate system time from chrony.
3. Start phc2sys -E ntpshm. Now that the PHC is correct, we can let
chrony use the samples from the PHC.

Another approach is to use a pps option (not the extpps option) with
the PHC refclock. This will make chrony ignore the time-of-day
information in the PHC, and just use the PPS information.

> 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.

As far as I remember, ts2phc can handle the PHC being wrong. If you
want to do a one-shot setting of the PHC from the system clock, you
can do

phc_ctl eth0 "set;" adj 37

This works immediately, although it is not as accurate as phc2sys.

> 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.
> From the source code it seems that ts2phc only considers edges falling within ±pulsewidth/2
> around the expected time valid and discards the rest. So for a 100ms-1PPS pulse you should
>  get the clock precise to 50ms before you start. As my pps is originally only µs long, I needed extra
> hardware to stretch it.

I am writing code (which will be released as open source) that amongst
other things tries to deal better with receiving timestamp events for
both pulse edges. Does the i210/i211 generate two events for the
original µs pulse? In your use case, do you have a GPS receiver
providing time-of-day information or do you just have the PPS?

James




More information about the Time-nuts_lists.febo.com mailing list