linuxptp-users Mailing List for linuxptp (Page 35)
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: Richard C. <ric...@gm...> - 2022-01-17 16:06:04
|
On Mon, Jan 17, 2022 at 08:25:06AM +0000, ramesh t wrote:
> Please suggest.
1. Make sure your ptp4l has these five patches:
a082bcd clockcheck: Increase minimum interval.
6df8425 port: Don't renew raw transport.
e117e37 port: Don't check timestamps from non-slave ports.
262a49b clock: Reset clock check on best clock/port change.
7e8eba5 clock: Reset state when switching port with same best clock.
If that doesn't fix the problem, then:
2. Disable clock sanity check.
sanity_freq_limit
The maximum allowed frequency offset between uncorrected clock
and the system monotonic clock in parts per billion (ppb). This
is used as a sanity check of the synchronized clock. When a
larger offset is measured, a warning message will be printed and
the servo will be reset. When set to 0, the sanity check is dis‐
abled. The default is 200000000 (20%).
|
|
From: ramesh t <ram...@ya...> - 2022-01-17 08:25:18
|
hi Richard, Issue: Running ptp4l in BC mode. Have connected one NIC port to BC/GM and another NIC port to testing unit (TU). On resetting of the testing unit, temporarily observing ptp4l going into FAULTY state though it shouldn't be impacted due to reset of testing unit. On debugged this issue further: By adding debugs to print mono_interval in clockcheck_sample, below is the understanding. In normal working case: Observing clockcheck_sample is getting called once in 120-128 milli seconds. ptp4l: [523771.617] mono 127658899 ptp4l: [523771.737] mono 120000322 On resetting testing Unit, whenever send sync failure is observed, clockcheck_sample is getting called after 200 milli seconds. ptp4l: [523772.664] timed out while polling for tx timestamp ptp4l: [523772.664] PID 6071 increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l: [523772.664] port 2: send sync failed ptp4l: [523772.700] mono 210350673 ptp4l: [523772.700] clockcheck port 1: clock jumped backward or running slower than expected! ptp4l: [523772.700] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT Since mono interval will be used to calculate min and max freq offset, clockcheck is reporting error and resetting servo. As I understand ptp4l is running in single thread and this seems to impact whenever send failure occurs. Please suggest. regards, Ramesh On Friday, January 7, 2022, 08:53:09 PM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Fri, Jan 07, 2022 at 07:32:39AM +0000, ramesh t wrote: > ptp4l: [325744.430] clockcheck: clock jumped forward or running faster than expected! > ptp4l: [325744.430] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT See this? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please suggest. I suggest reading the log messages to see the clearly identified source of the fault. |
|
From: Richard C. <ric...@gm...> - 2022-01-13 15:27:48
|
On Thu, Jan 13, 2022 at 09:44:50AM +0100, Peter Bergin wrote: > Backporting relevant stuff of this patch to my 5.4 kernel solved the padding > problem. Cool. Glad it was a driver issue and not a bug in silicon! Cheers, Richard |
|
From: Peter B. <pe...@be...> - 2022-01-13 08:45:05
|
On 2022-01-13 05:11, Richard Cochran wrote: > On Wed, Jan 12, 2022 at 03:57:55PM +0100, Peter Bergin wrote: > >> I have a setup with TI processor using the cpsw driver from Linux mainline, >> kernel version 5.4. I'm using IEEE 802.3 network transport and sending PTP >> frames on Ethernet. When sending SYNC, FOLLOW_UP and DELAY_REQ that has a >> length of 58 bytes they get padded up to 64 bytes. > I tried layer2 with a Beagle Board Black (am335x), and I also saw the > SIX bytes of padding. Wireshark hates this, and shows a FCS error > (but actually I think it assumes the last 4 bytes are FCS, but in fact > the FCS has been stripped by the MAX) > > As Miroslav pointed out, padding SIX bytes is wrong. > >> On the other side in my setup I have a PC with e1000e driver. On that side >> when sending SYNC, FOLLOW_UP and DELAY_REQ over Ethernet the PDUs are padded >> to 60 bytes. > This is correct. > > 44 (PTP PDU) + 14 (L2 dst+src+type) + 4 (FCS) = 62 bytes > > Two bytes padding are needed to make 64 bytes. Not SIX bytes. > > The TI MAC (or driver?) is padding six bytes instead of two. > > Somebody should tell TI about their bug. > Thanks for the confirmation Richard! I did some more research around this and it turned out is was already fixed in v5.14 upstream. For reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=acc68b8d2a1196c4db806947606f162dbeed2274 Backporting relevant stuff of this patch to my 5.4 kernel solved the padding problem. /Peter |
|
From: Richard C. <ric...@gm...> - 2022-01-13 04:11:27
|
On Wed, Jan 12, 2022 at 03:57:55PM +0100, Peter Bergin wrote:
> I have a setup with TI processor using the cpsw driver from Linux mainline,
> kernel version 5.4. I'm using IEEE 802.3 network transport and sending PTP
> frames on Ethernet. When sending SYNC, FOLLOW_UP and DELAY_REQ that has a
> length of 58 bytes they get padded up to 64 bytes.
I tried layer2 with a Beagle Board Black (am335x), and I also saw the
SIX bytes of padding. Wireshark hates this, and shows a FCS error
(but actually I think it assumes the last 4 bytes are FCS, but in fact
the FCS has been stripped by the MAX)
As Miroslav pointed out, padding SIX bytes is wrong.
> On the other side in my setup I have a PC with e1000e driver. On that side
> when sending SYNC, FOLLOW_UP and DELAY_REQ over Ethernet the PDUs are padded
> to 60 bytes.
This is correct.
44 (PTP PDU) + 14 (L2 dst+src+type) + 4 (FCS) = 62 bytes
Two bytes padding are needed to make 64 bytes. Not SIX bytes.
The TI MAC (or driver?) is padding six bytes instead of two.
Somebody should tell TI about their bug.
Thanks,
Richard
|
|
From: Miroslav L. <mli...@re...> - 2022-01-12 16:26:25
|
On Wed, Jan 12, 2022 at 03:57:55PM +0100, Peter Bergin wrote: > IEEE 802.3 minimum PDU size is 64 bytes. PTP messages SYNC, FOLLOW_UP and > DELAY_REQ is smaller than that, 58 bytes. Are there any spec telling how to > send PTP messages smaller than 64 bytes on Ethernet? FWIW, the minimum length of an Ethernet frame includes the 32-bit frame check sequence (FCS), i.e. the minimum payload length (assuming no VLAN tags, etc) is 46 octets. The minimum length of a PTP message is 44 octets, so at most 2 octets are needed to pad a PTP message to the required length. If more padding is needed, the PTP specification allows messages to be padded to (almost) any length with the PAD TLV, but I'm not sure if it is supposed to be the only way. -- Miroslav Lichvar |
|
From: Martin P. <pec...@fe...> - 2022-01-12 16:00:19
|
> You said this is an Nvidia vendor kernel on the jetson? > > I would try a mainline kernel without their hacks. I've already tried that with this card in a normal x86 Ubuntu computer with kernels 5.4 and 5.15. The behavior was exactly the same, though. Martin |
|
From: Richard C. <ric...@gm...> - 2022-01-12 15:36:35
|
On Wed, Jan 12, 2022 at 03:12:15PM +0100, Martin Pecka wrote: > So from the setup point of view, everything seems correct to me. Yes sounds like it. You said this is an Nvidia vendor kernel on the jetson? I would try a mainline kernel without their hacks. Thanks, Richard |
|
From: Peter B. <pe...@be...> - 2022-01-12 15:14:45
|
Hi, I have a setup with TI processor using the cpsw driver from Linux mainline, kernel version 5.4. I'm using IEEE 802.3 network transport and sending PTP frames on Ethernet. When sending SYNC, FOLLOW_UP and DELAY_REQ that has a length of 58 bytes they get padded up to 64 bytes. When receiving FOLLOW_UP and DELAY_REQ in linuxptp they are dropped with message "bad message" because the stack treats the padding as a TLV entry (suffix_post_recv in msg.c returns 4) and the pdulen and messageLength mismatch. IEEE 802.3 minimum PDU size is 64 bytes. PTP messages SYNC, FOLLOW_UP and DELAY_REQ is smaller than that, 58 bytes. Are there any spec telling how to send PTP messages smaller than 64 bytes on Ethernet? On the other side in my setup I have a PC with e1000e driver. On that side when sending SYNC, FOLLOW_UP and DELAY_REQ over Ethernet the PDUs are padded to 60 bytes. Also tested a NXP processor (i.Mx8mp) and that one also padded to 60 bytes. A slightly different approach that is working with linuxptp. Is my issue with the TI processor a driver issue with the cpsw driver in Linux? Thanks, /Peter |
|
From: Martin P. <pec...@fe...> - 2022-01-12 14:12:35
|
>> So it seems the card timestamps FOLLOW_UP and DELAY_RESP packets, but does >> not timestamp SYNC packets. Why could this be? Can it somehow mismatch SYNC >> and FOLLOW_UP messages in the chip and stamp the wrong one? (I think >> FOLLOW_UP stamps are not good for anything, are they?). Or is it still some >> problem with ptp4l not reading the socket? > No, no, NO! > > The msg_sots_missing() function checks the message type. It always > returns FALSE (zero) for non-event messages like FOLLOW_UP. You're right, Richard, I misunderstood what the if-branch does. So I went further in sk.c and verified that the control messages read when receiving SYNC packets do not contain the SO_TIMSTAMPING control message. I further verified that the setsockopt for SO_TIMESTAMPING succeeds and is called with flags=69, which is RX_HARDWARE+TX_HARDWARE+RAW_HARDWARE and that the SIOCSHWTSTAMP succeeds setting rx_filter 12 (HWTSTAMP_FILTER_PTP_V2_EVENT). So from the setup point of view, everything seems correct to me. Thanks, Martin |
|
From: Richard C. <ric...@gm...> - 2022-01-12 05:01:16
|
On Tue, Jan 11, 2022 at 04:57:25PM +0100, Martin Pecka wrote: > So it seems the card timestamps FOLLOW_UP and DELAY_RESP packets, but does > not timestamp SYNC packets. Why could this be? Can it somehow mismatch SYNC > and FOLLOW_UP messages in the chip and stamp the wrong one? (I think > FOLLOW_UP stamps are not good for anything, are they?). Or is it still some > problem with ptp4l not reading the socket? No, no, NO! The msg_sots_missing() function checks the message type. It always returns FALSE (zero) for non-event messages like FOLLOW_UP. Thanks, Richard |
|
From: Martin P. <pec...@fe...> - 2022-01-11 15:57:38
|
I did a deeper investigation of the "received SYNC without timestamp"
problem on the Intel 82576 card.
I instrumented port.c like this:
if (msg_sots_missing(msg) &&
!(p->timestamping == TS_P2P1STEP && msg_type(msg) == PDELAY_REQ)) {
pr_err("%s: received %s without timestamp",
p->log_name, msg_type_string(msg_type(msg)));
msg_put(msg);
return EV_NONE;
} else {
pr_err("%s: received %s with timestamp",
p->log_name, msg_type_string(msg_type(msg)));
}
And it seems the card timestamps some packets!
The log running E2E L2 sync is:
ptp4l[5854.200]: port 1 (eth2): INITIALIZING to SLAVE on INIT_COMPLETE
ptp4l[5854.201]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on
INIT_COMPLETE
ptp4l[5854.202]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on
INIT_COMPLETE
ptp4l[5854.202]: port 1 (eth2): received link status notification
ptp4l[5854.202]: interface index 5 is up
ptp4l[5854.271]: port 1 (eth2): received SYNC without timestamp
ptp4l[5854.272]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5854.397]: port 1 (eth2): received SYNC without timestamp
ptp4l[5854.397]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5854.397]: port 1 (eth2): have FOLLOW_UP 47602, expecting SYNC but
got FOLLOW_UP 47603, dropping
ptp4l[5854.522]: port 1 (eth2): received SYNC without timestamp
ptp4l[5854.523]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5854.523]: port 1 (eth2): have FOLLOW_UP 47603, expecting SYNC but
got FOLLOW_UP 47604, dropping
ptp4l[5854.647]: port 1 (eth2): received SYNC without timestamp
ptp4l[5854.648]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5854.648]: port 1 (eth2): have FOLLOW_UP 47604, expecting SYNC but
got FOLLOW_UP 47605, dropping
ptp4l[5854.773]: port 1 (eth2): received SYNC without timestamp
ptp4l[5854.773]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5854.773]: port 1 (eth2): have FOLLOW_UP 47605, expecting SYNC but
got FOLLOW_UP 47606, dropping
ptp4l[5854.898]: port 1 (eth2): received SYNC without timestamp
ptp4l[5854.898]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5854.898]: port 1 (eth2): have FOLLOW_UP 47606, expecting SYNC but
got FOLLOW_UP 47607, dropping
ptp4l[5855.024]: port 1 (eth2): received SYNC without timestamp
ptp4l[5855.024]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5855.024]: port 1 (eth2): have FOLLOW_UP 47607, expecting SYNC but
got FOLLOW_UP 47608, dropping
ptp4l[5855.149]: port 1 (eth2): received SYNC without timestamp
ptp4l[5855.149]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5855.149]: port 1 (eth2): have FOLLOW_UP 47608, expecting SYNC but
got FOLLOW_UP 47609, dropping
ptp4l[5855.275]: port 1 (eth2): received SYNC without timestamp
ptp4l[5855.276]: port 1 (eth2): received FOLLOW_UP with timestamp
ptp4l[5855.277]: port 1 (eth2): have FOLLOW_UP 47609, expecting SYNC but
got FOLLOW_UP 47610, dropping
ptp4l[5855.313]: port 1 (eth2): delay timeout
ptp4l[5855.314]: port 1 (eth2): received DELAY_RESP with timestamp
ptp4l[5855.400]: port 1 (eth2): received SYNC without timestamp
So it seems the card timestamps FOLLOW_UP and DELAY_RESP packets, but
does not timestamp SYNC packets. Why could this be? Can it somehow
mismatch SYNC and FOLLOW_UP messages in the chip and stamp the wrong
one? (I think FOLLOW_UP stamps are not good for anything, are they?). Or
is it still some problem with ptp4l not reading the socket?
--
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: Richard C. <ric...@gm...> - 2022-01-07 15:23:17
|
On Fri, Jan 07, 2022 at 07:32:39AM +0000, ramesh t wrote: > ptp4l: [325744.430] clockcheck: clock jumped forward or running faster than expected! > ptp4l: [325744.430] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT See this? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please suggest. I suggest reading the log messages to see the clearly identified source of the fault. |
|
From: Vladimir O. <ol...@gm...> - 2022-01-07 14:15:10
|
Hello Thomas, On Fri, 7 Jan 2022 at 16:07, Thomas Reisinger via Linuxptp-users <lin...@li...> wrote: > > Hello, > > Thats my first time here, I hope my question is right placed here. > > I am using the ptp4l/phc2sys services for my master thesis to synchronize my clock for precise timestamping of UDP messages that I am sending in myself programed c socket. Do you have more details about this program? I have one too, called "isochron", and it appears to do the same thing. https://github.com/vladimiroltean/tsn-scripts > When I start the service with "sudo ptp4l -i enp3s0f2 -P -2 -s -m -q", I get every second one of those output messages: > ptp4l[1386285.788]: master offset -4 s2 freq +56281 path delay 289 > > It would be awesome to have access to those values: master offset -4 and the current state "s2". > > With this information I would know, if my timestamped UDP messages are valid (because ptp4l was in locked state with a small master offset), > or if my timestamped UDP messages are invalid (because ptp4l was in an uncalibrated state or the offset was just to high). > > The best case would be something like: > > #include <getThoseValues.h> > > int main(){ > master_offset = getOffsetValue(); > current_state = getCurrentState(); > return 0; > } > > > I hope it was clear, what my problem is and that this functionality would be huge benefit. Erez Geva is developing a library called "libpmc" with bindings for a few programming languages (including C++), but not C: https://sourceforge.net/projects/libpmc/ isochron, which is written in C, has its own open-coded PTP management message handling in ptpmon.c. There's also sysmon.c which monitors phc2sys offset to a given PHC. That code is GPL, so worst case, if you cannot use isochron and cannot use libpmc either, you could copy ptpmon.c and sysmon.c. Vladimir |
|
From: Thomas R. <tre...@fs...> - 2022-01-07 14:02:31
|
Hello,
Thats my first time here, I hope my question is right placed here.
I am using the ptp4l/phc2sys services for my master thesis to synchronize my clock for precise timestamping of UDP messages that I am sending in myself programed c socket.
When I start the service with "sudo ptp4l -i enp3s0f2 -P -2 -s -m -q", I get every second one of those output messages:
ptp4l[1386285.788]: master offset -4 s2 freq +56281 path delay 289
It would be awesome to have access to those values: master offset -4 and the current state "s2".
With this information I would know, if my timestamped UDP messages are valid (because ptp4l was in locked state with a small master offset),
or if my timestamped UDP messages are invalid (because ptp4l was in an uncalibrated state or the offset was just to high).
The best case would be something like:
#include <getThoseValues.h>
int main(){
master_offset = getOffsetValue();
current_state = getCurrentState();
return 0;
}
I hope it was clear, what my problem is and that this functionality would be huge benefit.
Kind Regards,
Thomas
|
|
From: ramesh t <ram...@ya...> - 2022-01-07 07:35:15
|
hi Richard, In BC mode, Port 2 is connected to TestingUnit and Port 1 is connected to BC/GM unit. Observing below behavior on reboot of TestingUnit, Port 1 is going from SLAVE to UNCALIBRATED, which is not correct. Below are the ptp4l and phc2sys command used. ptp4l -2 -A -i enp175s0f1 -i enp95s0f1 -f /etc/ptp4l_bc.conf phc2sys_slave -a -r -n 24 ptp4l: [325741.182] rms 6 max 15 freq +648 +/- 10 delay 373 +/- 1 phc2sya: [325741.509] CLOCK_REALTIME phc offset 19 s2 freq -81940 delay 1150 phc2sys: [325741.510] enp95s0f1 phc offset 4 s2 freq -2830 delay 3808 ptp4l: [325742.182] rms 3 max 7 freq +647 +/- 5 delay 375 +/- 0 phc2sys: [325742.510] CLOCK_REALTIME phc offset 2 s2 freq -81952 delay 1164 phc2sys: [325742.510] enp95s0f1 phc offset -2 s2 freq -2835 delay 3820 ptp4l: [325743.182] rms 5 max 11 freq +646 +/- 9 delay 374 +/- 1 phc2sys: [325743.510] CLOCK_REALTIME phc offset -9 s2 freq -81962 delay 1166 phc2sys: [325743.510] enp95s0f1 phc offset 0 s2 freq -2834 delay 3817 kernel: [324954.668590] i40e 0000:5f:00.1 enp95s0f1: NIC Link is Down ptp4l: [325744.218] timed out while polling for tx timestamp ptp4l: [325744.218] increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l: [325744.218] port 2: send sync failed ptp4l: [325744.218] port 2: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l: [325744.259] clockcheck: clock jumped backward or running slower than expected! ptp4l: [325744.259] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l: [325744.259] PS_SLAVE: port_e2e_transition ptp4l: [325744.259] port 2: link down ptp4l: [325744.259] port 2: NEC received link status notification DOWN ptp4l: [325744.259] selected best master clock 000580.fffe.07cc8a ptp4l: [325744.259] updating UTC offset to 37 ptp4l: [325744.259] rms 5 max 13 freq +643 +/- 6 delay 374 +/- 1 ptp4l: [325744.259] port 2: NEC received link status notification DOWN ptp4l: [325744.366] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l: [325744.366] PS_SLAVE: port_e2e_transition ptp4l: [325744.430] clockcheck: clock jumped forward or running faster than expected! ptp4l: [325744.430] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l: [325744.430] PS_SLAVE: port_e2e_transition phc2sys: [325744.510] port 40a6b7.fffe.0da261-2 changed state phc2sys: [325744.510] port 40a6b7.fffe.0da261-1 changed state phc2sys: message repeated 2 times: [ [325744.510] port 40a6b7.fffe.0da261-1 changed state] phc2sys: [325744.510] reconfiguring after port state change phc2sys: [325744.510] selecting enp95s0f1 for synchronization phc2sys: [325744.510] master clock not ready, waiting... ptp4l: [325744.678] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l: [325744.678] PS_SLAVE: port_e2e_transition ptp4l: [325745.182] rms 16 max 31 freq +646 +/- 44 delay 374 +/- 1 phc2sys: [325745.510] port 40a6b7.fffe.0da261-1 changed state phc2sys: [325745.510] reconfiguring after port state change phc2sys: [325745.510] selecting enp95s0f1 for synchronization phc2sys: [325745.510] selecting CLOCK_REALTIME for synchronization phc2sys: [325745.510] selecting enp175s0f1 as the master clock phc2sys: [325745.510] CLOCK_REALTIME phc offset -11 s2 freq -81967 delay 1149 phc2sys: [325745.510] clockcheck: clock jumped backward or running slower than expected! phc2sys: [325745.510] enp95s0f1 phc offset -1106433060 s0 freq -2834 delay 194 Please suggest. regards, Ramesh On Friday, January 7, 2022, 12:38:31 AM GMT+5:30, ramesh t <ram...@ya...> wrote: hi Richard, >>Why does BC/GM port go to PS_FAULTY? Link down? Sorry, could be issues with my side of the changes. Tried looking into code to find out if there is any variable in port or clock struct which will tell if the interface is acting as client (slave) or server side of PTP. Please suggest. regards, Ramesh On Thursday, January 6, 2022, 08:03:06 AM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Wed, Jan 05, 2022 at 07:34:07PM +0000, ramesh t wrote: > On resetting of the testing unit, observing ptp port state of the > interface connected to BC/GM going to PS_FAULTY temporarily though > it shouldn't be impacted due to reset of testing unit. Why does BC/GM port go to PS_FAULTY? Link down? Thanks, Richard |
|
From: ramesh t <ram...@ya...> - 2022-01-06 19:08:40
|
hi Richard, >>Why does BC/GM port go to PS_FAULTY? Link down? Sorry, could be issues with my side of the changes. Tried looking into code to find out if there is any variable in port or clock struct which will tell if the interface is acting as client (slave) or server side of PTP. Please suggest. regards, Ramesh On Thursday, January 6, 2022, 08:03:06 AM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Wed, Jan 05, 2022 at 07:34:07PM +0000, ramesh t wrote: > On resetting of the testing unit, observing ptp port state of the > interface connected to BC/GM going to PS_FAULTY temporarily though > it shouldn't be impacted due to reset of testing unit. Why does BC/GM port go to PS_FAULTY? Link down? Thanks, Richard |
|
From: Martin P. <pec...@fe...> - 2022-01-06 17:14:22
|
Okay, I got the Linux 5.11 version compiling on the 4.9 kernel (5.15 version was too new). This is what I get (not sure if I'm running it correctly): $ sudo ./timestamp eth2 SOF_TIMESTAMPING_RX_HARDWARE PTPV2 SOF_TIMESTAMPING_TX_HARDWARE IP_MULTICAST_LOOP SOF_TIMESTAMPING_RAW_HARDWARE SO_TIMESTAMPNS SIOCSHWTSTAMP: tx_type 1 requested, got 1; rx_filter 7 requested, got 12 SO_TIMESTAMP 0 SO_TIMESTAMPNS 1 SO_TIMESTAMPING 69 1641489139.531700: select 468300us 1641489140.000559: select returned: 0, success 1641489140.001334: sent 44 bytes 1641489140.001415: select 4998585us 1641489140.001471: select returned: 1, success ready for reading 1641489140.001559: received regular data, 44 bytes from 192.168.88.93, 128 bytes control messages cmsg len 32: SOL_SOCKET SO_TIMESTAMPNS 1641489140.000892168 cmsg len 64: SOL_SOCKET SO_TIMESTAMPING SW 0.000000000 HW raw 78435.216557216 cmsg len 28: IPPROTO_IP IP_PKTINFO interface index 5 1641489140.002104: received error data, 86 bytes from 192.168.88.93, 144 bytes control messages cmsg len 32: SOL_SOCKET SO_TIMESTAMPNS 1641489140.002095905 cmsg len 64: SOL_SOCKET SO_TIMESTAMPING SW 0.000000000 HW raw 78435.216557216 cmsg len 48: IPPROTO_IP IP_RECVERR ee_errno 'No message of desired type' ee_origin 4 => bounced packet => GOT OUR DATA BACK (HURRAY!) 1641489140.002271: select 4997729us 1641489145.005062: select returned: 0, success 1641489145.005317: sent 44 bytes 1641489145.005975: select 4994025us 1641489145.006277: select returned: 1, success ready for reading 1641489145.006809: received regular data, 44 bytes from 192.168.88.93, 128 bytes control messages cmsg len 32: SOL_SOCKET SO_TIMESTAMPNS 1641489145.005170451 cmsg len 64: SOL_SOCKET SO_TIMESTAMPING SW 0.000000000 HW raw 78440.221013888 cmsg len 28: IPPROTO_IP IP_PKTINFO interface index 5 1641489145.007829: received error data, 86 bytes from 192.168.88.93, 144 bytes control messages cmsg len 32: SOL_SOCKET SO_TIMESTAMPNS 1641489145.007821168 cmsg len 64: SOL_SOCKET SO_TIMESTAMPING SW 0.000000000 HW raw 78440.221013888 cmsg len 48: IPPROTO_IP IP_RECVERR ee_errno 'No message of desired type' ee_origin 4 => bounced packet => GOT OUR DATA BACK (HURRAY!) 1641489145.009039: select 4990961us |
|
From: Richard C. <ric...@gm...> - 2022-01-06 16:33:37
|
On Thu, Jan 06, 2022 at 05:24:48PM +0100, Martin Pecka wrote: > Is there any other way to test the timestamping? E.g. a short C snippet to > compile and figure out if the stamps are coming if requested? In the linux kernel source tree: tools/testing/selftests/net/timestamping.c HTH, Richard |
|
From: Martin P. <pec...@fe...> - 2022-01-06 16:25:06
|
Dne 31. 12. 21 v 1:41 Keller, Jacob E napsal(a): > You won't see igb_process_skb_fields in the grep for ptp, because it > doesn't have ptp in its name, nor does its caller. Did not mention it, but of course I searched for it with a different grep pattern. There were none, though! Could there be another function called to process incoming packets? > Unless you have some network setup that is weird like VLANs, changing > the port numbers, etc.. I don't see much else that could be wrong here. Nothing weird in the setup, plain ethernet interfaces configured with out-of-stock Ubuntu (or the Linux4Tegra Ubuntu). > Nothing obvious is different between newer drivers, though its possible > there is a bug in both this driver version and the most recent driver... I finally managed to find a normal desktop x86 computer and put the card in it. The problem is the same even with x86 kernels 5.4 and 5.15. So I would rule out the kernel (or at least the fact that I test it on a 4.9 kernel aarch64 computer). >> I can provide a "diff" of the trace with the working igb card. >> >> Right. I suspect this comparison won't help us much because the newer >> card supports timestamping all frames, while this card does not. You were right, there was nothing interesting in the log from the better igb card. It looked completely different as it is timestamping all packets. When I find some time, I'll try to play around with linuxptp and how it sets up the capture, as I'd consider it weird that the cards support timestamping, Linux cannot handle it, and nobody ever noticed... I think driver error could be also ruled out because both igb and ixgbe are affected (well, they're both Intel, so maybe they could also copy-paste a bug, but I wouldn't bet on that...). Both of the problematic cards have in common that they don't support timestamping all packets, but report to support HWTSTAMP_FILTER_PTP_V2_EVENT, which should be enough for linuxptp. Is there any other way to test the timestamping? E.g. a short C snippet to compile and figure out if the stamps are coming if requested? Thanks for help, Martin |
|
From: Richard C. <ric...@gm...> - 2022-01-06 02:33:11
|
On Wed, Jan 05, 2022 at 07:34:07PM +0000, ramesh t wrote: > On resetting of the testing unit, observing ptp port state of the > interface connected to BC/GM going to PS_FAULTY temporarily though > it shouldn't be impacted due to reset of testing unit. Why does BC/GM port go to PS_FAULTY? Link down? Thanks, Richard |
|
From: ramesh t <ram...@ya...> - 2022-01-06 02:12:34
|
hi Richard, >>Using option -a will automatically time sync all the PHC devices in the system. >>Is there a way to sync only those interface which are part of BC configuration (port connected to Testing Unit)?? Please ignore above question. Repeated the testing with phc2sys automatic mode (-a), still same issue is seen. (Used command: phc2sys -a -r -n 24) Please suggest. regards, Ramesh On Thursday, January 6, 2022, 07:10:20 AM GMT+5:30, ramesh t <ram...@ya...> wrote: hi Richard, Using option -a will automatically time sync all the PHC devices in the system. Is there a way to sync only those interface which are part of BC configuration (port connected to Testing Unit)?? Using -a option, will it help to solve this issue seen? Because ptp4l is going into PS_FAULTY? Please suggest. regards, Ramesh On Thursday, January 6, 2022, 01:33:54 AM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Wed, Jan 05, 2022 at 07:34:07PM +0000, ramesh t wrote: > hi, > > Running ptp4l in BC mode, with clock_type set to BC and boundary_clock_jbod set to 1. Have connected one NIC port to BC/GM and another NIC port to testing unit (TU). Following is the ptp4l command. > > ./ptp4l -2 -A -w -i <port connected to BC/GM> -i <port connected to TU> -f /etc/ptp4l_bc.c > > In BC mode, ptp4l getting clock from BC/GM and is providing clock to testing unit. > > Also running below phc2sys command: > phc2sys -s <port to connected to BC/GM> -c CLOCK_REALTIME -w -r -n 24 > phc2sys -s <port to connected to BC/GM> -c <port connected to TU> -r -w -n 24 You should use the phc2sys automatic mode (-a) when using boundary_clock_jbod. Thanks, Richard |
|
From: ramesh t <ram...@ya...> - 2022-01-06 01:40:43
|
hi Richard, Using option -a will automatically time sync all the PHC devices in the system. Is there a way to sync only those interface which are part of BC configuration (port connected to Testing Unit)?? Using -a option, will it help to solve this issue seen? Because ptp4l is going into PS_FAULTY? Please suggest. regards, Ramesh On Thursday, January 6, 2022, 01:33:54 AM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Wed, Jan 05, 2022 at 07:34:07PM +0000, ramesh t wrote: > hi, > > Running ptp4l in BC mode, with clock_type set to BC and boundary_clock_jbod set to 1. Have connected one NIC port to BC/GM and another NIC port to testing unit (TU). Following is the ptp4l command. > > ./ptp4l -2 -A -w -i <port connected to BC/GM> -i <port connected to TU> -f /etc/ptp4l_bc.c > > In BC mode, ptp4l getting clock from BC/GM and is providing clock to testing unit. > > Also running below phc2sys command: > phc2sys -s <port to connected to BC/GM> -c CLOCK_REALTIME -w -r -n 24 > phc2sys -s <port to connected to BC/GM> -c <port connected to TU> -r -w -n 24 You should use the phc2sys automatic mode (-a) when using boundary_clock_jbod. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2022-01-05 20:01:47
|
On Wed, Jan 05, 2022 at 07:34:07PM +0000, ramesh t wrote: > hi, > > Running ptp4l in BC mode, with clock_type set to BC and boundary_clock_jbod set to 1. Have connected one NIC port to BC/GM and another NIC port to testing unit (TU). Following is the ptp4l command. > > ./ptp4l -2 -A -w -i <port connected to BC/GM> -i <port connected to TU> -f /etc/ptp4l_bc.c > > In BC mode, ptp4l getting clock from BC/GM and is providing clock to testing unit. > > Also running below phc2sys command: > phc2sys -s <port to connected to BC/GM> -c CLOCK_REALTIME -w -r -n 24 > phc2sys -s <port to connected to BC/GM> -c <port connected to TU> -r -w -n 24 You should use the phc2sys automatic mode (-a) when using boundary_clock_jbod. Thanks, Richard |
|
From: ramesh t <ram...@ya...> - 2022-01-05 19:34:20
|
hi, Running ptp4l in BC mode, with clock_type set to BC and boundary_clock_jbod set to 1. Have connected one NIC port to BC/GM and another NIC port to testing unit (TU). Following is the ptp4l command. ./ptp4l -2 -A -w -i <port connected to BC/GM> -i <port connected to TU> -f /etc/ptp4l_bc.c In BC mode, ptp4l getting clock from BC/GM and is providing clock to testing unit. Also running below phc2sys command: phc2sys -s <port to connected to BC/GM> -c CLOCK_REALTIME -w -r -n 24 phc2sys -s <port to connected to BC/GM> -c <port connected to TU> -r -w -n 24 On resetting of the testing unit, observing ptp port state of the interface connected to BC/GM going to PS_FAULTY temporarily though it shouldn't be impacted due to reset of testing unit. Verified the same behavior is seen with latest linuxptp4l code. Please suggest. regards, Ramesh |
27 messages has been excluded from this view by a project administrator.
