On 16 Mar 2021 at 16:59, Miroslav Lichvar wrote: > > I'm sorry for misleading you. I meant the ice driver (speeds up to > 100Gb). I didn't see an out-of-tree version of the igc driver. > Okay, thanks for that update... Still I'm curious what news the i225 may bring in terms of e.g. GPIO timestamping resolution. Does it get better than those 8 ns I got used to with the i210 etc. > The I225 might be an interesting NIC for experiments for a different > reason. It seems it supports the PCIe Precision Time Measurement (PTM) > feature. It is a hardware implementation of an NTP-like protocol over > PCIe, which should allow a highly accurate synchronization of the > system clock, avoiding the asymmetry on PCIe. It is not supported in > the igc driver yet, but there were some patches submitted for it. > > I measured the PCIe asymmetry with the I210 on few different > boards+CPUs and it changed a lot (between about -100ns and 100ns), so > I think PTM could make a significant improvement. > Erez Geva was quicker to respond, and I agree with him: the packet timestamping is done by the NIC HW, so unless you have an application where you need accurate timing all the way to the software-based system clock, the determinism of PCIe bus latencies should not matter much... I understand that you being a RedHat insider, a principal maintainer of Chrony and a maintainer of the RedHat linuxptp RPM, your application is precisely getting the system clock as solid as theoretically possible :-)
So far, I've only ever considered PTP and its breathtaking accuracy to be any use in dedicated hardware: switches with HW PTP support including a central stable oscillator, or pure slaves that syntonize a *stable* local hardware clock to the NIC's PHC and use that precise HW clock for some further, thoroughly HW-implemented purpose... As for getting the Linux system timebase precise, I guess the random component to ISR latency has several contributing factors, the PCI-e bus latency being only one of them... also, the crystal oscillator serving as a "stable" local reference for the PC chipset clock synth is in reality not very stable. I don't have a precise figure, but if I take the typical i210 NIC 25 MHz xtals for a benchmark, I've seen instability translating into ppb deviations of about +/- 10 to +/- 20 ppb, within the 1s period of ptp4l sampling - and a PC chipset is likely to have an even worse oscillator... BTW, speaking of NICs with PTP and SyncE support, the only one I know is a custom FPGA-based design by Oregano: https://www.oreganosystems.at/products/syn1588/hardware/syn1588r-pcie- nic Obviously that NIC is irrelevant to Linuxptp, as the FPGA-based Oregano stack implements the whole protocol... and that NIC is obviously not cheap :-) Thanks for spending your time, responding to my novice questions... Frank _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
