linuxptp-users Mailing List for linuxptp (Page 38)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Arfaoui M. <mah...@gm...> - 2021-12-04 16:07:38
|
Hi, Can anyone help me please. Regards. On Fri, Nov 26, 2021, 13:54 Arfaoui Mahdi <mah...@gm...> wrote: > Hi, first, thank you for the PTP4L that make our lives easier. > I'm trying to sync a custom buildroot kernel on an A7 MCU (master) with an > RPi B3, the issue that I'm receiving a continuous error of tx timestamp > timeout, I raised *tx_timestamp_timeout *to 100 then 1000, but the > problem always persists, after reading multiple threads on the subject, it > turns out that the source problem might be a driver issue. > Here are the infos and config I'm using. > > *ptp4l.conf:* > > [global] > # > # Default Data Set > # > twoStepFlag 1 > slaveOnly 0 > priority1 128 > priority2 128 > domainNumber 0 > clockClass 248 > clockAccuracy 0xFE > offsetScaledLogVariance 0xFFFF > free_running 0 > freq_est_interval 1 > # > # Port Data Set > # > logAnnounceInterval 1 > logSyncInterval 0 > logMinDelayReqInterval 0 > logMinPdelayReqInterval 0 > announceReceiptTimeout 3 > syncReceiptTimeout 0 > delayAsymmetry 0 > fault_reset_interval 4 > neighborPropDelayThresh 20000000 > # > # Run time options > # > assume_two_step 0 > logging_level 6 > path_trace_enabled 0 > follow_up_info 0 > hybrid_e2e 0 > tx_timestamp_timeout 1 > use_syslog 1 > verbose 0 > summary_interval 0 > kernel_leap 1 > check_fup_sync 0 > # > # Servo Options > # > pi_proportional_const 0.0 > pi_integral_const 0.0 > pi_proportional_scale 0.0 > pi_proportional_exponent -0.3 > pi_proportional_norm_max 0.7 > pi_integral_scale 0.0 > pi_integral_exponent 0.4 > pi_integral_norm_max 0.3 > step_threshold 0.0 > first_step_threshold 0.00002 > max_frequency 900000000 > clock_servo pi > sanity_freq_limit 200000000 > ntpshm_segment 0 > # > # Transport options > # > transportSpecific 0x0 > ptp_dst_mac 01:1B:19:00:00:00 > p2p_dst_mac 01:80:C2:00:00:0E > udp_ttl 32 > udp6_scope 0x0E > uds_address /var/run/ptp4l > # > # Default interface options > # > network_transport UDPv4 > delay_mechanism E2E > time_stamping software > tsproc_mode filter > delay_filter moving_median > delay_filter_length 10 > egressLatency 0 > ingressLatency 0 > boundary_clock_jbod 0 > # > # Clock description > # > productDescription ;; > revisionData ;; > manufacturerIdentity 00:00:00 > userDescription ; > timeSource 0xA0 > > > > *ptp4l.service : * > > > > > *[Unit]Description=Precision Time Protocol (PTP) > serviceWants=systemd-modules-load.serviceAfter=systemd-modules-load.service[Service]Type=simpleExecStart=/usr/sbin/ptp4l > -S -A -f /etc/ptp4l.conf -i eth0 > -mRestart=on-failureRestartSec=1[Install]WantedBy=network.targetWantedBy=multi-user.target* > > *PS :* I'm using software timestamping. > > *Ptp4l version : * > > *>>ptp4l -v* > v1.9.2_0_g47d6d15 > > *Interface Infos :* > > *>>ethtool -i eth0* > driver: st_gmac > version: Jan_2016 > firmware-version: > expansion-rom-version: > bus-info: > supports-statistics: yes > supports-test: no > supports-eeprom-access: no > supports-register-dump: yes > supports-priv-flags: no > > > *>>ethtool -T eth0* > Time stamping parameters for eth0: > 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: 0 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) > ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) > > > > > *Logs received on A7 side (master):* > > *>>ptp4l -i eth0 -A -S -f /etc/ptp4l.conf -m* > ptp4l[1660.053]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[1660.078]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[1667.471]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[1667.471]: selected local clock 020400.fffe.000200 as best master > ptp4l[1667.471]: assuming the grand master role > ptp4l[1668.472]: timed out while polling for tx timestamp > ptp4l[1668.473]: increasing tx_timestamp_timeout may correct this issue, > but it is likely caused by a driver bug > ptp4l[1668.473]: port 1: send sync failed > ptp4l[1668.473]: port 1: MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > ptp4l[1684.476]: port 1: FAULTY to LISTENING on INIT_COMPLETE > ptp4l[1691.120]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[1691.120]: selected local clock 020400.fffe.000200 as best master > ptp4l[1691.120]: assuming the grand master role > ptp4l[1692.122]: timed out while polling for tx timestamp > ptp4l[1692.122]: increasing tx_timestamp_timeout may correct this issue, > but it is likely caused by a driver bug > ptp4l[1692.122]: port 1: send sync failed > ptp4l[1692.122]: port 1: MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > ptp4l[1708.125]: port 1: FAULTY to LISTENING on INIT_COMPLETE > ptp4l[1714.987]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[1714.988]: selected local clock 020400.fffe.000200 as best master > ptp4l[1714.988]: assuming the grand master role > ptp4l[1715.989]: timed out while polling for tx timestamp > ptp4l[1715.989]: increasing tx_timestamp_timeout may correct this issue, > but it is likely caused by a driver bug > ptp4l[1715.989]: port 1: send sync failed > ptp4l[1715.989]: port 1: MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > ptp4l[1731.992]: port 1: FAULTY to LISTENING on INIT_COMPLETE > ptp4l[1739.090]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[1739.091]: selected local clock 020400.fffe.000200 as best master > ptp4l[1739.091]: assuming the grand master role > ptp4l[1740.092]: timed out while polling for tx timestamp > ptp4l[1740.092]: increasing tx_timestamp_timeout may correct this issue, > but it is likely caused by a driver bug > ptp4l[1740.093]: port 1: send sync failed > ptp4l[1740.093]: port 1: MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > > > > > *Logs received on RPi side (slave):* > > *>>sudo ptp4l -i eth0 -f /etc/ptp4l.conf -A -s -S -m* > ptp4l[65683.527]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[65683.528]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[65687.133]: port 1: new foreign master 020400.fffe.000200-1 > ptp4l[65690.310]: selected local clock b827eb.fffe.4bb224 as best master > ptp4l[65696.904]: selected local clock b827eb.fffe.4bb224 as best master > ptp4l[65704.244]: selected local clock b827eb.fffe.4bb224 as best master > ptp4l[65710.676]: selected local clock b827eb.fffe.4bb224 as best master > ptp4l[65717.917]: selected local clock b827eb.fffe.4bb224 as best master > > > > > Notice that on RPi, it detects the master clock for an instance (with id : 020400.fffe.000200) > but it doesn't take it as the local clock. > I hope you help me find a solution for my issue. > > Thanks > Best regards. > |
|
From: Richard C. <ric...@gm...> - 2021-12-04 15:45:55
|
On Sat, Dec 04, 2021 at 02:53:09PM +0200, Vladimir Oltean wrote: > Would this even be PTP, as in, IEEE 1588? No, it wouldn't be PTP. The Wifi standards do specifiy a precise synchronization method, but AFAICT no radio firmware implements it. It would also need work in the 802.11 layer in Linux. Thanks, Richard |
|
From: Vladimir O. <ol...@gm...> - 2021-12-04 12:53:32
|
On Sat, 4 Dec 2021 at 04:23, Richard Cochran <ric...@gm...> wrote: > > On Fri, Dec 03, 2021 at 12:21:34PM +0100, hesolium wrote: > > Hi Team, > > > > theoretically, having 3 radio transceivers, it is possible to synchronize > > time with an accuracy of several dozen microseconds without using TX > > timestamps. > > One can take advantage of the fact that the reception of the same frame by > > two different radio receivers is essentially simultaneous. > > Differences caused by the different distances of the receivers from the > > transmitter are negligible (nanoseconds). > > IOW, this is like PPS input. > > > I have a project working in an Ad-Hoc WiFi network and I need time > > synchronization with an accuracy of several dozen microseconds. > > All the drivers that I checked have only the software RX timestamps. > > Is a synchronization protocol using only receive timestamps implemented in > > PTP? > > No, not to my knowledge. Would this even be PTP, as in, IEEE 1588? |
|
From: Richard C. <ric...@gm...> - 2021-12-04 02:21:12
|
On Fri, Dec 03, 2021 at 12:21:34PM +0100, hesolium wrote: > Hi Team, > > theoretically, having 3 radio transceivers, it is possible to synchronize > time with an accuracy of several dozen microseconds without using TX > timestamps. > One can take advantage of the fact that the reception of the same frame by > two different radio receivers is essentially simultaneous. > Differences caused by the different distances of the receivers from the > transmitter are negligible (nanoseconds). IOW, this is like PPS input. > I have a project working in an Ad-Hoc WiFi network and I need time > synchronization with an accuracy of several dozen microseconds. > All the drivers that I checked have only the software RX timestamps. > Is a synchronization protocol using only receive timestamps implemented in > PTP? No, not to my knowledge. Sorry, Richard |
|
From: hesolium <hes...@gm...> - 2021-12-03 11:21:44
|
Hi Team, theoretically, having 3 radio transceivers, it is possible to synchronize time with an accuracy of several dozen microseconds without using TX timestamps. One can take advantage of the fact that the reception of the same frame by two different radio receivers is essentially simultaneous. Differences caused by the different distances of the receivers from the transmitter are negligible (nanoseconds). I have a project working in an Ad-Hoc WiFi network and I need time synchronization with an accuracy of several dozen microseconds. All the drivers that I checked have only the software RX timestamps. Is a synchronization protocol using only receive timestamps implemented in PTP? |
|
From: Vladimir O. <ol...@gm...> - 2021-11-27 18:01:01
|
On Sat, Nov 27, 2021 at 10:42:27AM +0530, Raj kishore Chhatoi wrote: > Hi Team, > > We are using linuxptp-3.1 version.We are running ptp4l with Primary > configuration on a DUT and running ptp4l with salve configuration in > another DUT. Both Primary and slaves are connecetd via Radmoon Media > converter. > > We observed that Primary board is successfully sending sync(in every 125 > ms),Follow up message,PDelayResp,PdelayRespFollowUp..etc and slave also > sending Peer_Dealy_Req_message and is recived by Primary DUT. The Primary > Board system time is also successfully updating in Slave board, however we > observed that "rms" vlues in the slave board is >10000000 consistently. > > When we analyzed the sync packet we found that "LogMessagePeriod: -3" . > > Could you please let us know in which scenario/case the "LogMessagePeriod: > -3" is getting updated in sync packet ? -3 means 2 to the power of -3 seconds which means 1/8 = 125 ms. It is the interval between Sync packets. You've mentioned this interval yourself, it is typical for the automotive profile of 802.1AS. Is that your question? > > Note : we are running "phc2sys -s eth0 -c CLOCK_REALTIME > --step_threshold=1" in slave board > > Logs: > root:~# ./ptp4l -i eth0 -f automotive-slave.cfg -m > ptp4l[291.097]: selected /dev/ptp0 as PTP clock > ptp4l[291.170]: port 1: INITIALIZING to SLAVE on INIT_COMPLETE > ptp4l[291.171]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[292.108]: port 1: new foreign master 0022a0.fffe.000106-1 > ptp4l[293.030]: rms 14298871623 max 28633786542 freq +32767999 +/- 0 delay 249550 +/- 0 > ptp4l[293.998]: rms 834329141 max 1086841975 freq +32767999 +/- 0 delay 238995 +/- 0 > ptp4l[294.966]: rms 656424174 max 1242086770 freq +32767999 +/- 0 delay 228440 +/- 0 > ptp4l[295.934]: rms 834413078 max 1086933599 freq +32767999 +/- 0 delay 47601 +/- 0 > ptp4l[295.977]: selected best master clock 0022a0.fffe.000106 > ptp4l[296.992]: rms 546142504 max 1241973769 freq +32767999 +/- 0 delay 219031 +/- 0 > ptp4l[297.919]: rms 910259892 max 1164392370 freq +32767999 +/- 0 delay 217901 +/- 0 > ptp4l[298.893]: rms 546157036 max 1242015850 freq +32767999 +/- 0 delay 216772 +/- 0 > ptp4l[299.867]: rms 910419317 max 1164606134 freq +32767999 +/- 0 delay 41767 +/- 0 > ptp4l[300.821]: rms 546124273 max 1242235894 freq +32767999 +/- 0 delay 216772 +/- 0 > ptp4l[301.735]: rms 910078978 max 1164216378 freq +32767999 +/- 0 delay 213509 +/- 0 > ptp4l[302.709]: rms 546122078 max 1241845058 freq +32767999 +/- 0 delay 148756 +/- 0 > ptp4l[303.682]: rms 910298081 max 1164439875 freq +32767999 +/- 0 delay 142954 +/- 0 > ptp4l[304.651]: rms 546142664 max 1242083695 freq +32767999 +/- 0 delay 201156 +/- 0 > ptp4l[305.551]: rms 910186093 max 1164323638 freq +32767999 +/- 0 delay 201156 +/- 0 > ptp4l[306.524]: rms 546136673 max 1241949998 freq +32767999 +/- 0 delay 189790 +/- 0 > ptp4l[307.498]: rms 910274018 max 1164416786 freq +32767999 +/- 0 delay 189790 +/- 0 > ptp4l[308.472]: rms 546156330 max 1242043326 freq +32767999 +/- 0 delay 199359 +/- 0 > ptp4l[309.381]: rms 910243669 max 1164393419 freq +32767999 +/- 0 delay 201871 +/- 0 > ptp4l[310.282]: rms 546152446 max 1242024319 freq +32767999 +/- 0 delay 199359 +/- 0 > ptp4l[311.182]: rms 910248741 max 1164373995 freq +32767999 +/- 0 delay 190736 +/- 0 The path delay is very high, and has a lot of jitter (all the way from 47 us to 249 us). PTP synchronization relies on having a constant path delay and symmetric in both directions. The path delay should not be any higher than around 10 us for a 100Mbps link. My guess is that the RAD-Moon media converter is to blame for the jitter. It would be good if you could test PTP straight between two 100base-T1 ports. Also, when asking for help related to synchronization failures, it is of utmost importance to mention the kernel and driver versions you are using. Most issues come from driver bugs, and there is a chance this one is no different. |
|
From: Raj k. C. <mai...@gm...> - 2021-11-27 05:12:51
|
Hi Team, We are using linuxptp-3.1 version.We are running ptp4l with Primary configuration on a DUT and running ptp4l with salve configuration in another DUT. Both Primary and slaves are connecetd via Radmoon Media converter. We observed that Primary board is successfully sending sync(in every 125 ms),Follow up message,PDelayResp,PdelayRespFollowUp..etc and slave also sending Peer_Dealy_Req_message and is recived by Primary DUT. The Primary Board system time is also successfully updating in Slave board, however we observed that "rms" vlues in the slave board is >10000000 consistently. When we analyzed the sync packet we found that "LogMessagePeriod: -3" . Could you please let us know in which scenario/case the "LogMessagePeriod: -3" is getting updated in sync packet ? Note : we are running "phc2sys -s eth0 -c CLOCK_REALTIME --step_threshold=1" in slave board Logs: root:~# ./ptp4l -i eth0 -f automotive-slave.cfg -m ptp4l[291.097]: selected /dev/ptp0 as PTP clock ptp4l[291.170]: port 1: INITIALIZING to SLAVE on INIT_COMPLETE ptp4l[291.171]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[292.108]: port 1: new foreign master 0022a0.fffe.000106-1 ptp4l[293.030]: rms 14298871623 max 28633786542 freq +32767999 +/- 0 delay 249550 +/- 0 ptp4l[293.998]: rms 834329141 max 1086841975 freq +32767999 +/- 0 delay 238995 +/- 0 ptp4l[294.966]: rms 656424174 max 1242086770 freq +32767999 +/- 0 delay 228440 +/- 0 ptp4l[295.934]: rms 834413078 max 1086933599 freq +32767999 +/- 0 delay 47601 +/- 0 ptp4l[295.977]: selected best master clock 0022a0.fffe.000106 ptp4l[296.992]: rms 546142504 max 1241973769 freq +32767999 +/- 0 delay 219031 +/- 0 ptp4l[297.919]: rms 910259892 max 1164392370 freq +32767999 +/- 0 delay 217901 +/- 0 ptp4l[298.893]: rms 546157036 max 1242015850 freq +32767999 +/- 0 delay 216772 +/- 0 ptp4l[299.867]: rms 910419317 max 1164606134 freq +32767999 +/- 0 delay 41767 +/- 0 ptp4l[300.821]: rms 546124273 max 1242235894 freq +32767999 +/- 0 delay 216772 +/- 0 ptp4l[301.735]: rms 910078978 max 1164216378 freq +32767999 +/- 0 delay 213509 +/- 0 ptp4l[302.709]: rms 546122078 max 1241845058 freq +32767999 +/- 0 delay 148756 +/- 0 ptp4l[303.682]: rms 910298081 max 1164439875 freq +32767999 +/- 0 delay 142954 +/- 0 ptp4l[304.651]: rms 546142664 max 1242083695 freq +32767999 +/- 0 delay 201156 +/- 0 ptp4l[305.551]: rms 910186093 max 1164323638 freq +32767999 +/- 0 delay 201156 +/- 0 ptp4l[306.524]: rms 546136673 max 1241949998 freq +32767999 +/- 0 delay 189790 +/- 0 ptp4l[307.498]: rms 910274018 max 1164416786 freq +32767999 +/- 0 delay 189790 +/- 0 ptp4l[308.472]: rms 546156330 max 1242043326 freq +32767999 +/- 0 delay 199359 +/- 0 ptp4l[309.381]: rms 910243669 max 1164393419 freq +32767999 +/- 0 delay 201871 +/- 0 ptp4l[310.282]: rms 546152446 max 1242024319 freq +32767999 +/- 0 delay 199359 +/- 0 ptp4l[311.182]: rms 910248741 max 1164373995 freq +32767999 +/- 0 delay 190736 +/- 0 Thanks, Raj |
|
From: Federico M. <Fed...@da...> - 2021-11-26 18:48:38
|
Hey everyone, I have done some advances with my PTP setup but still some fine enhancements need to be done. I am sending messages from one computer to another via the MK6c C-V2X devices. This devices have GPS and I am synchronising the computers to their respective Mk6c attached vie Ethernet. Now the problem is, that when I send a message from Tx to Rx and measure the latency (attach timestamp to message and check in the Rx with the actual time), I get negative values and quite high also. They are all around -400-450 ms delay, which means that the computers are not getting the exact time from the gps in the MK6c devices. I am executing the commands below in each device. Do you know if I can get a better synchronization in order to get the 4 elements in sync? Thanks a lot in advance and have a nice weekend! Bests, Fede Master-1 (Cohda Wireless MK6C with C-v2x qualcom modem and GPS integrated) chronyc sources 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #? KPPS 0 2 0 - +0ns[ +0ns] +/- 0ns #? GNSS 0 4 0 - +0ns[ +0ns] +/- 0ns ^* qti-modem 1 2 377 4 -173us[ -193us] +/- 1222us cat ptp.cfg [global] tx_timestamp_timeout 10 step_threshold 1 ptp4l -A -i eth0 -m -f ptp.cfg ptp4l[229.691]: selected /dev/ptp0 as PTP clock ptp4l[229.693]: driver changed our HWTSTAMP options ptp4l[229.693]: tx_type 1 not 1 ptp4l[229.693]: rx_filter 1 not 12 ptp4l[229.693]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[229.693]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[229.694]: port 1: link up ptp4l[237.053]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[237.053]: selected best master clock 04e548.fffe.23010c ptp4l[237.053]: assuming the grand master role Slave-1 (Ubuntu 20.04 Laptop) cat ptp.conf [global] #clientOnly 1 delay_mechanism Auto network_transport UDPv4 #time_stamping hardware # for the HW-timestamping slave #time_stamping software # for the SW-timestamping slave step_threshold 1.0 utc_offset 37 # make sure our slave clock is never elected as master priority1 255 priority2 255 [enp0s25] sudo ptp4l -f ptp.conf -m ptp4l[7229.653]: selected /dev/ptp0 as PTP clock ptp4l[7229.653]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[7229.653]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[7230.099]: port 1: new foreign master 04e548.fffe.23010c-1 ptp4l[7232.100]: selected best master clock 04e548.fffe.23010c ptp4l[7232.100]: running in a temporal vortex ptp4l[7232.100]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[7233.595]: master offset -494729050 s0 freq +3191 path delay 36620 ptp4l[7234.100]: master offset -494729136 s1 freq +3021 path delay 36620 ptp4l[7234.595]: master offset -24 s2 freq +2997 path delay 36620 ptp4l[7234.595]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[7235.100]: master offset 892 s2 freq +3906 path delay 36620 ptp4l[7235.595]: master offset 1404 s2 freq +4685 path delay 36620 ptp4l[7236.100]: master offset 357 s2 freq +4059 path delay 36979 sudo phc2sys -s enp0s25 -O 0 -m phc2sys[7239.599]: CLOCK_REALTIME phc offset -495721525 s0 freq +1751 delay 4109 phc2sys[7240.600]: CLOCK_REALTIME phc offset -495723277 s1 freq +0 delay 4377 phc2sys[7241.600]: CLOCK_REALTIME phc offset -147 s2 freq -147 delay 4301 phc2sys[7242.601]: CLOCK_REALTIME phc offset 312 s2 freq +268 delay 4103 phc2sys[7243.601]: CLOCK_REALTIME phc offset 450 s2 freq +500 delay 4113 phc2sys[7244.601]: CLOCK_REALTIME phc offset 573 s2 freq +758 delay 4143 phc2sys[7245.601]: CLOCK_REALTIME phc offset -246 s2 freq +110 delay 4146 phc2sys[7246.602]: CLOCK_REALTIME phc offset -19 s2 freq +264 delay 4160 phc2sys[7247.602]: CLOCK_REALTIME phc offset 184 s2 freq +461 delay 4109 phc2sys[7248.602]: CLOCK_REALTIME phc offset 212 s2 freq +544 delay 4160 phc2sys[7249.603]: CLOCK_REALTIME phc offset -554 s2 freq -158 delay 4125 Master 2 (Second Cohda Mk6c) chronyc sources 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #? KPPS 0 2 0 - +0ns[ +0ns] +/- 0ns #? GNSS 0 4 0 - +0ns[ +0ns] +/- 0ns ^* qti-modem 1 4 377 4 +112us[ +111us] +/- 1272us cat ptp.cfg [global] tx_timestamp_timeout 10 ptp4l -A -i eth0 -m -f ptp.cfg ptp4l[280.355]: selected /dev/ptp0 as PTP clock ptp4l[280.357]: driver changed our HWTSTAMP options ptp4l[280.357]: tx_type 1 not 1 ptp4l[280.357]: rx_filter 1 not 12 ptp4l[280.357]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[280.357]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[280.358]: port 1: link up ptp4l[287.756]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[287.757]: selected best master clock 04e548.fffe.230108 ptp4l[287.757]: assuming the grand master role Slave-2 (Ubuntu 20.04 Laptop) sudo ptp4l -f linuxptp.cfg -m ptp4l[362997.494]: selected /dev/ptp0 as PTP clock ptp4l[362997.494]: port 1 (enp0s31f6): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[362997.494]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[362997.494]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[362998.515]: port 1 (enp0s31f6): new foreign master 04e548.fffe.230108-1 ptp4l[363000.515]: selected best master clock 04e548.fffe.230108 ptp4l[363000.515]: running in a temporal vortex ptp4l[363000.515]: port 1 (enp0s31f6): LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[363001.515]: master offset -1841 s0 freq +3112 path delay 8204 ptp4l[363001.942]: master offset -1945 s2 freq +2868 path delay 8204 ptp4l[363001.942]: port 1 (enp0s31f6): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[363002.515]: master offset -1622 s2 freq +1246 path delay 8128 ptp4l[363002.942]: master offset -814 s2 freq +1568 path delay 8053 ptp4l[363003.515]: master offset -93 s2 freq +2045 path delay 8053 sudo phc2sys -s enp0s31f6 -O -0 -m phc2sys[363001.918]: CLOCK_REALTIME phc offset 49 s0 freq +3226 delay 0 phc2sys[363002.919]: CLOCK_REALTIME phc offset -1011 s2 freq +2167 delay 0 phc2sys[363003.919]: CLOCK_REALTIME phc offset -1263 s2 freq +904 delay 0 phc2sys[363004.920]: CLOCK_REALTIME phc offset 527 s2 freq +2315 delay 0 phc2sys[363005.920]: CLOCK_REALTIME phc offset 1450 s2 freq +3396 delay 0 phc2sys[363006.920]: CLOCK_REALTIME phc offset 1528 s2 freq +3909 delay 0 phc2sys[363007.920]: CLOCK_REALTIME phc offset 896 s2 freq +3735 delay 0 phc2sys[363008.921]: CLOCK_REALTIME phc offset 76 s2 freq +3184 delay 0 phc2sys[363009.921]: CLOCK_REALTIME phc offset -191 s2 freq +2940 delay 0 |
|
From: Arfaoui M. <mah...@gm...> - 2021-11-26 12:54:19
|
Hi, first, thank you for the PTP4L that make our lives easier.
I'm trying to sync a custom buildroot kernel on an A7 MCU (master) with an
RPi B3, the issue that I'm receiving a continuous error of tx timestamp
timeout, I raised *tx_timestamp_timeout *to 100 then 1000, but the problem
always persists, after reading multiple threads on the subject, it turns
out that the source problem might be a driver issue.
Here are the infos and config I'm using.
*ptp4l.conf:*
[global]
#
# Default Data Set
#
twoStepFlag 1
slaveOnly 0
priority1 128
priority2 128
domainNumber 0
clockClass 248
clockAccuracy 0xFE
offsetScaledLogVariance 0xFFFF
free_running 0
freq_est_interval 1
#
# Port Data Set
#
logAnnounceInterval 1
logSyncInterval 0
logMinDelayReqInterval 0
logMinPdelayReqInterval 0
announceReceiptTimeout 3
syncReceiptTimeout 0
delayAsymmetry 0
fault_reset_interval 4
neighborPropDelayThresh 20000000
#
# Run time options
#
assume_two_step 0
logging_level 6
path_trace_enabled 0
follow_up_info 0
hybrid_e2e 0
tx_timestamp_timeout 1
use_syslog 1
verbose 0
summary_interval 0
kernel_leap 1
check_fup_sync 0
#
# Servo Options
#
pi_proportional_const 0.0
pi_integral_const 0.0
pi_proportional_scale 0.0
pi_proportional_exponent -0.3
pi_proportional_norm_max 0.7
pi_integral_scale 0.0
pi_integral_exponent 0.4
pi_integral_norm_max 0.3
step_threshold 0.0
first_step_threshold 0.00002
max_frequency 900000000
clock_servo pi
sanity_freq_limit 200000000
ntpshm_segment 0
#
# Transport options
#
transportSpecific 0x0
ptp_dst_mac 01:1B:19:00:00:00
p2p_dst_mac 01:80:C2:00:00:0E
udp_ttl 32
udp6_scope 0x0E
uds_address /var/run/ptp4l
#
# Default interface options
#
network_transport UDPv4
delay_mechanism E2E
time_stamping software
tsproc_mode filter
delay_filter moving_median
delay_filter_length 10
egressLatency 0
ingressLatency 0
boundary_clock_jbod 0
#
# Clock description
#
productDescription ;;
revisionData ;;
manufacturerIdentity 00:00:00
userDescription ;
timeSource 0xA0
*ptp4l.service : *
*[Unit]Description=Precision Time Protocol (PTP)
serviceWants=systemd-modules-load.serviceAfter=systemd-modules-load.service[Service]Type=simpleExecStart=/usr/sbin/ptp4l
-S -A -f /etc/ptp4l.conf -i eth0
-mRestart=on-failureRestartSec=1[Install]WantedBy=network.targetWantedBy=multi-user.target*
*PS :* I'm using software timestamping.
*Ptp4l version : *
*>>ptp4l -v*
v1.9.2_0_g47d6d15
*Interface Infos :*
*>>ethtool -i eth0*
driver: st_gmac
version: Jan_2016
firmware-version:
expansion-rom-version:
bus-info:
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
*>>ethtool -T eth0*
Time stamping parameters for eth0:
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: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC)
ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
*Logs received on A7 side (master):*
*>>ptp4l -i eth0 -A -S -f /etc/ptp4l.conf -m*
ptp4l[1660.053]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1660.078]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1667.471]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1667.471]: selected local clock 020400.fffe.000200 as best master
ptp4l[1667.471]: assuming the grand master role
ptp4l[1668.472]: timed out while polling for tx timestamp
ptp4l[1668.473]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1668.473]: port 1: send sync failed
ptp4l[1668.473]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1684.476]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1691.120]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1691.120]: selected local clock 020400.fffe.000200 as best master
ptp4l[1691.120]: assuming the grand master role
ptp4l[1692.122]: timed out while polling for tx timestamp
ptp4l[1692.122]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1692.122]: port 1: send sync failed
ptp4l[1692.122]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1708.125]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1714.987]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1714.988]: selected local clock 020400.fffe.000200 as best master
ptp4l[1714.988]: assuming the grand master role
ptp4l[1715.989]: timed out while polling for tx timestamp
ptp4l[1715.989]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1715.989]: port 1: send sync failed
ptp4l[1715.989]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1731.992]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1739.090]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1739.091]: selected local clock 020400.fffe.000200 as best master
ptp4l[1739.091]: assuming the grand master role
ptp4l[1740.092]: timed out while polling for tx timestamp
ptp4l[1740.092]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1740.093]: port 1: send sync failed
ptp4l[1740.093]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
*Logs received on RPi side (slave):*
*>>sudo ptp4l -i eth0 -f /etc/ptp4l.conf -A -s -S -m*
ptp4l[65683.527]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[65683.528]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[65687.133]: port 1: new foreign master 020400.fffe.000200-1
ptp4l[65690.310]: selected local clock b827eb.fffe.4bb224 as best master
ptp4l[65696.904]: selected local clock b827eb.fffe.4bb224 as best master
ptp4l[65704.244]: selected local clock b827eb.fffe.4bb224 as best master
ptp4l[65710.676]: selected local clock b827eb.fffe.4bb224 as best master
ptp4l[65717.917]: selected local clock b827eb.fffe.4bb224 as best master
Notice that on RPi, it detects the master clock for an instance (with
id : 020400.fffe.000200)
but it doesn't take it as the local clock.
I hope you help me find a solution for my issue.
Thanks
Best regards.
|
|
From: ramesh t <ram...@ya...> - 2021-11-25 05:56:49
|
hi Jake, Richard, Observed issue with ptp 2.0 also. But based on below logs. Nov 10 03:49:04 ptp4l: [21956.414] rms 3 max 6 freq +2783 +/- 5 delay 85 +/- 1 Nov 10 03:49:05 phc2sys: [21956.824] CLOCK_REALTIME phc offset 8 s2 freq +9775 delay 2252 Nov 4 12:50:40 ptp4l: [21957.406] rms 3 max 5 freq +2780 +/- 5 delay 86 +/- 1 Nov 6 05:55:10 phc2sys: [21957.824] clockcheck: clock jumped backward or running slower than expected! Nov 6 05:55:10 phc2sys: [21957.824] CLOCK_REALTIME phc offset -338035766568736 s0 freq +9775 delay 2461 Nov 6 07:39:56 ptp4l: [21958.399] rms 2 max 3 freq +2783 +/- 3 delay 85 +/- 1 Nov 9 21:52:19 phc2sys: [21958.824] Nov 9 21:52:19 phc2sys: [21958.824] CLOCK_REALTIME phc offset -21408060435248 sclockcheck: clock jumped forward or running faster than expected!0 freq +9775 delay 2468 Nov 9 21:52:19 ptp4l: [21959.393] rms 3 max 6 freq +2784 +/- 4 delay 84 +/- 1 Nov 9 21:52:20 phc2sys: [21959.825] CLOCK_REALTIME phc offset -21408060435245 s2 freq +9772 delay 2472 Observing time change 3 to 4 times? ptp4l seems to have proper value ie phc offset -21408060435248 (Nov 9 21.52.19 + 21408 secs (5 hour + 56 minutes) around Nov 10 3:49. Please suggest. regards, Ramesh On Thursday, November 11, 2021, 10:26:28 PM GMT+5:30, ramesh t via Linuxptp-users <lin...@li...> wrote: hi Richard, Verified on the nodes where the problem re-occurred after almost a week using phc_ctl. NIC phc time was fine. But only system time had changed. Also as suggested was running a script to capture phc_ctl periodically, but the issue didn't happen on those node. Even nodes running ptp2.0 didn't report the problem. Nov 10 23:19:13 phc2sys: [43031.919] CLOCK_REALTIME phc offset -62 s2 freq +4363 delay 2331 Nov 10 23:19:14 ptp4l: [43032.308] rms 3 max 6 freq -834 +/- 4 delay 83 +/- 1 Nov 10 02:38:29 phc2sys: [43032.919] clockcheck: clock jumped backward or running slower than expected! Nov 10 02:38:29 phc2sys: [43032.919] CLOCK_REALTIME phc offset -74444707194042 s0 freq +4363 delay 2459 Nov 10 17:47:19 ptp4l: [43033.302] rms 3 max 7 freq -837 +/- 5 delay 83 +/- 1 Nov 10 22:36:11 phc2sys: [93661.492] CLOCK_REALTIME phc offset 34 s2 freq +9568 delay 2352 Nov 10 22:36:12 ptp4l: [93662.280] rms 3 max 5 freq +3086 +/- 4 delay 85 +/- 0 Nov 4 12:50:40 phc2sys: [93662.493] clockcheck: clock jumped backward or running slower than expected! Nov 4 12:50:40 phc2sys: [93662.493] CLOCK_REALTIME phc offset -553532738053986 s0 freq +9568 delay 2455 Nov 10 15:54:49 ptp4l: [93663.272] rms 2 max 5 freq +3084 +/- 3 delay 86 +/- 1 I guess there are two possibilities. 1) Some process is changing the time? Is there a way to monitor which all processes modify the system time? 2) phc2sys code has issues in 3.0 version? Please suggest. regards, Ramesh On Tuesday, November 2, 2021, 10:02:01 PM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Tue, Nov 02, 2021 at 03:32:04PM +0000, ramesh t wrote: > hi, > > Any suggestion for the below mentioned issue? Please let me know. Looks like a HW and/or driver issue. I would start by validating the HW/driver. For example, a long term test of phc_ctl eth0 get HTH, Richard _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Federico M. <Fed...@da...> - 2021-11-24 15:47:20
|
Hey everyone,
I have been trying for a while to set up my master-slave PTP sync but in the slave I can see an offset. When I ask for the date in the slave and the master they have around 36 seconds difference.
If I do not run this command after synchronizing with ptp4l, the slave is 36 seconds behind the master. If I run the command, then it is again around 36 seconds faster than the master. The problem is that they never are exactly at the same time.
sudo phc2sys -s enp0s31f6 -O 36 -m
Does someone knows what is the problem? Thank you very much in advance!
Below the logs:
Best regards,
Federico Murciano
Master:
root@MK6C:~# ptp4l -A -i eth0 -m
ptp4l[9493.515]: selected /dev/ptp0 as PTP clock
ptp4l[9493.517]: driver changed our HWTSTAMP options
ptp4l[9493.517]: tx_type 1 not 1
ptp4l[9493.517]: rx_filter 1 not 12
ptp4l[9493.517]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[9493.518]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[9493.518]: port 1: link up
ptp4l[9500.191]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[9500.191]: selected best master clock 04e548.fffe.230108
ptp4l[9500.191]: assuming the grand master role
ptp4l[9651.203]: timed out while polling for tx timestamp
ptp4l[9651.204]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[9651.204]: port 1: send sync failed
ptp4l[9651.204]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[9667.205]: driver changed our HWTSTAMP options
ptp4l[9667.205]: tx_type 1 not 1
ptp4l[9667.205]: rx_filter 1 not 12
Slave:
Terminal 1
sudo ptp4l -f linuxptp.cfg -m
ptp4l[179725.005]: selected /dev/ptp0 as PTP clock
ptp4l[179725.006]: port 1 (enp0s31f6): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[179725.006]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[179725.006]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[179725.809]: port 1 (enp0s31f6): new foreign master 04e548.fffe.230108-1
ptp4l[179730.210]: selected best master clock 04e548.fffe.230108
ptp4l[179730.210]: running in a temporal vortex
ptp4l[179730.210]: port 1 (enp0s31f6): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[179732.410]: master offset -40033 s0 freq +3094 path delay 8176
ptp4l[179733.510]: master offset -40231 s1 freq +2896 path delay 8178
ptp4l[179734.610]: master offset 130 s2 freq +3026 path delay 8178
ptp4l[179734.610]: port 1 (enp0s31f6): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[179735.710]: master offset -167 s2 freq +2768 path delay 8181
Terminal 2
sudo phc2sys -a -r -m
phc2sys[179735.688]: reconfiguring after port state change
phc2sys[179735.688]: selecting CLOCK_REALTIME for synchronization
phc2sys[179735.688]: selecting enp0s31f6 as the master clock
phc2sys[179735.689]: CLOCK_REALTIME phc offset 85994777540 s0 freq -100000000 delay 0
phc2sys[179736.689]: CLOCK_REALTIME phc offset 86085732758 s1 freq +2715 delay 0
phc2sys[179737.690]: CLOCK_REALTIME phc offset 12285 s2 freq +15000 delay 0
phc2sys[179738.690]: CLOCK_REALTIME phc offset 121 s2 freq +6521 delay 0
phc2sys[179739.691]: CLOCK_REALTIME phc offset -3304 s2 freq +3132 delay 0
phc2sys[179740.691]: CLOCK_REALTIME phc offset -3555 s2 freq +1890 delay 0
phc2sys[179741.692]: CLOCK_REALTIME phc offset -2345 s2 freq +2034 delay 0
phc2sys[179742.692]: CLOCK_REALTIME phc offset -1495 s2 freq +2180 delay 0
phc2sys[179743.692]: CLOCK_REALTIME phc offset -576 s2 freq +2651 delay 0
phc2sys[179744.693]: CLOCK_REALTIME phc offset -428 s2 freq +2626 delay 0
phc2sys[179745.693]: CLOCK_REALTIME phc offset -309 s2 freq +2617 delay 0
phc2sys[179746.694]: CLOCK_REALTIME phc offset 257 s2 freq +3090 delay 0
phc2sys[179747.694]: CLOCK_REALTIME phc offset 486 s2 freq +3396 delay 0
phc2sys[179748.694]: CLOCK_REALTIME phc offset -152 s2 freq +2904 delay 0
phc2sys[179749.695]: CLOCK_REALTIME phc offset -309 s2 freq +2701 delay 0
phc2sys[179750.695]: CLOCK_REALTIME phc offset 133 s2 freq +3050 delay 0
phc2sys[179751.696]: CLOCK_REALTIME phc offset -34 s2 freq +2923 delay 0
phc2sys[179752.696]: CLOCK_REALTIME phc offset 183 s2 freq +3130 delay 0
phc2sys[179753.696]: CLOCK_REALTIME phc offset -108 s2 freq +2894 delay 0
phc2sys[179754.696]: CLOCK_REALTIME phc offset 99 s2 freq +3069 delay 0
phc2sys[179755.697]: CLOCK_REALTIME phc offset -86 s2 freq +2913 delay 0
phc2sys[179756.697]: CLOCK_REALTIME phc offset 189 s2 freq +3163 delay 0
phc2sys[179757.698]: CLOCK_REALTIME phc offset -178 s2 freq +2852 delay 0
phc2sys[179758.698]: CLOCK_REALTIME phc offset -282 s2 freq +2695 delay 0
phc2sys[179759.698]: CLOCK_REALTIME phc offset 126 s2 freq +3018 delay 0
phc2sys[179760.699]: CLOCK_REALTIME phc offset -98 s2 freq +2832 delay 0
phc2sys[179761.699]: CLOCK_REALTIME phc offset 338 s2 freq +3239 delay 0
phc2sys[179762.699]: CLOCK_REALTIME phc offset -103 s2 freq +2899 delay 0
phc2sys[179763.700]: CLOCK_REALTIME phc offset 186 s2 freq +3157 delay 0
phc2sys[179764.700]: CLOCK_REALTIME phc offset -217 s2 freq +2810 delay 0
phc2sys[179765.700]: clockcheck: clock jumped forward or running faster than expected!
This happens after running the command
phc2sys[179765.701]: CLOCK_REALTIME phc offset 72000000088 s0 freq +2810 delay 0
phc2sys[179766.701]: CLOCK_REALTIME phc offset 71999999826 s2 freq +2700 delay 0
phc2sys[179767.701]: CLOCK_REALTIME phc offset 72000000062 s2 freq +100000000 delay 0
phc2sys[179768.702]: CLOCK_REALTIME phc offset 71979295436 s2 freq +100000000 delay 0
Terminal 3
sudo phc2sys -s enp0s31f6 -O 36 -m
phc2sys[179764.119]: CLOCK_REALTIME phc offset -71999999978 s0 freq +3157 delay 0
phc2sys[179765.120]: CLOCK_REALTIME phc offset -72000000048 s1 freq +3087 delay 0
phc2sys[179766.120]: CLOCK_REALTIME phc offset -45 s2 freq +3042 delay 0
phc2sys[179767.120]: CLOCK_REALTIME phc offset -82 s2 freq +2992 delay 0
phc2sys[179768.120]: CLOCK_REALTIME phc offset -46560779 s2 freq -46557730 delay 0
phc2sys[179769.121]: CLOCK_REALTIME phc offset -67251308 s2 freq -81216493 delay 0
phc2sys[179770.121]: CLOCK_REALTIME phc offset -70107428 s2 freq -100000000 delay 0
phc2sys[179771.121]: CLOCK_REALTIME phc offset -63443433 s2 freq -97584010 delay 0
|
|
From: ramesh t <ram...@ya...> - 2021-11-23 07:47:08
|
hi, step_threshold default config is 0.0. Hence it was not doing time-sync when moving from s0 to s2 via s1. After changing value of step_threshold, time-sync is happening. Question: Any reason as to why step_threshold is set 0.0? What should be the proper value? Also first_step_threshold value is set to 20 microseconds. Please suggest. regards, Ramesh On Tuesday, November 23, 2021, 12:00:53 AM GMT+5:30, ramesh t via Linuxptp-devel <lin...@li...> wrote: hi, phc2sys has 3 phases 1) unlock (s0, SERVO_UNLOCKED 2) time-sync (s1, SERVO_JUMP) 3) freq-sync (s2, SERVO_LOCKED) Based on the log capture below: Nov 10 03:49:05 phc2sys: [21956.824] CLOCK_REALTIME phc offset 8 s2 freq +9775 delay 2252 Nov 4 12:50:40 ptp4l: [21957.406] rms 3 max 5 freq +2780 +/- 5 delay 86 +/- 1 Nov 6 05:55:10 phc2sys: [21957.824] clockcheck: clock jumped backward or running slower than expected! Nov 6 05:55:10 phc2sys: [21957.824] CLOCK_REALTIME phc offset -338035766568736 s0 freq +9775 delay 2461 Nov 6 07:39:56 ptp4l: [21958.399] rms 2 max 3 freq +2783 +/- 3 delay 85 +/- 1 Nov 9 21:52:19 phc2sys: [21958.824] CLOCK_REALTIME phc offset -21408060435248 s0 freq +9775 delay 2468 Nov 9 21:52:19 ptp4l: [21959.393] rms 3 max 6 freq +2784 +/- 4 delay 84 +/- 1 Nov 9 21:52:20 phc2sys: [21959.825] CLOCK_REALTIME phc offset -21408060435245 s2 freq +9772 delay 2472 Actual time as received by ptp4l from GM is Nov 10 03:49 (1636516145) But system time is somehow got changed to Nov 9 21:52 (1636494740) Offset between two (ptp4l and system time) is 21408 seconds. So when the phc2sys moves from s0 to s2 via s1 phase, it should have set the system time to proper value based on below code (clockadj_step). case SERVO_JUMP: clockadj_step(clock->clkid, -offset); if (clock->sanity_check) clockcheck_step(clock->sanity_check, -offset); /* Fall through. */ case SERVO_LOCKED: But it still remained on Nov 9 21:52. What is wrong here? Nov 9 21:52:20 ptp4l: [21960.382] rms 3 max 6 freq +2776 +/- 2 delay 86 +/- 1 Nov 9 21:52:21 phc2sys: [21960.825] CLOCK_REALTIME phc offset -21408060435252 s2 freq -100000000 delay 2488 Nov 9 21:52:21 ptp4l: [21961.429] rms 3 max 6 freq +2778 +/- 5 delay 86 +/- 0 Nov 9 21:52:22 phc2sys: [21961.825] CLOCK_REALTIME phc offset -21407969493862 s2 freq -100000000 delay 2709 Nov 9 21:52:22 ptp4l: [21962.520] rms 3 max 7 freq +2784 +/- 4 delay 85 +/- 1 Please suggest. regards, Ramesh _______________________________________________ Linuxptp-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |
|
From: ramesh t <ram...@ya...> - 2021-11-22 18:29:10
|
hi, phc2sys has 3 phases 1) unlock (s0, SERVO_UNLOCKED 2) time-sync (s1, SERVO_JUMP) 3) freq-sync (s2, SERVO_LOCKED) Based on the log capture below: Nov 10 03:49:05 phc2sys: [21956.824] CLOCK_REALTIME phc offset 8 s2 freq +9775 delay 2252 Nov 4 12:50:40 ptp4l: [21957.406] rms 3 max 5 freq +2780 +/- 5 delay 86 +/- 1 Nov 6 05:55:10 phc2sys: [21957.824] clockcheck: clock jumped backward or running slower than expected! Nov 6 05:55:10 phc2sys: [21957.824] CLOCK_REALTIME phc offset -338035766568736 s0 freq +9775 delay 2461 Nov 6 07:39:56 ptp4l: [21958.399] rms 2 max 3 freq +2783 +/- 3 delay 85 +/- 1 Nov 9 21:52:19 phc2sys: [21958.824] CLOCK_REALTIME phc offset -21408060435248 s0 freq +9775 delay 2468 Nov 9 21:52:19 ptp4l: [21959.393] rms 3 max 6 freq +2784 +/- 4 delay 84 +/- 1 Nov 9 21:52:20 phc2sys: [21959.825] CLOCK_REALTIME phc offset -21408060435245 s2 freq +9772 delay 2472 Actual time as received by ptp4l from GM is Nov 10 03:49 (1636516145) But system time is somehow got changed to Nov 9 21:52 (1636494740) Offset between two (ptp4l and system time) is 21408 seconds. So when the phc2sys moves from s0 to s2 via s1 phase, it should have set the system time to proper value based on below code (clockadj_step). case SERVO_JUMP: clockadj_step(clock->clkid, -offset); if (clock->sanity_check) clockcheck_step(clock->sanity_check, -offset); /* Fall through. */ case SERVO_LOCKED: But it still remained on Nov 9 21:52. What is wrong here? Nov 9 21:52:20 ptp4l: [21960.382] rms 3 max 6 freq +2776 +/- 2 delay 86 +/- 1 Nov 9 21:52:21 phc2sys: [21960.825] CLOCK_REALTIME phc offset -21408060435252 s2 freq -100000000 delay 2488 Nov 9 21:52:21 ptp4l: [21961.429] rms 3 max 6 freq +2778 +/- 5 delay 86 +/- 0 Nov 9 21:52:22 phc2sys: [21961.825] CLOCK_REALTIME phc offset -21407969493862 s2 freq -100000000 delay 2709 Nov 9 21:52:22 ptp4l: [21962.520] rms 3 max 7 freq +2784 +/- 4 delay 85 +/- 1 Please suggest. regards, Ramesh |
|
From: Richard C. <ric...@gm...> - 2021-11-22 14:00:44
|
On Mon, Nov 22, 2021 at 10:13:30AM +0000, Mikael Arvids wrote: > Could you explain what I would use the TIME_STATUS_NP.ingress_time for when monitoring the end station? For example: - If ingress time does not increase: lost frames or lost GM - If delta(ingress time) unreasonable: broken GM or broken local clock HTH, Richard |
|
From: Mikael A. <mik...@ar...> - 2021-11-22 10:29:33
|
Hi Richard, Thanks for the quick reply! Could you explain what I would use the TIME_STATUS_NP.ingress_time for when monitoring the end station? Best regards, Mikael -----Original Message----- From: Richard Cochran <ric...@gm...> Sent: den 18 november 2021 23:23 To: Mikael Arvids <mik...@ar...> Cc: lin...@li... Subject: [EXTERNAL] Re: [Linuxptp-users] Monitoring an automotive-slave node On Thu, Nov 18, 2021 at 08:50:36AM +0000, Mikael Arvids via Linuxptp-users wrote: > > 1. Is this the expected behavior when using the automotive profile (especially the inhibit_announce option set to true)? Yes, looks about right to me. Remember, without Announce messages, the GM identity is lost. > 2. Is there a recommended way to monitor the end-stations as our earlier approach might not be the best, especially when introducing bridges? It really depends on your requirements. There is no "one size fits all" when it comes to synchronization monitoring. > We want to ensure that the end-stations are synchronized to the dedicated time server and that the accuracy is at least X microseconds. Well, you can monitor TIME_STATUS_NP.master_offset and TIME_STATUS_NP.ingress_time for starters. Good luck, Richard *************************************************************** To read the Company's Information and Confidentiality Notice, follow this link: https://www.arriver.com/important-information-and-confidentiality-notice *************************************************************** |
|
From: Richard C. <ric...@gm...> - 2021-11-18 22:23:39
|
On Thu, Nov 18, 2021 at 08:50:36AM +0000, Mikael Arvids via Linuxptp-users wrote: > > 1. Is this the expected behavior when using the automotive profile (especially the inhibit_announce option set to true)? Yes, looks about right to me. Remember, without Announce messages, the GM identity is lost. > 2. Is there a recommended way to monitor the end-stations as our earlier approach might not be the best, especially when introducing bridges? It really depends on your requirements. There is no "one size fits all" when it comes to synchronization monitoring. > We want to ensure that the end-stations are synchronized to the dedicated time server and that the accuracy is at least X microseconds. Well, you can monitor TIME_STATUS_NP.master_offset and TIME_STATUS_NP.ingress_time for starters. Good luck, Richard |
|
From: Nemanja K. <nem...@gm...> - 2021-11-18 16:35:07
|
Hi, I have a problem when I try to synchronize the PHC clock with the system clock. I use the De1_SOC board. The problem is when servo jump from state s1 to s2, phc offset increasing, for example: "sudo phc2sys -s CLOCK_REALTIME -c eth0 -m -O 35 -L 0 -S 0.7 -R 10" PHC offset increase for example from tens of millisecond to 0.7 second and then servo change state to s0 and to s1 and again to s2, and again from tens of millisecond to 1 second and everything is repeating. I don't know why in s2 state phc offset doesn't decrease. Here is the output of phc2sys command: hc2sys[2196.003]: eth0 sys offset -7071290975 s0 freq -32767998 delay 1090phc2sys[2279.239]: eth0 sys offset -853802608 s0 freq -32767999 delay 1060 phc2sys[2279.341]: eth0 sys offset -944724407 s0 freq -32767999 delay 1080 phc2sys[2279.442]: eth0 sys offset -1035512490 s0 freq -32767999 delay 1070 phc2sys[2279.543]: eth0 sys offset -1126373833 s0 freq -32767999 delay 1060 phc2sys[2279.644]: eth0 sys offset -1217189284 s0 freq -32767999 delay 1090 phc2sys[2279.745]: eth0 sys offset -1307049659 s0 freq -32767999 delay 1070 phc2sys[2279.855]: eth0 sys offset -1396908421 s1 freq -32767999 delay 1070 phc2sys[2279.956]: eth0 sys offset -99921060 s2 freq -32767999 delay 1070 phc2sys[2280.058]: eth0 sys offset -190802970 s2 freq -32767999 delay 1090 phc2sys[2280.159]: eth0 sys offset -281766043 s2 freq -32767999 delay 1060 phc2sys[2280.270]: eth0 sys offset -372705691 s2 freq -32767999 delay 1070 phc2sys[2280.372]: eth0 sys offset -472552450 s2 freq -32767999 delay 1070 phc2sys[2280.473]: eth0 sys offset -563478398 s2 freq -32767999 delay 1060 phc2sys[2280.585]: eth0 sys offset -654385481 s2 freq -32767999 delay 1080 phc2sys[2280.686]: eth0 sys offset -754228205 s0 freq -32767999 delay 1060 phc2sys[2280.787]: eth0 sys offset -845127878 s0 freq -32767999 delay 1060 phc2sys[2280.889]: eth0 sys offset -936027532 s0 freq -32767999 delay 1070 phc2sys[2280.990]: eth0 sys offset -1027032476 s0 freq -32767999 delay 1070 phc2sys[2281.091]: eth0 sys offset -1117894988 s0 freq -32767999 delay 1070 phc2sys[2281.193]: eth0 sys offset -1208718286 s0 freq -32767999 delay 1100 phc2sys[2281.294]: eth0 sys offset -1299525508 s0 freq -32767999 delay 1071 phc2sys[2281.404]: eth0 sys offset -1389388883 s1 freq -32767999 delay 1070 phc2sys[2281.506]: eth0 sys offset -99969360 s2 freq -32767999 delay 1070 phc2sys[2281.617]: eth0 sys offset -190863914 s2 freq -32767999 delay 1070 phc2sys[2281.729]: eth0 sys offset -290799101 s2 freq -32767999 delay 1060 phc2sys[2281.840]: eth0 sys offset -390680264 s2 freq -32767999 delay 1070 phc2sys[2281.951]: eth0 sys offset -490552209 s2 freq -32767999 delay 1070 phc2sys[2282.053]: eth0 sys offset -590477326 s2 freq -32767999 delay 1070 phc2sys[2282.154]: eth0 sys offset -681385110 s2 freq -32767999 delay 1060 phc2sys[2282.255]: eth0 sys offset -772268834 s0 freq -32767999 delay 1070 phc2sys[2282.357]: eth0 sys offset -863070173 s0 freq -32767999 delay 1070 phc2sys[2282.458]: eth0 sys offset -953858301 s0 freq -32767999 delay 1070 phc2sys[2282.559]: eth0 sys offset -1044650817 s0 freq -32767999 delay 1090 phc2sys[2282.661]: eth0 sys offset -1135569361 s0 freq -32767999 delay 1080 phc2sys[2282.761]: eth0 sys offset -1225432924 s0 freq -32767999 delay 1070 phc2sys[2282.861]: eth0 sys offset -1315298084 s0 freq -32767999 delay 1080 phc2sys[2282.971]: eth0 sys offset -1405156561 s1 freq -32767999 delay 1070 phc2sys[2283.073]: eth0 sys offset -100126120 s2 freq -32767999 delay 1100 phc2sys[2283.184]: eth0 sys offset -191017697 s2 freq -32767999 delay 1100 phc2sys[2283.296]: eth0 sys offset -290919211 s2 freq -32767999 delay 1070 phc2sys[2283.407]: eth0 sys offset -390755176 s2 freq -32767999 delay 1080 phc2sys[2283.508]: eth0 sys offset -490592010 s2 freq -32767999 delay 1060 phc2sys[2283.610]: eth0 sys offset -581472223 s2 freq -32767999 delay 1060 phc2sys[2283.711]: eth0 sys offset -672315176 s2 freq -32767999 delay 1070 phc2sys[2283.812]: eth0 sys offset -763194888 s0 freq -32767999 delay 1080 phc2sys[2283.912]: eth0 sys offset -853081478 s0 freq -32767999 delay 1060 phc2sys[2284.013]: eth0 sys offset -942950125 s0 freq -32767999 delay 1060 phc2sys[2284.113]: eth0 sys offset -1032825701 s0 freq -32767999 delay 1060 phc2sys[2284.213]: eth0 sys offset -1122694428 s0 freq -32767999 delay 1080 phc2sys[2284.313]: eth0 sys offset -1212556983 s0 freq -32767999 delay 1090 If I use the command phc_ctl /dev/ptp0 set, that works correctly, and the phc clock sets to the system clock. I don't know where the problem is, and I am stuck at this point for a long time, so if there is anybody who knows how to solve this please help. Best regards, Nemanja Koprena |
|
From: Mikael A. <mik...@ar...> - 2021-11-18 09:24:29
|
Hi,
We have been using the gPTP.cfg for a while now to synchronize an embedded linux product with either a PC running linuxptp or a dedicated time server synched to GNSS.
In order to ensure that the time synchronization works we have monitored the portState, master_offset and gmPresent fields using pmc in the embedded system.
In order to consider an end station to be in good shape we have required that portState == SLAVE && gmPresent == true && master_offset < MAX_ALLOWED_MASTER_OFFSET
This is an example output with the gPTP.cfg:
sending: GET TIME_STATUS_NP
24d76b.fffe.000776-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 103
ingress_time 1637221740828303224
cumulativeScaledRateOffset -0.000000007
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity 78d004.fffe.277c58
78d004.fffe.277c58-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 0
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent false
gmIdentity 78d004.fffe.277c58
Now we have introduced another setup where we have a third-party high capacity data logger acting as a bridge between the time server and a number of embedded systems. This bridge also runs linuxptp but uses the automotive profile. In this setup we no longer get gmPresent true (and gmIdentity is the local clock), but the end stations still seem to be in sync with the time server. This is also the case when using the automotive profile in the original setup (PC -> embedded system).
The output from pmc when running the automotive-slave.cfg is now:
sending: GET TIME_STATUS_NP
24d76b.fffe.000776-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset -78
ingress_time 1637222317034857054
cumulativeScaledRateOffset +0.000000009
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent false
gmIdentity 24d76b.fffe.000776
78d004.fffe.277c58-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 0
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent false
gmIdentity 78d004.fffe.277c58
1. Is this the expected behavior when using the automotive profile (especially the inhibit_announce option set to true)?
2. Is there a recommended way to monitor the end-stations as our earlier approach might not be the best, especially when introducing bridges?
We want to ensure that the end-stations are synchronized to the dedicated time server and that the accuracy is at least X microseconds.
Best regards,
Mikael Arvids
***************************************************************
To read the Company's Information and Confidentiality Notice, follow this link:
https://www.arriver.com/important-information-and-confidentiality-notice
***************************************************************
|
|
From: Ed B. <br...@ar...> - 2021-11-12 17:36:18
|
On 11/12/21 11:09, Vladimir Oltean wrote: > To be honest with you, I'm a bit concerned that it still won't work as > intended even if I remove the error from posix_clock_add(). This is > because find_dst_clock() from phc2sys finds clocks by phc_index. When > you run phc2sys between this /dev/ptp_kvm and CLOCK_REALTIME, I think it > might happen for this function to find the unintended clock, since both > of them have clock->phc_index = -1. > I tried phc2sys training my clock (with the symlink name changed) from CLOCK_REALTIME, and I don't see that problem. It appears to work fine and the associated message "skipping %s: %s has the same clock and is already selected" does not appear in the output. - Ed Branch |
|
From: Vladimir O. <ol...@gm...> - 2021-11-12 17:09:43
|
On Fri, Nov 12, 2021 at 10:45:53AM -0600, Ed Branch wrote:
> On 11/12/21 10:36, Vladimir Oltean wrote:
> >
> > What is your use case for the char device symlinks exactly? The
> > canonical way of finding the PTP char device corresponding to an
> > interface is to use "ethtool -T eth0 | grep 'PTP Hardware Clock'".
> >
>
> There is no network interface associated with this clock. Similar to the
> following from the stock Debian 10 entry in
> /lib/udev/rules.d/50-udev-default.rules:
>
> SUBSYSTEM=="ptp", ATTR{clock_name}=="KVM virtual PTP", SYMLINK += "ptp_kvm"
To be honest with you, I'm a bit concerned that it still won't work as
intended even if I remove the error from posix_clock_add(). This is
because find_dst_clock() from phc2sys finds clocks by phc_index. When
you run phc2sys between this /dev/ptp_kvm and CLOCK_REALTIME, I think it
might happen for this function to find the unintended clock, since both
of them have clock->phc_index = -1.
|
|
From: Ed B. <br...@ar...> - 2021-11-12 16:46:03
|
On 11/12/21 10:36, Vladimir Oltean wrote:
>
> What is your use case for the char device symlinks exactly? The
> canonical way of finding the PTP char device corresponding to an
> interface is to use "ethtool -T eth0 | grep 'PTP Hardware Clock'".
>
There is no network interface associated with this clock. Similar to the
following from the stock Debian 10 entry in
/lib/udev/rules.d/50-udev-default.rules:
SUBSYSTEM=="ptp", ATTR{clock_name}=="KVM virtual PTP", SYMLINK += "ptp_kvm"
- Ed Branch
|
|
From: Vladimir O. <ol...@gm...> - 2021-11-12 16:37:09
|
On Fri, Nov 12, 2021 at 10:27:06AM -0600, Ed Branch wrote: > On 11/11/21 17:28, Ed Branch wrote: > > > > Thanks for the quick reply. Understood, digging this out properly (ie. > > finding the /sys/class/ptp/ptp*/dev file with a matching minor to that > > of the device node) would add a lot of complexity. However, looking at > > the alloc_chardev_region() call in the ptp driver > > (drivers/ptp/ptp_clock.c) reveals the first minor in the requested range > > is always 0, so it might be ok to assume the PHC index is just the > > device node minor. > > > > Of course your suggestion of just ignoring the failure in phc2sys would > > be enough to fix my use case too. > > > > Thanks again for looking at this, > > - Ed Branch > > Reading a bit further into posix_clock_open(...), I see it already relied on > existence of device nodes named "/dev/ptp#". If these have to exist anyway > then maybe there's no point accounting for other names. My actual failure is > because I access them through a symlink created by udev based on the > clock_name sysfs attribute. So simply resolving symlinks prior to the > existing logic would also work. > > For now, my workaround is to rename the symlinks so they do not match the > "/dev/ptp*" pattern. What is your use case for the char device symlinks exactly? The canonical way of finding the PTP char device corresponding to an interface is to use "ethtool -T eth0 | grep 'PTP Hardware Clock'". |
|
From: Ed B. <br...@ar...> - 2021-11-12 16:27:16
|
On 11/11/21 17:28, Ed Branch wrote: > > Thanks for the quick reply. Understood, digging this out properly (ie. > finding the /sys/class/ptp/ptp*/dev file with a matching minor to that > of the device node) would add a lot of complexity. However, looking at > the alloc_chardev_region() call in the ptp driver > (drivers/ptp/ptp_clock.c) reveals the first minor in the requested range > is always 0, so it might be ok to assume the PHC index is just the > device node minor. > > Of course your suggestion of just ignoring the failure in phc2sys would > be enough to fix my use case too. > > Thanks again for looking at this, > - Ed Branch Reading a bit further into posix_clock_open(...), I see it already relied on existence of device nodes named "/dev/ptp#". If these have to exist anyway then maybe there's no point accounting for other names. My actual failure is because I access them through a symlink created by udev based on the clock_name sysfs attribute. So simply resolving symlinks prior to the existing logic would also work. For now, my workaround is to rename the symlinks so they do not match the "/dev/ptp*" pattern. - Ed Branch |
|
From: Keller, J. E <jac...@in...> - 2021-11-12 00:47:36
|
On 11/11/2021 2:34 PM, Vladimir Oltean wrote: > On Thu, Nov 11, 2021 at 03:55:29PM -0600, Ed Branch wrote: >> As of commit 380d023abb1fdce0dba9d58ca1abaf2e2de5488f PHC device nodes or >> symlinks named as "/dev/ptp*" where "*" is not a number cause phc2sys to >> fail with "failed to parse PHC index". Note however, if the filename does >> not match this pattern, it happily continues with no PHC index set. > > That would be me and my ts2phc patches. Sorry for that. Prior to that > change, posix_clock_open() used to simply not populate *phc_index when > passed a path to a PHC. I don't think there's any kernel API to deduce > the PHC number using ioctls on the char device itself, so for my use > case it would be pretty odd to have a PTP device named differently than > /dev/ptpN. Nonetheless, phc2sys does not need to know the exact number > of the PTP clock, and therefore, what I can do is move the error one > level upper, at the caller. I'll try to come up with a patch tomorrow. > There aren't any methods right now, but it is something I have felt would be useful in the past. Perhaps we can add a new field to the PTP_CLOCK_GETCAPS2 ioctl? Or add a new IOCTL which gets this data? I think that would be helpful for more than just this case. Thanks, Jake |
|
From: Ed B. <br...@ar...> - 2021-11-11 23:28:12
|
On 11/11/21 16:34, Vladimir Oltean wrote: > That would be me and my ts2phc patches. Sorry for that. Prior to that > change, posix_clock_open() used to simply not populate *phc_index when > passed a path to a PHC. I don't think there's any kernel API to deduce > the PHC number using ioctls on the char device itself, so for my use > case it would be pretty odd to have a PTP device named differently than > /dev/ptpN. Nonetheless, phc2sys does not need to know the exact number > of the PTP clock, and therefore, what I can do is move the error one > level upper, at the caller. I'll try to come up with a patch tomorrow. > Thanks for the quick reply. Understood, digging this out properly (ie. finding the /sys/class/ptp/ptp*/dev file with a matching minor to that of the device node) would add a lot of complexity. However, looking at the alloc_chardev_region() call in the ptp driver (drivers/ptp/ptp_clock.c) reveals the first minor in the requested range is always 0, so it might be ok to assume the PHC index is just the device node minor. Of course your suggestion of just ignoring the failure in phc2sys would be enough to fix my use case too. Thanks again for looking at this, - Ed Branch |
27 messages has been excluded from this view by a project administrator.
