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: Nemo C. <nem...@gm...> - 2023-02-06 15:21:40
|
Hi Linuxptp-users, I am using gPTP 802.1AS profile for my network. My simplified network topology looks like this, TimeLeader --> Eth Switch (802.1as Time Aware Bridge)-->Processor (BC?)--->TimeFollower In the above topology, The processor runs linuxptp (ptp4l & phc2sys) has 2 interfaces. One interface should act as 802.1AS TimeFollower and other should act as 802.1AS TimeLeader. I know that IEEE1588 BoundaryClock has this feature. But I am not sure if 802.1AS (gPTP) has similar feature. Can you please share me details? If this is supported by LinuxPTP, can you please help me how would the configuration file look like? Thanks,Nemo |
|
From: Chris N. <chr...@gm...> - 2023-02-04 22:41:02
|
Hi guys, I am seeing that on ptp4l has several config for automotive etc. but not for AES67. Is that possible to make an AES67 .cfg file or suggest some settings to make ti work? Best regards, Chris |
|
From: Aditya V. <adi...@5g...> - 2023-01-31 07:21:43
|
In the driver's adjtime function, I'm just returning 0 without doing anything as I think ptp master doesn't need this function. On Tue, Jan 31, 2023 at 12:45 PM Aditya Venu <adi...@5g...> wrote: > Hi linuxptp users, > > ptp4l code hangs when I run the master with sudo ./ptp4l -f > configs/default.cfg -i enp1s0 -2 -m. > I provided the information below. > > sudo ./ptp4l -v > 3.1-00193-g6bac465 > > *linux version*: 5.4.0-132-generic #148~18.04.1-Ubuntu SMP > > *Crash dump:* > RIP: 0010:0x0 > [ 887.936559] Code: Bad RIP value. > [ 887.936561] RSP: 0018:ffffb44f595a3db0 EFLAGS: 00010246 > [ 887.936563] RAX: 0000000000000000 RBX: ffffb44f595a3e30 RCX: > 000000003b9ac9ff > [ 887.936565] RDX: 0000000000000000 RSI: 0000000000000000 RDI: > ffff8ba9eeb949b0 > [ 887.936567] RBP: ffffb44f595a3dc8 R08: ffff8bb9f533ec38 R09: > 0000000000000000 > [ 887.936568] R10: 0000000000000000 R11: 0000000000000000 R12: > ffff8ba9eeb18000 > [ 887.936570] R13: 0000000000000000 R14: 0000000000000000 R15: > 0000000000000000 > [ 887.936572] FS: 00007fef83cb3b80(0000) GS:ffff8bbccf640000(0000) > knlGS:0000000000000000 > [ 887.936574] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 887.936576] CR2: ffffffffffffffd6 CR3: 0000001bcb794000 CR4: > 0000000000340ee0 > [ 887.936577] Call Trace: > [ 887.936584] ptp_clock_adjtime+0xe1/0x110 > [ 887.936588] pc_clock_adjtime+0x87/0xa0 > [ 887.936592] do_clock_adjtime+0x43/0x70 > [ 887.936596] __do_sys_clock_adjtime+0x46/0xa0 > [ 887.936601] __x64_sys_clock_adjtime+0x16/0x20 > [ 887.936606] do_syscall_64+0x57/0x190 > [ 887.936611] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 > [ 887.936613] RIP: 0033:0x7fef8301aee7 > [ 887.936616] Code: 73 01 c3 48 8b 0d a1 8f 2c 00 f7 d8 64 89 01 48 83 c8 > ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 31 01 00 00 0f 05 > <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 71 8f 2c 00 f7 d8 64 89 01 48 > [ 887.936618] RSP: 002b:00007ffd0eaa0968 EFLAGS: 00000202 ORIG_RAX: > 0000000000000131 > [ 887.936621] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: > 00007fef8301aee7 > [ 887.936622] RDX: 00007ffd0eaa0980 RSI: 00007ffd0eaa0980 RDI: > 00000000ffffffdb > [ 887.936623] RBP: 00007ffd0eaa0a60 R08: 0000000000000000 R09: > 0000000000000000 > [ 887.936625] R10: 00007ffd0eaa0930 R11: 0000000000000202 R12: > 000055af6926a740 > [ 887.936626] R13: 00007ffd0eaa0ca0 R14: 0000000000000000 R15: > 0000000000000000 > > > From the dump logs, I find that it hangs in ptp_clock_adjtime function in > the kernel. > > How to fix it? I guess this is not a driver issue. > > Please let me know if any further information is required. > > Thanks, > Aditya. > -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Aditya V. <adi...@5g...> - 2023-01-31 07:17:20
|
Cloned the latest git repo and tried the same. Getting single digit ns offset, frequency with some values and clock servo to locked state. Thanks for your time :) -Aditya On Mon, Jan 23, 2023 at 4:41 PM Miroslav Lichvar <mli...@re...> wrote: > On Mon, Jan 23, 2023 at 04:36:11PM +0530, Aditya Venu wrote: > > *It seems the first clock step is disabled. Did you > > changefirst_step_threshold in your config?* > > > > It is set to the default value itself(0.00002). > > I have no explanation. Sorry. > > -- > Miroslav Lichvar > > -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Aditya V. <adi...@5g...> - 2023-01-31 07:15:36
|
Hi linuxptp users, ptp4l code hangs when I run the master with sudo ./ptp4l -f configs/default.cfg -i enp1s0 -2 -m. I provided the information below. sudo ./ptp4l -v 3.1-00193-g6bac465 *linux version*: 5.4.0-132-generic #148~18.04.1-Ubuntu SMP *Crash dump:* RIP: 0010:0x0 [ 887.936559] Code: Bad RIP value. [ 887.936561] RSP: 0018:ffffb44f595a3db0 EFLAGS: 00010246 [ 887.936563] RAX: 0000000000000000 RBX: ffffb44f595a3e30 RCX: 000000003b9ac9ff [ 887.936565] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8ba9eeb949b0 [ 887.936567] RBP: ffffb44f595a3dc8 R08: ffff8bb9f533ec38 R09: 0000000000000000 [ 887.936568] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8ba9eeb18000 [ 887.936570] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 887.936572] FS: 00007fef83cb3b80(0000) GS:ffff8bbccf640000(0000) knlGS:0000000000000000 [ 887.936574] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 887.936576] CR2: ffffffffffffffd6 CR3: 0000001bcb794000 CR4: 0000000000340ee0 [ 887.936577] Call Trace: [ 887.936584] ptp_clock_adjtime+0xe1/0x110 [ 887.936588] pc_clock_adjtime+0x87/0xa0 [ 887.936592] do_clock_adjtime+0x43/0x70 [ 887.936596] __do_sys_clock_adjtime+0x46/0xa0 [ 887.936601] __x64_sys_clock_adjtime+0x16/0x20 [ 887.936606] do_syscall_64+0x57/0x190 [ 887.936611] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 887.936613] RIP: 0033:0x7fef8301aee7 [ 887.936616] Code: 73 01 c3 48 8b 0d a1 8f 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 31 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 71 8f 2c 00 f7 d8 64 89 01 48 [ 887.936618] RSP: 002b:00007ffd0eaa0968 EFLAGS: 00000202 ORIG_RAX: 0000000000000131 [ 887.936621] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fef8301aee7 [ 887.936622] RDX: 00007ffd0eaa0980 RSI: 00007ffd0eaa0980 RDI: 00000000ffffffdb [ 887.936623] RBP: 00007ffd0eaa0a60 R08: 0000000000000000 R09: 0000000000000000 [ 887.936625] R10: 00007ffd0eaa0930 R11: 0000000000000202 R12: 000055af6926a740 [ 887.936626] R13: 00007ffd0eaa0ca0 R14: 0000000000000000 R15: 0000000000000000 >From the dump logs, I find that it hangs in ptp_clock_adjtime function in the kernel. How to fix it? I guess this is not a driver issue. Please let me know if any further information is required. Thanks, Aditya. -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Richard C. <ric...@gm...> - 2023-01-24 19:10:23
|
On Tue, Jan 24, 2023 at 07:13:01AM +0000, ramesh t via Linuxptp-users wrote: > Any idea when is the next planned release for ptp4l? Yes, I'm going to release version 4.0 with the current git HEAD plus a few more items. ETA February 14, 2023. > We are currently using 3.1.1 release, but we need fixes present in the current base code. > Is it ok to take these missing fixes and merge into 3.1.1 local code base? Sure, you can patch your own 3.1.1 branch with any fixes you need. I will not be maintaining 3.1.x with bug fixes, unless a really serious bug appears. None of the fixes in current git HEAD would qualify. Thanks, Richard |
|
From: ramesh t <ram...@ya...> - 2023-01-24 07:13:13
|
Hello, Any idea when is the next planned release for ptp4l? We are currently using 3.1.1 release, but we need fixes present in the current base code. Is it ok to take these missing fixes and merge into 3.1.1 local code base? ######## For Example: commit e8dc364f9fd5fbdac5d2c5e433f28e9da0028d49 Author: Miroslav Lichvar <mli...@re...> Date: Wed May 18 11:33:38 2022 +0200 phc2sys: Don't exit when reading of PHC fails with EBUSY. Reading of the PHC can occasionally fail with some drivers, e.g. the ice driver returns EBUSY when it fails to get a lock. Continue in the loop instead of exiting on the error. ####### Please suggest. regards, Ramesh |
|
From: Miroslav L. <mli...@re...> - 2023-01-23 11:11:49
|
On Mon, Jan 23, 2023 at 04:36:11PM +0530, Aditya Venu wrote: > *It seems the first clock step is disabled. Did you > changefirst_step_threshold in your config?* > > It is set to the default value itself(0.00002). I have no explanation. Sorry. -- Miroslav Lichvar |
|
From: Aditya V. <adi...@5g...> - 2023-01-23 11:06:31
|
*It seems the first clock step is disabled. Did you changefirst_step_threshold in your config?* It is set to the default value itself(0.00002). On Mon, Jan 23, 2023 at 4:31 PM Miroslav Lichvar <mli...@re...> wrote: > On Mon, Jan 23, 2023 at 03:54:27PM +0530, Aditya Venu wrote: > > *Does it work if you enable SW timestamping on the client?* > > > > I'm pasting the output below with HW timestamping at master and SW > > timestamping on client: > > It seems the first clock step is disabled. Did you change > first_step_threshold in your config? > > -- > Miroslav Lichvar > > -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Miroslav L. <mli...@re...> - 2023-01-23 11:01:55
|
On Mon, Jan 23, 2023 at 03:54:27PM +0530, Aditya Venu wrote: > *Does it work if you enable SW timestamping on the client?* > > I'm pasting the output below with HW timestamping at master and SW > timestamping on client: It seems the first clock step is disabled. Did you change first_step_threshold in your config? -- Miroslav Lichvar |
|
From: Aditya V. <adi...@5g...> - 2023-01-23 10:24:53
|
*Does it work if you enable SW timestamping on the client?* I'm pasting the output below with HW timestamping at master and SW timestamping on client: *ptp4l[641.740]: port 1: INITIALIZING to LISTENING on INIT_COMPLETEptp4l[641.740]: port 0: INITIALIZING to LISTENING on INIT_COMPLETEptp4l[645.780]: selected local clock b49691.fffe.a72050 as best masterptp4l[646.596]: port 1: new foreign master 000a35.fffe.000002-1ptp4l[648.596]: selected best master clock 000a35.fffe.000002ptp4l[648.596]: port 1: LISTENING to UNCALIBRATED on RS_SLAVEptp4l[649.721]: rms 36994812072 max 36994830538 freq -1000000 +/- 0 delay 21137 +/- 1465 ptp4l[650.722]: rms 36994771193 max 36994793561 freq -1000000 +/- 0 delay 22453 +/- 276 ptp4l[651.722]: rms 36994737242 max 36994749517 freq -1000000 +/- 0 delay 21996 +/- 680 ptp4l[652.722]: rms 36994709493 max 36994747491 freq -1000000 +/- 0 delay 21561 +/- 507 ptp4l[653.723]: rms 36994672571 max 36994686986 freq -1000000 +/- 0 delay 21531 +/- 761 ptp4l[654.723]: rms 36994644178 max 36994694356 freq -1000000 +/- 0 delay 22666 +/- 223 ptp4l[655.723]: rms 36994602115 max 36994617235 freq -1000000 +/- 0 delay 20980 +/- 873 ptp4l[656.724]: rms 36994572174 max 36994588866 freq -1000000 +/- 0 delay 22051 +/- 959 ptp4l[657.724]: rms 36994536525 max 36994551653 freq -1000000 +/- 0 delay 23524 +/- 300 ptp4l[658.724]: rms 36994503810 max 36994522571 freq -1000000 +/- 0 delay 22821 +/- 921 ptp4l[659.725]: rms 36994470556 max 36994531559 freq -1000000 +/- 0 delay 21131 +/- 2000 ptp4l[660.725]: rms 36994442536 max 36994473073 freq -1000000 +/- 0 delay 20562 +/- 964 ptp4l[661.726]: rms 36994401104 max 36994416693 freq -1000000 +/- 0 delay 22141 +/- 972 ptp4l[662.726]: rms 36994394078 max 36994606592 freq -1000000 +/- 0 delay 22251 +/- 227 ptp4l[663.726]: rms 36994335309 max 36994354631 freq -1000000 +/- 0 delay 22678 +/- 310 ptp4l[664.727]: rms 36994297566 max 36994315433 freq -1000000 +/- 0 delay 24249 +/- 610 ptp4l[665.727]: rms 36994264080 max 36994280858 freq -1000000 +/- 0 delay 24312 +/- 391 ptp4l[666.727]: rms 36994231842 max 36994246342 freq -1000000 +/- 0 delay 23605 +/- 109 * *What NIC, kernel, and linuxptp version is it using?* NIC: The client NIC is Intel XXV710 Kernel: 5.4.0-132-generic linuxptp version: 2.0 We are running the master on an FPGA card with PCIe interface. The timestamping logic is implemented in FPGA and driver and ptp4l are running on x86. On Mon, Jan 23, 2023 at 2:03 PM Miroslav Lichvar <mli...@re...> wrote: > On Mon, Jan 23, 2023 at 11:54:25AM +0530, Aditya Venu wrote: > > Any suggestions to the above issue please?! > > I don't see anything wrong in the phc2ctl output, but your ptp4l > output shows frequency stuck at -1, which makes no sense to me. > Does it work if you enable SW timestamping on client? > What NIC, kernel, and linuxptp version is it using? > > -- > Miroslav Lichvar > > -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Miroslav L. <mli...@re...> - 2023-01-23 08:33:31
|
On Mon, Jan 23, 2023 at 11:54:25AM +0530, Aditya Venu wrote: > Any suggestions to the above issue please?! I don't see anything wrong in the phc2ctl output, but your ptp4l output shows frequency stuck at -1, which makes no sense to me. Does it work if you enable SW timestamping on client? What NIC, kernel, and linuxptp version is it using? -- Miroslav Lichvar |
|
From: Aditya V. <adi...@5g...> - 2023-01-23 06:24:48
|
Hi Miroslav, Any suggestions to the above issue please?! On Tue, Jan 17, 2023 at 4:21 PM Aditya Venu <adi...@5g...> wrote: > Hi Miroslav, > > *Below is the output for master*: > > > > > > > > > *sudo ./phc_ctl /dev/ptp2phc_ctl[14216.300]: capabilities: 999999999 > maximum frequency adjustment (ppb) 0 programable alarms 0 external time > stamp channels 0 programmable periodic signals doesn't have pulse per > second support* > > *And this is for slave*: > > > > > > > > > *sudo ./phc_ctl /dev/ptp0phc_ctl[14301.195]: capabilities: 999999999 > maximum frequency adjustment (ppb) 0 programable alarms 2 external time > stamp channels 2 programmable periodic signals has pulse per second > support* > > On Tue, Jan 17, 2023 at 4:11 PM Miroslav Lichvar <mli...@re...> > wrote: > >> On Tue, Jan 17, 2023 at 03:46:29PM +0530, Aditya Venu via Linuxptp-users >> wrote: >> > Corrected step_threshold to 0 and observed that slave's servo state >> going >> > to locked state. >> > >> > But the offset is continuously increasing.. >> >> It might be a driver issue. What does phc_ctl /dev/ptp0 (or the >> corresponding device) print? >> >> -- >> Miroslav Lichvar >> >> -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Richard C. <ric...@gm...> - 2023-01-19 05:08:37
|
On Wed, Jan 18, 2023 at 08:37:20PM -0500, First Last wrote: > So, does this mean that when using the Automotive Profile, we can never > have ptpTimescale set to 1? If so, is there a reason for this? It is an oversight from the original automotive profile patch set. I also noticed that the pmc settings on the master side never take effect. I guess the author didn't really test this profile very much. And I haven't had time to fix it. Sorry, Richard |
|
From: First L. <ssr...@gm...> - 2023-01-19 01:37:41
|
Hi again, >From doing some further digging, the flagField[1] value only gets populated in port_tx_announce(), which is called in the FD_MANNO_TIMER state. From https://sourceforge.net/p/linuxptp/mailman/linuxptp-users/thread/CAEk6gTCnLGsdppUGCXHEc9Oh5%2B0%2BHt0zB0kW1MsZVSkazgGkZg%40mail.gmail.com/#msg30920783 Richard has explained that this is the Announce TX timer, only going into this state when its time to send an announce message. Since I'm using the Automotive profile, we inhibit the announce message, which explains why the ptpTimescale value never gets actually gets set, regardless of what tds->flags is. So, does this mean that when using the Automotive Profile, we can never have ptpTimescale set to 1? If so, is there a reason for this? Regards, On Wed, Jan 18, 2023 at 7:06 PM First Last <ssr...@gm...> wrote: > Hello, > > I'm having some issues with the Automotive profile, namely that it doesn't > recognize the presence of a GM, even if we have one port in MASTER state, > and the only other port in the network in SLAVE state. I am verifying this > by using pmc: > gptp@gptp-desktop:~/linuxptp$ sudo pmc -u -b 1 -t 1 'GET PARENT_DATA_SET' > sending: GET PARENT_DATA_SET > 202564.fffe.7440f2-0 seq 0 RESPONSE MANAGEMENT PARENT_DATA_SET > parentPortIdentity 202564.fffe.7440f2-0 > parentStats 0 > observedParentOffsetScaledLogVariance 0xffff > observedParentClockPhaseChangeRate 0x7fffffff > grandmasterPriority1 248 > gm.ClockClass 248 > gm.ClockAccuracy 0xfe > gm.OffsetScaledLogVariance 0xffff > grandmasterPriority2 248 > grandmasterIdentity 202564.fffe.7440f2 > 489ebd.fffe.75b716-1 seq 0 RESPONSE MANAGEMENT PARENT_DATA_SET > parentPortIdentity 489ebd.fffe.75b716-0 > parentStats 0 > observedParentOffsetScaledLogVariance 0xffff > observedParentClockPhaseChangeRate 0x7fffffff > grandmasterPriority1 250 > gm.ClockClass 255 > gm.ClockAccuracy 0xfe > gm.OffsetScaledLogVariance 0xffff > grandmasterPriority2 248 > grandmasterIdentity 489ebd.fffe.75b716 > > Above, we can see that both ports in the network show > their parentPortIdentity to be themselves. Because of this, the > TIME_STATUS_NP also shows that the gmIdentity of each port within the > network is itself. I won't show it unless it's needed, but viewing > PORT_DATA_SET shows the two ports in the network and their port state being > MASTER and SLAVE. > > Background: I am using LinuxPTP in a simple 2 node network, using P2P > because I plan on introducing a switch + more slaves soon. I'm using the > automotive profile. > On the GM machine, I am using the following command to start the ptp4l > daemon: 'sudo ptp4l -i eno1 -f configs/automotive-master.cfg > --step_threshold=1 -m' with the default automotive-master.cfg. > On the Slave machine, I am using the following command to start the ptp4l > daemon: 'sudo ptp4l -i eno1 -f configs/automotive-slave.cfg > --step_threshold=1 -m' with the default automotive-slave.cfg. Both machines > are running phc2sys as well. > > More importantly, I am also unable to use pmc to change ptpTimescale in > the Sync/Fup/PDelayResp/PDelayRespFup messages sent to the slave (viewed on > Wireshark). I see the correct ptpTimescale value of 1 when using 'GET > GRANDMASTER_SETTINGS_NP' however this is not reflected in the flags portion > of the PTP packet. How can I change ptpTimescale in PTP packets sent to the > slave? > > Thanks in advance. > > Regards, > > > |
|
From: First L. <ssr...@gm...> - 2023-01-19 00:06:56
|
Hello,
I'm having some issues with the Automotive profile, namely that it doesn't
recognize the presence of a GM, even if we have one port in MASTER state,
and the only other port in the network in SLAVE state. I am verifying this
by using pmc:
gptp@gptp-desktop:~/linuxptp$ sudo pmc -u -b 1 -t 1 'GET PARENT_DATA_SET'
sending: GET PARENT_DATA_SET
202564.fffe.7440f2-0 seq 0 RESPONSE MANAGEMENT PARENT_DATA_SET
parentPortIdentity 202564.fffe.7440f2-0
parentStats 0
observedParentOffsetScaledLogVariance 0xffff
observedParentClockPhaseChangeRate 0x7fffffff
grandmasterPriority1 248
gm.ClockClass 248
gm.ClockAccuracy 0xfe
gm.OffsetScaledLogVariance 0xffff
grandmasterPriority2 248
grandmasterIdentity 202564.fffe.7440f2
489ebd.fffe.75b716-1 seq 0 RESPONSE MANAGEMENT PARENT_DATA_SET
parentPortIdentity 489ebd.fffe.75b716-0
parentStats 0
observedParentOffsetScaledLogVariance 0xffff
observedParentClockPhaseChangeRate 0x7fffffff
grandmasterPriority1 250
gm.ClockClass 255
gm.ClockAccuracy 0xfe
gm.OffsetScaledLogVariance 0xffff
grandmasterPriority2 248
grandmasterIdentity 489ebd.fffe.75b716
Above, we can see that both ports in the network show
their parentPortIdentity to be themselves. Because of this, the
TIME_STATUS_NP also shows that the gmIdentity of each port within the
network is itself. I won't show it unless it's needed, but viewing
PORT_DATA_SET shows the two ports in the network and their port state being
MASTER and SLAVE.
Background: I am using LinuxPTP in a simple 2 node network, using P2P
because I plan on introducing a switch + more slaves soon. I'm using the
automotive profile.
On the GM machine, I am using the following command to start the ptp4l
daemon: 'sudo ptp4l -i eno1 -f configs/automotive-master.cfg
--step_threshold=1 -m' with the default automotive-master.cfg.
On the Slave machine, I am using the following command to start the ptp4l
daemon: 'sudo ptp4l -i eno1 -f configs/automotive-slave.cfg
--step_threshold=1 -m' with the default automotive-slave.cfg. Both machines
are running phc2sys as well.
More importantly, I am also unable to use pmc to change ptpTimescale in the
Sync/Fup/PDelayResp/PDelayRespFup messages sent to the slave (viewed on
Wireshark). I see the correct ptpTimescale value of 1 when using 'GET
GRANDMASTER_SETTINGS_NP' however this is not reflected in the flags portion
of the PTP packet. How can I change ptpTimescale in PTP packets sent to the
slave?
Thanks in advance.
Regards,
|
|
From: Richard C. <ric...@gm...> - 2023-01-18 15:36:39
|
On Tue, Jan 17, 2023 at 09:05:47AM +0000, Wagner Florian (DC-AE/ESW2) via Linuxptp-users wrote:
> But for synchronizing the phase of the schedulers, it would be
> sufficient to synchronize the CLOCK_MONOTONICs relative to the cycle
> time of our tasks. So if we could for example define, that the
> offset between CLOCK_MONOTONIC and CLOCK_REALTIME can only be a
> multiple of our cycle time (eg. 1ms), this would be sufficient. Is
> there an option to do something like this?
The realtime/monotonic offset is handled in the kernel. Setting
CLOCK_REALTIME aka "wall clock" amounts to setting the variable
wall_to_monotonic in the timekeeper data structure.
There is no kernel interface to do what you what you propose.
> If this is not the case, what would happen if we hard (re-)set the
> offset during runtime of phc2sys to the closest multiple of our
> cycle time? Would phc2sys overwrite this
Yes, if allowed by the step_threshold configuration option.
> or would it just adjust the
> difference to the master clock that was introduced by this
> manipulation by adjusting the frequency of
> CLOCK_REALTIME/CLOCK_MONOTONIC?
This is the likely case, when step_threshold == 0.
> Do you have other recommendations to synchronize cyclic scheduling on linux systems with a monotonic time source?
Barring hacking the kernel, I think the easiest way would be to call
t1 = clock_gettime(CLOCK_REALTIME);
t2 = clock_gettime(CLOCK_MONOTONIC);
t3 = clock_gettime(CLOCK_REALTIME);
and figure the phase difference using (t1 + t3)/2 - t2
and then correct your monotonic timer so that it remains in phase with
CLOCK_REALTIME.
You only have to do this once at the beginning, then repeat whenever
CLOCK_REALTIME is set (you can detect that with the timer API).
HTH,
Richard
|
|
From: Richard C. <ric...@gm...> - 2023-01-18 15:15:52
|
On Wed, Jan 18, 2023 at 11:36:40AM +0530, Aditya Venu via Linuxptp-users wrote: > I am running my device as a master. Is it mandatory to implement driver > call backs for gettime and settime for master? > > I think the ptp4l program doesn't call clock_gettime() and clock_settime > but I'm not sure. Can you please clarify? I don't think ptp4l will call get/settime in master mode. strace will tell you for sure. HTH, Richard |
|
From: Aditya V. <adi...@5g...> - 2023-01-18 06:07:01
|
Hi linuxptp users, I have a query regarding clock_gettime implementation in the driver. I am running my device as a master. Is it mandatory to implement driver call backs for gettime and settime for master? I think the ptp4l program doesn't call clock_gettime() and clock_settime but I'm not sure. Can you please clarify? Regards, Aditya. -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Wagner F. (DC-AE/ESW2) <Flo...@bo...> - 2023-01-17 12:42:11
|
Hello all, I want to use linuxptp to synchronize multiple embedded real-time systems. So far, I managed to synchronize the CLOCK_REALTIME on two systems with high accuracy using ptp4l and phc2sys. For some applications running on those systems this is very useful. But we also have a scheduler that triggers cyclic tasks using nanosleep on CLOCK_MONOTONIC (to be safe in case of time jumps). Since the CLOCK_MONOTONICs on multiple systems are also syntonized with ptp4l and phc2sys, I can observe, that the schedulers do not drift against each, which is good. But I can also observe a random phase shift, which results from the “random” offset between CLOCK_MONOTONIC and CLOCK_REALTIME, depending on the current clock times at the start of phc2sys. I understand, that an absolute synchronization of the CLOCK_MONOTONICs is not possible by design. I also found this thread to confirm this: https://sourceforge.net/p/linuxptp/mailman/linuxptp-users/thread/20140219151200.GB9211%40netboy/#msg31998563 But for synchronizing the phase of the schedulers, it would be sufficient to synchronize the CLOCK_MONOTONICs relative to the cycle time of our tasks. So if we could for example define, that the offset between CLOCK_MONOTONIC and CLOCK_REALTIME can only be a multiple of our cycle time (eg. 1ms), this would be sufficient. Is there an option to do something like this? If this is not the case, what would happen if we hard (re-)set the offset during runtime of phc2sys to the closest multiple of our cycle time? Would phc2sys overwrite this or would it just adjust the difference to the master clock that was introduced by this manipulation by adjusting the frequency of CLOCK_REALTIME/CLOCK_MONOTONIC? Do you have other recommendations to synchronize cyclic scheduling on linux systems with a monotonic time source? Kind regards Florian |
|
From: Aditya V. <adi...@5g...> - 2023-01-17 10:51:57
|
Hi Miroslav, *Below is the output for master*: *sudo ./phc_ctl /dev/ptp2phc_ctl[14216.300]: capabilities: 999999999 maximum frequency adjustment (ppb) 0 programable alarms 0 external time stamp channels 0 programmable periodic signals doesn't have pulse per second support* *And this is for slave*: *sudo ./phc_ctl /dev/ptp0phc_ctl[14301.195]: capabilities: 999999999 maximum frequency adjustment (ppb) 0 programable alarms 2 external time stamp channels 2 programmable periodic signals has pulse per second support* On Tue, Jan 17, 2023 at 4:11 PM Miroslav Lichvar <mli...@re...> wrote: > On Tue, Jan 17, 2023 at 03:46:29PM +0530, Aditya Venu via Linuxptp-users > wrote: > > Corrected step_threshold to 0 and observed that slave's servo state going > > to locked state. > > > > But the offset is continuously increasing.. > > It might be a driver issue. What does phc_ctl /dev/ptp0 (or the > corresponding device) print? > > -- > Miroslav Lichvar > > -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Miroslav L. <mli...@re...> - 2023-01-17 10:41:42
|
On Tue, Jan 17, 2023 at 03:46:29PM +0530, Aditya Venu via Linuxptp-users wrote: > Corrected step_threshold to 0 and observed that slave's servo state going > to locked state. > > But the offset is continuously increasing.. It might be a driver issue. What does phc_ctl /dev/ptp0 (or the corresponding device) print? -- Miroslav Lichvar |
|
From: Aditya V. <adi...@5g...> - 2023-01-17 10:16:53
|
Hi Richard, Corrected step_threshold to 0 and observed that slave's servo state going to locked state. But the offset is continuously increasing.. ptp4l[12074.007]: master offset -31076 s2 freq -1 path delay 4145 ptp4l[12075.008]: master offset -46783 s2 freq -1 path delay 4997 ptp4l[12076.008]: master offset -60785 s2 freq -1 path delay 4145 ptp4l[12077.008]: master offset -76475 s2 freq -1 path delay 4977 ptp4l[12078.008]: master offset -92161 s2 freq -1 path delay 5809 ptp4l[12079.008]: master offset -107002 s2 freq -1 path delay 5809 ptp4l[12080.008]: master offset -121631 s2 freq -1 path delay 5596 ptp4l[12081.012]: master offset -136760 s2 freq -1 path delay 5809 ptp4l[12082.008]: master offset -151538 s2 freq -1 path delay 5809 ptp4l[12083.008]: master offset -166173 s2 freq -1 path delay 5596 ptp4l[12084.009]: master offset -181008 s2 freq -1 path delay 5596 ptp4l[12085.008]: master offset -194884 s2 freq -1 path delay 4624 ptp4l[12086.008]: master offset -208806 s2 freq -1 path delay 3698 ptp4l[12087.008]: master offset -223651 s2 freq -1 path delay 3698 ptp4l[12088.008]: master offset -238042 s2 freq -1 path delay 3241 ptp4l[12089.008]: master offset -252481 s2 freq -1 path delay 2838 ptp4l[12090.009]: master offset -267209 s2 freq -1 path delay 2722 ptp4l[12091.008]: master offset -282064 s2 freq -1 path delay 2722 ptp4l[12092.009]: master offset -296912 s2 freq -1 path delay 2722 ptp4l[12093.009]: master offset -310850 s2 freq -1 path delay 1819 ptp4l[12094.009]: master offset -327346 s2 freq -1 path delay 3463 ptp4l[12095.009]: master offset -342191 s2 freq -1 path delay 3463 ptp4l[12096.009]: master offset -356094 s2 freq -1 path delay 2521 ptp4l[12097.009]: master offset -372022 s2 freq -1 path delay 3604 ptp4l[12098.009]: master offset -386867 s2 freq -1 path delay 3604 ptp4l[12099.009]: master offset -401705 s2 freq -1 path delay 3604 ptp4l[12100.009]: master offset -416547 s2 freq -1 path delay 3604 Can you please help me in knowing what might be the reason for this? -Aditya On Tue, Jan 17, 2023 at 3:05 PM Richard Cochran <ric...@gm...> wrote: > On Fri, Jan 13, 2023 at 12:32:21PM +0530, Aditya Venu via Linuxptp-users > wrote: > > > d) I'm using default config files for both master and slave(attaching > them > > for reference) > > You are NOT using the default configuration. > You changed step_threshold from the default of zero. > This is the reason for the oscillation between S0 and S1. > > Thanks, > Richard > -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Richard C. <ric...@gm...> - 2023-01-17 09:35:52
|
On Fri, Jan 13, 2023 at 12:32:21PM +0530, Aditya Venu via Linuxptp-users wrote: > d) I'm using default config files for both master and slave(attaching them > for reference) You are NOT using the default configuration. You changed step_threshold from the default of zero. This is the reason for the oscillation between S0 and S1. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2023-01-16 10:17:18
|
On Mon, Jan 16, 2023 at 03:40:20PM +0530, Aditya Venu wrote: > Hi Miroslav, > > Attaching the slave and master's config files below. Your config sets step_threshold to 2 microseconds, which is less than the offsets measured by the client and causes it to constantly step. Such a poor performance with hardware timestamping indicates a problem in the network (e.g. have the switches enabled PTP support?). -- Miroslav Lichvar |
27 messages has been excluded from this view by a project administrator.
