Re: [Linuxptp-devel] Intel 210 to Intel 255

2021-06-09 Thread Keller, Jacob E 



> -Original Message-
> From: Richard Cochran 
> Sent: Monday, June 07, 2021 11:42 AM
> To: Geva, Erez 
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] Intel 210 to Intel 255
> 
> On Mon, Jun 07, 2021 at 02:01:28PM +, Geva, Erez wrote:
> 
> > Jun  7 15:44:07 ipc01 ptp4l: [673.869] timed out while polling for tx 
> > timestamp
> > Jun  7 15:44:07 ipc01 ptp4l: [673.869] increasing tx_timestamp_timeout may
> correct this issue, but it is likely caused by a driver bug
> 
> Try  --tx_timestamp_timeout=100
> 
> HTH,
> Richard
> 

I would recommend this as well, even for the i210. At least to rule out whether 
or not the issue still exists if you extend the timeout.

The timestamp is captured via interrupt, but I believe the igb driver might 
still rely on a work thread to actually finish reporting the timestamp. Even if 
it doesn't, there is some delay before the device gets notified of the 
timestamp, as well as further delay caused by reading the timestamp register. 
While it should still take less than the 1millisecond of time, I definitely 
recall cases where it took long enough to exceed the time limit in the worst 
case.

Thanks,
Jake


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Intel 210 to Intel 255

2021-06-07 Thread Frantisek Rysanek 
On 7 Jun 2021 at 11:42, Richard Cochran wrote:
>
> On Mon, Jun 07, 2021 at 02:01:28PM +, Geva, Erez wrote:
> 
> > Jun  7 15:44:07 ipc01 ptp4l: [673.869] timed out while polling for tx 
> > timestamp
> > Jun  7 15:44:07 ipc01 ptp4l: [673.869] increasing tx_timestamp_timeout may 
> > correct this issue, but it is likely caused by a driver bug
> 
> Try  --tx_timestamp_timeout=100
> 
> HTH,
> Richard
> 
I've taken another look, and I have to second that.
Richard is right.
I have "--tx_timestamp_timeout=20" in all my scripts, starting ptp4l 
in various configurations. I haven't started ptp4l by bare hand for 
ages.
That old LOM with broken timestamping would throw timeouts even with 
this setting.

Frank


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Intel 210 to Intel 255

2021-06-07 Thread Richard Cochran 
On Mon, Jun 07, 2021 at 02:01:28PM +, Geva, Erez wrote:

> Jun  7 15:44:07 ipc01 ptp4l: [673.869] timed out while polling for tx 
> timestamp
> Jun  7 15:44:07 ipc01 ptp4l: [673.869] increasing tx_timestamp_timeout may 
> correct this issue, but it is likely caused by a driver bug

Try  --tx_timestamp_timeout=100

HTH,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Intel 210 to Intel 255

2021-06-07 Thread Frantisek Rysanek 
...just my two cents worth, I haven't seen this error message for a
few years. I did get it back in 2017-ish on some older LOM NIC's by
Intel. The i210 has always been a workhorse for me.
This message is "local" = somewhere between the NIC HW and the
kernel-mode driver.
Then again, I'm not using the recentmost kernels. Maybe I should give
them a try. And I cannot rule out the possibility that some
development has happened inside the i210 firmware. My i210 hardware
is 2-3 years old now. My ptp4l isn't exactly bleeding edge either.

