On Wed, Oct 24, 2018 at 02:14:44PM +0530, Dolly Gyanchandani wrote: > Hello all, > > We are analyzing PTP for a control system software and measuring the > accuracy of PTP clock synchronization with a small setup of 2 personal > computers making one of them as a master and the other as slave. Our > current setup is very crude and we do not have a grandmaster yet. The > problem is that our accuracy numbers (as we currently measure them, which > might be incorrect) do not match with the standard numbers PTP protocol > claims and varies by a degree of magnitude 10.
Accuracy of which clock would you like to measure? The system clock or the PTP clock on the NIC? > We are using *ptp4l *and* ph2sys v1.8 *tools. > Our current measure of accuracy is based on* master-slave offsets reported > by the ptp4l process.* (ptp4l also reports path delays, we don't use those > numbers currently. Is there any significance of these numbers in accuracy > measurement?) Not really. A consistenly small offset reported by ptp4l (or any other PTP/NTP client) indicates a stable clock and stable synchronization, but doesn't say much about accuracy. Accuracy is generally unknown as there are asymmetries in the network and timestamping. A separate and more accurate time source is necessary. For measuring accuracy of SW timestamping you can use HW timestamping. If you had a NIC with PPS input or output (e.g. I210), you could compare it with PPS from the grandmaster. You could then use it as a reference to measure accuracy of another PTP clock in the machine. The trouble here is that the offset between two PTP clocks cannot be measured very accurately as there are unknown asymmetries in the delay on the PCIe bus. There are also asymmetries in the drivers (which might be fixed in near future). Measuring accuracy of the system clock has the same problem. -- Miroslav Lichvar _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
