On 17 Mar 2021 at 13:04, Miroslav Lichvar wrote: > > 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. > Thanks for all the data and clarifications :-) That's interesting...
I'm not sure the PTM (that you have mentioned previously) will help with asymmetry. You characterize the mechanism as "NTP-like". I'm not a member of the the PCI-SIG, and the only clear text about the PTM that can be found in Google is some change notice by the PCI-SIG from back in 2013, referring to PTM v1.0a. https://fdocuments.in/document/precision-time-measurement-ptm.html That paper clearly says (I'm quoting): "Therefore ((t4 - t1) - (t3 - t2)) effectively gives the round trip message transit time between the two components, and that quantity divided by 2 approximates the Link delay - the time difference between t1 and t2. It is assumed that the Link transit times from PTM Requester to PTM Responder and back again are symmetric, which is typically a good assumption." The current revision listed at the PCI-SIG website is v4.0. Which makes me wonder if this assumption is still considered valid :-) I understand that apart from the NIC (peripheral device / endpoint function in general), PTM must also be supported by the root complex and any PCI-e switches along the path... so a PTM-capable NIC alone will not even suffice for this simple NTP-style mechanism to function, if the host chipset is unaware of PTM. To account for asymmetry, the mechanism would have to resemble PTP = there would have to be a correction field in the PCI-e messages and the PCI-e switches would have to work like PTP TC switches :-) Frank _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
