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

Re: [Linuxptp-users] ptp over prp

[Emmanuel F. <man...@gm...>]

Le 10/06/2022 à 08:21, Kirchhoff, Philip a écrit :
> Actually, it is not PTP over PRP, but PTP over two networks, on which 
> PRP is also running.
> However, as you can see, the PRP driver assigns an identical MAC 
> address for both network interfaces. We wondered if this would be a 
> problem for the ptp4l.
> Also, the question arises whether one ptp4l instance can handle two 
> network interfaces, or whether we should have two ptp4l and two 
> phc2sys processes.
> And finally another question: Is it necessary for the PTP protocol 
> that the interfaces have IP addresses?
PTP could be run in L2 mode and you will not need IP addresses on the 
interfaces.
That was the mode I used: L2 on dedicated physical network.

Emmanuel.

Re: [Linuxptp-users] ptp over prp

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

Actually, it is not PTP over PRP, but PTP over two networks, on which PRP is also running.
However, as you can see, the PRP driver assigns an identical MAC address for both network interfaces. We wondered if this would be a problem for the ptp4l.
Also, the question arises whether one ptp4l instance can handle two network interfaces, or whether we should have two ptp4l and two phc2sys processes.
And finally another question: Is it necessary for the PTP protocol that the interfaces have IP addresses?

________________________________
From: Richard Cochran <ric...@gm...>
Sent: Thursday, June 9, 2022 8:56 AM
To: Wengler, Alexander <ale...@si...>
Cc: lin...@li... <lin...@li...>
Subject: Re: [Linuxptp-users] ptp over prp

On Thu, Jun 09, 2022 at 05:14:20AM +0000, Wengler, Alexander wrote:
> So the first question is: is it possible to use ptp in such a configuration at all?

PTP über PRP?  Das ist vielleicht Neuland...

Gruß,
Richard




_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-users&amp;data=05%7C01%7Cphilip.kirchhoff%40siemens-energy.com%7Cd983e61b977143ff187808da49e5a2dd%7C254ba93e1f6f48f390e6e2766664b477%7C1%7C0%7C637903547868517642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ekWjYxyy8%2BtbUpzDYdZ3LY1C9LCFwOAD3zJqCoAxXAA%3D&amp;reserved=0

Re: [Linuxptp-users] ptp over prp

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

On Thu, Jun 09, 2022 at 05:14:20AM +0000, Wengler, Alexander wrote:
> So the first question is: is it possible to use ptp in such a configuration at all?

PTP über PRP?  Das ist vielleicht Neuland...

Gruß,
Richard

[Linuxptp-users] ptp over prp

[Wengler, A. <ale...@si...>]

Hi all,

in our embedded device we try to get ptp running on a prp network.

