linuxptp-users Mailing List for linuxptp (Page 18)
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: <652...@qq...> - 2022-10-13 05:29:07
|
<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><link rel="stylesheet" type="text/css" id="mce-u0" href="file:///tmp/.web/html/tinymce/skins/ui/oxide/content.min.css"><link rel="stylesheet" type="text/css" id="mce-u1" href="file:///tmp/.web/html/editor.css"><link rel="stylesheet" type="text/css" id="mce-u2" href="file:///tmp/.web/html/reset.css"><style type="text/css">#tinymce{font-size:14px} .tinymce-editor-sign,.tinymce-mail-content{font-size:14px;font-family:Noto Sans CJK JP}</style><style>::selection{background-color:#1d9c00;color:#fff}
td[data-mce-last-selected="1"]::selection{color:#000}</style><style type="text/css">
.mail_des_content{
color:#000000;
font-size:14px;
font-family:Noto Sans CJK JP;
}
</style><style type="text/css">#sign,.tinymce-editor-sign,.tinymce-content-sign {
clear: both;
overflow: hidden;
position: relative;
padding-top: 10px;
margin-top: 15px;
}
.tinymce-editor-sign::before,.tinymce-content-sign::before{
content: '';
width: 200px;
height: 1px;
border-top: 1px solid #bbbbbb;
position: absolute;
top:0;
left:0;
}
#sign table,.tinymce-editor-sign table{color: #000;}
#sign .m-account, .tinymce-editor-sign .m-account{
display: inline-block;
color: #0000ee;
cursor: pointer;
}
table,td{
color:#000;
}
</style></head><body id="tinymce" class="mce-content-body dark" data-id="#vue-tinymce-1665638751314153" aria-label="Rich Text Area. Press ALT-0 for help." contenteditable="true" spellcheck="false" style="color: rgb(0, 0, 0); font-size: 14px; font-family: "Noto Sans CJK JP"; min-height: 405px;" data-mce-style="color: rgb(0, 0, 0); font-size: 14px; font-family: 'Noto Sans CJK JP'; min-height: 405px;"><div class="tinymce-mail-content"><p><br></p><p><a href="https://linuxptp.sourceforge.net/i210-rework/i210-rework.html">https://linuxptp.sourceforge.net/i210-rework/i210-rework.html</a></p><p><br data-mce-bogus="1"></p><p>I found this title，How should I set up the software</p></div></body></html> |
|
From: vignesh s. <vig...@ya...> - 2022-10-12 20:11:35
|
By increasing the tx_timestamp_timeout to 100ms., I confirmed that the timeout issue is fixed.
But I still see the jumps of around 100 usec now. Again, it is correlating with jumps in cSRO (Cumulative Scaled Rate Ratio.)
Any pointers are appreciated.
On Wednesday, 12 October, 2022 at 09:07:34 am GMT-4, vignesh shanmugam <vig...@ya...> wrote:
Does anyone have any inputs for this behavior?
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails?
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?
The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have attached the snipped showing this.
4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
Thanks!
On Friday, 7 October, 2022 at 10:38:40 am GMT-4, vignesh shanmugam <vig...@ya...> wrote:
Hi Richard,
This is Intel CPU, has support for HW timestamping in the MAC.
I also found few more issues when analyzing the logs and pcap,
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails?
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?
The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have shown the snippet below.
4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
Thanks!
On Friday, 7 October, 2022 at 10:08:03 am GMT-4, Richard Cochran <ric...@gm...> wrote:
On Thu, Oct 06, 2022 at 06:44:29PM +0000, vignesh shanmugam via Linuxptp-users wrote:
> Can you point me some clues what could cause this?
What is the MAC? Does it use software time stamping?
Thanks,
Richard
|
|
From: vignesh s. <vig...@ya...> - 2022-10-12 13:17:57
|
Does anyone have any inputs for this behavior?
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails?
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?
The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have attached the snipped showing this.
4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
Thanks!
On Friday, 7 October, 2022 at 10:38:40 am GMT-4, vignesh shanmugam <vig...@ya...> wrote:
Hi Richard,
This is Intel CPU, has support for HW timestamping in the MAC.
I also found few more issues when analyzing the logs and pcap,
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails?
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?
The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have shown the snippet below.
4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
Thanks!
On Friday, 7 October, 2022 at 10:08:03 am GMT-4, Richard Cochran <ric...@gm...> wrote:
On Thu, Oct 06, 2022 at 06:44:29PM +0000, vignesh shanmugam via Linuxptp-users wrote:
> Can you point me some clues what could cause this?
What is the MAC? Does it use software time stamping?
Thanks,
Richard
|
|
From: Gururaj B. <gur...@gm...> - 2022-10-12 13:08:42
|
Hello, We have a need for a PTP instance to only be a master but still respond normally to the BMCA. This is used when we have two or more dedicated masters which use the BMCA to choose the GM. So the expected states once running are Master and Passive. We can get this if we set the *clockClass * at 58 or below. This inhibits the slave states. However we need this to work with a *clockClass * of 248. Is there a way to inhibit the slave state? We cannot use masterOnly=1 as that mode forces it to go to Leader and ignores the announce messages and does not follow the BMCA. We have tried *asCapable*=true and *inhibit_delay_req*=1 but in that mode, device states are Master or Uncalibrated. It appears the logic we want is possible since it works when the *clockClass *is 58 or less. Is there an explicit configuration parameter to achieve this directly? Thank you. Regards, Guru |
|
From: Gururaj B. <gur...@gm...> - 2022-10-10 14:41:47
|
Thanks for quick response. -Guru On Mon, 10 Oct, 2022, 7:41 pm Miroslav Lichvar, <mli...@re...> wrote: > On Mon, Oct 10, 2022 at 07:28:31PM +0530, Gururaj Badiger wrote: > > Hello, > > > > In my current setup, whenever I want to change the message rates, I > update > > config file and restart Ptp4l process. > > > > I have a requirement where in, I want to change the message rates while > > Ptp4l process is in running state, perhaps by running a PMC SET command > (?). > > It's not possible to change the intervals with a management message > and the current code. > > -- > Miroslav Lichvar > > |
|
From: Nemo C. <nem...@gm...> - 2022-10-10 14:17:22
|
Hi Richard,
Did you get chance to see this? I am still looking for help on this.
Thanks
On Friday, 7 October, 2022 at 11:04:33 am GMT-4, vignesh shanmugam via Linuxptp-users <lin...@li...> wrote:
Hi Richard,
This is Intel CPU, has support for HW timestamping in the MAC.
I also found few more issues when analyzing the logs and pcap,
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails?
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?
The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have shown the snippet below.
4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
Thanks!
On Friday, 7 October, 2022 at 10:08:03 am GMT-4, Richard Cochran <ric...@gm...> wrote:
On Thu, Oct 06, 2022 at 06:44:29PM +0000, vignesh shanmugam via Linuxptp-users wrote:
> Can you point me some clues what could cause this?
What is the MAC? Does it use software time stamping?
Thanks,
Richard
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Miroslav L. <mli...@re...> - 2022-10-10 14:11:30
|
On Mon, Oct 10, 2022 at 07:28:31PM +0530, Gururaj Badiger wrote: > Hello, > > In my current setup, whenever I want to change the message rates, I update > config file and restart Ptp4l process. > > I have a requirement where in, I want to change the message rates while > Ptp4l process is in running state, perhaps by running a PMC SET command (?). It's not possible to change the intervals with a management message and the current code. -- Miroslav Lichvar |
|
From: Gururaj B. <gur...@gm...> - 2022-10-10 13:58:52
|
Hello, In my current setup, whenever I want to change the message rates, I update config file and restart Ptp4l process. I have a requirement where in, I want to change the message rates while Ptp4l process is in running state, perhaps by running a PMC SET command (?). I have done this for changing Priority1/2, however it doesn't look straight to do the same for message rates. Is it really possible? Could you please throw some light on this? Thank you, Guru |
|
From: vignesh s. <vig...@ya...> - 2022-10-07 14:59:15
|
Hi Richard,
This is Intel CPU, has support for HW timestamping in the MAC.
I also found few more issues when analyzing the logs and pcap,
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails?
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?
The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have shown the snippet below.
4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
Thanks!
On Friday, 7 October, 2022 at 10:08:03 am GMT-4, Richard Cochran <ric...@gm...> wrote:
On Thu, Oct 06, 2022 at 06:44:29PM +0000, vignesh shanmugam via Linuxptp-users wrote:
> Can you point me some clues what could cause this?
What is the MAC? Does it use software time stamping?
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2022-10-07 14:08:11
|
On Thu, Oct 06, 2022 at 06:44:29PM +0000, vignesh shanmugam via Linuxptp-users wrote: > Can you point me some clues what could cause this? What is the MAC? Does it use software time stamping? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2022-10-07 14:04:34
|
On Thu, Oct 06, 2022 at 08:40:54PM +0530, Gururaj Badiger wrote: > However, when Two LEADERS are running in the same domain then one of them > goes to "PASSIVE" state as there can be only one Best Master in the domain. > In that case, though there are two ports and they are configured to the > same domain, I was expecting the same behavior in my set-up too. Only if the networking stack does not drop UDP frames from other interface on same host. This is the default on Linux. HTH, Richard |
|
From: vignesh s. <vig...@ya...> - 2022-10-06 19:15:08
|
Hi All, I am working on a project where we are using an Ethernet Switch as gPTP Automotive profile master and Intel Denvorton CPU as gPTP Slave. Slave is working perfectly fine most of the time, and stays within the needed offset limit for most of the time (within 20 usec). But there is a sudden jump to 32 usec observed on the slave. I investigated if the issue happened because of the Ethernet switch master time, but the ingress time carried by the Followup message is looking as expected. The slave is running ptp4l. Other slaves connected to the same master are okay. They don't use ptp4l service for Slave. Can you point me some clues what could cause this? phc2sys[11112.734]: CLOCK_REALTIME phc offset -147 s2 freq +3777 delay 1066 ptp4l[11113.523]: master offset -239 s3 freq +3671 path delay 356 phc2sys[11113.734]: CLOCK_REALTIME phc offset 34 s2 freq +3914 delay 1070 ptp4l[11114.522]: master offset 32132 s3 freq +35970 path delay 355 phc2sys[11114.734]: CLOCK_REALTIME phc offset 6638 s2 freq +10528 delay 1063 ptp4l[11115.522]: master offset 428 s3 freq +13906 path delay 355 phc2sys[11115.734]: CLOCK_REALTIME phc offset 27682 s2 freq +33564 delay 872 ptp4l[11116.523]: master offset -9609 s3 freq +3997 path delay 355 phc2sys[11116.735]: CLOCK_REALTIME phc offset 5644 s2 freq +19830 delay 1055 ptp4l[11117.522]: master offset -9659 s3 freq +1064 path delay 355 phc2sys[11117.735]: CLOCK_REALTIME phc offset -10831 s2 freq +5048 delay 1066 |
|
From: Gururaj B. <gur...@gm...> - 2022-10-06 15:11:41
|
Thanks for the reply Richard. However, when Two LEADERS are running in the same domain then one of them goes to "PASSIVE" state as there can be only one Best Master in the domain. In that case, though there are two ports and they are configured to the same domain, I was expecting the same behavior in my set-up too. Please correct me if I am wrong. Regards, Guru On Thu, 6 Oct 2022 at 20:31, Richard Cochran <ric...@gm...> wrote: > On Thu, Oct 06, 2022 at 02:32:18PM +0530, Gururaj Badiger wrote: > > Used two commands on two terminls: > > > > TERMINAL:~# ptp4l -i eth1 -m -f > > /home/root/ptp-manager/source/linuxptp_config_0.conf > > TERMINAL:~# ptp4l -i eth2 -m -f > > /home/root/ptp-manager/source/linuxptp_config_1.conf > > You are running two instances on two network ports in two different > networks. So both ports will assume the PTP "master" role. This is > both correct and expected. > > HTH, > Richard > > |
|
From: Richard C. <ric...@gm...> - 2022-10-06 15:01:43
|
On Thu, Oct 06, 2022 at 02:32:18PM +0530, Gururaj Badiger wrote: > Used two commands on two terminls: > > TERMINAL:~# ptp4l -i eth1 -m -f > /home/root/ptp-manager/source/linuxptp_config_0.conf > TERMINAL:~# ptp4l -i eth2 -m -f > /home/root/ptp-manager/source/linuxptp_config_1.conf You are running two instances on two network ports in two different networks. So both ports will assume the PTP "master" role. This is both correct and expected. HTH, Richard |
|
From: Ondrej L. <ond...@nx...> - 2022-10-06 11:54:43
|
Hi everyone,
I am doing some work with Android and linuxptp so using Android toolchain (clang) to compile all the binaries.
When cross-compiling using clang for AARCH64 there are some warnings regarding unaligned access to members of packed structures. This unaligned access could cause app crash on ARM platforms.
Most of the issues is located within pmc_common.c file such as this one (and my workaround, using local variables) :
@@ -215,17 +225,24 @@ static void do_set_action(struct pmc *pmc, int action, int index, char *str)
"timeTraceable %d "
"frequencyTraceable %d "
"timeSource %hhx ",
- &gsn.clockQuality.clockClass,
- &gsn.clockQuality.clockAccuracy,
- &gsn.clockQuality.offsetScaledLogVariance,
- &gsn.utc_offset,
+ &clockClass,
+ &clockAccuracy,
+ &offsetScaledLogVariance,
+ &utc_offset,
&leap_61,
&leap_59,
&utc_off_valid,
&ptp_timescale,
&time_traceable,
&freq_traceable,
- &gsn.time_source);
+ &time_source);
+
+ gsn.clockQuality.clockClass = clockClass ;
+ gsn.clockQuality.clockAccuracy = clockAccuracy;
+ gsn.clockQuality.offsetScaledLogVariance = offsetScaledLogVariance;
+ gsn.utc_offset = utc_offset;
+ gsn.time_source = time_source;
+
Another unaligned access in util.c :
------------------------------------ util.c ------------------------------------
index a59b559..dfab1b8 100644
@@ -346,11 +346,13 @@ int str2pid(const char *s, struct PortIdentity *result)
{
struct PortIdentity pid;
unsigned char *ptr = pid.clockIdentity.id;
+ unsigned int portNumber;
int c;
c = sscanf(s, " %02hhx%02hhx%02hhx.%02hhx%02hhx.%02hhx%02hhx%02hhx-%hu",
&ptr[0], &ptr[1], &ptr[2], &ptr[3],
&ptr[4], &ptr[5], &ptr[6], &ptr[7],
- &pid.portNumber);
+ &portNumber);
+ pid.portNumber = portNumber;
Then a small issue is in rtnl.c where void pointer is used in arith. operation (see NLMSG_DATA in kernel https://elixir.bootlin.com/linux/v4.8/source/include/uapi/linux/netlink.h#L85), solution might be :
-#define GENLMSG_DATA(glh) ((void *)(NLMSG_DATA(glh) + GENL_HDRLEN))
+#define GENLMSG_DATA(glh) ((void *)((char *)NLMSG_DATA(glh) + GENL_HDRLEN))
Then second small issue might be there, missing include of string.h (however might be related to my integration to Android and different build system, so not really sure) :
--------------------------------- interface.c ---------------------------------
index 6c2630c..441f670 100644
@@ -4,6 +4,7 @@
* @note Copyright (C) 2020 Richard Cochran ric...@gm...<mailto:ric...@gm...>
* @note SPDX-License-Identifier: GPL-2.0+
*/
+#include <string.h>
#include <stdlib.h>
#include "interface.h"
And one small change to get Android happy (as Android already defines same macros https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/sys/endian.h;l=76;bpv=1?q=HTONS&ss=android%2Fplatform%2Fsuperproject ). This is not an issue, just improvement :
----------------------------------- tlv.c ------------------------------------
index 1c13460..4a8f0a7 100644
@@ -26,10 +26,18 @@
#include "tlv.h"
#include "msg.h"
-#define HTONS(x) (x) = htons(x)
-#define HTONL(x) (x) = htonl(x)
-#define NTOHS(x) (x) = ntohs(x)
-#define NTOHL(x) (x) = ntohl(x)
+#ifndef HTONS
+ #define HTONS(x) (x) = htons(x)
+#endif
+#ifndef HTONL
+ #define HTONL(x) (x) = htonl(x)
+#endif
+#ifndef NTOHS
+ #define NTOHS(x) (x) = ntohs(x)
+#endif
+#ifndef NTOHL
+ #define NTOHL(x) (x) = ntohl(x)
+#endif
Thanks for reading this super long email.
Kind Regards,
Ondrej Lutera
SW Engineer
NXP Semiconductors
Sochorova 3232/36
616 00 Brno Zabovresky
Czech Republic
Email: ond...@nx...<mailto:ond...@nx...>
[cid:image002.png@01D8D97A.90DE87D0]
|
|
From: Gururaj B. <gur...@gm...> - 2022-10-06 09:03:01
|
Hello, I did some testing by running two PTP instances in LEADER mode on same Processor (running Yacto flavour) simultaneously. Having the same domain number . Used two commands on two terminls: TERMINAL:~# ptp4l -i eth1 -m -f /home/root/ptp-manager/source/linuxptp_config_0.conf TERMINAL:~# ptp4l -i eth2 -m -f /home/root/ptp-manager/source/linuxptp_config_1.conf PTP4L running @ eth1 is PTP1 and eth2 is PTP2. PTP1 priority1 set to 125 and PTP2 priority1 set to 127 I was expecting PTP2 to go to PASSIVE state. However, It doesn't seem to. Both ports show ACTIVE and I see sync messages are getting generated by both instances. This problem is seen only when both PTP1 and PTP2 are run on the same host. After enabling some debug logs, I found that (in bmc.c) c*lock_best *and *port_best *structures are null. Apparently, this is the reason for both showing active state, could someone please confirm? If so, is there a fix available for this? Thank you. Regards, Guru |
|
From: Miroslav L. <mli...@re...> - 2022-10-06 07:33:45
|
On Thu, Oct 06, 2022 at 09:23:57AM +0200, Janusz Użycki wrote: > OK. The issue is not related to linuxptp v3.1. Thank you for pointing the > clamp. > Is it common for phc2sys and ts2phc also ? I see a phc_max_adj() call in both phc2sys and ts2phc, so I'd expect them to handle it correctly. -- Miroslav Lichvar |
|
From: Janusz U. <j.u...@el...> - 2022-10-06 07:24:18
|
OK. The issue is not related to linuxptp v3.1. Thank you for pointing the clamp. Is it common for phc2sys and ts2phc also ? best regards Janusz W dniu 06/10/2022 o 09:19, Janusz Użycki pisze: > >> On Thu, Oct 06, 2022 at 12:11:39AM +0200, Janusz Użycki wrote: >>> Hi. >>> >>> A lot of PTP/PHC drivers set max_adj value quite big. Howover due to >>> kernel's API limit of 32bit long type value (freq) and POSIX frequency >>> conversion it should limited to 32767999 ppb. >>> >>> It concerns the frequency limit check both for kernel, testptp and >>> ptp4linux >>> servos. Simply 65.536 * 32767999 is almost 2^31... It is also common >>> for >>> adjfreq() vs newer adjfine(). >>> Moreover such big frequency limits seem not practical (phase jump used >>> instead, 1000ppm is huge for any PTP oscillator application), even >>> driver or >>> rather PHC hardware has ability to tune is such range. >> What issue are you seeing with linuxptp? >> >> In phc_max_adj() there is some code clamping the value on 32-bit >> systems, so the overflow should be avoided. > > When I set testptp -f 32768000 or more PHC time starts to drift in > opposite direction relative to synced REALTIME system clock, tested > using testptp -k1. > First I noted the issue on much older kernel than latest mainline. > > > best regrds > Janusz > > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Janusz U. <j.u...@el...> - 2022-10-06 07:19:42
|
> On Thu, Oct 06, 2022 at 12:11:39AM +0200, Janusz Użycki wrote: >> Hi. >> >> A lot of PTP/PHC drivers set max_adj value quite big. Howover due to >> kernel's API limit of 32bit long type value (freq) and POSIX frequency >> conversion it should limited to 32767999 ppb. >> >> It concerns the frequency limit check both for kernel, testptp and ptp4linux >> servos. Simply 65.536 * 32767999 is almost 2^31... It is also common for >> adjfreq() vs newer adjfine(). >> Moreover such big frequency limits seem not practical (phase jump used >> instead, 1000ppm is huge for any PTP oscillator application), even driver or >> rather PHC hardware has ability to tune is such range. > What issue are you seeing with linuxptp? > > In phc_max_adj() there is some code clamping the value on 32-bit > systems, so the overflow should be avoided. When I set testptp -f 32768000 or more PHC time starts to drift in opposite direction relative to synced REALTIME system clock, tested using testptp -k1. First I noted the issue on much older kernel than latest mainline. best regrds Janusz |
|
From: Miroslav L. <mli...@re...> - 2022-10-06 07:14:00
|
On Thu, Oct 06, 2022 at 12:11:39AM +0200, Janusz Użycki wrote: > Hi. > > A lot of PTP/PHC drivers set max_adj value quite big. Howover due to > kernel's API limit of 32bit long type value (freq) and POSIX frequency > conversion it should limited to 32767999 ppb. > > It concerns the frequency limit check both for kernel, testptp and ptp4linux > servos. Simply 65.536 * 32767999 is almost 2^31... It is also common for > adjfreq() vs newer adjfine(). > Moreover such big frequency limits seem not practical (phase jump used > instead, 1000ppm is huge for any PTP oscillator application), even driver or > rather PHC hardware has ability to tune is such range. What issue are you seeing with linuxptp? In phc_max_adj() there is some code clamping the value on 32-bit systems, so the overflow should be avoided. -- Miroslav Lichvar |
|
From: Janusz U. <j.u...@el...> - 2022-10-05 22:27:09
|
More details: The type of "freq" field in "__kernel_timex" structure is fixed in mainline kernel to "long long" type. However "__kernel_long_t freq" in timex structure depends on machine. Eg. for some machines it see: include/uapi/asm-generic/posix_types.h:typedef long __kernel_long_t; arch/sparc/include/uapi/asm/posix_types.h: typedef long __kernel_long_t; best regards Janusz Uzycki W dniu 06/10/2022 o 00:11, Janusz Użycki pisze: > Hi. > > A lot of PTP/PHC drivers set max_adj value quite big. Howover due to > kernel's API limit of 32bit long type value (freq) and POSIX frequency > conversion it should limited to 32767999 ppb. > > It concerns the frequency limit check both for kernel, testptp and > ptp4linux servos. Simply 65.536 * 32767999 is almost 2^31... It is > also common for adjfreq() vs newer adjfine(). > Moreover such big frequency limits seem not practical (phase jump used > instead, 1000ppm is huge for any PTP oscillator application), even > driver or rather PHC hardware has ability to tune is such range. > > > best regards > Janusz Uzycki > > |
|
From: Janusz U. <j.u...@el...> - 2022-10-05 22:11:56
|
Hi. A lot of PTP/PHC drivers set max_adj value quite big. Howover due to kernel's API limit of 32bit long type value (freq) and POSIX frequency conversion it should limited to 32767999 ppb. It concerns the frequency limit check both for kernel, testptp and ptp4linux servos. Simply 65.536 * 32767999 is almost 2^31... It is also common for adjfreq() vs newer adjfine(). Moreover such big frequency limits seem not practical (phase jump used instead, 1000ppm is huge for any PTP oscillator application), even driver or rather PHC hardware has ability to tune is such range. best regards Janusz Uzycki |
|
From: Jason L. <ja...@as...> - 2022-10-04 02:40:21
|
Hi Martin, This is exactly the info I needed to make the pmc call work! Thanks, Jason On 10/3/2022 9:52 AM, Martin Pecka wrote: > > Hi Jason, that's what the readonly UDS socket is for. With default > configuration and PTP4L master branch, this is how you can query > TIME_STATUS_NP without root: > > pmc -u -s /var/run/ptp4lro -i /tmp/pmc.socket "GET TIME_STATUS_NP" > > The key is to supply the "-s /var/run/ptp4lro" which points to the > read-only socket. You also need to pass "-i /tmp/pmc.socket" or > something similar - this points to the path where PMC should create > its own socket. By default, it is /var/run/pmc.$pid, but that location > is not writable for non-root users. So I just usually point it to /tmp > (this socket is practically useless). > > Martin > > -- > Mgr. Martin Pecka, Ph.D. > Researcher at Vision for Robotics and Autonomous Systems group > Faculty of Electrical Engineering > Czech Technical University in Prague > Phone: +420 22435 7269 |
|
From: Martin P. <pec...@fe...> - 2022-10-03 17:21:48
|
Just make sure the filenames you pass as the "-i" argument are unique if the two pmc instances can run at the same time. Martin Dne 3.10.2022 v 19:19 Rich Schmidt napsal(a): > Thank you Martin, > > Indeed the sockets must be rw. > > > Regards, > > Rich Schmidt > > > $ sudo chmod o+r,o+w /var/run/ptp* > > > $ ls -l /var/run/ptp* > > srw-rw-rw-. 1 root root 0 Sep 30 17:55 /var/run/ptp4l-1 > > srw-rw-rw-. 1 root root 0 Sep 30 17:55 /var/run/ptp4l-2 > > > $ pmc -u -s /var/run/ptp4l-1 -i /tmp/pmc.socket "GET TIME_STATUS_NP" > > sending: GET TIME_STATUS_NP > > b49691.fffe.37fe80-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP > > master_offset13 > > ingress_time 1664817421491931913 > > cumulativeScaledRateOffset +0.000000000 > > scaledLastGmPhaseChange0 > > gmTimeBaseIndicator0 > > lastGmPhaseChange0x0000'0000000000000000.0000 > > gmPresenttrue > > gmIdentity 0019dd.fffe.002009 > > b49691.fffe.35c204-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP > > master_offset72 > > ingress_time 1664817421491932021 > > cumulativeScaledRateOffset +0.000000000 > > scaledLastGmPhaseChange0 > > gmTimeBaseIndicator0 > > lastGmPhaseChange0x0000'0000000000000000.0000 > > gmPresenttrue > > gmIdentity 0019dd.fffe.002009 > > [ntp.richard.schmidt@dc-ntp01 ~]$ pmc -u -s /var/run/ptp4l-2 -i > /tmp/pmc.socket "GET TIME_STATUS_NP" > > sending: GET TIME_STATUS_NP > > b49691.fffe.37fe82-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP > > master_offset-12 > > ingress_time 1664817432854059256 > > cumulativeScaledRateOffset +0.000000000 > > scaledLastGmPhaseChange0 > > gmTimeBaseIndicator0 > > lastGmPhaseChange0x0000'0000000000000000.0000 > > gmPresenttrue > > gmIdentity 0019dd.fffe.001ffb > > b49691.fffe.35c206-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP > > master_offset125 > > ingress_time 1664817432854059400 > > cumulativeScaledRateOffset +0.000000000 > > scaledLastGmPhaseChange0 > > gmTimeBaseIndicator0 > > lastGmPhaseChange0x0000'0000000000000000.0000 > > gmPresenttrue > > gmIdentity 0019dd.fffe.001ffb > |
|
From: Martin P. <pec...@fe...> - 2022-10-03 17:10:24
|
That's a misconception. The socket is read-only on the application level, i.e. you can't issue any SET commands via it. However, the socket special file itself has to be read-write, because pmc needs bidirectional communication with the running ptp4l instance. Make it rw and it should work. Or even beter, use /var/run/ptp4lro which already has these permissions. Martin Dne 3.10.2022 v 19:02 Rich Schmidt napsal(a): > I find that I still have to sudo to run pmc -u, even if I make the > server socket /var/run/ptp4l... permissions rw-rw-r-- > > Rich Schmidt > Precise Time Dept > US Naval Observatory > Washington, DC > > On Mon, Oct 3, 2022 at 9:56 AM Martin Pecka <pec...@fe...> wrote: > > Hi Jason, that's what the readonly UDS socket is for. With default > configuration and PTP4L master branch, this is how you can query > TIME_STATUS_NP without root: > > pmc -u -s /var/run/ptp4lro -i /tmp/pmc.socket "GET TIME_STATUS_NP" > > The key is to supply the "-s /var/run/ptp4lro" which points to the > read-only socket. You also need to pass "-i /tmp/pmc.socket" or > something similar - this points to the path where PMC should > create its own socket. By default, it is /var/run/pmc.$pid, but > that location is not writable for non-root users. So I just > usually point it to /tmp (this socket is practically useless). > > Martin > > -- > Mgr. Martin Pecka, Ph.D. > Researcher at Vision for Robotics and Autonomous Systems group > Faculty of Electrical Engineering > Czech Technical University in Prague > Phone: +420 22435 7269 > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > -- > > /"We learn from history that we learn nothing from history." / > *George Bernard Shaw > * > * > * > “The ideal subject of totalitarian rule is not the convinced Nazi or > the convinced communist, but people for whom the distinction between > fact and fiction . . . and the distinction between true and false > . . . no longer exist.” —Hanna Arendt, “The Origins of > Totalitarianism” (1951) -- Mgr. Martin Pecka, Ph.D. Researcher at Vision for Robotics and Autonomous Systems group Faculty of Electrical Engineering Czech Technical University in Prague Phone: +420 22435 7269 |
27 messages has been excluded from this view by a project administrator.
