Re: [Linuxptp-users] Get PTP but no Sync
On Wed, May 20, 2020 at 03:40:16PM +0200, Werner Macho wrote: > If the output of this: > > ># phc_ctl ens2f1 get cmp > phc_ctl[2350429.937]: clock time is 1589981848.451319038 or Wed May 20 > 15:37:28 2020 > phc_ctl[2350429.937]: offset from CLOCK_REALTIME is -37001639797ns > > now means that the NTP-synced clock of the PC where all this is running > (CLOCK_REALTIME) is -37001639797ns offset of the PHC on NIC ens2f1 > than this is exactly what I needed. Yes, the -37 seconds part reflects the UTC - TAI offset. > If someone could please confirm this one last question. I think you have what you need with phc_ctl. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Get PTP but no Sync
Hi All, If the output of this: ># phc_ctl ens2f1 get cmp phc_ctl[2350429.937]: clock time is 1589981848.451319038 or Wed May 20 15:37:28 2020 phc_ctl[2350429.937]: offset from CLOCK_REALTIME is -37001639797ns now means that the NTP-synced clock of the PC where all this is running (CLOCK_REALTIME) is -37001639797ns offset of the PHC on NIC ens2f1 than this is exactly what I needed. I hope this is true. And I really would like to contribute, but I think I've to learn a lot more programming for that. But maybe thats a good start. Thanks a lot all for your help. If someone could please confirm this one last question. kind regards Werner On Wed, May 20, 2020 at 3:04 PM Richard Cochran wrote: > On Wed, May 20, 2020 at 10:01:48PM +1000, David Mirabito wrote: > > 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? > > Oh wow, I totally forgot about that! > > Yeah, that is just what Werner would need, if I'm not wrong. > > Thanks, > Richard > ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Get PTP but no Sync
On Wed, May 20, 2020 at 10:01:48PM +1000, David Mirabito wrote: > 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? Oh wow, I totally forgot about that! Yeah, that is just what Werner would need, if I'm not wrong. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Get PTP but no Sync
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 meanPathDelay968.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, 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 > wrote: > >> > On Tue, May 19, 2020 at 4:36 PM Chris Caudle >> 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
Re: [Linuxptp-users] Get PTP but no Sync
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 wrote: > > On Tue, May 19, 2020 at 4:36 PM Chris Caudle > 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
Re: [Linuxptp-users] Get PTP but no Sync
> On Tue, May 19, 2020 at 4:36 PM Chris Caudle 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
Re: [Linuxptp-users] Get PTP but no Sync
Hi Chris, Thanks a lot for your email. Very good point. So to complete the explanation. 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. What I need now is way to directly get the time from the PTP (hardware or NIC attached to it) or even better the Difference between the server clock and the PTP clock. Maybe this is already what it displayed with --- pmc -u -b 0 'GET TIME_STATUS_NP' sending: GET TIME_STATUS_NP 98f2b3.fffe.138691-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP master_offset 30302 ingress_time 1589900176102021422 cumulativeScaledRateOffset +0.0 scaledLastGmPhaseChange0 gmTimeBaseIndicator0 lastGmPhaseChange 0x'. gmPresent true gmIdentity 0080ea.fffe.bd9a70 --- and maybe what I look for is the "master_offset", but thats where I am unsure. the entry in /etc/ptp4l.conf is now "free_running1" and the ntpd of the server is syncing with the "must" timeserver. Is there a way to easily get the difference somewhere (and maybe as a bonus the obviously more correct ptp time). Sorry for my dumb questions but I am not a ptp expert - I only need this time(difference). And yes - I also don't understand why they don't sync to PTP, especially when there is (I assume expensive) hardware attached. Thanks a lot for your help regards Werner On Tue, May 19, 2020 at 4:36 PM Chris Caudle wrote: > I am replying from the digest, I apologize if the message threading is > broken from that. > ... > > And compare ingress_time to the timestamp I get when I use the local > > hardware clock (which I am not allowed to sync with ptp). > ... > > For now all I need is the exact difference between what PTP would deliver > > compared to the local systemtime. > > You should make sure what exactly you are not permitted to sync with ptp. > Is it really hardware clock, or do you mean system clock and RTC? > In PTP context when you use the term "hardware clock" I think most would > assume that means the PTP Hardware Clock (PHC) in the network controller. > To most system administrators the term "hardware clock" would probably > imply the system clock maintained by the operating system using processor > counters, and synchronized to the realtime clock (RTC) on shutdown, and > possibly periodically while running. > > 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. > > So in summary it would be worth checking that you and whoever made the > restriction of not changing the hardware clock are really speaking of the > same thing, because a reasonable interpretation could be that you can sync > the NIC hardware clock using PTP, but just don't touch the system clock > running from the processor counter. > > -- > Chris Caudle > > > > > > > ___ > 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
Re: [Linuxptp-users] Get PTP but no Sync
I am replying from the digest, I apologize if the message threading is broken from that. ... > And compare ingress_time to the timestamp I get when I use the local > hardware clock (which I am not allowed to sync with ptp). ... > For now all I need is the exact difference between what PTP would deliver > compared to the local systemtime. You should make sure what exactly you are not permitted to sync with ptp. Is it really hardware clock, or do you mean system clock and RTC? In PTP context when you use the term "hardware clock" I think most would assume that means the PTP Hardware Clock (PHC) in the network controller. To most system administrators the term "hardware clock" would probably imply the system clock maintained by the operating system using processor counters, and synchronized to the realtime clock (RTC) on shutdown, and possibly periodically while running. 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. So in summary it would be worth checking that you and whoever made the restriction of not changing the hardware clock are really speaking of the same thing, because a reasonable interpretation could be that you can sync the NIC hardware clock using PTP, but just don't touch the system clock running from the processor counter. -- Chris Caudle ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Get PTP but no Sync
Hi Richard, Thanks for your answer! So if I understand correctly I can run pmc -u -b 0 'GET TIME_STATUS_NP' to get sending: GET TIME_STATUS_NP 98f2b3.fffe.138691-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP master_offset 14 ingress_time 1589869722179953606 cumulativeScaledRateOffset +0.0 scaledLastGmPhaseChange0 gmTimeBaseIndicator0 lastGmPhaseChange 0x'. gmPresent true gmIdentity 0080ea.fffe.bd9a70 locally on the machine with connected hardware (which should be enough for now). And compare ingress_time to the timestamp I get when I use the local hardware clock (which I am not allowed to sync with ptp). Or is ingress_time the wrong time to use if I am not syncing? For now all I need is the exact difference between what PTP would deliver compared to the local systemtime. Thanks a lot! regards Werner On Mon, May 18, 2020 at 4:06 PM Richard Cochran wrote: > On Mon, May 18, 2020 at 08:58:09AM +0200, Werner Macho wrote: > > So my questions are: > > Is there something I can call to get the very exact time without syncing > > the hardware clock on the computer? (I 'only' need a exact timestamp > > without considering the computers HW-clock) > > Would this somehow also be possible to call on a directly connected > > computer on LAN? > > Or better: Is this even possible at all? > > If you need a time stamp from a over an Ethernet network, then you need to > exchange Ethernet frames. > > But you are not allowed to do even that? > > Then you are out of luck. > > > If you can run PTP, I suggest: > > 1. Run ptp4l using the --free_running=1 mode. > > 2. Figure the time offset between the local clock and the remote clock >using TIME_STATUS_NP: > > # designed for use with gPTP and free_running > master_offset 0 > ingress_time 0 > cumulativeScaledRateOffset +0.0 > scaledLastGmPhaseChange0 > gmTimeBaseIndicator0 > lastGmPhaseChange 0x'. > gmPresent false > gmIdentity e89a8f.fffe.74f796 > > 3. Take your local time stamps via vdso (ie clock_gettime). > > 4. Use the result of step 2 to figure the global time of the time >stamps in step 3. > > HTH, > Richard > ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Get PTP but no Sync
On Mon, May 18, 2020 at 08:58:09AM +0200, Werner Macho wrote: > So my questions are: > Is there something I can call to get the very exact time without syncing > the hardware clock on the computer? (I 'only' need a exact timestamp > without considering the computers HW-clock) > Would this somehow also be possible to call on a directly connected > computer on LAN? > Or better: Is this even possible at all? If you need a time stamp from a over an Ethernet network, then you need to exchange Ethernet frames. But you are not allowed to do even that? Then you are out of luck. If you can run PTP, I suggest: 1. Run ptp4l using the --free_running=1 mode. 2. Figure the time offset between the local clock and the remote clock using TIME_STATUS_NP: # designed for use with gPTP and free_running master_offset 0 ingress_time 0 cumulativeScaledRateOffset +0.0 scaledLastGmPhaseChange0 gmTimeBaseIndicator0 lastGmPhaseChange 0x'. gmPresent false gmIdentity e89a8f.fffe.74f796 3. Take your local time stamps via vdso (ie clock_gettime). 4. Use the result of step 2 to figure the global time of the time stamps in step 3. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
