The phc_ctl utility has a 'cmp' command which can "compare PHC offset to CLOCK_REALTIME" . Is that the building block you're looking for? (alternatively look into the PTP_SYS_OFFSET ioctl to get the raw numbers directly)
By example, interface "ma1" is a ptp slave, and it's PHC is apparently ~7ns from the master. This tends to stay within some bounds over time. bash-4.4# pmc -u -b 0 'GET CURRENT_DATA_SET' sending: GET CURRENT_DATA_SET 7c534a.fffe.255601-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET stepsRemoved 3 offsetFromMaster 7.0 meanPathDelay 968.0 And less the 37s TAI/UTC offset, the local system clock is around 168µS from the PHC (I've not started phc2sys, so as to match your restrictions) This may drift and presumably would exhibit a knee each time ntpd yanks the system clock... bash-4.4# phc_ctl ma1 get cmp phc_ctl[5982309.303]: clock time is 1589975041.663448746 or Wed May 20 11:44:01 2020 phc_ctl[5982309.303]: offset from CLOCK_REALTIME is -37000167922ns As Richard suggested tracking this over time should let you interpolate a system->PHC mapping, or by chaining with pmc's results trace back to (within error bounds of all estimates) the master's PTP time. All whilst also being within 147ms of the some NTP server: bash-4.4# ntpstat synchronised to NTP server (10.70.1.14) at stratum 3 time correct to within 147 ms polling server every 1024 s Cheers, David. On Wed, 20 May 2020, 7:01 pm Werner Macho, <werner.ma...@gmail.com> wrote: > Hi! > (sorry for double post - forgot to include the list) > > Thanks for the answer, now I am completely confused ;) > > So there is no easy way to just get the difference from a PHC to the (PC) > system clock (unless the PHC is synced to the PC clock - which makes the > necessity of the difference obsolete). > > The problem here is that the ntp time server that must be used on the PC > is very unreliable and the time is drifting a lot. So the idea was to mark > each operation with a second more exact and reliable timestamp (PTP) to be > able to retrace some important operations. > > So conclusion for me is - there is nothing in the output of existing > programs (ptp4l, phc2sys, pmc) I can use to either get a timestamp or at > least an offset (i first thought I could use the master_offset from pmc) > but rather write a new programm based on phc2sys and use clock_gettime to > somehow get a PHC and a PC time and compare these two. > > Is this correct? > > thanks and best regards > Werner > > On Tue, May 19, 2020 at 5:56 PM Richard Cochran <richardcoch...@gmail.com> > wrote: > >> > On Tue, May 19, 2020 at 4:36 PM Chris Caudle <ch...@chriscaudle.org> >> wrote: >> > >> > > As far as I am aware the PHC in the NIC is not used for anything other >> > > than network time synchronization using PTP, and the PHC has no >> relation >> > > to the system clock unless you also run phc2sys to transfer time from >> the >> > > PHC to the system (software) clock. >> >> +1 good point >> >> On Tue, May 19, 2020 at 04:59:51PM +0200, Werner Macho wrote: >> > The system (Server) MUST be synced with NTP with a given timeserver. >> > Directly attached to the Server is a PTP Device: >> > --- >> > ethtool -T ens2f1 >> > Time stamping parameters for ens2f1: >> > Capabilities: >> > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) >> > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) >> > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) >> > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) >> > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) >> > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) >> > PTP Hardware Clock: 1 >> > Hardware Transmit Timestamp Modes: >> > off (HWTSTAMP_TX_OFF) >> > on (HWTSTAMP_TX_ON) >> > Hardware Receive Filter Modes: >> > none (HWTSTAMP_FILTER_NONE) >> > ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT) >> > ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT) >> > ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT) >> > --- >> > So the hardware clock (which I meant) is the server HW clock, this must >> be >> > leaved untouched and continue to sync with the given time server. >> >> In this case, you don't need to use --free_running. Simply let ptp4l >> control the PHC and synchronize it to the PTP network time. >> >> All you need is a little program that periodically reads two time >> values, the PHC and the Linux system time, and computes the offset. >> >> (the phc2sys program shows how to do this) >> >> Then you interpolate the PHC time for a given Linux system time stamp. >> >> HTH, >> Richard >> >> >> _______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-users >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
