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

Re: [Linuxptp-users] Compile issue in RHEL v6.3

[Ledda W. E. <Wil...@it...>]

PTP support starts from kernel 3.10x. Red Hat has backported this support into kernel 2.6x starting from 6.4 so I don't think that a workaround exists for 6.4.I had the same problem.
Even if you can compile you will probably have problems with the network driver.

Regards

William

From: Yoo, Choong Keun [mailto:cho...@hp...]
Sent: 26 February 2015 09:46
To: lin...@li...
Subject: [Linuxptp-users] Compile issue in RHEL v6.3

Dear,

I have a customer who use HP DL380Gen8 server with RHEL v6.3 OS.
They want to implement PTP with HP NC560 (Intel(r) 82599 Controller) NIC.

They encountered problem when they try to compile linuxptp.

grep: /usr/include/linux/net_tstamp.h: No such file or directory
ptp4l.c:25:30: error: linux/net_tstamp.h: No such file or directory

There is no net_tstamp.h in kernel-header package of RHEL 6.3 kernel 2.6.32-279.el6.
RHEL v6.4 has net_tstamp.h.

Is there any way to compile linuxptp on RHEL v6.3 ?
If not, what is technical issue in RHEL v6.3.

According to linuxptp.sourceforge.net we need set below kernel config  option but  it seems like only CONFIG_PPS is available as module. In RHEL v6.3
Is there any workaround?

Option

Description

CONFIG_PPS

Required

CONFIG_NETWORK_PHY_TIMESTAMPING

Timestamping in PHY devices

PTP_1588_CLOCK

PTP clock support


Regards,

Yoo, Choong Keun

[Linuxptp-users] Compile issue in RHEL v6.3

[Yoo, C. K. <cho...@hp...>]

Dear,

I have a customer who use HP DL380Gen8 server with RHEL v6.3 OS.
They want to implement PTP with HP NC560 (Intel(r) 82599 Controller) NIC.

They encountered problem when they try to compile linuxptp.

grep: /usr/include/linux/net_tstamp.h: No such file or directory
ptp4l.c:25:30: error: linux/net_tstamp.h: No such file or directory

There is no net_tstamp.h in kernel-header package of RHEL 6.3 kernel 2.6.32-279.el6.
RHEL v6.4 has net_tstamp.h.

Is there any way to compile linuxptp on RHEL v6.3 ?
If not, what is technical issue in RHEL v6.3.

According to linuxptp.sourceforge.net we need set below kernel config  option but  it seems like only CONFIG_PPS is available as module. In RHEL v6.3
Is there any workaround?

Option

Description

CONFIG_PPS

Required

CONFIG_NETWORK_PHY_TIMESTAMPING

Timestamping in PHY devices

PTP_1588_CLOCK

PTP clock support


Regards,

Yoo, Choong Keun

Re: [Linuxptp-users] Red Hat's Users Guide for linuxptp

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

On Thu, Jan 09, 2014 at 03:52:05PM -0200, Flavio Leitner wrote:
> And if you find any errors or have suggestions, feel free to speak up.
> I can forward it to the people responsible for the docs.

I just stumbled across an omission. In the section

   21.8. Serving NTP Time With PTP

there is configuration example for ptp4l where phc2sys will be
adjusting the PTP clock (eth3 in the example).

In such a case, you also want to have the option "free_running 1",
just in case ptp4l should lose the best master clock algorithm.
Otherwise, ptp4l and phc2sys will both adjust the eth3 clock at the
same time.

Thanks,
Richard

Re: [Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

[Axel H. <aho...@gm...>]

On Thu, Feb 19, 2015 at 08:29PM, Richard Cochran wrote:

> On Thu, Feb 19, 2015 at 08:03:51PM +0100, Axel Holzinger wrote:
> >
> > Well, it was a combination of all three tips. Finally I found out that
> > gPTP.cfg sets path_trace_enabled to 1 while switch B doesn't send a path
> > trace TLV. That was the reason for ptp4l to drop the announce message.
> 
> Switch B is non-compliant with 802.1-AS-2011.  The path trace TLV is
> required by clause 10.5.3.2.8 on page 91 and by F.3 g) on page 272.

Thank you Richard. I informed the manufacturer. I'll report back.

Regards
Axel

Re: [Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

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

On Thu, Feb 19, 2015 at 08:03:51PM +0100, Axel Holzinger wrote:
> 
> Well, it was a combination of all three tips. Finally I found out that
> gPTP.cfg sets path_trace_enabled to 1 while switch B doesn't send a path
> trace TLV. That was the reason for ptp4l to drop the announce message.

Switch B is non-compliant with 802.1-AS-2011.  The path trace TLV is
required by clause 10.5.3.2.8 on page 91 and by F.3 g) on page 272.

