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

[Bob Camp]

Hi

If accuracy off of a GPS module is the goal then one needs to start at the module.

All the low cost modules put out their PPS based on an internal free running clock.
It is off from “correct” by some number of NS each time. For historical reasons it
gets called sawtooth error ( = the error chart often looks like a sawtooth). 

There are a number of modules that will tell you what the error is in one string 
or another. It might have a range of +/- 20 ns. It could be down around +/-2 depending
on the make and model of the unit. 

The error is calculated once a second and is provided relative to a pps output.
If you adjust the output rate, working out just what point the “new” error comes 
in can be problematic. Most folks just go with 1 pps and move on. 

With some care, one can indeed move these edges into a fairly typical PC. Drivers
for this or that are a mixed bag. I’d stick with NTPSec if you want drivers that work. 

What typically happens is the pulses are used to come up with an estimate of the
computer’s internal clock. That clock is used to stamp this or that. It’s far more 
efficient to do it this way. The data from the external clock is used often enough
to keep the estimate reasonably accurate. Put another way, your timestamp is
always removed from that clock edge by a bit. Faster external clock rates 
don’t really do much with this approach. 

PTP does this all a bit differently. The above applies to the sorts of programs you 
are currently looking at. 

Bob

> On Feb 1, 2023, at 1:38 PM, John Miller via time-nuts <time-nuts at lists.febo.com> 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.
> 
> 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.
> 
> 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. 16Hz PPS with a rate of 16 - why not use 1Hz with a default rate of 1? The Dan Drown blog post makes a little bit more sense, but I think something is missing from the 'relevant chrony.conf' example - notably, it includes a single refclock line with the "pps"  option, which according to the chrony.conf docs[4]: "Another time source is needed to complete samples from the refclock." and that example isn't included. Furthermore, his "width" parameter is set to 0.7 milliseconds, which seems tremendously short to me. If the PPS pulses are 100ms (which I understand to be fairly standard) why wouldn't the width be configured as such? I may be misunderstanding this parameter.
> 
> Either way, am not able to get chrony to lock up to a PHC refclock.[5] This is what my chrony.conf looks like: https://paste.millerjs.org/ajoxigiquc.txt
> 
> 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). I may have to install a newer OS in order to try this out.
> 
> 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. I would greatly appreciate any help or feedback!
> 
> Thanks,
> John
> KC1QLN
> 
> 
> [1] https://portwell.com/products/detail.php?CUSTCHAR1=NANO-6050
> [2] https://chrony.tuxfamily.org/examples.html#_server_using_reference_clock_on_nic
> [3] https://blog.dan.drown.org/apu2-ntp-server-2/
> [4] https://chrony.tuxfamily.org/doc/4.3/chrony.conf.html
> [5] https://paste.millerjs.org/edebutayoz.txt
> 
> 
>> On Jan 31, 2023, at 9:43 PM, Matt Corallo <timenuts-list at mattcorallo.com> wrote:
>> 
>> 
>> 
>> 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/
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com