On Tue, Mar 16, 2021 at 11:38:17PM +0100, Frantisek Rysanek wrote: > 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.
I have not had a chance to play with one yet. If the frequency of the clock followed the increase in the symbol rate of 2.5GBASE-T, it would have a ~4.8ns resolution. > 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... Right, but in most cases I see people are interested in the accuracy and stability of the system clock. There don't seem to be many applications using hardware timestamps of the PHC. In some cases a sub-microsecond accuracy is required. The CPU<->NIC connection is the most problematic link in the chain. You can buy switches with good PTP support and compensate for asymmetric errors in hardware timestamping to get the PHC accurate to few nanoseconds, but due to the huge PCIe latency with an unknown asymmetry it's difficult to tell how accurate the system clock actually is. With the same NIC but different CPUs/boards you can get very different results. > 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... Normally there should be no interrupts involved. The time critical part is just a single read of a 32-bit PCI register. With the I210 that takes about 1700 ns and the asymmetry in my measurements was up to about 100 ns. The shortest delay I saw with faster NICs was about 450 ns, asymmetry unknown. > 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... I'd say that's normal for an uncompensated XO in a computer case where the temperature can change rapidly. The PTP and phc2sys update rate need to be higher to get better stability. Some PTP profiles use 128 messages/second. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