Thanks,
Richard

Re: [Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

[Axel H. <aho...@gm...>]

On Thu, Feb 19, 2015 at 04:05PM +0100, Richard Cochran wrote:
> On Thu, Feb 19, 2015 at 02:00:16PM +0100, Axel Holzinger wrote:
> > Hi all,
> >
> > I have two gPTP aware switches here and a PC with i210 and with switch A
> > ptp4l is syncing fine, while with switch B not. Could anybody point me
in a
> > direction how I can find out what ptp4l doesn't like regarding switch B.
It
> > always selects itself as best master continously (i210 MAC is
> > a0-36-9f-47-60-48). Prios are the same for switch A and B.
> 
> Increase the message level to take a look at the asCapable port
> variable.  There are quite a number of conditions.
> 
> Some other ideas:
> 
> Use wireshark to find out what, if any, messages are being exchanged.
> 
> In port.c, there are quite a few places where silently we drop invalid
> messages.  You can hack in a few debugging statements to find out what
> is going on, especially WRT asCapable.

Well, it was a combination of all three tips. Finally I found out that
gPTP.cfg sets path_trace_enabled to 1 while switch B doesn't send a path
trace TLV. That was the reason for ptp4l to drop the announce message.

Thanks a lot!
Axel

Re: [Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

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

On Thu, Feb 19, 2015 at 02:00:16PM +0100, Axel Holzinger wrote:
> Hi all,
> 
> I have two gPTP aware switches here and a PC with i210 and with switch A
> ptp4l is syncing fine, while with switch B not. Could anybody point me in a
> direction how I can find out what ptp4l doesn't like regarding switch B. It
> always selects itself as best master continously (i210 MAC is
> a0-36-9f-47-60-48). Prios are the same for switch A and B.

Increase the message level to take a look at the asCapable port
variable.  There are quite a number of conditions.

Some other ideas:

Use wireshark to find out what, if any, messages are being exchanged.

In port.c, there are quite a few places where silently we drop invalid
messages.  You can hack in a few debugging statements to find out what
is going on, especially WRT asCapable.

Good luck,
Richard

[Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

[Axel H. <aho...@gm...>]

Hi all,

I have two gPTP aware switches here and a PC with i210 and with switch A
ptp4l is syncing fine, while with switch B not. Could anybody point me in a
direction how I can find out what ptp4l doesn't like regarding switch B. It
always selects itself as best master continously (i210 MAC is
a0-36-9f-47-60-48). Prios are the same for switch A and B.

Here's the output (first part switch A, second switch B):
ptp@T20-1-Linux:~/Projects/linuxptp-1.5$ sudo ./ptp4l -f gPTP.cfg -i eth0 -s
-m -q
ptp4l[1342.478]: selected /dev/ptp0 as PTP clock
ptp4l[1342.504]: driver changed our HWTSTAMP options
ptp4l[1342.504]: tx_type   1 not 1
ptp4l[1342.504]: rx_filter 1 not 12
ptp4l[1342.504]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1342.504]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1345.544]: port 1: new foreign master 200cc8.fffe.3e281a-15
ptp4l[1347.544]: selected best master clock 200cc8.fffe.3e281a
ptp4l[1347.544]: running in a temporal vortex
ptp4l[1347.544]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1348.785]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[1349.105]: rms 19429 max 31010 freq -52740 +/- 4284 delay   576 +/-
0
ptp4l[1349.745]: rms 1638 max 3060 freq -53035 +/- 1223 delay   577 +/-   0
ptp4l[1350.385]: rms 1517 max 1937 freq -49043 +/- 985
ptp4l[1351.025]: rms 1907 max 1995 freq -46535 +/- 455 delay   578 +/-   0
ptp4l[1351.665]: rms 1269 max 1617 freq -45749 +/-  49 delay   579 +/-   0
ptp4l[1352.305]: rms  465 max  751 freq -46029 +/- 158
ptp4l[1352.945]: rms  146 max  237 freq -46624 +/- 165 delay   578 +/-   0
ptp4l[1353.585]: rms  276 max  287 freq -47079 +/-  97 delay   578 +/-   0
ptp4l[1354.225]: rms  225 max  267 freq -47280 +/-  24
ptp4l[1354.865]: rms  105 max  152 freq -47279 +/-  18 delay   576 +/-   0

