linuxptp-users Mailing List for linuxptp (Page 116)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
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: Vanderpool, C. <cly...@ax...> - 2016-06-22 12:16:27
|
I guess a little bit of both. From looking things up on google or different forums all I could find was kind of circular (i.e. 'frequency adjustment is the computer adjusting it's frequency') I figured it had something to do with the clock pulse of the individual machines but I don't want to guess. I have to present some information and I want to make sure I sound reasonably intelligent. Any info would be appreciated. On Tue, Jun 21, 2016 at 3:43 PM, Vanderpool, Clyde < cly...@ax...> wrote: > I guess a little bit of both. From looking things up on google or > different forums all I could find was kind of circular (i.e. 'frequency > adjustment is the computer adjusting it's frequency') I figured it had > something to do with the clock pulse of the individual machines but I don't > want to guess. I have to present some information and I want to make sure > I sound reasonably intelligent. Any info would be appreciated. > > Clyde > > On Tue, Jun 21, 2016 at 3:36 PM, Richard Cochran <ric...@gm... > > wrote: > >> On Tue, Jun 21, 2016 at 08:25:35AM -0400, Vanderpool, Clyde wrote: >> > implementation of PTP is working. Most of the information from the >> 'pmc' >> > and 'ptp4l' commands are pretty straight forward, but I was wondering >> what >> > 'frequency adjustment' actually means. >> >> Are you asking, what is frequency adjustment in general, or are you >> wondering about specific numbers reported by the programs (like the >> 'freq' column of ptp4l)? >> >> Thanks, >> Richard >> > > |
|
From: Richard C. <ric...@gm...> - 2016-06-21 19:36:49
|
On Tue, Jun 21, 2016 at 08:25:35AM -0400, Vanderpool, Clyde wrote: > implementation of PTP is working. Most of the information from the 'pmc' > and 'ptp4l' commands are pretty straight forward, but I was wondering what > 'frequency adjustment' actually means. Are you asking, what is frequency adjustment in general, or are you wondering about specific numbers reported by the programs (like the 'freq' column of ptp4l)? Thanks, Richard |
|
From: Vanderpool, C. <cly...@ax...> - 2016-06-21 12:55:59
|
Hello, I am pretty new to both Linux and the IEEE 1588. However, somehow I managed to build up my own kernel in order to implement Linux-PTP on a LAN consisting of 8 different machines. Even more surprising is that it seems to be working! I have been tasked to collect the time data from all the different clocks on the network and give a synopsis of how well this implementation of PTP is working. Most of the information from the 'pmc' and 'ptp4l' commands are pretty straight forward, but I was wondering what 'frequency adjustment' actually means. If anyone could just give me a brief description of what this pertains to I would be very grateful. I just want to make sure I can present the information to my boss in a somewhat intelligent manner. Thank you in advance. Clyde |
|
From: Richard C. <ric...@gm...> - 2016-06-08 14:37:25
|
On Wed, Jun 08, 2016 at 04:25:17PM +0200, ds...@gm... wrote: > I use on the slave side the ptp timestamp with high accuracy for logging data, > parallel i want to capture some wireshark frames with tcpdump. > tcpdump uses the RTC so i'm not able to see directly the associated > timestamps of PTP and RTC. > This is the reason why i want to have the same time at PHC and RTC. > > Is this possible? Yes, you can use "-O 0" on the phc2sys command line. Warning: This won't work with 3rd party PTP equipment! HTH, Richard |
|
From: <ds...@gm...> - 2016-06-08 14:25:32
|
Sorry, i hope now it is correct: Hi Richard, thanks for your help! >> The ptp hardware clock seems to be adjusted correct but with phc2sys i can't >> set the RTC on the same value as the PHC. It is 36 seconds away like TAI-UTC. > >The RTC should *not* have the same value as the PHC. The RTC uses the >UTC timescale, but the PHC uses TAI. > >BTW, your nodes all have TAI-UTC = 35, not the current 36. (This >shows that you are using some version prior to 1.6.) If you want to >have the correct offset, use the "set GRANDMASTER_SETTINGS_NP" pmc >command. > Thanks for the hint, i have seen the master is old with 1.4 and the slaves have the new version with 1.6 >> Master: >> ptp4l -2 -i eth0 -p /dev/ptp0 -m >> phc2sys -s eth0 -c CLOCK_REALTIME -w -m >> RTC: Wed Jun 8 10:34:27 2016 0.000000 seconds >> PHC: 2016-06-08 10:35:02.316598760 > >On the master, you are adjusting your CLOCK_REALTIME to follow the PHC >time. But what is setting the PHC time? Maybe you reversed the -s >and -c flags, but I don't know your intention. > I use on the slave side the ptp timestamp with high accuracy for logging data, parallel i want to capture some wireshark frames with tcpdump. tcpdump uses the RTC so i'm not able to see directly the associated timestamps of PTP and RTC. This is the reason why i want to have the same time at PHC and RTC. Is this possible? >> Slave1: >> ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/default.cfg -s -m >> phc2sys -s eth0 -c CLOCK_REALTIME -w -q -m >> RTC: Wed Jun 8 10:34:25 2016 0.000000 seconds >> PHC: 2016-06-08 10:35:00.084961211 > >> Slave2: >> ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/default.cfg -s -m >> phc2sys -s eth0 -c CLOCK_REALTIME -w -q -m >> RTC: Wed Jun 8 10:34:29 2016 0.000000 seconds >> PHC: 2016-06-08 10:35:04.220653446 > >> What am I doing wrong? > >The slaves are configured to adjust their CLOCK_REALTIME (UTC) to >follow the PHC (TAI). The master gives the slaves the TAI time and >tells them that TAI-UTC=35. Then, phc2sys sets the system clock, and >you can see the 35 second offset. > >So, there is nothing wrong with the slaves. > >HTH, DSP |
|
From: Richard C. <ric...@gm...> - 2016-06-08 14:08:34
|
No html, please. Thanks, Richard |
|
From: <ds...@gm...> - 2016-06-08 13:35:02
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div style="font-family: Verdana;font-size: 12.0px;"> <div> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>Hi Richard,</div> <div> </div> <div>thanks for your help!</div> <div> </div> <div>>> The ptp hardware clock seems to be adjusted correct but with phc2sys i can't<br/> >> set the RTC on the same value as the PHC. It is 36 seconds away like TAI-UTC.<br/> ><br/> >The RTC should *not* have the same value as the PHC. The RTC uses the<br/> >UTC timescale, but the PHC uses TAI.<br/> ><br/> >BTW, your nodes all have TAI-UTC = 35, not the current 36. (This<br/> >shows that you are using some version prior to 1.6.) If you want to<br/> >have the correct offset, use the "set GRANDMASTER_SETTINGS_NP" pmc<br/> >command.<br/> ></div> <div> </div> <div>Thanks for the hint, i have seen the master is old with 1.4 and the slaves have the new version</div> <div>with 1.6</div> <div><br/> >> Master:<br/> >> ptp4l -2 -i eth0 -p /dev/ptp0 -m<br/> >> phc2sys -s eth0 -c CLOCK_REALTIME -w -m<br/> >> RTC: Wed Jun 8 10:34:27 2016 0.000000 seconds<br/> >> PHC: 2016-06-08 10:35:02.316598760<br/> ><br/> >On the master, you are adjusting your CLOCK_REALTIME to follow the PHC<br/> >time. But what is setting the PHC time? Maybe you reversed the -s<br/> >and -c flags, but I don't know your intention.<br/> ></div> <div> </div> <div>I use on the slave side the ptp timestamp with high accuracy for logging data,</div> <div>parallel i want to capture some wireshark frames with tcpdump.</div> <div>tcpdump uses the RTC so i'm not able to see directly the associated</div> <div>timestamps of PTP and RTC.</div> <div>This is the reason why i want to have the same time at PHC and RTC.</div> <div> </div> <div>Is this possible?</div> <div><br/> >> Slave1:<br/> >> ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/default.cfg -s -m<br/> >> phc2sys -s eth0 -c CLOCK_REALTIME -w -q -m<br/> >> RTC: Wed Jun 8 10:34:25 2016 0.000000 seconds<br/> >> PHC: 2016-06-08 10:35:00.084961211<br/> ><br/> >> Slave2:<br/> >> ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/default.cfg -s -m<br/> >> phc2sys -s eth0 -c CLOCK_REALTIME -w -q -m<br/> >> RTC: Wed Jun 8 10:34:29 2016 0.000000 seconds<br/> >> PHC: 2016-06-08 10:35:04.220653446<br/> ><br/> >> What am I doing wrong?<br/> ><br/> >The slaves are configured to adjust their CLOCK_REALTIME (UTC) to<br/> >follow the PHC (TAI). The master gives the slaves the TAI time and<br/> >tells them that TAI-UTC=35. Then, phc2sys sets the system clock, and<br/> >you can see the 35 second offset.<br/> ><br/> >So, there is nothing wrong with the slaves.<br/> ><br/> >HTH,</div> <div> </div> <div>DSP</div> </div> </div> </div> <div> </div> <div class="signature"> </div> </div></div></body></html> |
|
From: Richard C. <ric...@gm...> - 2016-06-08 11:43:57
|
On Wed, Jun 08, 2016 at 09:19:40AM +0000, DSP wrote: > The ptp hardware clock seems to be adjusted correct but with phc2sys i can't > set the RTC on the same value as the PHC. It is 36 seconds away like TAI-UTC. The RTC should *not* have the same value as the PHC. The RTC uses the UTC timescale, but the PHC uses TAI. BTW, your nodes all have TAI-UTC = 35, not the current 36. (This shows that you are using some version prior to 1.6.) If you want to have the correct offset, use the "set GRANDMASTER_SETTINGS_NP" pmc command. > Master: > ptp4l -2 -i eth0 -p /dev/ptp0 -m > phc2sys -s eth0 -c CLOCK_REALTIME -w -m > RTC: Wed Jun 8 10:34:27 2016 0.000000 seconds > PHC: 2016-06-08 10:35:02.316598760 On the master, you are adjusting your CLOCK_REALTIME to follow the PHC time. But what is setting the PHC time? Maybe you reversed the -s and -c flags, but I don't know your intention. > Slave1: > ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/default.cfg -s -m > phc2sys -s eth0 -c CLOCK_REALTIME -w -q -m > RTC: Wed Jun 8 10:34:25 2016 0.000000 seconds > PHC: 2016-06-08 10:35:00.084961211 > Slave2: > ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/default.cfg -s -m > phc2sys -s eth0 -c CLOCK_REALTIME -w -q -m > RTC: Wed Jun 8 10:34:29 2016 0.000000 seconds > PHC: 2016-06-08 10:35:04.220653446 > What am I doing wrong? The slaves are configured to adjust their CLOCK_REALTIME (UTC) to follow the PHC (TAI). The master gives the slaves the TAI time and tells them that TAI-UTC=35. Then, phc2sys sets the system clock, and you can see the 35 second offset. So, there is nothing wrong with the slaves. HTH, |
|
From: DSP <ds...@gm...> - 2016-06-08 09:25:15
|
Hi, can someone please give me a hint to find the correct settings for my problem. I have a master and two slaves. I use Level2 and E2E mechanism for syncing. The ptp hardware clock seems to be adjusted correct but with phc2sys i can't set the RTC on the same value as the PHC. It is 36 seconds away like TAI-UTC. Here are my calls and the logs: Master: ptp4l -2 -i eth0 -p /dev/ptp0 -m ptp4l[5797.764]: selected /dev/ptp0 as PTP clock ptp4l[5797.810]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[5797.817]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[5804.739]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[5804.743]: selected best master clock 68c90b.fffe.24a105 ptp4l[5804.743]: assuming the grand master role phc2sys -s eth0 -c CLOCK_REALTIME -w -m phc2sys[5827.066]: sys offset 35000003040 s0 freq +0 delay 3760 phc2sys[5828.084]: sys offset 35000003048 s1 freq +8 delay 3760 phc2sys[5829.087]: sys offset 1511 s2 freq +1519 delay 3800 phc2sys[5830.088]: sys offset -1915 s2 freq -1454 delay 3800 phc2sys[5831.089]: sys offset 49 s2 freq -64 delay 3760 phc2sys[5832.090]: sys offset -1518 s2 freq -1617 delay 3760 phc2sys[5833.090]: sys offset 3387 s2 freq +2833 delay 3760 phc2sys[5834.091]: sys offset -2822 s2 freq -2360 delay 3760 phc2sys[5835.092]: sys offset 2490 s2 freq +2106 delay 3760 phc2sys[5836.093]: sys offset -3216 s2 freq -2853 delay 3760 phc2sys[5837.093]: sys offset 1816 s2 freq +1214 delay 3800 phc2sys[5838.094]: sys offset -8917 s2 freq -8974 delay 3721 phc2sys[5839.095]: sys offset 14571 s2 freq +11838 delay 3760 phc2sys[5840.095]: sys offset -8496 s2 freq -6857 delay 3761 RTC: Wed Jun 8 10:34:27 2016 0.000000 seconds PHC: 2016-06-08 10:35:02.316598760 ------------------------------------------------------------------------------- Slave1: ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/default.cfg -s -m ptp4l[5795.940]: selected /dev/ptp0 as PTP clock ptp4l[5795.976]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[5795.979]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[5801.713]: port 1: new foreign master 68c90b.fffe.24a105-1 ptp4l[5802.114]: selected best master clock ec24b8.fffe.be32ce ptp4l[5805.713]: selected best master clock 68c90b.fffe.24a105 ptp4l[5805.714]: running in a temporal vortex ptp4l[5805.716]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[5806.712]: master offset 950644976 s0 freq +0 path delay 0 ptp4l[5807.713]: master offset 950624115 s1 freq -20858 path delay 11577 ptp4l[5809.713]: master offset 22943 s2 freq +2085 path delay 10286 ptp4l[5809.715]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[5810.713]: master offset 9637 s2 freq -4338 path delay 12236 ptp4l[5811.713]: master offset 5655 s2 freq -5429 path delay 11261 ptp4l[5812.713]: master offset 1757 s2 freq -7630 path delay 11261 ptp4l[5813.714]: master offset 1034 s2 freq -7826 path delay 10286 ptp4l[5814.714]: master offset -336 s2 freq -8886 path delay 10202 ptp4l[5815.714]: master offset -656 s2 freq -9307 path delay 10119 ptp4l[5816.714]: master offset 141 s2 freq -8707 path delay 9344 ptp4l[5817.714]: master offset 261 s2 freq -8544 path delay 8616 ptp4l[5818.714]: master offset -494 s2 freq -9221 path delay 8588 ptp4l[5819.715]: master offset -594 s2 freq -9469 path delay 8588 ptp4l[5820.715]: master offset -409 s2 freq -9463 path delay 8544 phc2sys -s eth0 -c CLOCK_REALTIME -w -q -m phc2sys[5827.353]: phc offset 35950447461 s0 freq +0 delay 3720 phc2sys[5828.367]: phc offset 35950438138 s1 freq -9299 delay 3800 phc2sys[5829.370]: phc offset -16791 s2 freq -26090 delay 3720 phc2sys[5830.370]: phc offset 14730 s2 freq +393 delay 3680 phc2sys[5831.371]: phc offset 5749 s2 freq -4169 delay 3760 phc2sys[5832.371]: phc offset -2637 s2 freq -10830 delay 3760 phc2sys[5833.372]: phc offset 22752 s2 freq +13768 delay 3759 phc2sys[5834.372]: phc offset -27450 s2 freq -29608 delay 3760 phc2sys[5835.373]: phc offset 3138 s2 freq -7255 delay 3720 phc2sys[5836.373]: phc offset 4980 s2 freq -4472 delay 3720 phc2sys[5837.373]: phc offset -7288 s2 freq -15246 delay 3720 phc2sys[5838.374]: phc offset 2102 s2 freq -8042 delay 3719 phc2sys[5839.374]: phc offset 2061 s2 freq -7453 delay 3720 phc2sys[5840.375]: phc offset -2255 s2 freq -11151 delay 3720 phc2sys[5841.375]: phc offset -2802 s2 freq -12374 delay 3721 RTC: Wed Jun 8 10:34:25 2016 0.000000 seconds PHC: 2016-06-08 10:35:00.084961211 ------------------------------------------------------------------------------- Slave2: ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/default.cfg -s -m ptp4l[5794.721]: selected /dev/ptp0 as PTP clock ptp4l[5794.757]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[5794.760]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[5799.390]: port 1: new foreign master 68c90b.fffe.24a105-1 ptp4l[5801.550]: selected best master clock 68c90b.fffe.249cdd ptp4l[5803.389]: selected best master clock 68c90b.fffe.24a105 ptp4l[5803.391]: running in a temporal vortex ptp4l[5803.393]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[5804.389]: master offset 621663936 s0 freq +0 path delay 0 ptp4l[5805.389]: master offset 621660116 s1 freq -3819 path delay 0 ptp4l[5806.389]: master offset -1577 s2 freq -5396 path delay 0 ptp4l[5806.391]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[5807.390]: master offset -7964 s2 freq -12257 path delay 7991 ptp4l[5808.390]: master offset 493 s2 freq -6189 path delay 7991 ptp4l[5809.390]: master offset 2843 s2 freq -3691 path delay 8058 ptp4l[5810.390]: master offset 2498 s2 freq -3183 path delay 8270 ptp4l[5811.390]: master offset 1901 s2 freq -3031 path delay 8270 ptp4l[5812.390]: master offset 1001 s2 freq -3360 path delay 8416 ptp4l[5813.391]: master offset 563 s2 freq -3498 path delay 8424 ptp4l[5814.391]: master offset 264 s2 freq -3628 path delay 8431 ptp4l[5815.391]: master offset 76 s2 freq -3737 path delay 8431 ptp4l[5816.391]: master offset 28 s2 freq -3762 path delay 8431 ptp4l[5817.391]: master offset 10 s2 freq -3772 path delay 8423 ptp4l[5818.391]: master offset 1 s2 freq -3778 path delay 8423 ptp4l[5819.392]: master offset -6 s2 freq -3784 path delay 8423 ptp4l[5820.392]: master offset -50 s2 freq -3830 path delay 8423 phc2sys -s eth0 -c CLOCK_REALTIME -w -q -m phc2sys[5828.408]: phc offset 35621567434 s0 freq +0 delay 3800 phc2sys[5829.418]: phc offset 35621563619 s1 freq -3803 delay 3760 phc2sys[5830.423]: phc offset 3112 s2 freq -691 delay 3760 phc2sys[5831.423]: phc offset -2805 s2 freq -5675 delay 3720 phc2sys[5832.424]: phc offset -14338 s2 freq -18049 delay 3800 phc2sys[5833.424]: phc offset -1833 s2 freq -9845 delay 3721 phc2sys[5834.424]: phc offset 47771 s2 freq +39209 delay 3719 phc2sys[5835.425]: phc offset -49627 s2 freq -43858 delay 3721 phc2sys[5836.425]: phc offset 16395 s2 freq +7276 delay 3720 phc2sys[5837.426]: phc offset 9209 s2 freq +5008 delay 3759 phc2sys[5838.426]: phc offset -3540 s2 freq -4978 delay 3680 phc2sys[5839.426]: phc offset -2939 s2 freq -5439 delay 3720 phc2sys[5840.427]: phc offset -472 s2 freq -3854 delay 3720 phc2sys[5841.427]: phc offset -5922 s2 freq -9445 delay 3801 phc2sys[5842.428]: phc offset 2043 s2 freq -3257 delay 3720 phc2sys[5843.428]: phc offset 4164 s2 freq -523 delay 3760 RTC: Wed Jun 8 10:34:29 2016 0.000000 seconds PHC: 2016-06-08 10:35:04.220653446 What am I doing wrong? DSP |
|
From: Richard C. <ric...@gm...> - 2016-05-31 07:46:18
|
On Mon, May 30, 2016 at 01:58:42PM +0000, Rohit Borse wrote: > From PTP Master side code, can we know the PTP clock time status of > Remote Slave node using programmatic approach rather than using pmc > command. If you don't want to use the pmc program, then you can send the appropriate management messages directly. See pmc_common.h and pmc_common.c for an example. > eg. If master A needs that clock time of master A is not in sync > with clock time of slave B, to send some signal to any dependent > module which would be helpful. That is not the way it works. If node A wants information about node B, then node A must request it. For your case, this implies that A will poll the state of B. > So how master A can know if PTP time of slave B is not in sync/or in > sync. 1. Send the "GET PORT_DATA_SET" request and check that portState is SLAVE. 2. Send the "GET CURRENT_DATA_SET" request and check offsetFromMaster. > Currently we are planning to decide if Maser clock is not in sync > with slave Clock, if pDelayReq message is not sent by Slave for some > defined timeout. Is this suitable logic? No, that won't work at all. The delay requests are sent periodically, regardless of the synchronization status. Cheers, Richard |
|
From: Richard C. <ric...@gm...> - 2016-05-25 13:02:05
|
On Wed, May 25, 2016 at 11:49:48AM +0000, Rohit Borse wrote: > In PTP protocol specification, I found Signaling message, which can > be sent when PTP slave is Synchronized to PTP Master. Yes, there is a "Signaling" message in 1588, but it is not used in that way. > In linuxptp-1.3 stack, Is there any message to notify PTP > Synchronization Status (i.e.Synchronization lost) from PTP Slave to > PTP Master or any command/message can be sent from PTP Master to > Slave to check PTP Synchronization status? To monitor synchronization status, use the "pmc" program. HTH, Richard |
|
From: Rohit B. <Roh...@kp...> - 2016-05-25 12:12:50
|
Hi, In PTP protocol specification, I found Signaling message, which can be sent when PTP slave is Synchronized to PTP Master. In linuxptp-1.3 stack, Is there any message to notify PTP Synchronization Status (i.e.Synchronization lost) from PTP Slave to PTP Master or any command/message can be sent from PTP Master to Slave to check PTP Synchronization status? Thanks and Regards, Rohit Borse This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails. |
|
From: Keller, J. E <jac...@in...> - 2016-05-11 17:58:02
|
On Wed, 2016-05-11 at 23:13 +0530, vidya sagar wrote: > I added the dump_stack() to see the full flow as the error print > "PCIe link lost, device now detached" is there as part of igb_rd32() > API which is called at many places. Are we not supposed to 'cancel > delayed work of igb_ptp_overflow_check() when system goes to suspend > state (and schedule when system resumes)? It is probably because we're triggering a surprise removal event which we shouldn't be doing. It likely happens because of the suspend which puts is part way through this state, and we need to disable the overflow check and re-enable it at a resume time, yep. Thanks, Jake |
|
From: Keller, J. E <jac...@in...> - 2016-05-11 17:52:28
|
From: vidya sagar [mailto:sag...@gm...] Sent: Wednesday, May 11, 2016 10:44 AM To: Keller, Jacob E <jac...@in...> Cc: e10...@li...; lin...@li... Subject: Re: [E1000-devel] Need help with igb driver suspend crash issue I added the dump_stack() to see the full flow as the error print "PCIe link lost, device now detached" is there as part of igb_rd32() API which is called at many places. Are we not supposed to 'cancel delayed work of igb_ptp_overflow_check() when system goes to suspend state (and schedule when system resumes)? On Wed, May 11, 2016 at 9:54 PM, Keller, Jacob E <jac...@in...<mailto:jac...@in...>> wrote: Hi, > -----Original Message----- > From: vidya sagar [mailto:sag...@gm...<mailto:sag...@gm...>] > Sent: Wednesday, May 11, 2016 3:25 AM > To: e10...@li...<mailto:e10...@li...>; linuxptp- > us...@li...<mailto:us...@li...> > Subject: Re: [E1000-devel] Need help with igb driver suspend crash issue > > <<< Including lin...@li...<mailto:lin...@li...> >>> > > On Wed, May 11, 2016 at 3:51 PM, vidya sagar <sag...@gm...<mailto:sag...@gm...>> > wrote: > > > Hi, > > I'm using Intel IGB I350 NIC card on one of our arm based platforms. > > While suspending the system, sometimes we see "igb 0000:01:00.0 eth1: > PCIe > > link lost, device now detached" print in the log and subsequent resume > > causes system to crash. After digging the code (BTW, I'm using kernel-3.18 > > release), it looks like the above print comes because of the following call > > flow, which got executed after igb_suspend() is called ( I confirmed this > > with the help of prints) > > > > [10846.434381] [<ffffffc000089ce4>] dump_backtrace+0x0/0xf8 > > [10846.434386] [<ffffffc000089ea0>] show_stack+0x10/0x1c > > [10846.434393] [<ffffffc000bc3b70>] dump_stack+0x80/0xc4 > > [10846.434397] [<ffffffc000613d3c>] igb_rd32+0xb0/0x1a8 > > [10846.434400] [<ffffffc00062eb0c>] igb_ptp_read_82580+0x18/0x48 > > [10846.434407] [<ffffffc000106e6c>] timecounter_read+0x1c/0x60 > > [10846.434410] [<ffffffc00062f338>] igb_ptp_gettime_82576+0x2c/0x88 > > [10846.434413] [<ffffffc00062f41c>] igb_ptp_overflow_check+0x1c/0x58 > > [10846.434419] [<ffffffc0000ba584>] process_one_work+0x154/0x414 > > [10846.434424] [<ffffffc0000bb338>] worker_thread+0x13c/0x4e4 > > [10846.434428] [<ffffffc0000bfc4c>] kthread+0xf8/0x110 > > > > It looks like reading timer registers would have returned all F's as the > > device is already in D3Hot state. > > Is my understanding correct. Is there any patch available to fix this > > issue? > > Let me know if more information is needed. > > Maybe an ordering bug when doing suspend that we try to read things too late. Is that stack trace the actual crash or did you add the dump_stack yourself? Thanks, Jake > > Thanks, > > Vidya Sagar > > |
|
From: Keller, J. E <jac...@in...> - 2016-05-11 16:26:01
|
Hi, > -----Original Message----- > From: vidya sagar [mailto:sag...@gm...] > Sent: Wednesday, May 11, 2016 3:25 AM > To: e10...@li...; linuxptp- > us...@li... > Subject: Re: [E1000-devel] Need help with igb driver suspend crash issue > > <<< Including lin...@li... >>> > > On Wed, May 11, 2016 at 3:51 PM, vidya sagar <sag...@gm...> > wrote: > > > Hi, > > I'm using Intel IGB I350 NIC card on one of our arm based platforms. > > While suspending the system, sometimes we see "igb 0000:01:00.0 eth1: > PCIe > > link lost, device now detached" print in the log and subsequent resume > > causes system to crash. After digging the code (BTW, I'm using kernel-3.18 > > release), it looks like the above print comes because of the following call > > flow, which got executed after igb_suspend() is called ( I confirmed this > > with the help of prints) > > > > [10846.434381] [<ffffffc000089ce4>] dump_backtrace+0x0/0xf8 > > [10846.434386] [<ffffffc000089ea0>] show_stack+0x10/0x1c > > [10846.434393] [<ffffffc000bc3b70>] dump_stack+0x80/0xc4 > > [10846.434397] [<ffffffc000613d3c>] igb_rd32+0xb0/0x1a8 > > [10846.434400] [<ffffffc00062eb0c>] igb_ptp_read_82580+0x18/0x48 > > [10846.434407] [<ffffffc000106e6c>] timecounter_read+0x1c/0x60 > > [10846.434410] [<ffffffc00062f338>] igb_ptp_gettime_82576+0x2c/0x88 > > [10846.434413] [<ffffffc00062f41c>] igb_ptp_overflow_check+0x1c/0x58 > > [10846.434419] [<ffffffc0000ba584>] process_one_work+0x154/0x414 > > [10846.434424] [<ffffffc0000bb338>] worker_thread+0x13c/0x4e4 > > [10846.434428] [<ffffffc0000bfc4c>] kthread+0xf8/0x110 > > > > It looks like reading timer registers would have returned all F's as the > > device is already in D3Hot state. > > Is my understanding correct. Is there any patch available to fix this > > issue? > > Let me know if more information is needed. > > Maybe an ordering bug when doing suspend that we try to read things too late. Is that stack trace the actual crash or did you add the dump_stack yourself? Thanks, Jake > > Thanks, > > Vidya Sagar > > |
|
From: Don Ho <don...@gm...> - 2016-05-05 20:42:39
|
Please read the response part at the bottom of this email.
I did not have the latest kernel of v3.19. I have a working VLAN PTP
configured with the older way .
On Wed, Dec 02, 2015 at 03:34:57PM -0500, Don Ho wrote:
> If you are interested in using ptp4l/phc2sys hardware timestamp on
> vlan, the following instruction is working on my system.
> Someone may ask why VLAN, why I can just have the interfaces on
> different NIC cards. Sure you can. But if you want to reduce the
> number of cables, NIC cards, and may be switches. VLAN is the
> solution.
>
> Many thanks to Shawn Bohrer for helping me to make this configuration work.
I am suprised that you need to change ptp4l in order to work with VLAN
interfaces. I thought that I had fixed this in the kernel:
commit 37dd9255b2f6201195946014600a8d857f846cf4
Author: Richard Cochran <ric...@gm...>
Date: Fri Nov 21 14:16:20 2014 +0100
vlan: Pass ethtool get_ts_info queries to real device.
Commit a6111d3c "vlan: Pass SIOC[SG]HWTSTAMP ioctls to real device"
intended to enable hardware time stamping on VLAN interfaces, but
passing SIOCSHWTSTAMP is only half of the story. This patch adds
the second half, by letting user space find out the time stamping
capabilities of the device backing a VLAN interface.
Commit 37dd9255 is in kernel v3.19, and commit a6111d3c is in v3.17.
What kernel version are you using?
Thanks,
Richard
On Thu, May 5, 2016 at 4:13 PM, Keller, Jacob E
<jac...@in...> wrote:
> I don't see the original message you are replying to?
>
> I suspect you mean a patch that fixes software timestamping over vlan
> devices?
>
> Regards,
> Jake
>
> On Thu, 2016-05-05 at 19:46 +0000, Murali Karicheri wrote:
>> Keller, Jacob E <jacob.e.keller@...> writes:
>>
>> All,
>>
>> Do you know the status of this fix for ptp over vlan issue?
>>
>> Murali
>>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Murali K. <m-k...@ti...> - 2016-05-05 20:42:30
|
Keller, Jacob E <jacob.e.keller@...> writes: > > I don't see the original message you are replying to? > Couldn't post as the web interface I used complained about not pruning the message. Here is the original thread http://comments.gmane.org/gmane.comp.linux.ptp.user/635 > I suspect you mean a patch that fixes software timestamping over vlan > devices? Yes. Has the patch made into the kernel? We are using hardware based timestamping and this is needed Murali > > Regards, > Jake > > On Thu, 2016-05-05 at 19:46 +0000, Murali Karicheri wrote: > > Keller, Jacob E <jacob.e.keller <at> ...> writes: > > > > All, > > > > Do you know the status of this fix for ptp over vlan issue? > > > > Murali > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > |
|
From: Keller, J. E <jac...@in...> - 2016-05-05 20:14:14
|
I don't see the original message you are replying to? I suspect you mean a patch that fixes software timestamping over vlan devices? Regards, Jake On Thu, 2016-05-05 at 19:46 +0000, Murali Karicheri wrote: > Keller, Jacob E <jacob.e.keller@...> writes: > > All, > > Do you know the status of this fix for ptp over vlan issue? > > Murali > |
|
From: Murali K. <m-k...@ti...> - 2016-05-05 19:50:15
|
Keller, Jacob E <jacob.e.keller@...> writes: All, Do you know the status of this fix for ptp over vlan issue? Murali |
|
From: Richard C. <ric...@gm...> - 2016-05-04 12:56:23
|
On Wed, May 04, 2016 at 10:40:28AM +0200, Xavier Bestel wrote: > Excepted in hwstamp_ctl.c I can find no trace of PTPv1 support in > linuxptp. Does anyone know of a stack supporting this with hw > timestamping support ? I don't think there is any open source stack supporting V1 and HW time stamping. IIRC, some of the commercial stacks still claim V1 support. The easiest way might be to take the old ptpd and add HW time stamping to it. HTH, Richard |
|
From: Xavier B. <xav...@fr...> - 2016-05-04 08:40:46
|
Hi, Excepted in hwstamp_ctl.c I can find no trace of PTPv1 support in linuxptp. Does anyone know of a stack supporting this with hw timestamping support ? Regards, Xav |
|
From: Richard C. <ric...@gm...> - 2016-04-30 18:50:10
|
On Fri, Apr 29, 2016 at 02:50:42PM -0700, Ganesh Narayanan wrote: > Currently I am running PTP as below. Now if I need to add one more > interface (say eth1) to the running PTP instance, what is the best way to > do it ? Do I need to restart the PTP ? Yes. > I was wondering if there is a way > to pass the new interface to the currently running instance without > restarting the process. This isn't implemented, but I think it would be possible with some work. However, I doubt that such a feature is worth the effort. Thanks, Richard |
|
From: Ganesh N. <gan...@gm...> - 2016-04-29 21:50:49
|
Hi,
I am trying linuxPTP and I have a question on adding addition interfaces.
Someone please clarify.
Currently I am running PTP as below. Now if I need to add one more
interface (say eth1) to the running PTP instance, what is the best way to
do it ? Do I need to restart the PTP ? I was wondering if there is a way
to pass the new interface to the currently running instance without
restarting the process.
ptp4l -S -A -q -f /etc/linuxptp/ptp4l.conf -i eth0
I tried looking at archives first, but the archives are not accessible.
With pmc, I see only the below options for set.
{ "PRIORITY1", TLV_PRIORITY1, do_set_action },
{ "PRIORITY2", TLV_PRIORITY2, do_set_action },
{ "GRANDMASTER_SETTINGS_NP", TLV_GRANDMASTER_SETTINGS_NP, do_set_action },
{ "PORT_DATA_SET_NP", TLV_PORT_DATA_SET_NP, do_set_action },
Archives not accessible:
Error GMANE-03252: Something is wrong. Perhaps something didn't match a
group name. Perhaps something else.
http://news.gmane.org/gmane.comp.linux.ptp.user
http://news.gmane.org/gmane.comp.linux.ptp.devel
error 403 - Read access required
http://sourceforge.net/mailarchive/forum.php?forum_name=linuxptp-users
Thanks,
Ganesh
|
|
From: Richard C. <ric...@gm...> - 2016-04-25 21:16:28
|
On Mon, Apr 25, 2016 at 01:39:19PM -0700, Ganesh Narayanan wrote: > I am trying to access the email archives, but I get error 403 - Read access > required. > > http://sourceforge.net/mailarchive/forum.php?forum_name=linuxptp-users > > Can someone please help ? I myself can see the SF archives, but for some reason they are broken for some users. So, please use gmane for the archives. http://news.gmane.org/gmane.comp.linux.ptp.user http://news.gmane.org/gmane.comp.linux.ptp.devel Thanks, Richard |
27 messages has been excluded from this view by a project administrator.
