Thread: [Linuxptp-users] Problems with ptp4l via a Cisco Nexus 5000 Switch
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: Christian <chr...@fr...> - 2016-06-23 12:10:35
|
Hello,
I'm currently trying to set up a ptp4l session between 3 servers, which are connected via a Cisco Nexus 5000 switch
Server A is supposed to be the grand master, Server B and C should be the slaves.
The Grandmaster is working fine, the Switch does accept it, but the Slaves are not working properly.
Here is the ptp log of one of the slave servers:
@s0002794:~$ ptp4l[618557.966]: selected /dev/ptp0 as PTP clock
ptp4l[618557.967]: driver changed our HWTSTAMP options
ptp4l[618557.967]: tx_type 1 not 1
ptp4l[618557.967]: rx_filter 1 not 12
ptp4l[618557.967]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[618557.967]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[618564.664]: driver changed our HWTSTAMP options
ptp4l[618564.664]: tx_type 1 not 1
ptp4l[618564.664]: rx_filter 1 not 12
ptp4l[618564.664]: selected best master clock a0369f.fffe.a1b68c <-- MAC Addr. of the Slave server
ptp4l[618564.840]: port 1: new foreign master 002a6a.fffe.ac97fc-16 <-- MAC Addr. of the Switch port
ptp4l[618571.137]: driver changed our HWTSTAMP options
ptp4l[618571.137]: tx_type 1 not 1
ptp4l[618571.137]: rx_filter 1 not 12
ptp4l[618571.137]: selected best master clock a0369f.fffe.a1b68c
ptp4l[618578.192]: driver changed our HWTSTAMP options
ptp4l[618578.192]: tx_type 1 not 1
ptp4l[618578.192]: rx_filter 1 not 12
ptp4l[618578.192]: selected best master clock a0369f.fffe.a1b68c
ptp4l[618580.850]: selected best master clock a0369f.fffe.a1b688 <-- MAC Addr. of the Master server
ptp4l[618580.850]: foreign master not using PTP timescale
ptp4l[618580.850]: running in a temporal vortex
ptp4l[618580.850]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[618582.669]: port 1: minimum delay request interval 2^4
ptp4l[618582.851]: master offset 1299422 s0 freq +4989 path delay -11798
ptp4l[618584.852]: master offset 1321175 s1 freq +15865 path delay -9425
ptp4l[618587.572]: driver changed our HWTSTAMP options
ptp4l[618587.572]: tx_type 1 not 1
ptp4l[618587.572]: rx_filter 1 not 12
ptp4l[618587.572]: port 1: UNCALIBRATED to LISTENING on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[618587.572]: selected best master clock a0369f.fffe.a1b68c
ptp4l[618594.597]: driver changed our HWTSTAMP options
ptp4l[618594.597]: tx_type 1 not 1
ptp4l[618594.597]: rx_filter 1 not 12
ptp4l[618594.597]: selected best master clock a0369f.fffe.a1b68c
ptp4l[618596.851]: selected best master clock a0369f.fffe.a1b688
ptp4l[618596.851]: foreign master not using PTP timescale
ptp4l[618596.851]: running in a temporal vortex
ptp4l[618596.851]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[618598.850]: master offset 43778 s2 freq +37754 path delay 0
ptp4l[618598.850]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[618600.852]: master offset 6710 s2 freq +25787 path delay 0
there also was this line every one in a while:
ptp4l[5828.626]: port 1: minimum delay request interval 2^^4
I am starting the Master with a config File.
ptp4l -f /etc/ptp.config
with following config file:
[global]
verbose 1
path_trace_enabled 1
time_stamping hardware
priority1 1
priority2 1
[eth4]
The Slaves are started via: ptp4l -A -m -i eth4 -s
I also wrote a config file for them, but if I use the file, they do select themself as the best clock.
rupp@s0002794:~$ ptp4l[619043.020]: selected best master clock a0369f.fffe.a1b68c <--MAC Addr. of the Slave
ptp4l[619050.271]: selected best master clock a0369f.fffe.a1b68c
ptp4l[619056.348]: selected best master clock a0369f.fffe.a1b68c
ptp4l[619062.726]: selected best master clock a0369f.fffe.a1b68c
with following config File:
[global]
verbose 1
path_trace_enabled 1
time_stamping hardware
slaveOnly 1
priority1 255
priority2 255
[eth4]
Phc2sys is running on both, the Master and the Slaves.
Master: phc2sys -s CLOCK_REALTIME -c eth4 -w &
Slaves: phc2sys -s eth4 -w &
Here is the configuration of the Switch:
ptp brief:
PTP port status
-----------------------
Port State
------- --------------
Eth1/17 Master <--Server C
Eth1/19 Master <--Server B
Eth1/31 Slave <--Server A
ptp clock:
PTP Device Type: Boundary clock
Clock Identity : 00:2a:6a:ff:fe:ac:97:fc
Clock Domain: 0
Number of PTP ports: 3
Priority1 : 2
Priority2 : 2
Clock Quality:
Class : 248
Accuracy : 254
Offset (log variance) : 65535
Offset From Master : 467
Mean Path Delay : 33580
Steps removed : 1
Local clock time:Thu Jun 23 13:52:14 2016
Slave port:
PTP Port Dataset: Eth1/17
Port identity: clock identity: 00:2a:6a:ff:fe:ac:97:fc
Port identity: port number: 16
PTP version: 2
Port state: Master
VLAN info: 1
Delay request interval(log mean): 4
Announce receipt time out: 2
Peer mean path delay: 0
Announce interval(log mean): 3
Sync interval(log mean): 1
Delay Mechanism: End to End
Master port:
PTP Port Dataset: Eth1/31
Port identity: clock identity: 00:2a:6a:ff:fe:ac:97:fc
Port identity: port number: 30
PTP version: 2
Port state: Slave
VLAN info: 1
Delay request interval(log mean): 4
Announce receipt time out: 2
Peer mean path delay: 0
Announce interval(log mean): 3
Sync interval(log mean): 1
Delay Mechanism: End to End
Thank you in advance.
Greeting,
Christian
|
|
From: Richard C. <ric...@gm...> - 2016-06-23 13:24:40
|
On Thu, Jun 23, 2016 at 02:08:02PM +0200, Christian wrote: > there also was this line every one in a while: > > ptp4l[5828.626]: port 1: minimum delay request interval 2^^4 That is informational only, not an error. > I am starting the Master with a config File. > ptp4l -f /etc/ptp.config > > with following config file: > > [global] > verbose 1 > path_trace_enabled 1 ... > The Slaves are started via: ptp4l -A -m -i eth4 -s > with following config File: > > [global] > verbose 1 > path_trace_enabled 1 You have path_trace_enabled, but why? That is only for use in gPTP according to IEEE 802.1AS-2011. > Here is the configuration of the Switch: > PTP Device Type: Boundary clock Your switch is a BC. Maybe it cannot deal with the path trace option. Thanks, Richard |
|
From: Christian <chr...@fr...> - 2016-06-23 13:40:50
|
I took it out and it still has the same Problem. Am 23.06.2016 um 15:24 schrieb Richard Cochran: > You have path_trace_enabled, but why? That is only for use in gPTP > according to IEEE 802.1AS-2011. > >> >Here is the configuration of the Switch: >> >PTP Device Type: Boundary clock > Your switch is a BC. Maybe it cannot deal with the path trace > option. |
|
From: Christian <chr...@fr...> - 2016-06-30 12:16:59
|
Hello, As I have not made any progress in the matter, I have made a new log, so you can maybe see better where the Problem is. I have taken out the path trace enable option and upped the logging level to 7, else all the configuration is still the same. Here are pictures of the logs: Server s0002796 is the master s0002792 ands0002794 are the slaves. ptplog7start is the log it produced right after starting ptp4l.: https://s32.postimg.org/i6af9ejx1/ptplog7start.png ptplog7 is shortly thereafter: https://s32.postimg.org/bnsuv6rat/ptplog7.png ptplog7_2 is a bit later.: https://s32.postimg.org/jmtjfahhh/ptplog7_2.png After a while I checked the PHC clocks via phc_ctl and 94 seemed to be synchronising, while 92 was not. Thanks again for every little bit of help. Greetings, Christian Am 23.06.2016 um 14:08 schrieb Christian: > Hello, > > I'm currently trying to set up a ptp4l session between 3 servers, which are connected via a Cisco Nexus 5000 switch > > > Server A is supposed to be the grand master, Server B and C should be the slaves. > > > > The Grandmaster is working fine, the Switch does accept it, but the Slaves are not working properly. > > Here is the ptp log of one of the slave servers: > > @s0002794:~$ ptp4l[618557.966]: selected /dev/ptp0 as PTP clock > ptp4l[618557.967]: driver changed our HWTSTAMP options > ptp4l[618557.967]: tx_type 1 not 1 > ptp4l[618557.967]: rx_filter 1 not 12 > ptp4l[618557.967]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[618557.967]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[618564.664]: driver changed our HWTSTAMP options > ptp4l[618564.664]: tx_type 1 not 1 > ptp4l[618564.664]: rx_filter 1 not 12 > ptp4l[618564.664]: selected best master clock a0369f.fffe.a1b68c <-- MAC Addr. of the Slave server > ptp4l[618564.840]: port 1: new foreign master 002a6a.fffe.ac97fc-16 <-- MAC Addr. of the Switch port > ptp4l[618571.137]: driver changed our HWTSTAMP options > ptp4l[618571.137]: tx_type 1 not 1 > ptp4l[618571.137]: rx_filter 1 not 12 > ptp4l[618571.137]: selected best master clock a0369f.fffe.a1b68c > ptp4l[618578.192]: driver changed our HWTSTAMP options > ptp4l[618578.192]: tx_type 1 not 1 > ptp4l[618578.192]: rx_filter 1 not 12 > ptp4l[618578.192]: selected best master clock a0369f.fffe.a1b68c > ptp4l[618580.850]: selected best master clock a0369f.fffe.a1b688 <-- MAC Addr. of the Master server > ptp4l[618580.850]: foreign master not using PTP timescale > ptp4l[618580.850]: running in a temporal vortex > ptp4l[618580.850]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[618582.669]: port 1: minimum delay request interval 2^4 > ptp4l[618582.851]: master offset 1299422 s0 freq +4989 path delay -11798 > ptp4l[618584.852]: master offset 1321175 s1 freq +15865 path delay -9425 > ptp4l[618587.572]: driver changed our HWTSTAMP options > ptp4l[618587.572]: tx_type 1 not 1 > ptp4l[618587.572]: rx_filter 1 not 12 > ptp4l[618587.572]: port 1: UNCALIBRATED to LISTENING on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[618587.572]: selected best master clock a0369f.fffe.a1b68c > ptp4l[618594.597]: driver changed our HWTSTAMP options > ptp4l[618594.597]: tx_type 1 not 1 > ptp4l[618594.597]: rx_filter 1 not 12 > ptp4l[618594.597]: selected best master clock a0369f.fffe.a1b68c > ptp4l[618596.851]: selected best master clock a0369f.fffe.a1b688 > ptp4l[618596.851]: foreign master not using PTP timescale > ptp4l[618596.851]: running in a temporal vortex > ptp4l[618596.851]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[618598.850]: master offset 43778 s2 freq +37754 path delay 0 > ptp4l[618598.850]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED > ptp4l[618600.852]: master offset 6710 s2 freq +25787 path delay 0 > > there also was this line every one in a while: > > ptp4l[5828.626]: port 1: minimum delay request interval 2^^4 > > > I am starting the Master with a config File. > ptp4l -f /etc/ptp.config > > with following config file: > > [global] > verbose 1 > path_trace_enabled 1 > time_stamping hardware > priority1 1 > priority2 1 > [eth4] > > > The Slaves are started via: ptp4l -A -m -i eth4 -s > > I also wrote a config file for them, but if I use the file, they do select themself as the best clock. > > > > rupp@s0002794:~$ ptp4l[619043.020]: selected best master clock a0369f.fffe.a1b68c <--MAC Addr. of the Slave > ptp4l[619050.271]: selected best master clock a0369f.fffe.a1b68c > ptp4l[619056.348]: selected best master clock a0369f.fffe.a1b68c > ptp4l[619062.726]: selected best master clock a0369f.fffe.a1b68c > > with following config File: > > [global] > verbose 1 > path_trace_enabled 1 > time_stamping hardware > slaveOnly 1 > priority1 255 > priority2 255 > [eth4] > > > Phc2sys is running on both, the Master and the Slaves. > Master: phc2sys -s CLOCK_REALTIME -c eth4 -w & > Slaves: phc2sys -s eth4 -w & > > > Here is the configuration of the Switch: > > > ptp brief: > > PTP port status > ----------------------- > Port State > ------- -------------- > Eth1/17 Master <--Server C > Eth1/19 Master <--Server B > Eth1/31 Slave <--Server A > > ptp clock: > > PTP Device Type: Boundary clock > Clock Identity : 00:2a:6a:ff:fe:ac:97:fc > Clock Domain: 0 > Number of PTP ports: 3 > Priority1 : 2 > Priority2 : 2 > Clock Quality: > Class : 248 > Accuracy : 254 > Offset (log variance) : 65535 > Offset From Master : 467 > Mean Path Delay : 33580 > Steps removed : 1 > Local clock time:Thu Jun 23 13:52:14 2016 > > Slave port: > PTP Port Dataset: Eth1/17 > Port identity: clock identity: 00:2a:6a:ff:fe:ac:97:fc > Port identity: port number: 16 > PTP version: 2 > Port state: Master > VLAN info: 1 > Delay request interval(log mean): 4 > Announce receipt time out: 2 > Peer mean path delay: 0 > Announce interval(log mean): 3 > Sync interval(log mean): 1 > Delay Mechanism: End to End > > Master port: > PTP Port Dataset: Eth1/31 > Port identity: clock identity: 00:2a:6a:ff:fe:ac:97:fc > Port identity: port number: 30 > PTP version: 2 > Port state: Slave > VLAN info: 1 > Delay request interval(log mean): 4 > Announce receipt time out: 2 > Peer mean path delay: 0 > Announce interval(log mean): 3 > Sync interval(log mean): 1 > Delay Mechanism: End to End > > > Thank you in advance. > > > Greeting, > Christian > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Dale S. <dal...@gm...> - 2016-06-30 15:32:56
|
On Thu, Jun 30, 2016 at 8:14 AM, Christian < chr...@fr...> wrote: > Here are pictures of the logs: > Server s0002796 is the master s0002792 ands0002794 are the slaves. > > ptplog7start is the log it produced right after starting ptp4l.: > https://s32.postimg.org/i6af9ejx1/ptplog7start.png > ptplog7 is shortly thereafter: > https://s32.postimg.org/bnsuv6rat/ptplog7.png > ptplog7_2 is a bit later.: https://s32.postimg.org/jmtjfahhh/ptplog7_2.png > Howdy Christian, I think it would be far better to submit the logs as text instead of images. Those images are very difficult to read and impossible to edit (the text). -Dale |
|
From: Richard C. <ric...@gm...> - 2016-06-30 19:05:47
|
On Thu, Jun 30, 2016 at 11:32:49AM -0400, Dale Smith wrote: > I think it would be far better to submit the logs as text instead of > images. Those images are very difficult to read and impossible to edit > (the text). +1 In addition, can you post a short pcap file showing the PTP traffic on the non-working port? Thanks, Richard |
|
From: Christian <chr...@fr...> - 2016-07-01 13:28:36
|
I have attached 3 .txt files with the logs. Again, 96 is the master server and 94 and 92 are the slaves. And I have attached a pcap file of the Server 94(not captured at the same moment, but the behavior was the same). Am 30.06.2016 um 21:05 schrieb Richard Cochran: > On Thu, Jun 30, 2016 at 11:32:49AM -0400, Dale Smith wrote: >> I think it would be far better to submit the logs as text instead of >> images. Those images are very difficult to read and impossible to edit >> (the text). > +1 > > In addition, can you post a short pcap file showing the PTP traffic on > the non-working port? > > Thanks, > Richard |
|
From: Richard C. <ric...@gm...> - 2016-07-05 09:05:05
|
On Fri, Jul 01, 2016 at 03:26:05PM +0200, Christian wrote: > I have attached 3 .txt files with the logs. Again, 96 is the master server > and 94 and 92 are the slaves. > And I have attached a pcap file of the Server 94(not captured at the same > moment, but the behavior was the same). Sorry about the delay. I finally took a look at your problem... In the PCAP, the Announce messages are only sent by the Cisco every seven seconds. The PCAP frames are truncated, so we can't see what the Cisco advertises for the logMessageInterval (logAnnounceInterval). I guess it is set to 3 (2^3 = 8 seconds). Anyhow, you can fix this by configuring the Cisco and your client to the same logAnnounceInterval value. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2016-07-05 12:53:39
|
BTW, in the log I noticed a bug (not related to your problem): On Fri, Jul 01, 2016 at 03:26:05PM +0200, Christian wrote: > ptp4l[622912.203]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[622912.209]: port 0: setting asCapable > ptp4l[622918.492]: port 0: announce timeout > ptp4l[622925.985]: port 0: announce timeout > ptp4l[622932.071]: port 0: announce timeout Port 0 is the UDS port and should never see an announce message timeout. This is a regression in v1.6. I just posted a fix for it on the linuxptp-devel mailing list. Thanks, Richard |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X