Miroslav Lichvar <mlichvar@xxxxxxxxxx> writes: > On Mon, Nov 09, 2020 at 10:10:19PM -0800, Vinicius Costa Gomes wrote: >> i225 has support for PCIe PTM, which allows us to implement support >> for the PTP_SYS_OFFSET_PRECISE ioctl(), implemented in the driver via >> the getcrosststamp() function. > > Would it be possible to provide the PTM measurements with the > PTP_SYS_OFFSET_EXTENDED ioctl instead of PTP_SYS_OFFSET_PRECISE? Sorry for the long delay. About PTP_SYS_OFFSET_EXTENDED, I did play with it a bit, but I didn't like it too much: because I don't have access to all the timestamps from the same "cycle", I ended up having to run two cycles to retrieve all the information. So, the new version will expose the timestamps via PTP_SYS_OFFSET_PRECISE, later we can think of PTP_SYS_OFFSET_EXTENDED. > > As I understand it, PTM is not cross timestamping. It's basically > NTP over PCIe, which provides four timestamps with each "dialog". From > the other constants added to the header file it looks like they could > all be obtained and then they could be converted to the triplets > returned by the EXTENDED ioctl. > > The main advantage would be that it would provide applications with > the round trip time, which is important to estimate the maximum error > in the measurement. As your example phc2sys output shows, with the > PRECISE ioctl the delay is 0, which is misleading here. > > I suspect the estimate would be valid only when the NIC is connected > directly to the PTM root (PCI root complex). Is it possible to get the > timestamps or delay from PTM-capable switches on the path between CPU > and NIC? Also, how frequent can be the PTM dialogs? Could they be > performed synchronously in the ioctl? > > -- > Miroslav Lichvar > Cheers, -- Vinicius
