Re: [Linuxptp-users] Configuration for boundary clock with on two-port NIC

[Andre P. <and...@sr...>]

Hi everyone,

I am picking up this thread as we're still facing some issues with 
getting the BC mode working on this two-port Intel 82599ES NIC.

Cabling is still the same as in the original post - one port receives 
PTP sync from an external GM and should redistribute it over the second 
port to a client.

We've previously used two ptp4linux instances, one for each interface 
but I am not sure that is the way to go. Indeed the clock_mode setting 
in the config file allows for BC which in turn requires two interfaces 
to be specified. However, doing so results in a PHC device mismatch:

  /opt/linuxptp/ptp4l -2 -i enp1s0f1 -i enp1s0f0 -f 
/opt/ptp4l_cfg/bc.cfg -m -l 6
ptp4l[851.735]: selected /dev/ptp1 as PTP clock
ptp4l[851.735]: port 1 (enp1s0f1): PHC device mismatch
ptp4l[851.735]: port 1 (enp1s0f1): /dev/ptp1 requested, ptp0 attached
ptp4l[851.735]: failed to open port enp1s0f1
failed to create a clock

I am not sure where this is coming from but indeed the first interface 
seems PHC 1 assigned and the second PHC 0. Not sure if this is an issue.

$ ethtool -T enp1s0f0
Time stamping parameters for enp1s0f0:
Capabilities:
         hardware-transmit
         software-transmit
         hardware-receive
         software-receive
         software-system-clock
         hardware-raw-clock
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
         off
         on
Hardware Receive Filter Modes:
         none
         ptpv1-l4-sync
         ptpv1-l4-delay-req
         ptpv2-event


I've further noticed the phc_index config param but it doesn't make a 
difference, resulting in the same mismatch error.

Specifying the -p param, however, helps in getting over (this) error but 
I still don't get PTP packets on the output interface (tcpdump not 
showing anything).

/opt/linuxptp/ptp4l -2 -i enp1s0f1 -i enp1s0f0 -p /dev/ptp0 -f 
/opt/ptp4l_cfg/bc.cfg -m -l6
ptp4l[1040.051]: selected /dev/ptp0 as PTP clock
ptp4l[1040.051]: port 2 (enp1s0f0): taking /dev/ptp0 from the command 
line, not the attached ptp1
ptp4l[1040.097]: driver rejected most general HWTSTAMP filter
ptp4l[1040.097]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range
ptp4l[1040.132]: port 1 (enp1s0f1): INITIALIZING to FAULTY on 
FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1040.180]: driver rejected most general HWTSTAMP filter
ptp4l[1040.180]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range
ptp4l[1040.220]: port 2 (enp1s0f0): INITIALIZING to FAULTY on 
FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1040.220]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[1040.220]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on 
INIT_COMPLETE


My questions are now whether or not the BC clock_mode is the way to go? 
And, if so, what do you think might be causing the issues we are seeing 
with the config [1] or setup?

Thanks
Andre


[1] https://pastes.io/epvudxplcz



On 3/10/23 15:41, Nils Fuerste wrote:
> Ah yeah, I didnt read well. That really improved the sync quality - 
> thanks a lot for your advice!
> 
> On 3/10/23 14:38, Miroslav Lichvar wrote:
>> On Tue, Oct 03, 2023 at 02:33:32PM +0200, Nils Fuerste wrote:
>>> Thanks for your help! Unfortunately, setting those values doesn't 
>>> work for
>>> me. I get the following errors:
>>>
>>> sudo ptp4l -2 -i enp1s0f1 -f ./default-new-master.cfg -m
>>> -1.0 is an out of range value for option pi_proportional_const at 
>>> line 73
>>> failed to parse configuration file ./default-new-master.cfg
>> It should be pi_proportional_exponent, not pi_proportional_const.
>>
>>> $ sudo ptp4l -2 -i enp1s0f1 -f ./default-new-master.cfg -m
>>> P is a malformed value for option pi_proportional_scale at line 75
>>> failed to parse configuration file ./default-new-master.cfg
>> P and I should be replaced with the values from the table.
>>
> 
> 
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users