linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] received SYNC without timestamp

[Keller, J. E <jac...@in...>]

On 12/29/2021 1:12 PM, pec...@fe... wrote:
> Thanks for the ftrace tips, Jake.
> 
> I ran it with a 'igb_*' filter and grepped everything with ptp and
> excluded the rx_hang calls. This is the whole trace after starting the
> PTP client:
> 
>            ptp4l-23256 [007] ...1 1064642.422359: igb_ptp_gettime_82576 <-ptp_clock_gettime
>            ptp4l-23256 [007] d..2 1064642.422362: igb_ptp_read_82576 <-timecounter_read
>            ptp4l-23256 [007] d..2 1064642.422362: igb_rd32 <-igb_ptp_read_82576
>            ptp4l-23256 [007] d..2 1064642.422366: igb_rd32 <-igb_ptp_read_82576
>            ptp4l-23256 [007] ...1 1064642.422388: igb_ptp_adjfreq_82576 <-ptp_clock_adjtime
>            ptp4l-23256 [007] ...1 1064642.472550: igb_ptp_set_ts_config <-igb_ioctl
>            ptp4l-23256 [007] ...1 1064642.472551: igb_ptp_set_timestamp_mode <-igb_ptp_set_ts_config
>            ptp4l-23256 [007] ...1 1064642.472552: igb_rd32 <-igb_ptp_set_timestamp_mode
>            ptp4l-23256 [007] ...1 1064642.472557: igb_rd32 <-igb_ptp_set_timestamp_mode
>            ptp4l-23256 [007] ...1 1064642.472567: igb_rd32 <-igb_ptp_set_timestamp_mode
>            ptp4l-23256 [007] ...1 1064642.472571: igb_rd32 <-igb_ptp_set_timestamp_mode
>            ptp4l-23256 [007] ...1 1064642.472576: igb_rd32 <-igb_ptp_set_timestamp_mode
>            ptp4l-23256 [007] ...1 1064642.472581: igb_rd32 <-igb_ptp_set_timestamp_mode
>            ptp4l-23256 [007] ...1 1064642.472585: igb_rd32 <-igb_ptp_set_timestamp_mode
>      kworker/7:0-19672 [007] ...1 1064642.682658: igb_ptp_tx_work <-process_one_work
>      kworker/7:0-19672 [007] ...1 1064642.682660: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064642.682666: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064642.682670: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064642.682673: igb_ptp_systim_to_hwtstamp <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064644.014869: igb_ptp_tx_work <-process_one_work
>      kworker/7:0-19672 [007] ...1 1064644.014878: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064644.014884: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064644.014888: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064644.014891: igb_ptp_systim_to_hwtstamp <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064645.055664: igb_ptp_tx_work <-process_one_work
>      kworker/7:0-19672 [007] ...1 1064645.055665: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064645.055672: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064645.055675: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064645.055679: igb_ptp_systim_to_hwtstamp <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064645.521853: igb_ptp_tx_work <-process_one_work
>      kworker/7:0-19672 [007] ...1 1064645.521854: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064645.521860: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064645.521864: igb_rd32 <-igb_ptp_tx_work
>      kworker/7:0-19672 [007] ...1 1064645.521867: igb_ptp_systim_to_hwtstamp <-igb_ptp_tx_work
> 
> So there's not a single call to igb_ptp_rx_rgtstamp . There's even not a
> single call to igb_process_skb_fields . That's kind of weird. But
> wireshark sees packets coming, so they should not be discarded.
> 

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.

Your particular device, if I remember, should be an older card which
only supports one timestamp at a time.

Because this hardware only supports timestamping one frame at a time, it
is plausible that somehow the config for what packets to timestamp is
broken..

But I checked the set timestamp mode function and it looks reasonable.
For L2 packets this sets an ethertype filter on the PTP ethertype. For
L4 packets it sets a filter for the PTP UDP port.

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 obvious is different between newer drivers, though its possible
there is a bug in both this driver version and the most recent driver...

> If it helps, I think this is the exact version of igb running on the
> machine:
> https://nv-tegra.nvidia.com/r/gitweb?p=linux-4.9.git;a=tree;f=drivers/net/ethernet/intel/igb;hb=43744be0144f1aefb06ade8e684fe5497d557e6f
> . It is compiled in the kernel, not as a module.
> 

I did fetch this and take a closer look. There are some changes but
nothing in the PTP area that looks especially problematic.

> Thanks for further hints. On Jan 3 I should get back to the hardware, so
> then 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.


At this point, I think I've exhausted all the potential obvious avenues
of known issues I recall being fixed.

> 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 
> 

Re: [Linuxptp-users] What is openil/linuxptp ?

[Ravi R <to...@ya...>]

 Thanks Vladimir !

    On Thursday, December 30, 2021, 04:35:17 PM PST, Vladimir Oltean <ol...@gm...> wrote:  
 
 On Fri, Dec 31, 2021 at 12:24:10AM +0000, Ravi R via Linuxptp-users wrote:
> Hi,    I am confused and unclear about the relation between three different linuxptp source code:
> #1. linuxptp PTP IEEE 1588 stack for Linux Brought to you by:
> #2.  GitHub - richardcochran/linuxptp: User space PTP stack for the GNU/Linux operating system.
> #3. GitHub - openil/linuxptp: PTP IEEE 1588 stack for Linux 
> Seems like #2 is a mirror of #1 - how often is the sync ?
> 
> can someone clarify to me please ?
> Thanks!Ravi

#3 (openil/linuxptp) is the result of some people pressing the "fork"
button and making some extra changes on top. You can safely ignore it.
The only official repository, and the one used by distributions for
packaging, is the one on Sourceforge AFAIK. It is rather unfortunate
that other repositories come up in front of that on a Google search.
  

Re: [Linuxptp-users] What is openil/linuxptp ?

[Vladimir O. <ol...@gm...>]

