linuxptp-users Mailing List for linuxptp (Page 26)
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: Miroslav L. <mli...@re...> - 2022-07-13 10:08:53
|
On Wed, Jul 13, 2022 at 09:29:46AM +0000, joy...@ar... wrote: > Dear Miroslav, > > Certainly, I have attached packet captures from both cases (controlField 0 and controlField 5). The captures show other differences than the controlField. The most suspicious is priority1. It is 0 in the working case and 128 in the failing case. Have you tried changing that? -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2022-07-13 08:18:56
|
(I didn't receive the original messages from the list) > On Fri, Jul 08, 2022 at 01:08:04AM +0000, joy...@ar... wrote: > > However, it does send delay requests to the GM. > > Upon close inspection, it turns out that the unless the 'Announce' message control field value is set to '5', the slave does not accept GM as master. If it's sending delay requests to the server, it means it was already selected by the client. > > Is this a bug or can v3.1 be configured to ignore this field? I just did a test with 3.1 and a modified server sending announce messages with control of 0 and it works, even with dataset_comparison set to G.8275.x. It might help if you could provide a packet capture. -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2022-07-13 07:07:23
|
On Wed, Jul 13, 2022 at 01:28:18AM +0000, joy...@ar... wrote: > Even under the erroneous presumption that what you claim is correct, Sorry, I am going to ignore you now. As I said before, linuxptp ignores the control field, and so the control field difference, zero vs five, is likely a red herring. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2022-07-13 07:01:12
|
On Wed, Jul 13, 2022 at 01:28:18AM +0000, joy...@ar... wrote: > Attached PDF document " IEEE Standard for a Precision Clock > Synchronization Protocol for Networked Measurement and Control > Systems" from the " IEEE Instrumentation and Measurement Society" > for your perusal. Please refer to Page 221. In the future, please do NOT post copyrighted material to this list that is not freely distributable! Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2022-07-12 20:52:10
|
On Tue, Jul 12, 2022 at 02:29:22AM +0000, joy...@ar... wrote: > Therefore, there is no such thing as an 'incorrect value' for the control field as long as it is PTP V2. You are mistaken. Please read IEEE 1588. You will find the following specification: 13.3.2.10 controlField (UInteger8) The value of controlField depends on the message type defined in the messageType field (see 13.3.2.2) and shall have the value specified in Table 23. - IEEE 1588-2008 page 127 The word "shall" has a specific meaning in 1588: 4.2 Word usage 4.2.1 Shall The word "shall," which is equivalent to "is required to," is used to indicate mandatory requirements, strictly to be followed in order to conform to the standard and from which no deviation is permitted. - IEEE 1588-2008 page 9 So setting Announce.control to value 5 is a mandatory requirement. > The GM has been tested by Calnex too, so conformance is not an issue here. I can't answer for Calnex, but it is too bad that they allow such non-conformance to go undeteced. Thanks, Richard |
|
From: ramesh t <ram...@ya...> - 2022-07-12 17:36:51
|
Hello, Have connected Server to a switch. The switch act as a Boundary clock and provides timing to the server using ptp. On the server, we are running ptp4l and phc2sys process. As part of testing, we are doing disable and enable of PTP on the switch. Sometimes we are observing phc2sys process struck on "Waiting for ptp4l". Please let me know if this is fixed in latest releases? regards, Ramesh Jun 30 15:56:16 ptp4l: [113392.006] handle_state_decision_event PS_SLAVE Jun 30 15:56:16 ptp4l: [113392.006] port 1: LISTENING to UNCALIBRATED on RS_SLAVE Jun 30 15:56:16 ptp4l: [113392.006] PS_SLAVE: port_e2e_transition Jun 30 15:56:16 ptp4l: [113392.126] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED Jun 30 15:56:16 ptp4l: [113392.126] PS_SLAVE: port_e2e_transition Jun 30 15:56:17 ptp4l: [113393.006] rms 1059386 max 2163105 freq -2207284 +/- 920482 delay -41410 +/- 25811 Jun 30 15:56:17 ptp4l: [113393.261] selected best master clock 40b5c1.fffe.7b083f Jun 30 15:56:17 ptp4l: [113393.261] handle_state_decision_event PS_SLAVE Jun 30 15:56:18 ptp4l: [113394.006] rms 397954 max 489864 freq -407181 +/- 377766 delay -13706 +/- 7315 Jun 30 15:56:19 ptp4l: [113395.006] rms 376195 max 475259 freq +255291 +/- 51294 delay 1286 +/- 1440 Jun 30 15:56:20 ptp4l: [113396.006] rms 127843 max 219841 freq +205626 +/- 48533 delay 3164 +/- 594 Jun 30 15:56:21 ptp4l: [113397.006] rms 19534 max 29511 freq +57700 +/- 31071 delay 1541 +/- 934 Jun 30 15:56:22 ptp4l: [113398.006] rms 27033 max 30256 freq -5731 +/- 7417 delay 227 +/- 124 Jun 30 15:56:23 ptp4l: [113399.006] rms 11949 max 18787 freq -10217 +/- 2374 delay -99 +/- 64 Jun 30 15:56:24 ptp4l: [113400.006] rms 1772 max 3816 freq -848 +/- 2494 delay 99 +/- 51 Jun 30 15:56:25 ptp4l: [113401.006] rms 1794 max 1914 freq +4826 +/- 825 delay 213 +/- 20 Jun 30 15:56:26 ptp4l: [113402.006] rms 1056 max 1526 freq +5878 +/- 84 delay 247 +/- 5 Jun 30 15:56:26 ptp4l: [113402.126] EV_STATUS_REPORT_TIMEOUT_EXPIRES Jun 30 15:56:27 ptp4l: [113403.006] rms 229 max 454 freq +5348 +/- 179 delay 247 +/- 3 Jun 30 15:56:28 ptp4l: [113404.010] rms 103 max 122 freq +4892 +/- 80 delay 234 +/- 3 Jun 30 15:56:29 ptp4l: [113405.006] rms 90 max 115 freq +4747 +/- 11 delay 232 +/- 1 Jun 30 15:56:30 ptp4l: [113406.006] rms 26 max 50 freq +4772 +/- 14 delay 231 +/- 1 Jun 30 15:56:31 ptp4l: [113407.006] rms 8 max 15 freq +4811 +/- 10 delay 232 +/- 0 Jun 30 15:56:32 ptp4l: [113408.006] rms 9 max 17 freq +4827 +/- 6 delay 232 +/- 1 Jun 30 15:56:33 ptp4l: [113409.006] rms 5 max 11 freq +4826 +/- 7 delay 232 +/- 1 Jun 30 15:56:34 ptp4l: [113410.006] rms 3 max 6 freq +4824 +/- 5 delay 233 +/- 1 Jun 30 15:56:35 ptp4l: [113411.006] rms 3 max 7 freq +4825 +/- 6 delay 232 +/- 0 Jun 30 15:56:36 ptp4l: [113412.006] rms 3 max 5 freq +4824 +/- 6 delay 232 +/- 1 Jun 30 15:56:37 ptp4l: [113413.006] rms 3 max 6 freq +4823 +/- 5 delay 232 +/- 0 Jun 30 15:56:38 ptp4l: [113414.006] rms 3 max 6 freq +4820 +/- 5 delay 232 +/- 0 Jun 30 15:56:39 ptp4l: [113415.006] rms 3 max 6 freq +4821 +/- 5 delay 232 +/- 1 Jun 30 15:56:40 ptp4l: [113416.006] rms 3 max 6 freq +4821 +/- 5 delay 233 +/- 1 Jun 30 15:56:41 ptp4l: [113417.006] rms 3 max 7 freq +4821 +/- 5 delay 233 +/- 1 Jun 30 15:56:42 ptp4l: [113418.006] rms 4 max 6 freq +4822 +/- 6 delay 232 +/- 0 Jun 30 15:56:43 ptp4l: [113419.006] rms 3 max 6 freq +4817 +/- 5 delay 232 +/- 0 Jun 30 15:56:44 phc2sys: [113419.955] uds: sendto failed: No such file or directory Jun 30 15:56:44 ptp4l: [113420.010] rms 3 max 6 freq +4818 +/- 5 delay 232 +/- 0 Jun 30 15:56:45 phc2sys: [113420.959] Waiting for ptp4l... Jun 30 15:56:45 phc2sys: [113420.959] uds: sendto failed: No such file or directory Jun 30 15:56:45 ptp4l: [113421.006] rms 3 max 6 freq +4816 +/- 5 delay 232 +/- 0 Jun 30 15:56:46 phc2sys: [113421.962] Waiting for ptp4l... Jun 30 15:56:46 phc2sys: [113421.962] uds: sendto failed: No such file or directory Jun 30 15:56:46 ptp4l: [113422.006] rms 4 max 6 freq +4810 +/- 5 delay 232 +/- 0 Jun 30 15:56:47 phc2sys: [113422.963] Waiting for ptp4l... Jun 30 15:56:47 phc2sys: [113422.963] uds: sendto failed: No such file or directory Jun 30 15:56:47 ptp4l: [113423.006] rms 3 max 5 freq +4809 +/- 5 delay 232 +/- 0 Jun 30 15:56:48 phc2sys: [113423.966] Waiting for ptp4l... Jun 30 15:56:48 phc2sys: [113423.966] uds: sendto failed: No such file or directory Jun 30 15:56:48 ptp4l: [113424.006] rms 4 max 9 freq +4815 +/- 6 delay 232 +/- 1 Jun 30 15:56:49 phc2sys: [113424.967] Waiting for ptp4l... Jun 30 15:56:49 phc2sys: [113424.967] uds: sendto failed: No such file or directory Jun 30 15:56:49 ptp4l: [113425.006] rms 3 max 6 freq +4815 +/- 5 delay 232 +/- 0 Jun 30 15:56:50 phc2sys: [113425.971] Waiting for ptp4l... Jun 30 15:56:50 phc2sys: [113425.971] uds: sendto failed: No such file or directory |
|
From: Richard C. <ric...@gm...> - 2022-07-11 10:05:10
|
On Mon, Jul 11, 2022 at 01:42:14AM +0000, joy...@ar... wrote: > Slave is running ptp4l, GM is running custom time-sync solution > (G8275.1). GM has already been tested with Calnex Paragon Neo and > has passed the test so compliance with 1588 should not be the issue > here. How can it pass when sending incorrect values in the control field? > I have attached the 'Announce' messages from both CTL0 and > CTL5 tests. However, this issue is with linuxptp v3.1. Once we > change to master branch, this issue does not happen. Please bisect to find the offending commit. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2022-07-11 07:36:29
|
On Mon, Jul 11, 2022 at 09:06:12AM +0200, Marco Davids (SIDN) via Linuxptp-users wrote: > Op 09-07-2022 om 08:44 schreef Maciek Machnikowski: > > > The ntpshm servo will put results in the shm and let the other entity > > to control the clock - hence it doesn't lock itself and always returns the > > SERVO_UNLOCKED. > > Right. To expand a bit on this, there is no information provided back to ptp4l/phc2sys about the state of the clock from the consumer, or whether the samples are actually accepted and used for synchronization. > > I'd recommend setting up ptp4l with one of regular > > servos and use the phc2sys to transfer the offset to the NTP daemon. > > But that wouldn't work iwith software time stamping, would it? It wouldn't. phc2sys is needed when ptp4l synchronizes a PHC. With software timestamping it should be ptp4l using the ntpshm servo. -- Miroslav Lichvar |
|
From: Marco D. (SIDN) <mar...@si...> - 2022-07-11 07:22:00
|
Hi Maciek, Op 09-07-2022 om 08:44 schreef Maciek Machnikowski: > The ntpshm servo will put results in the shm and let the other entity > to control the clock - hence it doesn't lock itself and always returns the > SERVO_UNLOCKED. Right. > I'd recommend setting up ptp4l with one of regular > servos and use the phc2sys to transfer the offset to the NTP daemon. But that wouldn't work iwith software time stamping, would it? Thanks. -- Marco >> -----Original Message----- >> From: Marco Davids (SIDN) via Linuxptp-users <linuxptp- >> us...@li...> >> Sent: Friday, July 8, 2022 11:04 PM >> To: lin...@li... >> Subject: [Linuxptp-users] clock_servo ntpshm question >> >> Hi, >> >> So, I decided to configure 'clock_servo ntpshm' to use LinuxPTP as a 'refclock' >> for an NTP-daemon on a server with software time stamping. >> >> And it appeared to worked well, until I looked a bit closer. >> >> I noticed that with 'ntpshm' the servo state remains 's0' and the port state >> remains UNCALIBRATED. >> >> By choosing 'linreg' and enable the 'local' refclock in NTP I got it working as >> expected, but I find this a suboptimal solution. >> >> So, I would like to understand why ptp4l won't move to 's2' / SLAVE status in >> servo_clock ntpshm mode. >> >> Anyone? >> >> Thanks! >> >> -- >> Marco > |
|
From: Richard C. <ric...@gm...> - 2022-07-10 11:49:23
|
On Fri, Jul 08, 2022 at 01:08:04AM +0000, joy...@ar... wrote: > Hi, > > Using a binary built on v3.1, I'm trying to synchronize a Slave > device with a Grandmaster but the Slave does not accept the > Grandmaster as Master. It does not lock or synchronize either. Which node is running ptp4l? GM, slave, or both? > However, it does send delay requests to the GM. > Upon close inspection, it turns out that the unless the 'Announce' message control field value is set to '5', the slave does not accept GM as master. > Announce message(Control Field 0): Master ignored > Announce message (Control Field 5): Master accepted > Dataset comparison set to G8275.x for both, all other slave and master configurations identical for both scenarios. > This is puzzling since PTPV2(which 3.1 is based on) should not use this field for BMCA, as far as I know, only PTPV1 uses this field. > Is this a bug or can v3.1 be configured to ignore this field? If ptp4l is GM and your slave is some other stack, then that stack does not follow 1588 correctly. If ptp4l is the slave, then you are mistaken in your analysis. The control field is set for transmitted messages, but never tested on recieved messages: Cscope finding symbol "control" yields: *** nsm.c: nsm_request[398] msg->header.control = CTL_DELAY_REQ; *** pmc_common.c: pmc_message[453] msg->header.control = CTL_MANAGEMENT; *** port.c: port_pdelay_request[1353] msg->header.control = CTL_OTHER; port_delay_request[1417] msg->header.control = CTL_DELAY_REQ; port_tx_announce[1469] msg->header.control = CTL_OTHER; port_tx_sync[1546] msg->header.control = CTL_SYNC; port_tx_sync[1582] fup->header.control = CTL_FOLLOW_UP; process_delay_req[1914] msg->header.control = CTL_DELAY_RESP; process_pdelay_req[2105] rsp->header.control = CTL_OTHER; process_pdelay_req[2153] fup->header.control = CTL_OTHER; port_management_construct[2929] msg->header.control = CTL_MANAGEMENT; *** port_signaling.c: port_signaling_construct[49] msg->header.control = CTL_OTHER; *** tc.c: tc_fwd_sync[459] fup->header.control = CTL_FOLLOW_UP; TL;DR -- header.control is never used for anything. Thanks, Richard |
|
From: Maciek M. <ma...@ma...> - 2022-07-09 06:44:39
|
The ntpshm servo will put results in the shm and let the other entity to control the clock - hence it doesn't lock itself and always returns the SERVO_UNLOCKED. I'd recommend setting up ptp4l with one of regular servos and use the phc2sys to transfer the offset to the NTP daemon. Regards Maciek > -----Original Message----- > From: Marco Davids (SIDN) via Linuxptp-users <linuxptp- > us...@li...> > Sent: Friday, July 8, 2022 11:04 PM > To: lin...@li... > Subject: [Linuxptp-users] clock_servo ntpshm question > > Hi, > > So, I decided to configure 'clock_servo ntpshm' to use LinuxPTP as a 'refclock' > for an NTP-daemon on a server with software time stamping. > > And it appeared to worked well, until I looked a bit closer. > > I noticed that with 'ntpshm' the servo state remains 's0' and the port state > remains UNCALIBRATED. > > By choosing 'linreg' and enable the 'local' refclock in NTP I got it working as > expected, but I find this a suboptimal solution. > > So, I would like to understand why ptp4l won't move to 's2' / SLAVE status in > servo_clock ntpshm mode. > > Anyone? > > Thanks! > > -- > Marco |
|
From: Maciek M. <ma...@ma...> - 2022-07-09 06:41:01
|
Nope, I think it's more about the clock_servo option. Free-running will not do anything to the clock. clock_servo The servo which is used to synchronize the local clock. Valid values are [...] "nullf" for a servo thatalways dials frequency offset zero (for use in SyncE nodes). Regards Maciek > -----Original Message----- > From: Gao Meitao（高玫涛） <mei...@as...> > Sent: Friday, July 8, 2022 5:05 AM > To: Richard Cochran <ric...@gm...> > Cc: lin...@li... > Subject: [Linuxptp-users] 答复: 答复: PTP > > Richard: > You mean free_running paremter ? I check source code of ptp, found that > clock sync only use clockadj_set_freq function. > > > Thanks. > > -----邮件原件----- > 发件人: Richard Cochran [mailto:ric...@gm...] > 发送时间: 2022年7月8日 8:27 > 收件人: Gao Meitao（高玫涛） <mei...@as...> > 抄送: lin...@li... > 主题: Re: 答复: [Linuxptp-users] PTP > > On Thu, Jul 07, 2022 at 01:52:32AM +0000, Gao Meitao（高玫涛） wrote: > > Does ptp4l has a feather that only adjust time offset not freq ? > > Yes, see the man page. > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Marco D. (SIDN) <mar...@si...> - 2022-07-08 22:46:41
|
Hi, So, I decided to configure 'clock_servo ntpshm' to use LinuxPTP as a 'refclock' for an NTP-daemon on a server with software time stamping. And it appeared to worked well, until I looked a bit closer. I noticed that with 'ntpshm' the servo state remains 's0' and the port state remains UNCALIBRATED. By choosing 'linreg' and enable the 'local' refclock in NTP I got it working as expected, but I find this a suboptimal solution. So, I would like to understand why ptp4l won't move to 's2' / SLAVE status in servo_clock ntpshm mode. Anyone? Thanks! -- Marco |
|
From: Gao Meitao（高. <mei...@as...> - 2022-07-08 03:05:29
|
Richard:
You mean free_running paremter ? I check source code of ptp, found that clock sync only use clockadj_set_freq function.
Thanks.
-----邮件原件-----
发件人: Richard Cochran [mailto:ric...@gm...]
发送时间: 2022年7月8日 8:27
收件人: Gao Meitao（高玫涛） <mei...@as...>
抄送: lin...@li...
主题: Re: 答复: [Linuxptp-users] PTP
On Thu, Jul 07, 2022 at 01:52:32AM +0000, Gao Meitao（高玫涛） wrote:
> Does ptp4l has a feather that only adjust time offset not freq ?
Yes, see the man page.
|
|
From: Richard C. <ric...@gm...> - 2022-07-08 00:27:37
|
On Thu, Jul 07, 2022 at 01:52:32AM +0000, Gao Meitao（高玫涛） wrote: > Does ptp4l has a feather that only adjust time offset not freq ? Yes, see the man page. |
|
From: Gao Meitao（高. <mei...@as...> - 2022-07-07 02:01:29
|
Hi Richard:
We use Arasan GEMAC-1588-AVB， clock control looks like simple, a fix 100M clock as input, you could change Increment Attributes Register for ethernet system timer
I think it doen't have fine freq adjustment. So this should be reason?
Register settting example
• If the Increment Value is 10 and the Increment Period is 1, a value of 10 is added to
the counter every clock. This gives a counter operating at nanosecond resolution and
counts time in terms of nanoseconds.
• If the Increment Value is 100 and the Increment Period is 1, a value of 100 is added
to the counter every clock. This gives a counter operating at 0.1 ns resolution and
counts time in terms of 0.1 ns.
Timestamping generate by hardware, be save by register, driver read tx/rx timestamp then pass them to application.
Does ptp4l has a feather that only adjust time offset not freq ?
Thans for your reply .
-----邮件原件-----
发件人: Richard Cochran [mailto:ric...@gm...]
发送时间: 2022年7月6日 22:01
收件人: Gao Meitao（高玫涛） <mei...@as...>
抄送: lin...@li...
主题: Re: [Linuxptp-users] PTP
On Wed, Jul 06, 2022 at 06:07:40AM +0000, Gao Meitao（高玫涛） wrote:
> Hi all:
>
> I try to test ptp as slave for my evb borad, and found that it seem not work properly , as you can see from below logs
> First run, it seem be out of control by ptp, after run again, thing seem work fine.
>
> Any suggestion about this ? thanks in advance
What device is that?
Check the implementation of the hardware and of the device driver WRT:
1. clock control
2. time stamp generation + reporting
Good luck,
Richard
|
|
From: Jacob K. <jac...@in...> - 2022-07-06 19:05:39
|
Hi, On 6/7/2022 7:54 AM, Mehmet Akbulut wrote: > Hello, > > We see that if a 'certain' process is running, it causes ptp4l to switch > into faulty state at some point. After that, phc2sys never syncs back to > ptp4l. > I'm sorry to hear this. > This certain process is a proprietary application running as > non-root/unprivileged but, at a very high level, it receives UDP > packets, transforms the data, sends TCP packets. It does not perform any > high frequency scheduling or other unusual activity. The CPU load from > this application is 50-70%. We have verified that simply running a CPU > stress test with 100% load does not cause ptp4l to go into this faulty > state so we don't think CPU load is a contributor by itself. > Sure. Does this application request Tx timestamps? > We have also tried to increase `tx_timestamp_timeout` to 10ms but same > behavior was observed. Network driver is `ixgbe` on Linux kernel 5.4. > ixgbe only supports a single outgoing Tx timestamp per interface at a time. Multiple applications attempting to issue Tx timestamps could interfere with each other. As far as I know there's no lock or indication to the application that its Tx timestamp was ignored. > We are looking for any pointers to help resolve this issue and > especially figure out what's causing this transition to faulty state. > Can you gather the output of ethtool -S? It should have tx_hwtstamp_timeouts and tx_hwtstamp_skipped statistics. Are either of those incrementing? Thanks, Jake |
|
From: Richard C. <ric...@gm...> - 2022-07-06 14:00:51
|
On Wed, Jul 06, 2022 at 06:07:40AM +0000, Gao Meitao（高玫涛） wrote: > Hi all: > > I try to test ptp as slave for my evb borad, and found that it seem not work properly , as you can see from below logs > First run, it seem be out of control by ptp, after run again, thing seem work fine. > > Any suggestion about this ? thanks in advance What device is that? Check the implementation of the hardware and of the device driver WRT: 1. clock control 2. time stamp generation + reporting Good luck, Richard |
|
From: Gao Meitao（高. <mei...@as...> - 2022-07-06 06:30:10
|
Hi all:
I try to test ptp as slave for my evb borad, and found that it seem not work properly , as you can see from below logs
First run, it seem be out of control by ptp, after run again, thing seem work fine.
Any suggestion about this ? thanks in advance
sh-4.4# ptp4l -i eth0 -m -s
ptp4l[113.936]: selected /dev/ptp0 as PTP clock
ptp4l[113.938]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[113.938]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[113.938]: port 1: link up
ptp4l[114.611]: port 1: new foreign master 3c7c3f.fffe.52836b-1
ptp4l[118.611]: selected best master clock 3c7c3f.fffe.52836b
ptp4l[118.612]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[120.924]: master offset 4892970 s0 freq +0 path delay 10137
ptp4l[121.924]: master offset 4891972 s1 freq -998 path delay 10184
ptp4l[123.925]: master offset 205043608 s2 freq +62500000 path delay -5057707
ptp4l[123.925]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[124.925]: master offset 305049479 s2 freq +62500000 path delay -5057707
ptp4l[125.925]: master offset 410122852 s2 freq +62500000 path delay -10125551
ptp4l[126.925]: master offset 510000365 s2 freq +62500000 path delay -9996884
ptp4l[127.925]: master offset 614778485 s2 freq +62500000 path delay -14769127
ptp4l[128.925]: master offset 719428102 s2 freq +62500000 path delay -19412703
ptp4l[129.925]: master offset 819434760 s2 freq +62500000 path delay -19412703
ptp4l[130.925]: master offset 925152988 s2 freq +62500000 path delay -25124444
ptp4l[131.925]: master offset 1025158638 s2 freq +62500000 path delay -25124444
ptp4l[132.925]: master offset 1134366095 s2 freq +62500000 path delay -34325912
ptp4l[133.925]: master offset 1231821341 s2 freq +62500000 path delay -31775534
ptp4l[134.925]: master offset 1326115786 s2 freq +62500000 path delay -26063793
ptp4l[135.925]: master offset 1426121794 s2 freq +62500000 path delay -26063793
ptp4l[136.925]: master offset 1526127707 s2 freq +62500000 path delay -26063793
^Csh-4.4# ptp4l -i eth0 -m -s
ptp4l[138.552]: selected /dev/ptp0 as PTP clock
ptp4l[138.553]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[138.554]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[138.554]: port 1: link up
ptp4l[138.612]: port 1: new foreign master 3c7c3f.fffe.52836b-1
ptp4l[142.612]: selected best master clock 3c7c3f.fffe.52836b
ptp4l[142.612]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[143.926]: master offset -4290093738 s0 freq +62500000 path delay 10104
ptp4l[144.926]: master offset -4290094645 s1 freq +62499150 path delay 10136
ptp4l[145.926]: master offset -1045 s2 freq +62498105 path delay 10136
ptp4l[145.926]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[146.926]: master offset -1705 s2 freq +62497131 path delay 10136
ptp4l[147.926]: master offset -2637 s2 freq +62495688 path delay 10143
ptp4l[148.926]: master offset -3673 s2 freq +62493861 path delay 10183
ptp4l[149.926]: master offset -4483 s2 freq +62491949 path delay 10143
ptp4l[150.926]: master offset -5298 s2 freq +62489789 path delay 10183
ptp4l[151.927]: master offset -6344 s2 freq +62487153 path delay 10183
ptp4l[152.927]: master offset -7228 s2 freq +62484366 path delay 10157
ptp4l[153.927]: master offset -8000 s2 freq +62481426 path delay 10139
ptp4l[154.927]: master offset -9057 s2 freq +62477969 path delay 10180
ptp4l[155.927]: master offset -9752 s2 freq +62474557 path delay 10180
ptp4l[156.927]: master offset -10690 s2 freq +62470693 path delay 10133
ptp4l[157.927]: master offset -11519 s2 freq +62466657 path delay 10111
ptp4l[158.927]: master offset -12389 s2 freq +62462331 path delay 10111
ptp4l[159.927]: master offset -13234 s2 freq +62457770 path delay 10101
ptp4l[160.927]: master offset -14085 s2 freq +62452949 path delay 10082
ptp4l[161.927]: master offset -14991 s2 freq +62447817 path delay 10082
ptp4l[162.927]: master offset -15970 s2 freq +62442341 path delay 10101
ptp4l[163.927]: master offset -16857 s2 freq +62436663 path delay 10098
ptp4l[164.927]: master offset -17732 s2 freq +62430731 path delay 10098
ptp4l[165.927]: master offset -18523 s2 freq +62424620 path delay 10073
ptp4l[166.928]: master offset -19340 s2 freq +62418246 path delay 10080
ptp4l[167.928]: master offset -20225 s2 freq +62411559 path delay 10080
ptp4l[168.928]: master offset -21201 s2 freq +62404516 path delay 10080
|
|
From: Richard C. <ric...@gm...> - 2022-06-30 03:15:34
|
On Wed, Jun 29, 2022 at 12:29:16PM +0200, Miroslav Lichvar wrote: > If I understand it correctly, it's about exchanging hidden information > for controlling botnets etc. In PTP it could be in the timestamps, > sequence numbers and other fields in the header, or TLVs. It cannot be > prevented. Yeah. I mean, the protocol requires ignoring unrecognized TLVs, and TCs will just forward those without question. Thanks, Richard |
|
From: Deshpande, Y. <yas...@tu...> - 2022-06-29 14:29:47
|
> PPS signal is the best way. I think it is also "easy" because it removes the guesswork. Thanks a lot. Is there any source on how to enable the PPS output on the SDP pins and loop it back into the same NICs SDP inputs? My plan is this: 1) enable PPS output from port1 to SDP0 2) Then loopback a single wire from SDP0 of port1 to SDP0 of port2. 3) Run ts2phc for port2 in free-running mode. This should give me the fixed offset I mentioned in the first message of the thread. Also my two options are: ./ts2phc --free_running=1 -c enp2s0f0 -s enp2s0f1 ./ts2phc --free_running=1 -c enp2s0f0 -s generic but I am not sure which one is the correct one. Do I need to change my igb driver from the default one being able to enable pps input/output? Can step 1 be done by ts2phc or should I do it before running ts2phc? I tried a dry run of ts2phc and it failed with the following error: ts2phc[100692.637]: PTP_EXTTS_REQUEST2 failed: Invalid argument ts2phc[100692.637]: PTP_EXTTS_REQUEST2 failed: Invalid argument failed to arm PPS sinks ts2phc[100692.637]: PTP_EXTTS_REQUEST2 failed: Invalid argument is it because of the wrong igb driver or not having done step 1 or is it another problem altogether? Best Regards, Yash ________________________________ From: Richard Cochran <ric...@gm...> Sent: Tuesday, June 28, 2022 4:09:04 PM To: Deshpande, Yash Cc: Miroslav Lichvar; lin...@li... Subject: Re: [Linuxptp-users] Finding the Fixed offset between two Ports of the same NIC. On Tue, Jun 28, 2022 at 01:30:32PM +0000, Deshpande, Yash wrote: > I would like to ask the second part of the question once again. I > dont wish to synchronize the two ports. I know that their relative > offset is constant as they are running on the same oscillator. This > is also reported by the ptp4l. I would just like to know this offset > without running ptp4l.Is there an easier way than PPS loopback? PPS signal is the best way. I think it is also "easy" because it removes the guess work. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2022-06-29 10:29:32
|
On Wed, May 25, 2022 at 08:12:49AM -0700, Richard Cochran wrote: > Abby, > > On Mon, May 23, 2022 at 01:27:29PM -0500, Abby Marsh wrote: > > I'm a researcher working on a project that's confirmed a viable covert > > channel in the current version of linuxptp. I'd like to report this; is it > > best to do so here, or on another list? > > What is a "viable covert channel", and why does it matter? If I understand it correctly, it's about exchanging hidden information for controlling botnets etc. In PTP it could be in the timestamps, sequence numbers and other fields in the header, or TLVs. It cannot be prevented. As PTP is not normally used over Internet, I'd expect any PTP message routed to Internet to trigger an alarm. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2022-06-29 07:09:05
|
On Tue, Jun 28, 2022 at 10:18:39AM -0400, Prottay Adhikari wrote: > Hi, > Thanks for the reply. As for your question ... > > What hardware does the VM emulate? > The details can be found here. > https://browser.geekbench.com/v4/cpu/compare/3910977?baseline=3910977 > <https://browser.geekbench.com/v4/cpu/compare/3910977?baseline=3910977> That doesn't show the network controller. Try "lspci | grep Ether". > > Maybe you could configure a different one? > I was hoping to avoid this solution. If we have to opt for a different > configuration anyway, is there a configuration you suggest? I don't know what options are there on Azure. Try something different than what you are using now. -- Miroslav Lichvar |
|
From: Prottay A. <pro...@gm...> - 2022-06-28 14:50:28
|
Hi, Thanks for the tip. I tried rebooting my VM. Unfortunately, it didn't work. *Prottay M. AdhikariDistributed Embedded Controls Specialist @* Eaton Center of Excellence *Ph.D. *(Electrical Engineering, Rensselaer Polytechnic Institute), On Tue, Jun 28, 2022 at 9:53 AM Martin Pecka <pec...@fe...> wrote: > Hi, I've started getting into this issue too on one of my test computers > (Jetson TX2 + Orbitty Carrier running Ubuntu 18.04). I usually "resolve" > it by rebooting the computer. After a fresh reboot, software > timestamping works. > > Does a reboot help in your case? > > Martin > > > Hi, > > The command I am trying to run is > > *sudo ptp4l -i eth0 -m -S* > > > > The response I am seeing is: > > port 1 (eth0): send sync failed > > ptp4l[687780.178]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED > > (FT_UNSPECIFIED) > > ptp4l[687796.179]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE > > ptp4l[687803.557]: port 1 (eth0): LISTENING to MASTER on > > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > ptp4l[687803.557]: port 1 (eth0): assuming the grand master role > > ptp4l[687804.567]: timed out while polling for tx timestamp > > ptp4l[687804.568]: increasing tx_timestamp_timeout may correct this > issue, > > but it is likely caused by a driver bug > > ptp4l[687804.568]: port 1 (eth0): send sync failed > > ptp4l[687804.568]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED > > (FT_UNSPECIFIED) > > ptp4l[687820.568]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE > > ptp4l[687826.779]: port 1 (eth0): LISTENING to MASTER on > > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > ptp4l[687826.780]: port 1 (eth0): assuming the grand master role > > ptp4l[687827.790]: timed out while polling for tx timestamp > > ptp4l[687827.790]: increasing tx_timestamp_timeout may correct this > issue, > > but it is likely caused by a driver bug > > ptp4l[687827.790]: port 1 (eth0): send sync failed > > ptp4l[687827.790]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED > > (FT_UNSPECIFIED) > > > > My system is an Ubuntu 20.04 VM hosted on MS Azure. > > > > If I disable the -S flag and run the ptp4l on HW mode for the other > > interface of my system, it works fine. > > *sudo ptp4l -i enP48399s1 -m* > > > > This interface does not support the -S flag. So, I am trying the -S flag > on > > the other existing interface eth0. Do you have any suggestions on how to > > make the SW PTP run on the eth0 interface? > > |
|
From: Richard C. <ric...@gm...> - 2022-06-28 14:28:06
|
On Tue, Jun 28, 2022 at 03:21:02PM +0200, Martin Pecka wrote: > - according to one user, for P2P to work over this switch, it might be > required to connect a host CPU to the MII port. I don't quite understand why > it should be a different port that would be creating the PDelay messages on > regard of the downstream ports, but that would quite plausibly explain the > behavior of the switch (but would not explain why the datasheet tells it can > act as P2P TC, if it actually needs a linux computer next to it to gain this > functionality). Most (all?) TCs need a micro-processor or micro-controller to handle the PTP. PTP is just too complicated to do in hardware. The peer messages must be generated per-port, and some program need to do that. When used with DSA switches, ptp4l can do this work. Thanks, Richard |
27 messages has been excluded from this view by a project administrator.