ptp@T20-1-Linux:~/Projects/linuxptp-1.5$ sudo ./ptp4l -f gPTP.cfg -i eth0 -s
-m -q
ptp4l[1390.190]: selected /dev/ptp0 as PTP clock
ptp4l[1390.212]: driver changed our HWTSTAMP options
ptp4l[1390.212]: tx_type   1 not 1
ptp4l[1390.212]: rx_filter 1 not 12
ptp4l[1390.212]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1390.212]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1397.925]: selected best master clock a0369f.fffe.476048
ptp4l[1403.991]: selected best master clock a0369f.fffe.476048
ptp4l[1411.821]: selected best master clock a0369f.fffe.476048
ptp4l[1419.027]: selected best master clock a0369f.fffe.476048
ptp4l[1425.377]: selected best master clock a0369f.fffe.476048
ptp4l[1433.077]: selected best master clock a0369f.fffe.476048
ptp4l[1440.106]: selected best master clock a0369f.fffe.476048
ptp4l[1447.154]: selected best master clock a0369f.fffe.476048
ptp4l[1454.366]: selected best master clock a0369f.fffe.476048

Thank you
Axel

Re: [Linuxptp-users] Linear regression or pi?

[Ledda W. E. <Wil...@it...>]

Thank you Miroslav, 
Very useful explanation


William LEDDA
-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...] 
Sent: 18 February 2015 18:17
To: Ledda William EXT
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Linear regression or pi?

On Tue, Feb 17, 2015 at 12:43:50PM +0000, Ledda William EXT wrote:
> Dear linuxptp-users,
> I installed today linuxptp 1.5 to make some tests. I found that it is possible to use two different servos with phc2sys. I was using a version based on 1.3 and I found that the pi works fine for me. So which is the best? Or better... when one is preferable to the other? Which are the pros and cons?

The main advantage of linreg over pi is that it doesn't require any configuration for good performance, it works well in a wide range of conditions. The disadvantage is that it's much more heavy on math.
Unless it's running on an extremely slow cpu with software floating point, I'd not expect this to be a problem.

My recommendation is: if you care about accuracy and you can find good PI constants for your conditions, use pi. Otherwise use linreg.

--
Miroslav Lichvar

Re: [Linuxptp-users] Linear regression or pi?

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

On Tue, Feb 17, 2015 at 12:43:50PM +0000, Ledda William EXT wrote:
> Dear linuxptp-users,
> I installed today linuxptp 1.5 to make some tests. I found that it is possible to use two different servos with phc2sys. I was using a version based on 1.3 and I found that the pi works fine for me. So which is the best? Or better... when one is preferable to the other? Which are the pros and cons?

The main advantage of linreg over pi is that it doesn't require any
configuration for good performance, it works well in a wide range of
conditions. The disadvantage is that it's much more heavy on math.
Unless it's running on an extremely slow cpu with software floating
point, I'd not expect this to be a problem.

My recommendation is: if you care about accuracy and you can find good
PI constants for your conditions, use pi. Otherwise use linreg.

-- 
Miroslav Lichvar

[Linuxptp-users] Linear regression or pi?

[Ledda W. E. <Wil...@it...>]

Dear linuxptp-users,
I installed today linuxptp 1.5 to make some tests. I found that it is possible to use two different servos with phc2sys. I was using a version based on 1.3 and I found that the pi works fine for me. So which is the best? Or better... when one is preferable to the other? Which are the pros and cons?

Thank you

William

Re: [Linuxptp-users] neither machine acknowledges the other

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

On Wed, 2015-02-11 at 21:55 +0000, Bryan Yeung wrote:
> Keller, Jacob E <jacob.e.keller@...> writes:
> > 
> > Hi,
> > 
> > 
> > Try ensuring any firewall (iptables, firewalld, etc) has allowed
> > multicast traffic. That's usually the symptom I see when the packets
> > arrive in tcpdump but not the application.
> 
> *face palm*
> 
> I probably should have thought of that.  Sure enough, fixing up iptables 
> does the trick.
> 
> Thanks for the pointer!
> 
> Bryan

I've done the exact same thing a million times. Glad I could help.

Regards,
Jake

Re: [Linuxptp-users] neither machine acknowledges the other

[Bryan Y. <br...@gm...>]

Keller, Jacob E <jacob.e.keller@...> writes:
> 
> Hi,
> 
> 
> Try ensuring any firewall (iptables, firewalld, etc) has allowed
> multicast traffic. That's usually the symptom I see when the packets
> arrive in tcpdump but not the application.

