On Wed, Mar 17, 2021 at 04:49:01PM +0100, Frantisek Rysanek wrote: > 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.
Right, all those components are expected to support PTM. It's implemented in the hardware. My understanding is that (at least some) existing CPUs already support it. I have no idea about switches. I guess even if they didn't support it, it could still perform better than what we currently have. As a workaround, at least for testing, the NIC can be inserted in the 16x slot which is connected directly to the CPU. In servers with fast NICs and CPUs with large number of PCIe lanes that could be the usual case. > 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 :-) The switches are supposed to work like NTP server and client at the same time (boundary clock in the PTP terminology), so all PCIe links have hardware timestamping on both ends. BTW, at least in theory, a network using boundary clocks should perform better than a similar network using transparent clocks, assuming the servos are well configured and the sync interval is short enough to minimize the time errors in the chain. Divide and conquer :). I think transparent clocks are meant to be the simpler and cheaper variant. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