On Fri, Dec 31, 2021 at 12:24:10AM +0000, Ravi R via Linuxptp-users wrote:
> Hi,    I am confused and unclear about the relation between three different linuxptp source code:
> #1. linuxptp PTP IEEE 1588 stack for Linux Brought to you by:
> #2.  GitHub - richardcochran/linuxptp: User space PTP stack for the GNU/Linux operating system.
> #3. GitHub - openil/linuxptp: PTP IEEE 1588 stack for Linux 
> Seems like #2 is a mirror of #1 - how often is the sync ?
> 
> can someone clarify to me please ?
> Thanks!Ravi

#3 (openil/linuxptp) is the result of some people pressing the "fork"
button and making some extra changes on top. You can safely ignore it.
The only official repository, and the one used by distributions for
packaging, is the one on Sourceforge AFAIK. It is rather unfortunate
that other repositories come up in front of that on a Google search.

[Linuxptp-users] What is openil/linuxptp ?

[Ravi R <to...@ya...>]

Hi,    I am confused and unclear about the relation between three different linuxptp source code:
#1. linuxptp PTP IEEE 1588 stack for Linux Brought to you by:

| 
| 
|  | 
linuxptp PTP IEEE 1588 stack for ...


 |

 |

 |



#2.  GitHub - richardcochran/linuxptp: User space PTP stack for the GNU/Linux operating system.

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
GitHub - richardcochran/linuxptp: User space PTP stack for the GNU/Linux...

User space PTP stack for the GNU/Linux operating system. - GitHub - richardcochran/linuxptp: User space PTP stac...
 |

 |

 |


#3. GitHub - openil/linuxptp: PTP IEEE 1588 stack for Linux 


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
GitHub - openil/linuxptp: PTP IEEE 1588 stack for Linux

PTP IEEE 1588 stack for Linux. Contribute to openil/linuxptp development by creating an account on GitHub.
 |

 |

 |


Seems like #2 is a mirror of #1 - how often is the sync ?

can someone clarify to me please ?
Thanks!Ravi

Re: [Linuxptp-users] received SYNC without timestamp

[<pec...@fe...>]

Thanks for the ftrace tips, Jake.

I ran it with a 'igb_*' filter and grepped everything with ptp and 
excluded the rx_hang calls. This is the whole trace after starting the 
PTP client:

            ptp4l-23256 [007] ...1 1064642.422359: igb_ptp_gettime_82576 <-ptp_clock_gettime
            ptp4l-23256 [007] d..2 1064642.422362: igb_ptp_read_82576 <-timecounter_read
            ptp4l-23256 [007] d..2 1064642.422362: igb_rd32 <-igb_ptp_read_82576
            ptp4l-23256 [007] d..2 1064642.422366: igb_rd32 <-igb_ptp_read_82576
            ptp4l-23256 [007] ...1 1064642.422388: igb_ptp_adjfreq_82576 <-ptp_clock_adjtime
            ptp4l-23256 [007] ...1 1064642.472550: igb_ptp_set_ts_config <-igb_ioctl
            ptp4l-23256 [007] ...1 1064642.472551: igb_ptp_set_timestamp_mode <-igb_ptp_set_ts_config
            ptp4l-23256 [007] ...1 1064642.472552: igb_rd32 <-igb_ptp_set_timestamp_mode
            ptp4l-23256 [007] ...1 1064642.472557: igb_rd32 <-igb_ptp_set_timestamp_mode
            ptp4l-23256 [007] ...1 1064642.472567: igb_rd32 <-igb_ptp_set_timestamp_mode
            ptp4l-23256 [007] ...1 1064642.472571: igb_rd32 <-igb_ptp_set_timestamp_mode
            ptp4l-23256 [007] ...1 1064642.472576: igb_rd32 <-igb_ptp_set_timestamp_mode
            ptp4l-23256 [007] ...1 1064642.472581: igb_rd32 <-igb_ptp_set_timestamp_mode
            ptp4l-23256 [007] ...1 1064642.472585: igb_rd32 <-igb_ptp_set_timestamp_mode
      kworker/7:0-19672 [007] ...1 1064642.682658: igb_ptp_tx_work <-process_one_work
      kworker/7:0-19672 [007] ...1 1064642.682660: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064642.682666: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064642.682670: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064642.682673: igb_ptp_systim_to_hwtstamp <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064644.014869: igb_ptp_tx_work <-process_one_work
      kworker/7:0-19672 [007] ...1 1064644.014878: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064644.014884: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064644.014888: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064644.014891: igb_ptp_systim_to_hwtstamp <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064645.055664: igb_ptp_tx_work <-process_one_work
      kworker/7:0-19672 [007] ...1 1064645.055665: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064645.055672: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064645.055675: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064645.055679: igb_ptp_systim_to_hwtstamp <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064645.521853: igb_ptp_tx_work <-process_one_work
      kworker/7:0-19672 [007] ...1 1064645.521854: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064645.521860: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064645.521864: igb_rd32 <-igb_ptp_tx_work
      kworker/7:0-19672 [007] ...1 1064645.521867: igb_ptp_systim_to_hwtstamp <-igb_ptp_tx_work

So there's not a single call to igb_ptp_rx_rgtstamp . There's even not a 
single call to igb_process_skb_fields . That's kind of weird. But 
wireshark sees packets coming, so they should not be discarded.

If it helps, I think this is the exact version of igb running on the 
machine: 
https://nv-tegra.nvidia.com/r/gitweb?p=linux-4.9.git;a=tree;f=drivers/net/ethernet/intel/igb;hb=43744be0144f1aefb06ade8e684fe5497d557e6f 
. It is compiled in the kernel, not as a module.

Thanks for further hints. On Jan 3 I should get back to the hardware, so 
then I can provide a "diff" of the trace with the working igb card.

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

Re: [Linuxptp-users] received SYNC without timestamp

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Martin Pecka <pec...@fe...>
> Sent: Wednesday, December 22, 2021 4:16 PM
> To: lin...@li...
> Subject: Re: [Linuxptp-users] received SYNC without timestamp
> 
> Hi Jake and others.
> 
> I'm sorry for the slow response time, but it's Christmas time and I have
> vacation. This also means I won't physically get to the computer until
> January, but it is still running with the faulty Gbit card (igb driver),
> so I can examine it remotely. Answers follow.
> 
> Dne 18. 12. 21 v 13:13 lin...@li...
> napsal(a):
> 
> > Ok. So its based on the 4.9 kernel?
> Yes.
> > The only other thing I might suggest is using ftrace to check whether
> > igb_ptp_rx_rgtstamp and related functions are actually being called.
> >
> > This function is called in igb_process_skb_fields when a receive packet
> > is detected as having a timestamp captured in the register.
> 
> Fortunately, the kernel has ftrace already enabled, so I did the test
> with the PTP client running. What's interesting is that ftrace doesn't
> report any calls of igb_process_skb_fields. It does also report no
> usages of igb_ptp_rx_tgtstamp. However, I saw this in the log:
> 
>       kworker/4:0-9357  [004] ...1 471985.266393: igb_ptp_rx_hang
> <-igb_watchdog_task
>       kworker/4:0-9357  [004] ...1 471985.266393: igb_rd32
> <-igb_ptp_rx_hang
> 
> I'm not sure if it's helpful, but it's the only thing I got.
> 

Ok. So those are expected to be called periodically. They are periodic functions which check whether possible hang conditions are true.

The Rx hang detection is to check whether or not a Receive timestamp has been marked as "valid" for longer than a few seconds. This implies that hardware captured a receive timestamp but software never delivered the packet. If this occurs, no future Rx timestamps would ever be triggered by hardware, because it won't capture a new timestamp until the receive timestamp register valid bit is cleared (If I recall correct, this is a Clear-on-Read event).

 

> Just to check, this is the way I'm reading the ftrace:
> 
> echo function | sudo tee /sys/kernel/debug/tracing/current_tracer; for i
> in $(seq 1 10); do sudo cat /sys/kernel/debug/tracing/trace | grep -C3
> igb_ptp; done; echo nop | sudo tee /sys/kernel/debug/tracing/current_tracer
> 

That seems a bit weird to me. You're writing function in, then reading, and then disabling function tracer?

I would just do "echo function | sudo tee /sys/kernel/debug/tracing/current_tracer" before the test starts, and then the following:

cat /sys/kernel/debug/tracing/trace_pipe | grep -C3 ice_ptp

This command can be left executing (trace_pipe is a variant of the trace file which acts as a pipe and will continue processing new traces until you close the access, that way the cat stays open and reads it like a pipe instead of getting an EOF).

You could then execute the test using ptp4l, and leave tracer as function the whole time.

I suspect in your case what has happened is that the function tracer wasn't on when the test was run since you only enabled it just before calling the cat process to read it.

You can also limit the trace a bit by set_ftrace_filter, so if you jsut wanna trace only igb calls you can do:

echo ':mod:igb' > /sys/kernel/debug/tracing/set_ftrace_filter

which will add filters for every function that is in the igb module and nothing else. Then you shouldn't need the grep ice_ptp either.

Thanks,
Jake

Re: [Linuxptp-users] received SYNC without timestamp

[Martin P. <pec...@fe...>]

Hi Jake and others.

I'm sorry for the slow response time, but it's Christmas time and I have 
vacation. This also means I won't physically get to the computer until 
January, but it is still running with the faulty Gbit card (igb driver), 
so I can examine it remotely. Answers follow.

Dne 18. 12. 21 v 13:13 lin...@li... 
napsal(a):

> Ok. So its based on the 4.9 kernel?
Yes.
> The only other thing I might suggest is using ftrace to check whether
> igb_ptp_rx_rgtstamp and related functions are actually being called.
>
> This function is called in igb_process_skb_fields when a receive packet
> is detected as having a timestamp captured in the register.

Fortunately, the kernel has ftrace already enabled, so I did the test 
with the PTP client running. What's interesting is that ftrace doesn't 
report any calls of igb_process_skb_fields. It does also report no 
usages of igb_ptp_rx_tgtstamp. However, I saw this in the log:

      kworker/4:0-9357  [004] ...1 471985.266393: igb_ptp_rx_hang 
<-igb_watchdog_task
      kworker/4:0-9357  [004] ...1 471985.266393: igb_rd32 
<-igb_ptp_rx_hang

I'm not sure if it's helpful, but it's the only thing I got.

Just to check, this is the way I'm reading the ftrace:

echo function | sudo tee /sys/kernel/debug/tracing/current_tracer; for i 
in $(seq 1 10); do sudo cat /sys/kernel/debug/tracing/trace | grep -C3 
igb_ptp; done; echo nop | sudo tee /sys/kernel/debug/tracing/current_tracer

In January, I'll be able to provide ftrace comparison with the working 
igb card.

Thanks for further guidance here.

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

Re: [Linuxptp-users] received SYNC without timestamp

[Keller, J. E <jac...@in...>]

On 12/17/2021 5:30 AM, Martin Pecka wrote:
> Thanks for the very prompt reply, Jake. My answers below.
>> What version of the kernel and drivers are you using?
> Linux clone-robot-jetson 4.9.253-tegra #1 SMP PREEMPT Mon Jul 26
> 12:19:28 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux
> 
> driver: igb
> version: 5.4.0-k
> firmware-version: 1.2.1
> 
> driver: ixgbe
> version: 4.4.0-k
> 

Ok. So its based on the 4.9 kernel?

At a glance, at least for ixgbe it looks like at least one potential
commit since 4.9 to ixgbe_ptp.c could be at fault:

aeb4c73100be ("ixgbe: Fix incorrect bitwise operations of PTP Rx
timestamp flags")

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeb4c73100be8aade8a1189b50bd226b709ca8bb

If you're comfortable checking source, you could see if your kernel has
this particular defect or not. At least this would help us confirm the
case for X540.



> Unfortunately, it'd be difficult to test newer kernels as this is NVidia
> Jetson Xavier AGX, which needs an nvidia-customized kernel to run. They
> haven't issued yet any newer versions. But if there is a known bug in
> the NIC drivers in this kernel version, I'd understand that there's not
> much to do (except e.g. asking NVidia to backport the patches).
>> So this is the X540 which is receiving the frames? The "SYNC without
>> timestamp" means that the packet is received without a timestamp.
> Yes, the problematic chips are X540 and 82576.
>> Could you check the ethtool stats output and see if rx_hwtstamp_cleared
>> is incrementing?
> No, it is always zero on all tested cards. Even on the working card with
> I350.

Ok, so its probably not the Rx timestamp hang problem where a timestamp
is stuck in the register but not freed up.

>> Another possible check would be to use the test utility testptp and
>> verify that the network device clock is actually incrementing.
> Ran the test, time is incrementing.
>> I believe "SYNC without timestamp" can occur if the reported timestamp is 0?
> Is that the same as not set?
>> Could you try layer 3 UDP packets instead of L2?
> No difference with either UDPv4 or UDPv6 transports. I also tried P2P
> instead of E2E, but still no difference.
> 

Interesting. So its not related to the layer. That surprises me since
these devices don't support timestamping all frames. I had thought
possibly there was a bug in the L2 setup. But this seems to indicate the
issue is not in the packet layer setup...

> I attach two PCAPs from the client machine recorded using tshark.
> ptp_goog.pcapng is the case with I350 where PTP works. ptp_bad.pcapng is
> the case with 82576 where PTP does not work. I saw only one difference -
> logMessagePeriod is -3 in the bad case and 0 in the good case. But I
> couldn't find any documentation on what does this value mean.
> 

I'm not familiar with what logMessagePeriod means either.

> I'll add one maybe relevant information - the computer I use as a client
> has an integrated PTP-capable NIC, too (eqos driver). With this one, PTP
> sync works. And both the non-working PCIe cards are two-port cards
> (without an internal switch - each port is connected as a separated PCI
> device). So in the end, the system sees 3 NICs and 3 PTP clock devices.
> When running ptp4l, I always specify just the NIC and let ptp4l select
> the clock.
> 

Yea that's fine. ptp4l is able to figure out which clock is associated
with which NIC.

> Thanks for further help,
> Martin
>

The only other thing I might suggest is using ftrace to check whether
igb_ptp_rx_rgtstamp and related functions are actually being called.

This function is called in igb_process_skb_fields when a receive packet
is detected as having a timestamp captured in the register.

I believe ixgbe also has a similar function, but I am suspicious that
the ixgbe device is fixed with the commit mentioned above.

Thanks,
Jake
 >
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] received SYNC without timestamp

[Martin P. <pec...@fe...>]

Thanks for the very prompt reply, Jake. My answers below.
> What version of the kernel and drivers are you using?
Linux clone-robot-jetson 4.9.253-tegra #1 SMP PREEMPT Mon Jul 26 
12:19:28 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux

driver: igb
version: 5.4.0-k
firmware-version: 1.2.1

driver: ixgbe
version: 4.4.0-k

Unfortunately, it'd be difficult to test newer kernels as this is NVidia 
Jetson Xavier AGX, which needs an nvidia-customized kernel to run. They 
haven't issued yet any newer versions. But if there is a known bug in 
the NIC drivers in this kernel version, I'd understand that there's not 
much to do (except e.g. asking NVidia to backport the patches).
> So this is the X540 which is receiving the frames? The "SYNC without
> timestamp" means that the packet is received without a timestamp.
Yes, the problematic chips are X540 and 82576.
> Could you check the ethtool stats output and see if rx_hwtstamp_cleared
> is incrementing?
No, it is always zero on all tested cards. Even on the working card with 
I350.
> Another possible check would be to use the test utility testptp and
> verify that the network device clock is actually incrementing.
Ran the test, time is incrementing.
> I believe "SYNC without timestamp" can occur if the reported timestamp is 0?
Is that the same as not set?
> Could you try layer 3 UDP packets instead of L2?
No difference with either UDPv4 or UDPv6 transports. I also tried P2P 
instead of E2E, but still no difference.

I attach two PCAPs from the client machine recorded using tshark. 
ptp_goog.pcapng is the case with I350 where PTP works. ptp_bad.pcapng is 
the case with 82576 where PTP does not work. I saw only one difference - 
logMessagePeriod is -3 in the bad case and 0 in the good case. But I 
couldn't find any documentation on what does this value mean.

I'll add one maybe relevant information - the computer I use as a client 
has an integrated PTP-capable NIC, too (eqos driver). With this one, PTP 
sync works. And both the non-working PCIe cards are two-port cards 
(without an internal switch - each port is connected as a separated PCI 
device). So in the end, the system sees 3 NICs and 3 PTP clock devices. 
When running ptp4l, I always specify just the NIC and let ptp4l select 
the clock.

Thanks for further help,
Martin

Re: [Linuxptp-users] System Clock not synchronized correctly

[Kirchhoff, P. <phi...@si...>]

I> f you try "phc_ctl eth1 get" and "phc_ctl eth2 get" commands, is the
> time roughly correct or is it in the past too?

It is in the past too.

> The capture shows that the sync messages have correctionField set to
> about -68135 seconds. That is very suspicious.

What ist the meaning of the correctionField? Can you tell me where I can find more info on this?


________________________________
From: Miroslav Lichvar <mli...@re...>
Sent: Thursday, December 16, 2021 9:35 AM
To: Kirchhoff, Philip (SE GP T HG PE T 1 2) <phi...@si...>
Cc: lin...@li... <lin...@li...>
Subject: Re: [Linuxptp-users] System Clock not synchronized correctly

On Thu, Dec 16, 2021 at 07:54:14AM +0000, Kirchhoff, Philip wrote:
> Hi,
>
> I have a problem with an embedded device running Timemaster/ptp4l. The ptp4l says that it is synchronized to the GM but the system time is several hours in the past. The device has two redundant ethernet ports (PRP).

If you try "phc_ctl eth1 get" and "phc_ctl eth2 get" commands, is the
time roughly correct or is it in the past too?

> Please find attached the related log files and a wireshark capture.

The capture shows that the sync messages have correctionField set to
about -68135 seconds. That is very suspicious.

--
Miroslav Lichvar

Re: [Linuxptp-users] Does not show the offset frequency etc..

[藍彥凱 <ggy...@gm...>]

Dear Richard

Yes i  have checked the standard "the originTimestamp shallbe set to 0
or worse than +-1s"


But I still haven’t found the reason for the packet (Delay_Resp message) loss

The firewall has also been confirmed

inactive


If there is any way please let me know thank you




Richard Cochran <ric...@gm...> 於 2021年12月15日 週三 下午10:37寫道：

> On Wed, Dec 15, 2021 at 10:32:06PM +0800, 藍彥凱 wrote:
> > Sync_Message and Delay_Req Message originTimestamp always 0 (seconds &
> > nanoseconds)
>
> This is normal and expected.  See IEEE 1588 to understand the meaning
> of the message fields.
>
> Thanks,
> Richard
>

Re: [Linuxptp-users] received SYNC without timestamp

[Keller, J. E <jac...@in...>]

On 12/16/2021 9:04 AM, Martin Pecka wrote:
> Hi PTP users.
> 
> We bought a few PCIe network cards for testing, all with Intel chipsets 
> and supposedly supporting PTP. I succeeded running HW-stamping PTP L2 
> client on a card with I350 chipset and igb driver.
> 
> However, two of the cards have a problem. The symptoms are the same, 
> although one is 1GbE with Intel 82576 chipset running igb driver and the 
> other is 10GbE with Intel X540 running ixgbe driver.
> 
> The timestamping capabilities for both look like this:
> 

What version of the kernel and drivers are you using?

> $ ethtool -T eth2
> Time stamping parameters for eth2:
> Capabilities:
>      hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
>      software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
>      hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
>      software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
>      software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
>      hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
> PTP Hardware Clock: 1
> Hardware Transmit Timestamp Modes:
>      off                   (HWTSTAMP_TX_OFF)
>      on                    (HWTSTAMP_TX_ON)
> Hardware Receive Filter Modes:
>      none                  (HWTSTAMP_FILTER_NONE)
>      ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
>      ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
>      ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
> 
> Most importantly, ptpv2-event is there, as well as HW stamping and HW 
> clock. So PTP should be satisfied, shouldn't it? But the synchronization 
> never happens. This is what I see running the client:
> 
> $ sudo /usr/local/sbin/ptp4l -H -i eth2 -f 
> /etc/linuxptp/automotive-slave.cfg --step_threshold=0.001 -m -l7 | grep 
> -v config
> ptp4l[1127.941]: interface index 5 is up
> ptp4l[1127.941]: selected /dev/ptp1 as PTP clock
> ptp4l[1127.941]: section item /var/run/ptp4l.announceReceiptTimeout now 0
> ptp4l[1127.941]: section item /var/run/ptp4l.delay_mechanism now 0
> ptp4l[1127.941]: section item /var/run/ptp4l.network_transport now 0
> ptp4l[1127.941]: section item /var/run/ptp4l.delay_filter_length now 1
> ptp4l[1127.941]: section item /var/run/ptp4lro.announceReceiptTimeout now 0
> ptp4l[1127.941]: section item /var/run/ptp4lro.delay_mechanism now 0
> ptp4l[1127.941]: section item /var/run/ptp4lro.network_transport now 0
> ptp4l[1127.941]: section item /var/run/ptp4lro.delay_filter_length now 1
> ptp4l[1127.942]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
> ptp4l[1128.000]: port 1 (eth2): INITIALIZING to SLAVE on INIT_COMPLETE
> ptp4l[1128.001]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on 
> INIT_COMPLETE
> ptp4l[1128.002]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on 
> INIT_COMPLETE
> ptp4l[1128.002]: port 1 (eth2): received link status notification
> ptp4l[1128.002]: interface index 5 is up
> ptp4l[1128.532]: port 1 (eth2): received SYNC without timestamp
> ptp4l[1129.097]: port 1 (eth2): delay timeout
> ptp4l[1129.532]: port 1 (eth2): received SYNC without timestamp
> ptp4l[1129.532]: port 1 (eth2): have FOLLOW_UP 59819, expecting SYNC but 
> got FOLLOW_UP 59820, dropping


So this is the X540 which is receiving the frames? The "SYNC without
timestamp" means that the packet is received without a timestamp.

Could you check the ethtool stats output and see if rx_hwtstamp_cleared
is incrementing?

Another possible check would be to use the test utility testptp and
verify that the network device clock is actually incrementing.

I believe "SYNC without timestamp" can occur if the reported timestamp is 0?


> ptp4l[1130.282]: port 1 (eth2): delay timeout
> ptp4l[1130.468]: port 1 (eth2): delay timeout
> ptp4l[1130.532]: port 1 (eth2): received SYNC without timestamp
> ptp4l[1130.532]: port 1 (eth2): have FOLLOW_UP 59820, expecting SYNC but 
> got FOLLOW_UP 59821, dropping
> ptp4l[1130.866]: port 1 (eth2): delay timeout
> ptp4l[1131.532]: port 1 (eth2): received SYNC without timestamp
> ptp4l[1131.533]: port 1 (eth2): have FOLLOW_UP 59821, expecting SYNC but 
> got FOLLOW_UP 59822, dropping
> ptp4l[1132.269]: port 1 (eth2): delay timeout
> ptp4l[1132.532]: port 1 (eth2): received SYNC without timestamp
> ptp4l[1132.533]: port 1 (eth2): have FOLLOW_UP 59822, expecting SYNC but 
> got FOLLOW_UP 59823, dropping
> ptp4l[1132.770]: port 1 (eth2): delay timeout
> 
> So SYNC packets are coming in, FOLLOW_UP packets are coming in (I see 
> them in wireshark), 2-step sync is on, yet ptp still isn't working. Why 
> is that? As I said, if I just swap the card in the client for another 
> one with I350 chipset, it works. So the master should be okay. The two 
> computers are directly connected via a cable, no switch in between them.
> > I'm testing this with both server and client running the master branch
> of linuxptp from sourceforge.
> 
> To avoid out-of-order packets to be the source of the above mismatch, I 
> also decreased the number of RX queues to 1:
>

The root cause is likely that the packets are being received but not
timestamped. So I don't think out of order packets is the problem.


> $ sudo ethtool -L eth2 combined 1
> $ ethtool -l eth2
> Channel parameters for eth2:
> Pre-set maximums:
> RX:        0
> TX:        0
> Other:        1
> Combined:    8
> Current hardware settings:
> RX:        0
> TX:        0
> Other:        1
> Combined:    1
> 
> That did not change anything.
> 
> These are the master and slave configs:
> 
> $ cat /etc/linuxptp/automotive-master.cfg
> [global]
> gmCapable        1
> priority1        248
> priority2        248
> logSyncInterval        -3
> syncReceiptTimeout    3
> neighborPropDelayThresh    800
> min_neighbor_prop_delay    -20000000
> assume_two_step        1
> path_trace_enabled    1
> follow_up_info        1
> transportSpecific    0x1
> ptp_dst_mac        01:80:C2:00:00:0E
> network_transport    L2
> delay_mechanism        E2E
> BMCA            noop
> serverOnly        1
> inhibit_announce    1
> asCapable               true
> inhibit_delay_req       1
> 
> $ cat /etc/linuxptp/automotive-slave.cfg
> [global]
> gmCapable        1
> priority1        248
> priority2        248
> logSyncInterval        -3
> syncReceiptTimeout    3
> neighborPropDelayThresh    800
> min_neighbor_prop_delay    -20000000
> assume_two_step        1
> path_trace_enabled    1
> follow_up_info        1
> transportSpecific    0x1
> ptp_dst_mac        01:80:C2:00:00:0E
> network_transport    L2
> delay_mechanism        E2E
> BMCA            noop
> clientOnly        1
> inhibit_announce    1
> asCapable               true
> ignore_source_id    1
> step_threshold          1
> operLogSyncInterval     0
> operLogPdelayReqInterval 2
> msg_interval_request     1
> servo_offset_threshold   30
> servo_num_offset_values  10
> hwts_filter normal
> 

Could you try layer 3 UDP packets instead of L2?

> I'm a bit clueless here. I checked by adding a log message that the 
> ioctl setting HWTSTAMP_FILTER_PTP_V2_EVENT does not error out. So 
> everything seems okay, yet the sync does not work.
> > Thank you for any help or hint.
> 
> Martin Pecka
>
Thanks,
Jake

[Linuxptp-users] received SYNC without timestamp

[Martin P. <pec...@fe...>]

Hi PTP users.

We bought a few PCIe network cards for testing, all with Intel chipsets 
and supposedly supporting PTP. I succeeded running HW-stamping PTP L2 
client on a card with I350 chipset and igb driver.

However, two of the cards have a problem. The symptoms are the same, 
although one is 1GbE with Intel 82576 chipset running igb driver and the 
other is 10GbE with Intel X540 running ixgbe driver.

The timestamping capabilities for both look like this:

$ ethtool -T eth2
Time stamping parameters for eth2:
Capabilities:
     hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
     software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
     hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
     software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
     software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
     hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
     off                   (HWTSTAMP_TX_OFF)
     on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
     none                  (HWTSTAMP_FILTER_NONE)
     ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
     ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
     ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)

Most importantly, ptpv2-event is there, as well as HW stamping and HW 
clock. So PTP should be satisfied, shouldn't it? But the synchronization 
never happens. This is what I see running the client:

$ sudo /usr/local/sbin/ptp4l -H -i eth2 -f 
/etc/linuxptp/automotive-slave.cfg --step_threshold=0.001 -m -l7 | grep 
-v config
ptp4l[1127.941]: interface index 5 is up
ptp4l[1127.941]: selected /dev/ptp1 as PTP clock
ptp4l[1127.941]: section item /var/run/ptp4l.announceReceiptTimeout now 0
ptp4l[1127.941]: section item /var/run/ptp4l.delay_mechanism now 0
ptp4l[1127.941]: section item /var/run/ptp4l.network_transport now 0
ptp4l[1127.941]: section item /var/run/ptp4l.delay_filter_length now 1
ptp4l[1127.941]: section item /var/run/ptp4lro.announceReceiptTimeout now 0
ptp4l[1127.941]: section item /var/run/ptp4lro.delay_mechanism now 0
ptp4l[1127.941]: section item /var/run/ptp4lro.network_transport now 0
ptp4l[1127.941]: section item /var/run/ptp4lro.delay_filter_length now 1
ptp4l[1127.942]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[1128.000]: port 1 (eth2): INITIALIZING to SLAVE on INIT_COMPLETE
ptp4l[1128.001]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[1128.002]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[1128.002]: port 1 (eth2): received link status notification
ptp4l[1128.002]: interface index 5 is up
ptp4l[1128.532]: port 1 (eth2): received SYNC without timestamp
ptp4l[1129.097]: port 1 (eth2): delay timeout
ptp4l[1129.532]: port 1 (eth2): received SYNC without timestamp
ptp4l[1129.532]: port 1 (eth2): have FOLLOW_UP 59819, expecting SYNC but 
got FOLLOW_UP 59820, dropping
ptp4l[1130.282]: port 1 (eth2): delay timeout
ptp4l[1130.468]: port 1 (eth2): delay timeout
ptp4l[1130.532]: port 1 (eth2): received SYNC without timestamp
ptp4l[1130.532]: port 1 (eth2): have FOLLOW_UP 59820, expecting SYNC but 
got FOLLOW_UP 59821, dropping
ptp4l[1130.866]: port 1 (eth2): delay timeout
ptp4l[1131.532]: port 1 (eth2): received SYNC without timestamp
ptp4l[1131.533]: port 1 (eth2): have FOLLOW_UP 59821, expecting SYNC but 
got FOLLOW_UP 59822, dropping
ptp4l[1132.269]: port 1 (eth2): delay timeout
ptp4l[1132.532]: port 1 (eth2): received SYNC without timestamp
ptp4l[1132.533]: port 1 (eth2): have FOLLOW_UP 59822, expecting SYNC but 
got FOLLOW_UP 59823, dropping
ptp4l[1132.770]: port 1 (eth2): delay timeout