*face palm*

I probably should have thought of that.  Sure enough, fixing up iptables 
does the trick.

Thanks for the pointer!

Bryan

Re: [Linuxptp-users] neither machine acknowledges the other

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

Hi,

On Wed, 2015-02-11 at 19:34 +0000, Bryan Yeung wrote:
> Hello,
> 
> I'm trying to setup PTP with software timestamping between two machines on 
> my local network.
> 
> When running ptp4l, both machines end up assuming the grand master role 
> (i.e. I see this on both machines):
> ptp4l[1747.050]: PI servo: sync interval 1.000 kp 0.100 ki 0.001000
> ptp4l[1747.051]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available
> ptp4l[1747.051]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[1747.051]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[1754.276]: port 1: announce timeout
> ptp4l[1754.276]: port 1: LISTENING to MASTER on 
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[1754.276]: selected best master clock 089e01.fffe.e6e911
> ptp4l[1754.276]: assuming the grand master role
> ptp4l[1754.277]: port 1: master tx announce timeout
> ptp4l[1754.277]: port 1: setting asCapable
> ptp4l[1755.277]: port 1: master sync timeout
> ptp4l[1756.277]: port 1: master sync timeout
> ptp4l[1756.278]: port 1: master tx announce timeout
> ptp4l[1757.277]: port 1: master sync timeout
> ptp4l[1758.277]: port 1: master sync timeout
> ptp4l[1758.278]: port 1: master tx announce timeout
> ...
> 
> 
> If I run tcpdump on either machine, I can see the messages from both 
> machines to the multicast address:
> 11:12:04.114210 IP 172.23.188.135.320 > ptp-primary.mcast.net.320: UDP, 
> length 64
> 11:12:04.235244 IP 172.23.188.213.319 > ptp-primary.mcast.net.319: UDP, 
> length 44
> 11:12:04.235294 IP 172.23.188.213.320 > ptp-primary.mcast.net.320: UDP, 
> length 44
> 11:12:04.450571 IP 172.23.188.213.319 > ptp-primary.mcast.net.319: UDP, 
> length 44
> 11:12:04.450620 IP 172.23.188.213.320 > ptp-primary.mcast.net.320: UDP, 
> length 44
> 11:12:04.451046 IP 172.23.188.213.320 > ptp-primary.mcast.net.320: UDP, 
> length 64
> 11:12:05.113616 IP 172.23.188.135.319 > ptp-primary.mcast.net.319: UDP, 
> length 44
> 11:12:05.113677 IP 172.23.188.135.320 > ptp-primary.mcast.net.320: UDP, 
> length 44
> 11:12:05.234128 IP 172.23.188.213.320 > ptp-primary.mcast.net.320: UDP, 
> length 64
> 
> 
> Any debugging tips or suggestions would be greatly appreciated.
> 
> 
> Thanks!
> 
> Bryan
> 
> 

Try ensuring any firewall (iptables, firewalld, etc) has allowed
multicast traffic. That's usually the symptom I see when the packets
arrive in tcpdump but not the application.

Regards,
Jake

[Linuxptp-users] neither machine acknowledges the other

[Bryan Y. <br...@gm...>]

Hello,

I'm trying to setup PTP with software timestamping between two machines on 
my local network.

When running ptp4l, both machines end up assuming the grand master role 
(i.e. I see this on both machines):
ptp4l[1747.050]: PI servo: sync interval 1.000 kp 0.100 ki 0.001000
ptp4l[1747.051]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[1747.051]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1747.051]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1754.276]: port 1: announce timeout
ptp4l[1754.276]: port 1: LISTENING to MASTER on 
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1754.276]: selected best master clock 089e01.fffe.e6e911
ptp4l[1754.276]: assuming the grand master role
ptp4l[1754.277]: port 1: master tx announce timeout
ptp4l[1754.277]: port 1: setting asCapable
ptp4l[1755.277]: port 1: master sync timeout
ptp4l[1756.277]: port 1: master sync timeout
ptp4l[1756.278]: port 1: master tx announce timeout
ptp4l[1757.277]: port 1: master sync timeout
ptp4l[1758.277]: port 1: master sync timeout
ptp4l[1758.278]: port 1: master tx announce timeout
...