Umm... PCI-e ASPM comes to mind, maybe.
The master and slave are the same HW platform (motherboard model) ?
As you tried to "turn the table" on the bug, at various layers, have
you tried switching the motherboards? (It's just a silly theory, the
chances aren't high.)

Frank



On 7 Jun 2021 at 14:01, Geva, Erez wrote:

Hi,
 
I see an issue with the ptp4l using an Intel I210 connected back to
back to an Intel i255.
I am not sure if the issue is Intel related or is it ptp4l.
Probably something wrong that I did.
 
I use a very simple configuration:
On client side:
[global]
delay_mechanism P2P
network_transport L2
time_stamping hardware
slaveOnly 1
priority1 255
priority2 255
hwts_filter full
 
On source side:
[global]
delay_mechanism P2P
network_transport L2
time_stamping hardware
slaveOnly 0
priority1 100
priority2 100
hwts_filter full
 
I get this message on client.
I tried to switch sides of source, client and have the same message,
once on the I210 and once in the i255.
 
Jun  7 15:44:06 ipc01 ptp4l: [672.901] master offset    177 s2
freq  -34616 path delay   -10
Jun  7 15:44:06 ipc01 ptp4l: [673.434] port 1: FAULTY to LISTENING on
INIT_COMPLETE
Jun  7 15:44:07 ipc01 ptp4l: [673.869] timed out while polling for tx
timestamp
Jun  7 15:44:07 ipc01 ptp4l: [673.869] increasing
tx_timestamp_timeout may correct this issue, but it is likely caused
by a driver bug
Jun  7 15:44:07 ipc01 ptp4l: [673.869] port 1: send peer delay
response failed
 
I use both interface with auto-negotiation
 
root@ipc01:~# ethtool -i enp8s0
driver: igb
version: 5.10.30-rt37-tsn3-rt-ipipe
...
root@ipc01:~# ethtool  enp8s0
Settings for enp8s0:
   Supported ports: [ TP ]
   Supported link modes:   10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Supported pause frame use: Symmetric
   Supports auto-negotiation: Yes
   Supported FEC modes: Not reported
   Advertised link modes:  10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Advertised pause frame use: Symmetric
   Advertised auto-negotiation: Yes
   Advertised FEC modes: Not reported
   Speed: 1000Mb/s
   Duplex: Full
   Port: Twisted Pair
   PHYAD: 1
   Transceiver: internal
   Auto-negotiation: on
   MDI-X: on (auto)
   Supports Wake-on: pumbg
   Wake-on: g
   Current message level: 0x0007 (7)
    drv probe link
   Link detected: yes
 
 
root@ipc02:~# ethtool -i enp7s0
driver: igc
version: 5.10.30-rt37-tsn3-rt-ipipe
...
root@ipc02:~# ethtool enp7s0
Settings for enp7s0:
   Supported ports: [ ]
   Supported link modes:   10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   2500baseT/Full
   Supported pause frame use: Symmetric
   Supports auto-negotiation: Yes
   Supported FEC modes: Not reported
   Advertised link modes:  10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Advertised pause frame use: Symmetric
   Advertised auto-negotiation: Yes
   Advertised FEC modes: Not reported
   Speed: 1000Mb/s
   Duplex: Full
   Port: Twisted Pair
   PHYAD: 0
   Transceiver: internal
   Auto-negotiation: on
   MDI-X: off (auto)
   Supports Wake-on: pumbg
   Wake-on: g
   Current message level: 0x0007 (7)
    drv probe link
   Link detected: yes
 
With best regards,
Erez Geva

AURELLY TECHNOLOGIES GmbH 
External service provider at Siemens AG
Digital Industries
Process Automation
Software House Nbg
DI PA DCP R 3
Gleiwitzer Str. 555
90475 Nuremberg, Germany 
mailto:erez.geva@siemens.com
 

[Linuxptp-devel] Intel 210 to Intel 255

2021-06-07 Thread Geva, Erez 
Hi,

I see an issue with the ptp4l using an Intel I210 connected back to back to an 
Intel i255.
I am not sure if the issue is Intel related or is it ptp4l.
Probably something wrong that I did.

I use a very simple configuration:
On client side:
[global]
delay_mechanism P2P
network_transport L2
time_stamping hardware
slaveOnly 1
priority1 255
priority2 255
hwts_filter full

On source side:
[global]
delay_mechanism P2P
network_transport L2
time_stamping hardware
slaveOnly 0
priority1 100
priority2 100
hwts_filter full

I get this message on client.
I tried to switch sides of source, client and have the same message, once on 
the I210 and once in the i255.

Jun  7 15:44:06 ipc01 ptp4l: [672.901] master offset177 s2 freq  -34616 
path delay   -10
Jun  7 15:44:06 ipc01 ptp4l: [673.434] port 1: FAULTY to LISTENING on 
INIT_COMPLETE
Jun  7 15:44:07 ipc01 ptp4l: [673.869] timed out while polling for tx timestamp
Jun  7 15:44:07 ipc01 ptp4l: [673.869] increasing tx_timestamp_timeout may 
correct this issue, but it is likely caused by a driver bug
Jun  7 15:44:07 ipc01 ptp4l: [673.869] port 1: send peer delay response failed

I use both interface with auto-negotiation

root@ipc01:~# ethtool -i enp8s0
driver: igb
version: 5.10.30-rt37-tsn3-rt-ipipe
...
root@ipc01:~# ethtool  enp8s0
Settings for enp8s0:
   Supported ports: [ TP ]
   Supported link modes:   10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Supported pause frame use: Symmetric
   Supports auto-negotiation: Yes
   Supported FEC modes: Not reported
   Advertised link modes:  10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Advertised pause frame use: Symmetric
   Advertised auto-negotiation: Yes
   Advertised FEC modes: Not reported
   Speed: 1000Mb/s
   Duplex: Full
   Port: Twisted Pair
   PHYAD: 1
   Transceiver: internal
   Auto-negotiation: on
   MDI-X: on (auto)
   Supports Wake-on: pumbg
   Wake-on: g
   Current message level: 0x0007 (7)
drv probe link
   Link detected: yes


root@ipc02:~# ethtool -i enp7s0
driver: igc
version: 5.10.30-rt37-tsn3-rt-ipipe
...
root@ipc02:~# ethtool enp7s0
Settings for enp7s0:
   Supported ports: [ ]
   Supported link modes:   10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   2500baseT/Full
   Supported pause frame use: Symmetric
   Supports auto-negotiation: Yes
   Supported FEC modes: Not reported
   Advertised link modes:  10baseT/Half 10baseT/Full
   100baseT/Half 100baseT/Full
   1000baseT/Full
   Advertised pause frame use: Symmetric
   Advertised auto-negotiation: Yes
   Advertised FEC modes: Not reported
   Speed: 1000Mb/s
   Duplex: Full
   Port: Twisted Pair
   PHYAD: 0
   Transceiver: internal
   Auto-negotiation: on
   MDI-X: off (auto)
   Supports Wake-on: pumbg
   Wake-on: g
   Current message level: 0x0007 (7)
drv probe link
   Link detected: yes

With best regards,
Erez Geva

AURELLY TECHNOLOGIES GmbH
External service provider at Siemens AG
Digital Industries
Process Automation
Software House Nbg
DI PA DCP R 3
Gleiwitzer Str. 555
90475 Nuremberg, Germany
mailto:erez.geva@siemens.com
[cid:image002.jpg@01D75BB6.5ED14EF0]
www.aurelly.com
CEO: Jens Stötzner, company's place of business: Nürnberg,
VAT identification: DE 255071685, Commercial register No.: HRB: 15550
[cid:image004.png@01D75BB6.5ED14EF0] Please consider the environment before 
printing this email
Important notice: This e-mail and any attachment thereof contain corporate 
proprietary information. If you have received it by mistake, please notify us 
immediately by reply e-mail and delete this e-mail and its attachments from 
your system. Thank you.

___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel