[time-nuts] Re: Network interface cards that support timestamping
Matt Corallo
timenuts-list at mattcorallo.com
Wed Feb 1 02:43:18 UTC 2023
On 1/30/23 10:15â¯AM, John Miller via time-nuts wrote:
> Hey All,
> I'm curious as to what the collective experience is amongst this group when it comes to feeding a timestamp signal into a NIC, either for PTP purposes or for as a normal PPS refclock. The Intel i210 PCIe network card has a few software defined pins that can be used for this purpose, and the chrony documentation has some information about it:
>
> https://chrony.tuxfamily.org/examples.html#_server_using_reference_clock_on_nic
>
> I imagine most of us here use traditional RS232 serial ports to get this signal into an x86 computer, usually using the DCD pin. I've found some implementations of RS232 on PCs don't implement all of the additional signaling pins, so sometimes DCD is flat out missing. In other cases - especially with smaller embedded-type boards only UARTs with Rx/Tx are available to the user. (I'm fiddling with using GPIO pins on a few such systems, but it's quite a struggle.) So, there is a need for getting PPS signals into systems.
>
> There are also highly specialized network interface cards, such as this one: https://www.ebay.com/itm/404117321209
>
> ... which does explicitly support PTP timestamping, but it's not clear to me if it could pull in a "standard" PPS signal to be made available to chrony or NTPsec. I haven't found much documentation on the NT20E2 yet, unfortunately, and it may simply not exist for hobbyists.
>
> Does anyone here know if any other network cards that support software defined pins, like the i210 does, or any other methods for getting a PPS signal to be fed into a PC, and of course interpreted correctly?
A friend pointed me at this thread, I just finished hooking up 2 i211s to two separate u-blox
receivers to rather good effect. Specifically, I have an APU2 and hooked up the receivers as
described at [1]. Note that it doesn't actually matter which of the four pins you hook it up to, any
can be configured to interrupt (though you need the patch at [2] for recent kernels).
The serials on the same board come in via a Nuvoton NCT5104D LPC <-> 4xCOM port chip (which I assume
is probably not uncommon for many machines these days). The same GPS receivers were hooked up via
that via DCD pins, which were properly interrupt'ing but had jitter on the order of 10-25us. Chrony
would often report a bit less std dev across a few samples, but the two receivers would wander
around the current time and often by off in different directions. With the receivers moved over to
the i211s chrony now reports std dev between 5 and 100ns, though given they're always off in the
same direction on a similar order of magnitude I think that's the system clock being off more than
interrupt latency.
You can find graphs at [3], though excuse the lack of history, I re-soldered a few hours ago and am
still testing it so dropping data since last boot.
While the i211 theoretically supports both interrupting for the Software-Defined-Pins and packet
timestamping for PTP (and NTP) purposes, it is entirely unclear to me if chrony uses the NIC clock
to respond to NTP. chrony happily accepts the hwtimestamping option for the NICs and correctly reads
from the NIC's PPS pin as a PHC clock, but there doesn't seem to be any config to hook the two up
somehow.
The `testptp` utility in the kernel source tree tells me that it takes 8000-9000ns to read the NIC's
clock, and chrony pretty reliably reports the +/- on a sample from the NIC PPS as +/- 1100-1200ns so
it lines up that there's around 1000ns of jitter on the interrupt.
Matt
[1] https://blog.dan.drown.org/apu2-ntp-server-2/
[2] https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20230130/031970.html
[3] https://noc.as397444.net/ntpgraphs.day/
More information about the Time-nuts_lists.febo.com
mailing list