If I run tcpdump on either machine, I can see the messages from both 
machines to the multicast address:
11:12:04.114210 IP 172.23.188.135.320 > ptp-primary.mcast.net.320: UDP, 
length 64
11:12:04.235244 IP 172.23.188.213.319 > ptp-primary.mcast.net.319: UDP, 
length 44
11:12:04.235294 IP 172.23.188.213.320 > ptp-primary.mcast.net.320: UDP, 
length 44
11:12:04.450571 IP 172.23.188.213.319 > ptp-primary.mcast.net.319: UDP, 
length 44
11:12:04.450620 IP 172.23.188.213.320 > ptp-primary.mcast.net.320: UDP, 
length 44
11:12:04.451046 IP 172.23.188.213.320 > ptp-primary.mcast.net.320: UDP, 
length 64
11:12:05.113616 IP 172.23.188.135.319 > ptp-primary.mcast.net.319: UDP, 
length 44
11:12:05.113677 IP 172.23.188.135.320 > ptp-primary.mcast.net.320: UDP, 
length 44
11:12:05.234128 IP 172.23.188.213.320 > ptp-primary.mcast.net.320: UDP, 
length 64


Any debugging tips or suggestions would be greatly appreciated.


Thanks!

Bryan

Re: [Linuxptp-users] Anyone using Intel i350v2-T2 on RedHat Linux?

[Ledda W. E. <Wil...@it...>]

Hello Rich
I’m using a i350-AM2 (integrated in the motherboard) with RH 6.5 with both kernels 2.6.32-431.20.3.el6.x86_64 and 3.10.33-rt32.52.el6rt.x86_64. I can run ptp4l version 1.3 without issues. I have also tested it on RH 6.4 and I have always used the driver provided by RH. Why have you installed a different driver? Remember that while the PTP support was introduced starting from kernel 3.10, RH has backported  it into kernel 2.6x so it is highly customized. It is possible that the “community driver” is not fully compatible with RH.

$ uname -r
2.6.32-431.20.3.el6.x86_64

$ ethtool -i eth2
driver: igb
version: 5.0.5-k
firmware-version: 1.61, 0x8000090f
bus-info: 0000:24:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

$ 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: 2
Hardware Transmit Timestamp Modes:
                off                   (HWTSTAMP_TX_OFF)
                on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
                none                  (HWTSTAMP_FILTER_NONE)
                all                   (HWTSTAMP_FILTER_ALL)


From: Rich Schmidt [mailto:sch...@gm...]
Sent: 28 January 2015 00:42
To: linuxptp-users
Subject: [Linuxptp-users] Anyone using Intel i350v2-T2 on RedHat Linux?

I have tested the Intel 82547L and the i210 NICs with linuxptp 1.4 and 1.5.
They work fine on our Red Hat Linux kernel make -C /lib/modules/2.6.32-504.3.3.el6.x86_64.
But I cannot get the i350T2V2BLK  to work.
It sees the correct PTP Grandmaster 0019dd.fffe.00085c, but all I get this, even increasing tx_timestamp_timeout to 1000:

ptp4l -i eth2 -f /etc/ptp4l.conf -m -l 7

ptp4l[181.099]: eth2: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[181.099]: port 1: UNCALIBRATED to LISTENING on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[183.076]: port 1: setting asCapable
ptp4l[183.078]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[187.079]: selected best master clock 0019dd.fffe.00085c
ptp4l[187.079]: foreign master not using PTP timescale
ptp4l[187.079]: running in a temporal vortex
ptp4l[187.079]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[194.076]: port 1: delay timeout
ptp4l[194.176]: timed out while polling for tx timestamp
ptp4l[194.176]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[194.176]: port 1: send delay request failed
...
I have installed the latest igb driver 5.1.15.

ethtool -i eth2
driver: igb
version: 5.2.15
firmware-version: 1.63, 0x80000cbb
bus-info: 0000:10:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
[root@ptp2 ~]# 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)
            all                   (HWTSTAMP_FILTER_ALL)

I have installed an i210, which uses the same driver, and it works nicely:

ptp4l -i eth4 -f /etc/ptp4l.conf -m -l 7