So SYNC packets are coming in, FOLLOW_UP packets are coming in (I see 
them in wireshark), 2-step sync is on, yet ptp still isn't working. Why 
is that? As I said, if I just swap the card in the client for another 
one with I350 chipset, it works. So the master should be okay. The two 
computers are directly connected via a cable, no switch in between them.

I'm testing this with both server and client running the master branch 
of linuxptp from sourceforge.

To avoid out-of-order packets to be the source of the above mismatch, I 
also decreased the number of RX queues to 1:

$ sudo ethtool -L eth2 combined 1
$ ethtool -l eth2
Channel parameters for eth2:
Pre-set maximums:
RX:        0
TX:        0
Other:        1
Combined:    8
Current hardware settings:
RX:        0
TX:        0
Other:        1
Combined:    1

That did not change anything.

These are the master and slave configs:

$ cat /etc/linuxptp/automotive-master.cfg
[global]
gmCapable        1
priority1        248
priority2        248
logSyncInterval        -3
syncReceiptTimeout    3
neighborPropDelayThresh    800
min_neighbor_prop_delay    -20000000
assume_two_step        1
path_trace_enabled    1
follow_up_info        1
transportSpecific    0x1
ptp_dst_mac        01:80:C2:00:00:0E
network_transport    L2
delay_mechanism        E2E
BMCA            noop
serverOnly        1
inhibit_announce    1
asCapable               true
inhibit_delay_req       1

$ cat /etc/linuxptp/automotive-slave.cfg
[global]
gmCapable        1
priority1        248
priority2        248
logSyncInterval        -3
syncReceiptTimeout    3
neighborPropDelayThresh    800
min_neighbor_prop_delay    -20000000
assume_two_step        1
path_trace_enabled    1
follow_up_info        1
transportSpecific    0x1
ptp_dst_mac        01:80:C2:00:00:0E
network_transport    L2
delay_mechanism        E2E
BMCA            noop
clientOnly        1
inhibit_announce    1
asCapable               true
ignore_source_id    1
step_threshold          1
operLogSyncInterval     0
operLogPdelayReqInterval 2
msg_interval_request     1
servo_offset_threshold   30
servo_num_offset_values  10
hwts_filter normal

I'm a bit clueless here. I checked by adding a log message that the 
ioctl setting HWTSTAMP_FILTER_PTP_V2_EVENT does not error out. So 
everything seems okay, yet the sync does not work.

Thank you for any help or hint.

Martin Pecka

Re: [Linuxptp-users] System Clock not synchronized correctly

[Miroslav L. <mli...@re...>]

On Thu, Dec 16, 2021 at 07:54:14AM +0000, Kirchhoff, Philip wrote:
> Hi,
> 
> I have a problem with an embedded device running Timemaster/ptp4l. The ptp4l says that it is synchronized to the GM but the system time is several hours in the past. The device has two redundant ethernet ports (PRP).

If you try "phc_ctl eth1 get" and "phc_ctl eth2 get" commands, is the
time roughly correct or is it in the past too?

> Please find attached the related log files and a wireshark capture.

The capture shows that the sync messages have correctionField set to
about -68135 seconds. That is very suspicious.

-- 
Miroslav Lichvar

[Linuxptp-users] System Clock not synchronized correctly

[Kirchhoff, P. <phi...@si...>]

Hi,

I have a problem with an embedded device running Timemaster/ptp4l. The ptp4l says that it is synchronized to the GM but the system time is several hours in the past. The device has two redundant ethernet ports (PRP).

Please find attached the related log files and a wireshark capture.

Can anyone tell me what is going wrong?

[Linuxptp-users] Stop synchronizing when the master or slave is restarted

[황승현 <les...@gm...>]

I have three nodes and one of them is master only and the others are slave
only. The configuration I used is configs/automotive-master.cfg
<https://github.com/richardcochran/linuxptp/blob/master/configs/automotive-master.cfg>
and configs/automotive-slave.cfg
<https://github.com/richardcochran/linuxptp/blob/master/configs/automotive-slave.cfg>
without L2 related configs (I want to run the ptp4l on L3).

Let's say master is M and slaves are S1 and S2 and consider all things are
working good.

- When M restarts, S1 and S2 stop synchronizing. They decided to select the
local clock as the best clock.
- When S1 restarts, M and S2 keep synchronizing, but S1 decided to select
the local clock as the best clock.

Is this intended behavior or did I misconfigure something?


Thanks.

Re: [Linuxptp-users] Does not show the offset frequency etc..

[藍彥凱 <ggy...@gm...>]

yes firewall  Status: inactive

I have modified etc/linuxptp/ptp4l.conf  verbose &time_stamping add[enp4s0]

verbose 1

# Default interface options
network_transport UDPv4
delay_mechanism E2E
time_stamping software
tsproc_mode filter
delay_filter moving_median
delay_filter_length 10
egressLatency 0
ingressLatency 0
boundary_clock_jbod 0
[enp4s0]
#

Is there a problem here?

Where should I go to check the problem


thank you



Richard Cochran <ric...@gm...> 於 2021年12月15日 週三 下午10:36寫道：

> On Wed, Dec 15, 2021 at 04:04:30PM +0800, 藍彥凱 wrote:
> > Dear Richard
> >
> > I use wireshark to check ptp packets.
> >
> > I found that I didn't see Delay_Req Message .
> >
> > Sync_Message and Delay_Req Message originTimestamp always 0 (seconds &
> > nanoseconds)
> >
> > screenshot can’t seem to be uploaded.
> >
> > I tried to send you a picture, I hope you can view it
> >
> > How can i solve it?
>
> You need to find out why the delay packets are missing.
>
> Did you check your firewall?
>
> HTH,
> Richard
>

Re: [Linuxptp-users] Does not show the offset frequency etc..

[Richard C. <ric...@gm...>]

On Wed, Dec 15, 2021 at 10:32:06PM +0800, 藍彥凱 wrote:
> Sync_Message and Delay_Req Message originTimestamp always 0 (seconds &
> nanoseconds)

This is normal and expected.  See IEEE 1588 to understand the meaning
of the message fields.

Thanks,
Richard

Re: [Linuxptp-users] Does not show the offset frequency etc..

[Richard C. <ric...@gm...>]

On Wed, Dec 15, 2021 at 04:04:30PM +0800, 藍彥凱 wrote:
> Dear Richard
> 
> I use wireshark to check ptp packets.
> 
> I found that I didn't see Delay_Req Message .
> 
> Sync_Message and Delay_Req Message originTimestamp always 0 (seconds &
> nanoseconds)
> 
> screenshot can’t seem to be uploaded.
> 
> I tried to send you a picture, I hope you can view it
> 
> How can i solve it?

You need to find out why the delay packets are missing.

Did you check your firewall?

HTH,
Richard

[Linuxptp-users] Does not show the offset frequency etc..

[藍彥凱 <ggy...@gm...>]

Hello, I tested ptp4l on two PC. The master clock display is correct,
but from the clock display to port 1: LISTENING to UNCALIBRATED on
RS_SLAVE, there is nothing to do. The master offset is not displayed.
What is the problem?

chu@chu-ThinkStation-S30:~$ sudo ptp4l -i eno1 -s -m -S

ptp4l[2711616.630]: port 1 (eno1): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[2711616.630]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING
on INIT_COMPLETE
ptp4l[2711616.630]: port 0 (/var/run/ptp4lro): INITIALIZING to
LISTENING on INIT_COMPLETE
ptp4l[2711618.664]: port 1 (eno1): new foreign master d45d64.fffe.3ffc8b-1
ptp4l[2711622.664]: selected best master clock d45d64.fffe.3ffc8b
ptp4l[2711622.664]: foreign master not using PTP timescale
ptp4l[2711622.664]: port 1 (eno1): LISTENING to UNCALIBRATED on RS_SLAVE

I use wireshark to check ptp packets.

I found that I didn't see Delay_Req Message .

Sync_Message and Delay_Req Message originTimestamp always 0 (seconds &
nanoseconds)

screenshot can’t seem to be uploaded.

I tried to send Richard a picture, I hope you can view it

How can i solve it?

Thanks

Re: [Linuxptp-users] question about uds_address in phc2sys, ptp4l

[Kat Y <aps...@gm...>]

Okay, thank you all! So I have to make sure uds_address is the same for
ptp4l and phc2sys combination and separate per interface. If it's not
separate per interface I only get one reply or none at all.

uto, 14. pro 2021. u 18:28 Keller, Jacob E <jac...@in...>
napisao je:

>
>
> > -----Original Message-----
> > From: Ed Branch <br...@ar...>
> > Sent: Friday, December 10, 2021 6:11 AM
> > To: lin...@li...
> > Subject: Re: [Linuxptp-users] question about uds_address in phc2sys,
> ptp4l
> >
> > With the -w argument, phc2sys uses this port to communicate with ptp4l
> > to wait until ptp4l is tracking and to get the UTC offset propagated
> > from PTP protocol.
> >
> > - ed
> >
>
> I believe it is also used in automatic mode as well?
>
> Thanks,
> Jake
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>

Re: [Linuxptp-users] question about uds_address in phc2sys, ptp4l

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Ed Branch <br...@ar...>
> Sent: Friday, December 10, 2021 6:11 AM
> To: lin...@li...
> Subject: Re: [Linuxptp-users] question about uds_address in phc2sys, ptp4l
> 
> With the -w argument, phc2sys uses this port to communicate with ptp4l
> to wait until ptp4l is tracking and to get the UTC offset propagated
> from PTP protocol.
> 
> - ed
> 

I believe it is also used in automatic mode as well?

Thanks,
Jake

Re: [Linuxptp-users] Redundant boundary clocks

[Marco D. (SIDN) <mar...@si...>]

Thanks, this seems to do the trick!

Instead of 'slave Only 1', I tried 'clockClass 255' and that worked. But 
it also seems to work with the default clockClass-setting.

Cheers,

-- 
Marco

Op 11-12-2021 om 03:22 schreef Richard Cochran:

>> I am working out a setup with two master clocks (one GM/leader, one
>> slave/follower, depending on what BMCA decides) and two boundary clocks that
>> both slave from the above setup and both provide time to the same vlan on
>> the other side. The BC's are slave only toward the GM and master only toward
>> the clients on the other side:
> 
> Don't configure "slave only" on the BC.  They will naturally form a
> spanning tree without that.
> 
> Then your OC will have only one choice.

[Linuxptp-users] Starting linuxptp on a virtual/logical NIC

[Antonio T. <ant...@br...>]

Hello.

Long story short, I need to run linuxptp with hardware timestamping
over a Wireguard VPN network interface. This is due to compliance
reasons, as I'm trying to implement a protocol for time
synchronization for a timestamping (RFC3161) server application. The
standard is defined by the Brazilian government so there's pretty much
no way around it.

The issue is, I'm trying to run this on a server with a NIC that has
hardware timestamping support for PTP, but if I try to run linuxptp
over the virtual interface created by wireguard it doesn't start
because the virtual interface has no PTP timestamping capabilities at
all. Is there any way to run the linuxptp packets through this virtual
interface while using the physical interface's hardware timestamping
capabilities?

Re: [Linuxptp-users] Does not show the offset frequency etc..

[Richard C. <ric...@gm...>]

On Mon, Dec 13, 2021 at 10:50:56AM +0800, 藍彥凱 wrote:
> Sorry,how should I make sure them?

Wireshark and/or tcpdump are your friends!

Thanks,
Richard