When I enable prp, ifconfig looks like ...
ip netns exec process ifconfig
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet6 fe80::2d0:93ff:fe37:758e  prefixlen 64  scopeid 0x20<link>
        ether 00:d0:93:37:75:8e  txqueuelen 1000  (Ethernet)
        RX packets 9827  bytes 883796 (863.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7324  bytes 1119153 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device base 0xa000

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet6 fe80::2d0:93ff:fe37:758e  prefixlen 64  scopeid 0x20<link>
        ether 00:d0:93:37:75:8e  txqueuelen 1000  (Ethernet)
        RX packets 4141  bytes 372857 (364.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6554  bytes 1074997 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device base 0xc000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536  metric 1
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 2615  bytes 232732 (227.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2615  bytes 232732 (227.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

prp1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1494  metric 1
        inet 192.168.2.2  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::2d0:93ff:fe37:758e  prefixlen 64  scopeid 0x20<link>
        ether 00:d0:93:37:75:8e  txqueuelen 1000  (Ethernet)
        RX packets 13967  bytes 1061018 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6587  bytes 987621 (964.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


So the first question is: is it possible to use ptp in such a configuration at all?
If so, what would be the right configuration: one ptp4l listening on both eth devices like
  ptp4l -l 5 -f /var/run/timemaster/ptp4l.0.conf -H -i eth1 -i eth2
or one ptp4l and phc2sys for each eth device?

Is there some kind of documentation describing the correct configuration of ptp on prp?

Thank you very much in advance

  Alex

[Linuxptp-users] timed out while polling for tx timestamp

[Mehmet A. <meh...@mo...>]

Hello,

We see that if a 'certain' process is running, it causes ptp4l to switch
into faulty state at some point. After that, phc2sys never syncs back to
ptp4l.

This certain process is a proprietary application running as
non-root/unprivileged but, at a very high level, it receives UDP packets,
transforms the data, sends TCP packets. It does not perform any high
frequency scheduling or other unusual activity. The CPU load from this
application is 50-70%. We have verified that simply running a CPU stress
test with 100% load does not cause ptp4l to go into this faulty state so we
don't think CPU load is a contributor by itself.

We have also tried to increase `tx_timestamp_timeout` to 10ms but same
behavior was observed. Network driver is `ixgbe` on Linux kernel 5.4.

We are looking for any pointers to help resolve this issue and especially
figure out what's causing this transition to faulty state.

Log:
```
May 27 20:28:08 hostname phc2sys[534]: [1061.490] CLOCK_REALTIME phc offset
      131 s0 freq      +0 delay   1800
May 27 20:28:09 hostname ptp4l[629]: [1062.033] master offset        -68 s3
freq    -423 path delay      1779
May 27 20:28:09 hostname phc2sys[534]: [1062.490] CLOCK_REALTIME phc offset
       59 s0 freq      +0 delay   1807
May 27 20:28:10 hostname ptp4l[629]: [1062.666] master offset        -26 s3
freq    -401 path delay      1779
May 27 20:28:10 hostname ptp4l[629]: [1063.291] master offset         39 s3
freq    -344 path delay      1779
May 27 20:28:10 hostname ptp4l[629]: [1063.296] timed out while polling for
tx timestamp
May 27 20:28:10 hostname ptp4l[629]: [1063.296] increasing
tx_timestamp_timeout may correct this issue, but it is likely caused by a
driver bug
May 27 20:28:10 hostname ptp4l[629]: [1063.296] port 1: send peer delay
response failed
May 27 20:28:10 hostname ptp4l[629]: [1063.296] port 1: SLAVE to FAULTY on
FAULT_DETECTED (FT_UNSPECIFIED)
May 27 20:28:10 hostname phc2sys[534]: [1063.490] port 2046a1.fffe.06da8d-1
changed state
May 27 20:28:10 hostname phc2sys[534]: [1063.490] reconfiguring after port
state change
May 27 20:28:10 hostname phc2sys[534]: [1063.490] selecting eth0 for
synchronization
May 27 20:28:10 hostname phc2sys[534]: [1063.490] nothing to synchronize
May 27 20:28:26 hostname ptp4l[629]: [1079.456] port 1: FAULTY to LISTENING
on INIT_COMPLETE
May 27 20:28:28 hostname ptp4l[629]: [1080.548] timed out while polling for
tx timestamp
May 27 20:28:28 hostname ptp4l[629]: [1080.548] increasing
tx_timestamp_timeout may correct this issue, but it is likely caused by a
driver bug
May 27 20:28:28 hostname ptp4l[629]: [1080.548] port 1: send peer delay
response failed
May 27 20:28:28 hostname ptp4l[629]: [1080.548] port 1: LISTENING to FAULTY
on FAULT_DETECTED (FT_UNSPECIFIED)
May 27 20:28:44 hostname ptp4l[629]: [1096.716] port 1: FAULTY to LISTENING
on INIT_COMPLETE
May 27 20:28:45 hostname ptp4l[629]: [1097.779] port 1: new foreign master
020021.fffe.120104-28
May 27 20:28:47 hostname ptp4l[629]: [1099.822] selected best master clock
26cc35.fffe.82241b
May 27 20:28:47 hostname ptp4l[629]: [1099.822] running in a temporal vortex
May 27 20:28:47 hostname ptp4l[629]: [1099.822] port 1: LISTENING to
UNCALIBRATED on RS_SLAVE
May 27 20:28:47 hostname ptp4l[629]: [1100.322] master offset        232 s3
freq    -139 path delay      1779
May 27 20:28:47 hostname phc2sys[534]: [1100.492] port 2046a1.fffe.06da8d-1
changed state
May 27 20:28:47 hostname phc2sys[534]: [1100.492] reconfiguring after port
state change
May 27 20:28:47 hostname phc2sys[534]: [1100.492] master clock not ready,
waiting...
May 27 20:28:48 hostname ptp4l[629]: [1100.957] master offset        -28 s3
freq    -330 path delay      1780
May 27 20:28:49 hostname ptp4l[629]: [1101.581] master offset        -60 s3
freq    -370 path delay      1780
May 27 20:28:49 hostname ptp4l[629]: [1102.208] master offset       -112 s3
freq    -440 path delay      1780
May 27 20:28:50 hostname ptp4l[629]: [1102.833] master offset        -95 s3
freq    -457 path delay      1781
```
`/etc/linuxptp.cfg`:
```
[global]
#
# Options carried over from gPTP.
#
gmCapable 1
priority1 255
priority2 255
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 P2P
#
# Automotive Profile specific options
#
BMCA ptp
slaveOnly 1
inhibit_announce 1
asCapable               true
ignore_source_id 1
# Required to quickly correct Time Jumps in master
step_threshold          1
operLogSyncInterval     0
operLogPdelayReqInterval 2
msg_interval_request     1
servo_offset_threshold   30
servo_num_offset_values  10

[eth0]
```
Process arguments:
```
/usr/sbin/ptp4l -f /etc/linuxptp.cfg

/usr/sbin/phc2sys -a -r -E ntpshm -M 9 --transportSpecific=1
```

Sincerely,

Mehmet Akbulut

-- 
This email contains information belonging to Motional AD LLC or its 
affiliates and may contain confidential, proprietary, copyrighted and/or 
privileged information. Any unauthorized review, use, reliance, disclosure, 
distribution or copying is prohibited. If you are not the intended 
recipient, immediately destroy all copies of the original email and any 
attachments and contact the sender by reply email.

[Linuxptp-users] LinuxPTP using intel TSE MAC IP and DP83640

[Vitor W. <vit...@aq...>]

This is my first time on the Source Forge mailing list, so I apologize if i dont follow some community guidelines.



I am trying to make an implementation for PTP time synchronization using a DP83640 PHY + intel TSE MAC + LinuxPTP stack. The Hardware Time Stamps are created in the PHY and the Linux PTP stack receive this information through the TSE MAC via MII.



Checking the time stamp capabilties of my ethernet adapter using ethtol -t eth0 i get the following:

[thumbnail_image001.png]

Apparently, i should be okay to use the linuxPTP software, however, when i try to run it or even use the debug tool hwstamp_ctl i get the following:

[thumbnail_image002.png]

I thought i configured all the drivers correctly, as well as the device tree. It seems to be a driver related problem. Does anyone have any idea of what the problem could be?



I am using Linux Kernel Version: 5.4.94 and LinuxPTP Version: 3.1

Re: [Linuxptp-users] ptp4l and Broadcom 5720 problem

[Jay S. <li...@sh...>]

On 07/06/2022 10:28, Miroslav Lichvar wrote:
> On Tue, Jun 07, 2022 at 10:13:31AM +0100, Jay Shardlow wrote:
>> At this point I'm slightly out of my depth and out of ideas. The Broadcom
>> obviously does work (or they wouldn't advertise it as such), so must be
>> something with my environemnt, but I have no idea what.
> 
> I doubt it's HW related. You can try software timestamping (-S) to
> rule that out. In the ptp4l log there should be a message about the
> remote clock. If there is only the local clock, ptp4l is not getting
> the annoucement messages. That doesn't require any timestamping.
> 
> You can verify ptp4l is receiving messages from network with strace
> like this:
> 
> strace -erecvmsg ptp4l -m -q -i eth0 -s
> 

Thank you.

No joy on the software timestamping:

# ptp4l  -i lan2 -s -S -m
ptp4l[961566.609]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[961566.609]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[961572.642]: selected local clock e43d1a.fffe.acab65 as best master
ptp4l[961579.274]: selected local clock e43d1a.fffe.acab65 as best master
ptp4l[961587.069]: selected local clock e43d1a.fffe.acab65 as best master

And for the strace, on the working Intel I can see lots of this with the 
IP of our master:

recvmsg(14, {msg_name={sa_family=AF_INET, sin_port=htons(320), 
sin_addr=inet_addr("IP_REDACTED")}, msg_namelen=128->16, 
msg_iov=[{iov_base="\t\2\0006\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\354Fp\377\376\0\277\4\0\1\34\246"..., 
iov_len=1500}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 54

But on the Broadcom I don't see any such message from the same IP. So 
looks like ptp4l is not getting such annoucements as you suspected.

I've asked the networks team to check the switchport for Broadcom box is 
set up the same as Intel box, which they have confirmed it is. Meanwhile 
I've asked Meinberg for a bit of help/advice on the appliance config in 
case it's something at that end.

J

Re: [Linuxptp-users] ptp4l and Broadcom 5720 problem

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

On Tue, Jun 07, 2022 at 10:13:31AM +0100, Jay Shardlow wrote:
> At this point I'm slightly out of my depth and out of ideas. The Broadcom
> obviously does work (or they wouldn't advertise it as such), so must be
> something with my environemnt, but I have no idea what.

I doubt it's HW related. You can try software timestamping (-S) to
rule that out. In the ptp4l log there should be a message about the
remote clock. If there is only the local clock, ptp4l is not getting
the annoucement messages. That doesn't require any timestamping.

You can verify ptp4l is receiving messages from network with strace
like this:

strace -erecvmsg ptp4l -m -q -i eth0 -s

-- 
Miroslav Lichvar

Re: [Linuxptp-users] ptp4l and Broadcom 5720 problem

[Jay S. <li...@sh...>]

On 07/06/2022 09:17, Miroslav Lichvar wrote:
> On Mon, Jun 06, 2022 at 04:10:19PM +0100, Jay Shardlow wrote:
>> Hello all, after a bit of advice/help. I've got some CentOS 7 servers and I
>> need to get them running ptp4l (from linuxptp) as clients, with the
>> grandmaster being a Meinberg appliance. One with an Intel i350 works fine.
>> Another with a Broadcom 5720 does not. Both servers are connected to the
>> same network for their PTP. I suspect I know why the Broadcom doesn't work,
>> but I was wondering if anyone could point me in the right direction on how
>> to get it to do so.
> 
> Do the servers have the same configuration? Usually it's a firewall
> issue. If the issue was with missing timestamps, ptp4l would print an
> error. In my experience, BCM5720 works fine with UDPv4 PTP.
> 

They're not identical, but they're both CentOS 7.9 running linuxptp 
2.0.2. No firewall on the Broadcom server.

To my untrained eye the only real difference is the Hardware Recieve 
Filter Modes. Elsewhere in our environment we have combos of 
Solarflare/sfptpd, Intel i350/ptpd, Intel X520/ptpd which all work fine, 
though they either support HWTSTAMP_FILTER_ALL or at least 
HWTSTAMP_FILTER_PTP_V2_EVENT.

Though I've literally just read that ptp4l prefers to have 
HWTSTAMP_FILTER_PTP_V2_EVENT, but will fall back to 
HWTSTAMP_FILTER_PTP_V2_L4_EVENT or HWTSTAMP_FILTER_PTP_V2_L4_EVENT (the 
latter two available on the Broadcom).

At this point I'm slightly out of my depth and out of ideas. The 
Broadcom obviously does work (or they wouldn't advertise it as such), so 
must be something with my environemnt, but I have no idea what.

J

Re: [Linuxptp-users] ptp4l and Broadcom 5720 problem

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

On Mon, Jun 06, 2022 at 04:10:19PM +0100, Jay Shardlow wrote:
> Hello all, after a bit of advice/help. I've got some CentOS 7 servers and I
> need to get them running ptp4l (from linuxptp) as clients, with the
> grandmaster being a Meinberg appliance. One with an Intel i350 works fine.
> Another with a Broadcom 5720 does not. Both servers are connected to the
> same network for their PTP. I suspect I know why the Broadcom doesn't work,
> but I was wondering if anyone could point me in the right direction on how
> to get it to do so.

Do the servers have the same configuration? Usually it's a firewall
issue. If the issue was with missing timestamps, ptp4l would print an
error. In my experience, BCM5720 works fine with UDPv4 PTP.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] ptp4l and Broadcom 5720 problem

[Jay S. <li...@sh...>]

On 06/06/2022 16:10, Jay Shardlow wrote:
> Hello all, after a bit of advice/help. I've got some CentOS 7 servers 
> and I need to get them running ptp4l (from linuxptp) as clients, with 
> the grandmaster being a Meinberg appliance. One with an Intel i350 works 
> fine. Another with a Broadcom 5720 does not. Both servers are connected 
> to the same network for their PTP. I suspect I know why the Broadcom 
> doesn't work, but I was wondering if anyone could point me in the right 
> direction on how to get it to do so.
> 
> In short the i350's hardware timstamping capabilities say this:
> 
> |# ethtool -T lan2 <snip> Hardware Receive Filter Modes: 
> none                  (HWTSTAMP_FILTER_NONE) all                   
> (HWTSTAMP_FILTER_ALL) |
> 
> But the Broadcom says this:
> 
> |# ethtool -T lan2 <snip> Hardware Receive Filter Modes: 
> none                  (HWTSTAMP_FILTER_NONE) ptpv1-l4-event        
> (HWTSTAMP_FILTER_PTP_V1_L4_EVENT) ptpv2-l4-event        
> (HWTSTAMP_FILTER_PTP_V2_L4_EVENT) ptpv2-l2-event        
> (HWTSTAMP_FILTER_PTP_V2_L2_EVENT) |
> 
> So I get the feeling that the Broadcom isn't picking up some of the 
> messages coming back from the grandmaster. eg in the logs I can see:
> 
> |Jun  3 10:12:37.000 ldalgc01 ptp4l[8290]: ptp4l[601302.197]: selected 
> local clock e43d1a.fffe.acab65 as best master Jun  3 10:12:37.000 
> ldalgc01 ptp4l: [601302.197] selected local clock e43d1a.fffe.acab65 as 
> best master Jun  3 10:12:38.000 ldalgc01 phc2sys: [601303.026] Waiting 
> for ptp4l... Jun  3 10:12:39.000 ldalgc01 phc2sys: [601304.027] Waiting 
> for ptp4l... |
> 
> But a tcpdump shows that such messages are arriving:
> 
> |10:12:39.381908 IP gsdgmca01-ptp0.prod.instinet.com.ptp-general > 
> 224.0.1.129.ptp-general: UDP, length 54 10:12:39.398091 IP 
> gsdgmca01-ptp0.prod.instinet.com.ptp-general > 224.0.1.129.ptp-general: 
> UDP, length 54 10:12:39.404572 IP 
> gsdgmca01-ptp0.prod.instinet.com.ptp-general > 224.0.1.129.ptp-general: 
> UDP, length 54 |
> 
> The Broadcom 5720 blurb says that it has Hardware support for IEEE 1588 
> timestamping <https://docs.broadcom.com/doc/5720-PB01-R>, so I guess it 
> might need some tweaking of the ptp4l conf, but I'm not sure where to 
> start. Current config (that works fine on the i350) is:
> 
> |[global] # # Default Data Set # twoStepFlag             1 
> slaveOnly               1 priority1               128 priority2 
>          128 domainNumber            0 #utc_offset             37 
> clockClass              248 clockAccuracy           0xFE 
> offsetScaledLogVariance 0xFFFF free_running            0 
> freq_est_interval       1 dscp_event              0 
> dscp_general            0 dataset_comparison      ieee1588 
> G.8275.defaultDS.localPriority  128 # # Port Data Set # 
> logAnnounceInterval     1 logSyncInterval         0 
> logMinDelayReqInterval  0 logMinPdelayReqInterval 0 
> announceReceiptTimeout  3 syncReceiptTimeout      0 
> delayAsymmetry          0 fault_reset_interval    4 
> neighborPropDelayThresh 20000000 masterOnly              0 
> G.8275.portDS.localPriority     128 # # Run time options # 
> assume_two_step         0 logging_level           6 
> path_trace_enabled      0 follow_up_info          0 
> hybrid_e2e              1 inhibit_multicast_service       0 
> net_sync_monitor        0 tc_spanning_tree        0 
> tx_timestamp_timeout    1 unicast_listen          0 
> unicast_master_table    0 unicast_req_duration    3600 
> use_syslog              1 verbose                 1 
> summary_interval        0 kernel_leap             1 
> check_fup_sync          0 # # Servo Options # pi_proportional_const 0.0 
> pi_integral_const       0.0 pi_proportional_scale   0.0 
> pi_proportional_exponent        -0.3 pi_proportional_norm_max        0.7 
> pi_integral_scale       0.0 pi_integral_exponent    0.4 
> pi_integral_norm_max    0.3 step_threshold          0.0 
> first_step_threshold    0.00002 max_frequency           900000000 
> clock_servo             linreg sanity_freq_limit       200000000 
> ntpshm_segment          0 # # Transport options # 
> transportSpecific       0x0 ptp_dst_mac             01:1B:19:00:00:00 
> p2p_dst_mac             01:80:C2:00:00:0E udp_ttl                 32 
> udp6_scope              0x0E uds_address             /var/run/ptp4l # # 
> Default interface options # clock_type              OC 
> network_transport       UDPv4 delay_mechanism         E2E 
> time_stamping           hardware tsproc_mode             filter 
> delay_filter            moving_median delay_filter_length     10 
> egressLatency           0 ingressLatency          0 boundary_clock_jbod 
>     0 # # Clock description # productDescription      ;; 
> revisionData            ;; manufacturerIdentity    00:00:00 
> userDescription         ; timeSource              0xA0 Thanks in 
> advance, J |
> 
> 
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Apologies for the bad formatting, let me try some of that again with a 
bit more care with the cut/paste.

In short Intel i350 is fine, Broadcom 5720 is not. The Broadcom is 
listed as having Hardware support for IEEE 1588 timestamping. But I'm 
not sure how to get it workimg (like the Intel) with ptp4l.

Intel i350:
# ethtool -T lan2
<snip>
Hardware Receive Filter Modes:
         none                  (HWTSTAMP_FILTER_NONE)
         all                   (HWTSTAMP_FILTER_ALL)

Broadcom 5720:
# ethtool -T lan2
<snip>
Hardware Receive Filter Modes:
         none                  (HWTSTAMP_FILTER_NONE)
         ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
         ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
         ptpv2-l2-event        (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)

ptp4l logs:
Jun  3 10:12:37.000 ldalgc01 ptp4l[8290]: ptp4l[601302.197]: selected 
local clock e43d1a.fffe.acab65 as best master
Jun  3 10:12:37.000 ldalgc01 ptp4l: [601302.197] selected local clock 
e43d1a.fffe.acab65 as best master
Jun  3 10:12:38.000 ldalgc01 phc2sys: [601303.026] Waiting for ptp4l...
Jun  3 10:12:39.000 ldalgc01 phc2sys: [601304.027] Waiting for ptp4l...
Jun  3 10:12:40.000 ldalgc01 phc2sys: [601305.029] Waiting for ptp4l...

tcpdump snippet:
10:12:39.381908 IP gsdgmca01-ptp0.prod.instinet.com.ptp-general > 
224.0.1.129.ptp-general: UDP, length 54
10:12:39.398091 IP gsdgmca01-ptp0.prod.instinet.com.ptp-general > 
224.0.1.129.ptp-general: UDP, length 54
10:12:39.404572 IP gsdgmca01-ptp0.prod.instinet.com.ptp-general > 
224.0.1.129.ptp-general: UDP, length 54
10:12:39.406287 IP gsdgmca01-ptp0.prod.instinet.com.ptp-general > 
224.0.1.129.ptp-general: UDP, length 54
10:12:39.486361 IP gsdgmca01-ptp0.prod.instinet.com.ptp-general > 
224.0.1.129.ptp-general: UDP, length 54
10:12:39.499305 IP gsdgmca01-ptp0.prod.instinet.com.ptp-general > 
224.0.1.129.ptp-general: UDP, length 54

ptp4l.conf (which works OK on the Intel i350):
[global]
#
# Default Data Set
#
twoStepFlag             1
#slaveOnly              0
slaveOnly               1
priority1               128
priority2               128
domainNumber            0
#utc_offset             37
clockClass              248
clockAccuracy           0xFE
offsetScaledLogVariance 0xFFFF
free_running            0
freq_est_interval       1
dscp_event              0
dscp_general            0
dataset_comparison      ieee1588
G.8275.defaultDS.localPriority  128
#
# Port Data Set
#
logAnnounceInterval     1
logSyncInterval         0
logMinDelayReqInterval  0
logMinPdelayReqInterval 0
announceReceiptTimeout  3
syncReceiptTimeout      0
delayAsymmetry          0
fault_reset_interval    4
neighborPropDelayThresh 20000000
masterOnly              0
G.8275.portDS.localPriority     128
#
# Run time options
#
assume_two_step         0
logging_level           6
path_trace_enabled      0
follow_up_info          0
#hybrid_e2e             0
hybrid_e2e              1
inhibit_multicast_service       0
net_sync_monitor        0
tc_spanning_tree        0
tx_timestamp_timeout    1
unicast_listen          0
unicast_master_table    0
unicast_req_duration    3600
use_syslog              1
#verbose                        0
verbose                 1
summary_interval        0
kernel_leap             1
check_fup_sync          0
#
# Servo Options
#
pi_proportional_const   0.0
pi_integral_const       0.0
pi_proportional_scale   0.0
pi_proportional_exponent        -0.3
pi_proportional_norm_max        0.7
pi_integral_scale       0.0
pi_integral_exponent    0.4
pi_integral_norm_max    0.3
step_threshold          0.0
first_step_threshold    0.00002
max_frequency           900000000
#clock_servo            pi
clock_servo             linreg
sanity_freq_limit       200000000
ntpshm_segment          0
#
# Transport options
#
transportSpecific       0x0
ptp_dst_mac             01:1B:19:00:00:00
p2p_dst_mac             01:80:C2:00:00:0E
#udp_ttl                        1
udp_ttl                 32
udp6_scope              0x0E
uds_address             /var/run/ptp4l
#
# Default interface options
#
clock_type              OC
network_transport       UDPv4
delay_mechanism         E2E
time_stamping           hardware
tsproc_mode             filter
delay_filter            moving_median
delay_filter_length     10
egressLatency           0
ingressLatency          0
boundary_clock_jbod     0
#
# Clock description
#
productDescription      ;;
revisionData            ;;
manufacturerIdentity    00:00:00
userDescription         ;
timeSource              0xA0

Thanks and sorry again for the previous formatting.

J

[Linuxptp-users] ptp4l and Broadcom 5720 problem

[Jay S. <li...@sh...>]

Hello all, after a bit of advice/help. I've got some CentOS 7 servers 
and I need to get them running ptp4l (from linuxptp) as clients, with 
the grandmaster being a Meinberg appliance. One with an Intel i350 works 
fine. Another with a Broadcom 5720 does not. Both servers are connected 
to the same network for their PTP. I suspect I know why the Broadcom 
doesn't work, but I was wondering if anyone could point me in the right 
direction on how to get it to do so.

In short the i350's hardware timstamping capabilities say this:

|# ethtool -T lan2 <snip> Hardware Receive Filter Modes:         
none                  (HWTSTAMP_FILTER_NONE)         
all                   (HWTSTAMP_FILTER_ALL) |

But the Broadcom says this:

|# ethtool -T lan2 <snip> Hardware Receive Filter Modes:         
none                  (HWTSTAMP_FILTER_NONE)         
ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)         
ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)         
ptpv2-l2-event        (HWTSTAMP_FILTER_PTP_V2_L2_EVENT) |

So I get the feeling that the Broadcom isn't picking up some of the 
messages coming back from the grandmaster. eg in the logs I can see:

|Jun  3 10:12:37.000 ldalgc01 ptp4l[8290]: ptp4l[601302.197]: selected 
local clock e43d1a.fffe.acab65 as best master Jun  3 10:12:37.000 
ldalgc01 ptp4l: [601302.197] selected local clock e43d1a.fffe.acab65 as 
best master Jun  3 10:12:38.000 ldalgc01 phc2sys: [601303.026] Waiting 
for ptp4l... Jun  3 10:12:39.000 ldalgc01 phc2sys: [601304.027] Waiting 
for ptp4l... |

But a tcpdump shows that such messages are arriving:

|10:12:39.381908 IP gsdgmca01-ptp0.prod.instinet.com.ptp-general > 
224.0.1.129.ptp-general: UDP, length 54 10:12:39.398091 IP 
gsdgmca01-ptp0.prod.instinet.com.ptp-general > 224.0.1.129.ptp-general: 
UDP, length 54 10:12:39.404572 IP 
gsdgmca01-ptp0.prod.instinet.com.ptp-general > 224.0.1.129.ptp-general: 
UDP, length 54 |

The Broadcom 5720 blurb says that it has Hardware support for IEEE 1588 
timestamping <https://docs.broadcom.com/doc/5720-PB01-R>, so I guess it 
might need some tweaking of the ptp4l conf, but I'm not sure where to 
start. Current config (that works fine on the i350) is:

|[global] # # Default Data Set # twoStepFlag             1 
slaveOnly               1 priority1               128 priority2       
         128 domainNumber            0 #utc_offset             37 
clockClass              248 clockAccuracy           0xFE 
offsetScaledLogVariance 0xFFFF free_running            0 
freq_est_interval       1 dscp_event              0 
dscp_general            0 dataset_comparison      ieee1588 
G.8275.defaultDS.localPriority  128 # # Port Data Set # 
logAnnounceInterval     1 logSyncInterval         0 
logMinDelayReqInterval  0 logMinPdelayReqInterval 0 
announceReceiptTimeout  3 syncReceiptTimeout      0 
delayAsymmetry          0 fault_reset_interval    4 
neighborPropDelayThresh 20000000 masterOnly              0 
G.8275.portDS.localPriority     128 # # Run time options # 
assume_two_step         0 logging_level           6 
path_trace_enabled      0 follow_up_info          0 
hybrid_e2e              1 inhibit_multicast_service       0 
net_sync_monitor        0 tc_spanning_tree        0 
tx_timestamp_timeout    1 unicast_listen          0 
unicast_master_table    0 unicast_req_duration    3600 
use_syslog              1 verbose                 1 
summary_interval        0 kernel_leap             1 
check_fup_sync          0 # # Servo Options # pi_proportional_const   
0.0 pi_integral_const       0.0 pi_proportional_scale   0.0 
pi_proportional_exponent        -0.3 pi_proportional_norm_max        0.7 
pi_integral_scale       0.0 pi_integral_exponent    0.4 
pi_integral_norm_max    0.3 step_threshold          0.0 
first_step_threshold    0.00002 max_frequency           900000000 
clock_servo             linreg sanity_freq_limit       200000000 
ntpshm_segment          0 # # Transport options # 
transportSpecific       0x0 ptp_dst_mac             01:1B:19:00:00:00 
p2p_dst_mac             01:80:C2:00:00:0E udp_ttl                 32 
udp6_scope              0x0E uds_address             /var/run/ptp4l # # 
Default interface options # clock_type              OC 
network_transport       UDPv4 delay_mechanism         E2E 
time_stamping           hardware tsproc_mode             filter 
delay_filter            moving_median delay_filter_length     10 
egressLatency           0 ingressLatency          0 boundary_clock_jbod  
    0 # # Clock description # productDescription      ;; 
revisionData            ;; manufacturerIdentity    00:00:00 
userDescription         ; timeSource              0xA0 Thanks in advance, J |

Re: [Linuxptp-users] Can not sync with ptp4l slave

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

On Fri, Jun 03, 2022 at 12:40:15PM +0000, Barbaros Kazan via Linuxptp-users wrote:
> ptp4l[2698.347]: selected local clock aabbcc.fffe.ddee27 as best master
> ptp4l[2699.143]: port 1: unicast request timeout
> ptp4l[2699.144]: port 1: time to renew unicast subscriptions
> ptp4l[2699.144]: port 1: unicast ANNOUNCE granted for 60 sec
> ptp4l[2699.177]: port 1: renewal timeout at 2744
> ptp4l[2699.178]: port 1: unicast SYNC granted for 60 sec
> ptp4l[2699.178]: port 1: unicast DELAY_RESP granted for 60 sec
> ptp4l[2699.552]: selected best master clock b49691.fffe.b7a21c
> ptp4l[2699.552]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE

Your client has not entered the SLAVE state, and it is not yet
synchronizing.

In order to transition from the UNCALIBRATED state, it needs to
complete one delay measurement.

Check the request/responses with tcpdump/wireshark.

> ptp4l[2699.661]: u_pi_state                1
> ptp4l[2699.695]: u_pi_last_freq            2000.000000
> ptp4l[2699.695]: u_pi_offset               1271227
> ptp4l[2699.695]: u_pi_freq                 2000.000000
> ptp4l[2699.728]: u_pi_freq_diff            0.000000
> ptp4l[2699.728]: u_pi_lock_check_cnt       0/100
> ptp4l[2699.729]: u_pi_unlock_check_cnt     0/100
> ptp4l[2699.729]: u_pi_offset_mavg_result   17846/100
> ptp4l[2699.762]: u_pi_freq_mavg_result     0.000000/50.000000
> ptp4l[2699.762]: share_lock_status         0
> ptp4l[2699.763]: u_pi_bring_up_core1_flag  0

This is not the official SW, and so I won't support it.

Thanks,
Richard

[Linuxptp-users] Can not sync with ptp4l slave

[Barbaros K. <bar...@ya...>]

Hello all, i am trying to sync an embedded platform with my server as using my server as master and the embedded platform as slave using G.8275.x

On the master side my ethernet card has the ethtool output;

Time stamping parameters for enp134s0f0:
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: 7
Hardware Transmit Timestamp Modes:
    off                   (HWTSTAMP_TX_OFF)
    on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
    none                  (HWTSTAMP_FILTER_NONE)
    all                   (HWTSTAMP_FILTER_ALL)



ethtool -i enp134s0f0
driver: ice
version: 1.8.8
firmware-version: 2.10 0x8000433d 1.2789.0
expansion-rom-version: 
bus-info: 0000:86:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes


I am setting ptp device clock from system clock, everything is fine 

ptp4l -i enp134s0f0 -l 7 -f default.cfg &
phc2sys -c enp134s0f0 -n 44 -s CLOCK_REALTIME -O 0 &

phc_ctl /dev/ptp7 get or phc_ctl enp134s0f0 get 

phc_ctl[11027.049]: clock time is 1654258591.165904796 or Fri Jun  3 15:16:31 2022 (synced with real time)




phc2sys: [11286.528] enp134s0f0 sys offset       -14 s2 freq  +81619 delay    682
phc2sys: [11287.530] enp134s0f0 sys offset        21 s2 freq  +81650 delay    682
phc2sys: [11288.531] enp134s0f0 sys offset        -2 s2 freq  +81633 delay    589
phc2sys: [11289.533] enp134s0f0 sys offset         5 s2 freq  +81640 delay    681
phc2sys: [11290.533] enp134s0f0 sys offset         7 s2 freq  +81643 delay    678
phc2sys: [11291.534] enp134s0f0 sys offset        -8 s2 freq  +81630 delay    683
phc2sys: [11292.535] enp134s0f0 sys offset       -45 s2 freq  +81591 delay    578
phc2sys: [11293.537] enp134s0f0 sys offset        18 s2 freq  +81641 delay    686
phc2sys: [11294.540] enp134s0f0 sys offset         3 s2 freq  +81631 delay    682
phc2sys: [11295.540] enp134s0f0 sys offset        25 s2 freq  +81654 delay    681
phc2sys: [11296.542] enp134s0f0 sys offset       -13 s2 freq  +81623 delay    682
phc2sys: [11297.544] enp134s0f0 sys offset       -20 s2 freq  +81612 delay    681
phc2sys: [11298.545] enp134s0f0 sys offset         3 s2 freq  +81629 delay    587
My default config file is


global]
#
# Default Data Set
#
twoStepFlag             1
clientOnly              0
socket_priority         0
priority1               127
priority2               128
domainNumber            44
#utc_offset             37
clockClass              248
clockAccuracy           0xFE
offsetScaledLogVariance 0xFFFF
free_running            0
freq_est_interval       1
dscp_event              0
dscp_general            0
dataset_comparison      G.8275.x
G.8275.defaultDS.localPriority  128
maxStepsRemoved         255
#
# Port Data Set
#
logAnnounceInterval     1
logSyncInterval         0
operLogSyncInterval     0
logMinDelayReqInterval  0
logMinPdelayReqInterval 0
operLogPdelayReqInterval 0
announceReceiptTimeout  3
syncReceiptTimeout      0
delay_response_timeout  0
delayAsymmetry          0
fault_reset_interval    4
neighborPropDelayThresh 20000000
serverOnly              1
G.8275.portDS.localPriority     128
asCapable               auto
BMCA                    ptp
inhibit_announce        0
inhibit_delay_req       0
ignore_source_id        0
#
# Run time options
#

assume_two_step         0
logging_level           6
path_trace_enabled      0
follow_up_info          0
hybrid_e2e              1
inhibit_multicast_service       1
net_sync_monitor        0
tc_spanning_tree        0
tx_timestamp_timeout    10
unicast_listen          1
unicast_master_table    0
unicast_req_duration    3600
use_syslog              1
verbose                 0
summary_interval        0
kernel_leap             1
check_fup_sync          0
clock_class_threshold   248
#
# Servo Options
#
pi_proportional_const   0.0
pi_integral_const       0.0
pi_proportional_scale   0.0
pi_proportional_exponent        -0.3
pi_proportional_norm_max        0.7
pi_integral_scale       0.0
pi_integral_exponent    0.4
pi_integral_norm_max    0.3
step_threshold          0.0
first_step_threshold    0.00002
max_frequency           900000000
clock_servo             pi
sanity_freq_limit       200000000
ntpshm_segment          0
msg_interval_request    0
servo_num_offset_values 10
servo_offset_threshold  0
write_phase_mode        0
#

# Transport options
#
transportSpecific       0x0
ptp_dst_mac             01:1B:19:00:00:00
p2p_dst_mac             01:80:C2:00:00:0E
udp_ttl                 1
udp6_scope              0x0E
uds_address             /var/run/ptp4l
uds_file_mode           0660
uds_ro_address          /var/run/ptp4lro
uds_ro_file_mode                0666
#
# Default interface options
#
clock_type              OC
network_transport       UDPv4
delay_mechanism         E2E
time_stamping           hardware
tsproc_mode             filter
delay_filter            moving_median
delay_filter_length     10
egressLatency           0
ingressLatency          0
boundary_clock_jbod     0
phc_index               -1
#
# Clock description
#
productDescription      ;;
revisionData            ;;
manufacturerIdentity    00:00:00
userDescription         ;
timeSource              0xA0



---------------
On the slave side, when i do 

/usr/linuxptp/ptp4l -i qse-eth -smf /usr/linuxptp/configs/user_gen.cfg -l 9
/phc_ctl qse-eth get

I see that clock ise synced with my rmaster b49691.fffe.b7a21c
As you see in log, it selects b49691.fffe.b7a21c

But after that it selects and tries local clock that is the clock of eth interface

ptp4l[2698.347]: selected local clock aabbcc.fffe.ddee27 

there is negative delay with own local clock and remote master is not synced

the pmc output shows the status.

It never syncs with my master and tries local with huge offset.

But phc clock is continously synced with my master clock.


 
ptp4l[2698.347]: selected local clock aabbcc.fffe.ddee27 as best master
ptp4l[2699.143]: port 1: unicast request timeout
ptp4l[2699.144]: port 1: time to renew unicast subscriptions
ptp4l[2699.144]: port 1: unicast ANNOUNCE granted for 60 sec
ptp4l[2699.177]: port 1: renewal timeout at 2744
ptp4l[2699.178]: port 1: unicast SYNC granted for 60 sec
ptp4l[2699.178]: port 1: unicast DELAY_RESP granted for 60 sec
ptp4l[2699.552]: selected best master clock b49691.fffe.b7a21c
ptp4l[2699.552]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[2699.594]: port 1: delay timeout
ptp4l[2699.627]: negative delay      -2567
ptp4l[2699.628]: delay = (t2 - t3) * rr + (t4 - t1)
ptp4l[2699.628]: t2 - t3 =  -62117995
ptp4l[2699.628]: t4 - t1 =  +62112860
ptp4l[2699.661]: rr = 1.000000000
ptp4l[2699.661]: delay   filtered      -2567   raw      -2567
ptp4l[2699.661]: u_pi_state                1
ptp4l[2699.695]: u_pi_last_freq            2000.000000
ptp4l[2699.695]: u_pi_offset               1271227
ptp4l[2699.695]: u_pi_freq                 2000.000000
ptp4l[2699.728]: u_pi_freq_diff            0.000000
ptp4l[2699.728]: u_pi_lock_check_cnt       0/100
ptp4l[2699.729]: u_pi_unlock_check_cnt     0/100
ptp4l[2699.729]: u_pi_offset_mavg_result   17846/100
ptp4l[2699.762]: u_pi_freq_mavg_result     0.000000/50.000000
ptp4l[2699.762]: share_lock_status         0
ptp4l[2699.763]: u_pi_bring_up_core1_flag  0
ptp4l[2699.796]: ptp_sync_status  0
ptp4l[2699.796]: ptp_freq         2000
ptp4l[2699.796]: ptp_rms          672288
ptp4l[2699.796]: ptp_rms_max      1029942
ptp4l[2699.829]: ptp_delay        -3330
ptp4l[2699.830]: reserved         0


sending: GET CURRENT_DATA_SET
    aabbcc.fffe.ddee27-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET 
        stepsRemoved     1
        offsetFromMaster 116346207.0
        meanPathDelay    -752.0
    b49691.fffe.b7a21c-1 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET 
        stepsRemoved     0
        offsetFromMaster 0.0
        meanPathDelay    0.0



:/usr/linuxptp# ./pmc -u -b 1 -d 44 'GET CURRENT_DATA_SET'sending: GET CURRENT_DATA_SET
    aabbcc.fffe.ddee27-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET 
        stepsRemoved     1
        offsetFromMaster 364137.0
        meanPathDelay    -876.0

 
pmc -u -b 1 -d 44 'GET CURRENT_DATA_SET'sending: GET CURRENT_DATA_SET
    aabbcc.fffe.ddee27-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET 
        stepsRemoved     1
        offsetFromMaster 364137.0
        meanPathDelay    -876.0

./pmc -u -b 1 -d 44 'GET CURRENT_DATA_SET'
sending: GET CURRENT_DATA_SET
    aabbcc.fffe.ddee27-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET 
        stepsRemoved     1
        offsetFromMaster 115345133.0
        meanPathDelay    -2406.0
    b49691.fffe.b7a21c-1 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET 
        stepsRemoved     0
        offsetFromMaster 0.0
        meanPathDelay    0.0



Thanks for help, Kind Regards

Re: [Linuxptp-users] Finding the Fixed offset between two Ports of the same NIC.

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

On Tue, May 31, 2022 at 12:02:33PM +0000, Deshpande, Yash wrote:
> However, trying to reuse the pieces of code from phc2sys.c "read_phc" did not give satisfactory results.

> I know that PPS loopback is probably the best way going forward - but i was wondering if there is any easier and more obvious way that I am missing out.

You could compare the two clocks relative to the system clock using
there calls of the PTP_SYS_OFFSET_EXTENDED ioctl, similarly to running

phc_ctl eth0 cmp
phc_ctl eth1 cmp
phc_ctl eth0 cmp

and comparing the mean offset from the first and third call with the
offset from the second call.

That should give you more stable measurements as the they will not be
impacted by userspace, but there will likely still be some asymmetry
of at least few nanoseconds due to PCIe, CPU and the I350 itself.

If you decide to go with PPS timestamping and depending on how much you
want to avoid asymmetries in your measurements, it might be better to
have both ports as PPS input timestamping an external PPS signal
instead of connecting one port as PPS output to the other as PPS
input.

-- 
Miroslav Lichvar

[Linuxptp-users] Finding the Fixed offset between two Ports of the same NIC.

[Deshpande, Y. <yas...@tu...>]

Hello All,


Here is my setup and what I observe:

An intel i350 NIC with two RJ45 Ports is connected to a simple 4 Core PC with Linux (Ubuntu 20). A cable is connected between the two ports (this is what I call a loopback connection). When I run a PTP Source (Master) on one port and a PTP Sink (Slave) on the other with the latter in free_running mode, I see that the Sink reports a constant offset - for a test I ran for 3 hours. Since I dont adjust the time or frequency on the sink port, and I get a constant offset for an extended period of time, I assume that the clocks on both the ports are running on the same Oscillator (what the Datasheet seems to suggest as well). Is this assumption correct?

The reported offset value changes every time I reboot. It also changes after I assign each port to a separate namespace.


What I want to do:

Now I want to find this offset value without running PTP4l because the Loopback connection will be done with a DUT in the middle. Assuming that the offset between the two ports is constant, I assume that a mechanism that gets the clock values from the two ports repeatedly and one after the other should help in finding this value.

However, trying to reuse the pieces of code from phc2sys.c "read_phc" did not give satisfactory results.


Here is my rough piece of code.


static int64_t read_phc_offsets(clockid_t clkid1, clockid_t clkid2)
{
struct timespec tdst1, tdst2, tsrc;
int i;
int64_t interval, best_interval = INT64_MAX;
int readings = 10;
int64_t offset,ts;
/* Pick the quickest clkid reading. */
for (i = 0; i < readings; i++) {
if (clock_gettime(clkid2, &tdst1) ||
clock_gettime(clkid1, &tsrc) ||
clock_gettime(clkid2, &tdst2)) {
printf("Failed to read clock");
return 0;
}

interval = (tdst2.tv_sec - tdst1.tv_sec) * NS_PER_SEC +
tdst2.tv_nsec - tdst1.tv_nsec;

if (best_interval > interval) {
best_interval = interval;
offset = ((tdst1.tv_sec - tsrc.tv_sec) * NS_PER_SEC) + (tdst1.tv_nsec - tsrc.tv_nsec);
ts = tdst2.tv_sec * NS_PER_SEC + tdst2.tv_nsec;
}
}
ts = best_interval;
return offset;
}


Where clkid1 is the Clock ID of the first port and clkid2 is the Clock ID of the second port.


I know that PPS loopback is probably the best way going forward - but i was wondering if there is any easier and more obvious way that I am missing out.


Best Regards

Yash Deshpande



Yash Deshpande
Lehrstuhl für Kommunikationsnetze
Technische Universität München
Arcisstr. 21, 80333 München

Fon: +49 89 289 23511
yas...@tu...
www.lkn.ei.tum.de<http://www.lkn.ei.tum.de>

Re: [Linuxptp-users] Linux PTP4l Query : Simple Experiment connecting 2 VMs

[Ritesh D. <hum...@gm...>]

Thanks a lot Miroslav
     I tried removing the complete firewall, and it was such a relief to
see it working fine. Thanks again for your suggestion.

Regards
Ritesh

On Mon, May 23, 2022 at 5:36 PM Miroslav Lichvar <mli...@re...>
wrote:

> On Mon, May 23, 2022 at 05:14:58PM +0530, Ritesh Dhingra wrote:
> > VM-2 is a clone of VM-1. Both VMs have one  ens3 port each which are
> > interconnected.
> > In VM-2 Wireshark, I can see that Announce Message , Sync Message and
> > Follow_UP Message are reaching VM-2 on port ens3, from VM-1 ens3.
> > I have used all the default configurations, using the default ptp4l.conf
> > file.
>
> Have you allowed the PTP ports (319 and 320) in firewall?
>
> --
> Miroslav Lichvar
>
>

-- 
Regards
Ritesh

Re: [Linuxptp-users] Reporting a covert channel vulnerability

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

Abby,

On Mon, May 23, 2022 at 01:27:29PM -0500, Abby Marsh wrote:
> I'm a researcher working on a project that's confirmed a viable covert
> channel in the current version of linuxptp. I'd like to report this; is it
> best to do so here, or on another list?

What is a "viable covert channel", and why does it matter?

Thanks,
Richard

[Linuxptp-users] Reporting a covert channel vulnerability

[Abby M. <am...@ma...>]

Hello, all—

I'm a researcher working on a project that's confirmed a viable covert
channel in the current version of linuxptp. I'd like to report this; is it
best to do so here, or on another list?

Thanks!

-- 
Abby Marsh (They/Them)
Assistant Professor of Computer Science
Macalester College

Re: [Linuxptp-users] Linux PTP4l Query : Simple Experiment connecting 2 VMs

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

On Mon, May 23, 2022 at 05:14:58PM +0530, Ritesh Dhingra wrote:
> VM-2 is a clone of VM-1. Both VMs have one  ens3 port each which are
> interconnected.
> In VM-2 Wireshark, I can see that Announce Message , Sync Message and
> Follow_UP Message are reaching VM-2 on port ens3, from VM-1 ens3.
> I have used all the default configurations, using the default ptp4l.conf
> file.

Have you allowed the PTP ports (319 and 320) in firewall?

-- 
Miroslav Lichvar

[Linuxptp-users] Linux PTP4l Query : Simple Experiment connecting 2 VMs

[Ritesh D. <hum...@gm...>]

Hi Folks,
    I am trying to perform a simple experiment between 2 VMs, with 1 OC on
each VM. VM-1 in Master mode and VM-2 in Slave mode.
However, I see VM-2 OC never goes into SLAVE mode and selecting its local
clock as its BMC :  *"selected local clock 525400.fffe.9b28c6 as best
master"*
Can you please help, if I am missing something.

*Setup Used:*
VM-2 is a clone of VM-1. Both VMs have one  ens3 port each which are
interconnected.
In VM-2 Wireshark, I can see that Announce Message , Sync Message and
Follow_UP Message are reaching VM-2 on port ens3, from VM-1 ens3.
I have used all the default configurations, using the default ptp4l.conf
file.

I am using :
--CentOS Linux-7
--5.15.1-1.el7.elrepo.x86_64
--PTP version used is : 1588-v2

*Commands Used and Output : *

*VM-1*
*(root@localhost /etc) **ptp4l -S -A -l 6 -q -i ens3 -f /etc/ptp4l.conf -m*
ptp4l[77831.311]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[77831.311]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[77838.185]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[77838.185]: selected local clock 525400.fffe.5d8331 as best master
ptp4l[77838.185]: assuming the grand master role

*VM-2:* (-s to Force it to be Slave )
*(root@localhost /etc) ptp4l -S -A -l 6 -q -i ens3 -f /etc/ptp4l.conf -s -m*
ptp4l[77768.013]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[77768.013]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[77774.209]: selected local clock 525400.fffe.9b28c6 as best master
ptp4l[77781.751]: selected local clock 525400.fffe.9b28c6 as best master
ptp4l[77788.333]: selected local clock 525400.fffe.9b28c6 as best master

Regards
Ritesh

[Linuxptp-users] SDP rework guide for Intel i210 cards

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

Dear list,

I put together a little guide on how to use the hardware signals on
the Intel i210 Ethernet controller cards.

   http://linuxptp.sourceforge.net/i210-rework/i210-rework.html

Enjoy!

Thanks,
Richard

Re: [Linuxptp-users] Filter occasional spikes in offset

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

This should be discussed at linuxptp-devel.

On Wed, May 04, 2022 at 11:39:19AM +0000, Oleg Obleukhov wrote:
> >> I implemented a quick patch https://gist.github.com/leoleovich/5a4dff7e089bd429c5d208d9276e1683 which can mitigate this and it works very well:
> > 
> >> Preventing unnecessary tuning of the servo for a short period of time by using a padding technique (simply filling with previous values).
> The patch I proposed simply doesn’t pass the offset to a servo - so it shouldn’t be too bad. For example with default ptp4l settings we can tolerate several missed syncs in a row. But I am open for suggestions of course.

I think the default configuration of the PI servo can tolerate only
one missed update at a time. If you repeatedly drop two samples and
pass one, it will be unstable and oscillations will grow until it is
updated at a higher rate. However unlikely that would be to happen in
real world, your patch doesn't seem to prevent that.

> > That patch seems to be dropping the sample and there is a different
> > output shown in the example. Is there a newer version of the patch you
> > didn't publish?
> The code I suggested matches the output. It simply prints something like:
> skip 1/2 large offset (>20000) -248483
> When occasional spikes arise. The only difference is max_offset_locked and max_offset_locked_skip should be set to 0 and currently they are at 20000  and 2 respectively. 

The example output posted here didn't have the SYNCHRONIZATION_FAULT
messages, so I assumed you were doing something with the servo.

-- 
Miroslav Lichvar

[Linuxptp-users] [help] I want to output pps in inter i210

[652436962 <652...@qq...>]

<!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 style="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;
  }
  .tinymce-editor-sign:empty::before,.tinymce-content-sign:empty::before{
    border-top: none;
  }
  #sign .m-account, .tinymce-editor-sign .m-account{
    display: inline-block;
    color: #0000ee;
    cursor: pointer;
  }</style></head><body id="tinymce" class="mce-content-body" data-id="#vue-tinymce-1652152119866695" aria-label="Rich Text Area. Press ALT-0 for help." contenteditable="true" spellcheck="false" style="min-height: 410px;" data-mce-style="min-height: 410px;"><div class="tinymce-mail-content"><p>I have a&nbsp; inter i210,&nbsp; I test ptp sync ,now&nbsp; I already&nbsp; use linuxptp project sync,&nbsp; I want to&nbsp; output pps&nbsp; &nbsp;,&nbsp; &nbsp;what&nbsp; should i do?</p><p><br></p></div></body></html>

Re: [Linuxptp-users] Filter occasional spikes in offset

[Oleg O. <leo...@fb...>]

> On 4 May 2022, at 11:33, Miroslav Lichvar <mli...@re...> wrote:
> 
Hi Miroslav,
Thank you for your response. I appreciate it.
> On Tue, May 03, 2022 at 02:26:21PM +0000, Oleg Obleukhov via Linuxptp-users wrote:
>> Hi team,
>> In large distributed networks very many factors can lead to a short term spike in offset. Primarily network equipment without Transparent Clock support (even on a single device).
> 
> PTP was designed for networks with constant delay. On switched
> networks that requires full on-path PTP support. If you don't have
> that, you should be looking at NTP or another protocol designed for
> networks with variable delays, where more effective filtering can be
> implemented.
While we are phasing out old equipment the reality is - there will be always some % of misbehaving/old switches in large distributed systems with thousands switches on the way. During congestion which only lasts several microseconds we may be affected and we need to survive. 
> 
> Of course, that doesn't mean linuxptp couldn't try to do better in
> these suboptimal conditions. The question is if it's in the scope of
> the project. As you seem to have found out, the main issue with the
> current design is that dropping samples can lead to servo instability.
> 
>> Looking at ptp4l config I didn’t to find anything to overcome this situation and ignore this 1 bad outlier.
>> I implemented a quick patch https://gist.github.com/leoleovich/5a4dff7e089bd429c5d208d9276e1683 which can mitigate this and it works very well:
> 
>> Preventing unnecessary tuning of the servo for a short period of time by using a padding technique (simply filling with previous values).
The patch I proposed simply doesn’t pass the offset to a servo - so it shouldn’t be too bad. For example with default ptp4l settings we can tolerate several missed syncs in a row. But I am open for suggestions of course.
> 
> That patch seems to be dropping the sample and there is a different
> output shown in the example. Is there a newer version of the patch you
> didn't publish?
The code I suggested matches the output. It simply prints something like:
skip 1/2 large offset (>20000) -248483
When occasional spikes arise. The only difference is max_offset_locked and max_offset_locked_skip should be set to 0 and currently they are at 20000  and 2 respectively. 
> 
>> The bottom line is - we need to find a way to ignore outliers in a locked state where it’s not expected to have shot term large jumps in offset.
>> Please check this out and let me know if there is a better way to handle this situation or if this patch can inspire any other ideas…
> 
> If a spike filter needs to be implemented, I think it would better if
> the threshold was automatically adjusted based on the jitter. For an
> example, see the "Popcorn spike suppressor" in RFC5905 (NTPv4).
Automatically adjusted filter is something even better. If you open for such idea we can discuss this as well. I wanted to start somewhere.
> 
> -- 
> Miroslav Lichvar
> 
Thank you,
Oleg.