option pi_offset_const is deprecated, please use step_threshold instead
option pi_f_offset_const is deprecated, please use first_step_threshold instead
option pi_max_frequency is deprecated, please use max_frequency instead
ptp4l[1301.376]: selected /dev/ptp0 as PTP clock
ptp4l[1301.376]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[1301.377]: eth4: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[1301.377]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1301.377]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1301.827]: port 1: setting asCapable
ptp4l[1301.829]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[1305.829]: selected best master clock 0019dd.fffe.00085c
ptp4l[1305.829]: foreign master not using PTP timescale
ptp4l[1305.829]: running in a temporal vortex
ptp4l[1305.829]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1307.828]: PI servo: sync interval 2.000 kp 0.350 ki 0.150000
ptp4l[1309.441]: port 1: delay timeout
ptp4l[1309.494]: path delay         14356      14356
ptp4l[1309.829]: master offset  -16816366 s0 freq  -16632 path delay     14356
.
.
.
ptp4l[1341.934]: port 1: delay timeout
ptp4l[1342.034]: path delay           947        947
ptp4l[1342.992]: port 1: delay timeout
ptp4l[1343.092]: path delay           957        968
ptp4l[1343.272]: port 1: delay timeout
ptp4l[1343.372]: path delay           957        979
ptp4l[1343.830]: master offset       -264 s2 freq  -16676 path delay       957
ptp4l[1345.830]: master offset       -315 s2 freq  -16741 path delay       957
ptp4l[1347.830]: master offset       -216 s2 freq  -16739 path delay       957
ptp4l[1349.830]: master offset       -116 s2 freq  -16721 path delay       957
ptp4l[1351.217]: port 1: delay timeout
ptp4l[1351.318]: path delay           928        910
ptp4l[1351.830]: master offset         12 s2 freq  -16675 path delay       928
ptp4l[1353.830]: master offset        -79 s2 freq  -16718 path delay       928
ptp4l[1355.830]: master offset         61 s2 freq  -16660 path delay       928
ptp4l[1355.865]: port 1: delay timeout
ptp4l[1355.965]: path delay           928        956
ptp4l[1357.713]: port 1: delay timeout
ptp4l[1357.813]: path delay           928       1015
ptp4l[1357.830]: master offset        -70 s2 freq  -16716 path delay       928

If anyone has had success, please reply.
With thanks, Rich Schmidt

[Linuxptp-users] Anyone using Intel i350v2-T2 on RedHat Linux?

[Rich S. <sch...@gm...>]

I have tested the Intel 82547L and the i210 NICs with linuxptp 1.4 and 1.5.

They work fine on our Red Hat Linux kernel make -C
/lib/modules/2.6.32-504.3.3.el6.x86_64.
But I cannot get the i350T2V2BLK  to work.
It sees the correct PTP Grandmaster 0019dd.fffe.00085c, but all I get this,
even increasing tx_timestamp_timeout to 1000:

ptp4l -i eth2 -f /etc/ptp4l.conf -m -l 7

ptp4l[181.099]: eth2: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[181.099]: port 1: UNCALIBRATED to LISTENING on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[183.076]: port 1: setting asCapable
ptp4l[183.078]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[187.079]: selected best master clock 0019dd.fffe.00085c
ptp4l[187.079]: foreign master not using PTP timescale
ptp4l[187.079]: running in a temporal vortex
ptp4l[187.079]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[194.076]: port 1: delay timeout
ptp4l[194.176]: timed out while polling for tx timestamp
ptp4l[194.176]: increasing tx_timestamp_timeout may correct this issue, but
it is likely caused by a driver bug
ptp4l[194.176]: port 1: send delay request failed
...
I have installed the latest igb driver 5.1.15.

ethtool -i eth2
driver: igb
version: 5.2.15
firmware-version: 1.63, 0x80000cbb
bus-info: 0000:10:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
[root@ptp2 ~]# 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)
all                   (HWTSTAMP_FILTER_ALL)

I have installed an i210, which uses the same driver, and it works nicely:

ptp4l -i eth4 -f /etc/ptp4l.conf -m -l 7

option pi_offset_const is deprecated, please use step_threshold instead
option pi_f_offset_const is deprecated, please use first_step_threshold
instead
option pi_max_frequency is deprecated, please use max_frequency instead
ptp4l[1301.376]: selected /dev/ptp0 as PTP clock
ptp4l[1301.376]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[1301.377]: eth4: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[1301.377]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1301.377]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1301.827]: port 1: setting asCapable
ptp4l[1301.829]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[1305.829]: selected best master clock 0019dd.fffe.00085c
ptp4l[1305.829]: foreign master not using PTP timescale
ptp4l[1305.829]: running in a temporal vortex
ptp4l[1305.829]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1307.828]: PI servo: sync interval 2.000 kp 0.350 ki 0.150000
ptp4l[1309.441]: port 1: delay timeout
ptp4l[1309.494]: path delay         14356      14356
ptp4l[1309.829]: master offset  -16816366 s0 freq  -16632 path delay
14356
.
.
.
ptp4l[1341.934]: port 1: delay timeout
ptp4l[1342.034]: path delay           947        947
ptp4l[1342.992]: port 1: delay timeout
ptp4l[1343.092]: path delay           957        968
ptp4l[1343.272]: port 1: delay timeout
ptp4l[1343.372]: path delay           957        979
ptp4l[1343.830]: master offset       -264 s2 freq  -16676 path delay
957
ptp4l[1345.830]: master offset       -315 s2 freq  -16741 path delay
957
ptp4l[1347.830]: master offset       -216 s2 freq  -16739 path delay
957
ptp4l[1349.830]: master offset       -116 s2 freq  -16721 path delay
957
ptp4l[1351.217]: port 1: delay timeout
ptp4l[1351.318]: path delay           928        910
ptp4l[1351.830]: master offset         12 s2 freq  -16675 path delay
928
ptp4l[1353.830]: master offset        -79 s2 freq  -16718 path delay
928
ptp4l[1355.830]: master offset         61 s2 freq  -16660 path delay
928
ptp4l[1355.865]: port 1: delay timeout
ptp4l[1355.965]: path delay           928        956
ptp4l[1357.713]: port 1: delay timeout
ptp4l[1357.813]: path delay           928       1015
ptp4l[1357.830]: master offset        -70 s2 freq  -16716 path delay
928

If anyone has had success, please reply.
With thanks, Rich Schmidt

[Linuxptp-users] Results I dont understand with linuxptp

[Kiran <kir...@gm...>]

Hello,

I ran linux ptp between two freescale imx6 cards. The two test setups are:

Card1 -> Switch -> Card2

Card1 -> PTP Switch (Moxa PT7728) -> Card2

Surprisingly in the first case i get an offset of +/-50ns while in the
second case it goes to +/-100. 

The PTP switch is configured to 2-step P2P

Regards,
Kiran 

Re: [Linuxptp-users] tx poll timeout

[Ledda W. E. <Wil...@it...>]

Thank you Richard, 
I'll investigate further in this sense tuning the parameters.

William


William LEDDA
External Contractor
CODAC Section

ITER Organization, Building 72/4115, CHD, Control System Division
Route de Vinon-sur-Verdon - CS 90 046 - 13067 St Paul Lez Durance Cedex - France
Phone: +33 4 42 17 85 94
Get the latest ITER news on http://www.iter.org/whatsnew
-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: 21 January 2015 11:31
To: Ledda William EXT
Cc: lin...@li...
Subject: Re: [Linuxptp-users] tx poll timeout

On Wed, Jan 21, 2015 at 09:06:39AM +0000, Ledda William EXT wrote:
> Hello,
> Sometimes I see a "tx poll timeout" sending a delay requests. After about 20 seconds and then the synchronization restarts. What could be the root cause? It could be a problem of the driver or a problem of the network? What else?

This can be caused by:

1. link down
2. driver/stack latency delivering the time stamp 3. driver/hw dropping the time stamp

Cases 1 and 3 will always trigger the fault. If this happens too often, you can reduce the fault duration with the configuration option called "fault_reset_interval".

Case 2 can be mitigated by increasing the "tx_timestamp_timeout"
option. The default is 1 millisecond, and so you could try 2 milliseconds.

HTH
Richard

Re: [Linuxptp-users] tx poll timeout

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

On Wed, Jan 21, 2015 at 09:06:39AM +0000, Ledda William EXT wrote:
> Hello,
> Sometimes I see a "tx poll timeout" sending a delay requests. After about 20 seconds and then the synchronization restarts. What could be the root cause? It could be a problem of the driver or a problem of the network? What else?

This can be caused by:

1. link down
2. driver/stack latency delivering the time stamp
3. driver/hw dropping the time stamp

Cases 1 and 3 will always trigger the fault. If this happens too
often, you can reduce the fault duration with the configuration option
called "fault_reset_interval".

Case 2 can be mitigated by increasing the "tx_timestamp_timeout"
option. The default is 1 millisecond, and so you could try 2
milliseconds.

HTH
Richard

[Linuxptp-users] tx poll timeout

[Ledda W. E. <Wil...@it...>]

Hello,
Sometimes I see a "tx poll timeout" sending a delay requests. After about 20 seconds and then the synchronization restarts. What could be the root cause? It could be a problem of the driver or a problem of the network? What else?
...
...: master offset          5 s2 freq  +34434 path delay       278
...: poll tx timestamp timeout
...: port 1: send delay request failed
...: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
...: driver changed our HWTSTAMP options
...: tx_type   1 not 1
...: rx_filter 1 not 12
...: port 1: FAULTY to LISTENING on FAULT_CLEARED
...: port 1: new foreign master 008063.fffe.db5e00-4
...: selected best master clock 00a069.fffe.01c094
...: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
...: port 1: minimum delay request interval 2^3
...: master offset       -250 s2 freq  +34188 path delay       289
...: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
...: master offset         12 s2 freq  +34370 path delay       289
...: master offset         27 s2 freq  +34388 path delay       289
...

I'm using ptp4l version 1.3 with an Intel i350 ethernet interface with Red Hat RHEL 6.5.

$ uname -a
Linux xxxx 2.6.32-431.20.3.el6.x86_64 #1 SMP Fri Jun 6 18:30:54 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

$ ethtool -i eth1
driver: igb
version: 5.0.5-k
firmware-version: 1.61, 0x8000090f
bus-info: 0000:24:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

Thank you

William

Re: [Linuxptp-users] SOF_TIMESTAMPING_TX_SOFTWARE missing

[Tino K. <tin...@al...>]

Hi Sebastien,

do you use ptp4l inside the VM (on the guest), or on the host system?

Regards,
Tino

Re: [Linuxptp-users] SOF_TIMESTAMPING_TX_SOFTWARE missing

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

This is because the network driver does not correctly implement software
timestamping.

Regards,
Jake

On Sun, 2015-01-11 at 22:45 +0000, Sebastien wrote:
> Hello,
> 
> 
> 
> 
> 
> 
> 
> I've got a new HP server, with Esxi E1000, with a NIC Broadcom NetXtreme 
> 
> BCM 57810, and VM hosting RHEL6.5
> 
> 
> 
> 
> 
> 
> 
> I would like it to use the Soft option to synchronize from PTP source, 
> 
> connected on Eth1.
> 
> 
> 
> I've installed linuxptp, and updated the NIC driver for the RHEL 6.5
> 
> 
> 
> 
> 
> 
> 
> Unfortunately, the software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
> 
> 
> 
> is not reported after the command ethtool -T eth1
> 
> 
> 
> And , using ptp4l -i eth1 -m -S shows ;
> 
> 
> 
> 
> 
> 
> 
> [root]# ptp4l -i eth1 -m -S
> 
> 
> 
> interface 'eth1' does not support requested timestamping mode.
> 
> 
> 
> [root]#  ethtool -T eth1
> 
> 
> 
> Time stamping parameters for eth1:
> 
> 
> 
> Capabilities:
> 
> 
> 
>         software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
> 
> 
> 
>         software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
> 
> 
> 
> PTP Hardware Clock: none
> 
> 
> 
> Hardware Transmit Timestamp Modes: none
> 
> 
> 
> Hardware Receive Filter Modes: none
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Is it because of a NIC card compatibility or an ESXI compatibility?
> 
> 
> 
> Is there some description, recommendation of Linux and Hardware version to 
> 
> support linuxptp?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thanks for your help
> 
> 
> 
> 
> 
> 
> 
> Regards
> 
> 
> 
> Sebastien
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

[Linuxptp-users] SOF_TIMESTAMPING_TX_SOFTWARE missing

[Sebastien <seb...@jd...>]

Hello,







I've got a new HP server, with Esxi E1000, with a NIC Broadcom NetXtreme 

BCM 57810, and VM hosting RHEL6.5







I would like it to use the Soft option to synchronize from PTP source, 

connected on Eth1.



I've installed linuxptp, and updated the NIC driver for the RHEL 6.5







Unfortunately, the software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)



is not reported after the command ethtool -T eth1



And , using ptp4l -i eth1 -m -S shows ;







[root]# ptp4l -i eth1 -m -S



interface 'eth1' does not support requested timestamping mode.



[root]#  ethtool -T eth1



Time stamping parameters for eth1:



Capabilities:



        software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)



        software-system-clock (SOF_TIMESTAMPING_SOFTWARE)



PTP Hardware Clock: none



Hardware Transmit Timestamp Modes: none



Hardware Receive Filter Modes: none











Is it because of a NIC card compatibility or an ESXI compatibility?



Is there some description, recommendation of Linux and Hardware version to 

support linuxptp?















Thanks for your help







Regards



Sebastien

Re: [Linuxptp-users] Hardware and software timestamping

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

On Fri, Jan 09, 2015 at 11:50:48AM +0000, Kiran wrote:
> Hi Richard,
> 
> I am trying to run PTP and I would like to know if it is possible to run a
> master with hardware timestamping and a slave with software timestamping or
> the other way around.

Yes, there is no problem to mix different hosts.

HTH
Richard