linuxptp-users Mailing List for linuxptp (Page 153)
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: Adrian K. <ad...@dr...> - 2013-05-16 10:45:34
|
On Wed, May 15, 2013 at 08:34:43PM +0000, Keller, Jacob E wrote: > The numbers you are seeing are... > > ptp4l[1821233.508]: Clock identifier per the PTP standard. > > master offset 93511: The calculated offset from master measured in > nanoseconds. > > s2: The state of the P/I servo, there are 3 states, 0, 1, 2 with the > following meanings. > > 0: initial state, servo is unlocked, meaning measurements being > calculated but not actually applying adjustment. > 1: second state: used when the clock will be jumped. > 2: third state: servo is locked to master, and is being adjusted > > adj +10006: The frequency adjustment measured in parts per billion > (might be parts per million for SW, I don't actually know for sure) > This is a measurement of percent-like adjustment in the frequency, so > in this case it means the frequency of the SW clock has been increased > by ten thousand parts per billion. This means for every 1 billion > seconds of nominal time, 10006 seconds in addition will have > accumulated. > > path delay 53481: The measurement in nanoseconds of the delay > between this node and the master node (or the peer if using peer > delay) How about copy&pasting this to README.org? I can propose a patch to the devel ML. While at it, I'd probably add an example section to ptp4l.8 showing gPTP.cfg. It's easier to see how a proper config file should look like than to work oneself through a paraphrased description of the config format. Just my €0.02 -- mail: ad...@th... http://adi.thur.de PGP/GPG: key via keyserver |
|
From: <Tim...@de...> - 2013-05-15 09:12:34
|
Please correct me if I'm wrong ... master offset 113817 : the offset time of the two ptp clocks in ns s0-2: the connection stage of ptp4l adj +12655: Here I'm not sure, because on my tests it always was called "freq". It should be the servo rate to adjust the time path delay 53184: the delay of your Ethernet connection But the values are pretty hight. Mine are about : ptp4l[71767.156]: master offset 11 s2 freq +123009 path delay 719 Are you using SW time stamping or HW time stamping? Keep in mind to use the phc2sys program to set the system time, if you want to use the syncronized time as system time. - Benny Von: Ledda William EXT [mailto:Wil...@it...] Gesendet: Mittwoch, 15. Mai 2013 09:29 An: lin...@li... Betreff: [Linuxptp-users] Output of ptp4l Hi all, I'm newbie user of linuxptp. I need some help to understand the output produced by ptp4l. ptp4l[1821211.588]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[1821211.592]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[1821212.510]: port 1: new foreign master 008063.fffe.db5e00-15 ptp4l[1821216.510]: selected best master clock 00a069.fffe.01c094 ptp4l[1821216.510]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[1821216.705]: port 1: minimum delay request interval 2^3 ptp4l[1821218.509]: master offset 171578 s0 adj +0 path delay 53481 ptp4l[1821219.509]: master offset 172021 s0 adj +0 path delay 53481 ptp4l[1821220.510]: master offset 174685 s0 adj +0 path delay 53481 ptp4l[1821221.509]: master offset 177810 s1 adj +0 path delay 53481 ptp4l[1821222.509]: master offset 753 s2 adj +76 path delay 53481 ptp4l[1821222.509]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[1821223.509]: master offset 17736 s2 adj +1792 path delay 53481 ptp4l[1821224.509]: master offset 17754 s2 adj +1812 path delay 53481 ptp4l[1821225.508]: master offset 38232 s2 adj +3898 path delay 53481 ptp4l[1821226.508]: master offset 47856 s2 adj +4908 path delay 53481 ptp4l[1821227.508]: master offset 57136 s2 adj +5893 path delay 53481 ptp4l[1821228.508]: master offset 67594 s2 adj +7006 path delay 53481 ptp4l[1821229.508]: master offset 75302 s2 adj +7853 path delay 53481 ptp4l[1821230.508]: master offset 71573 s2 adj +7551 path delay 53481 ptp4l[1821231.508]: master offset 77021 s2 adj +8173 path delay 53481 ptp4l[1821232.508]: master offset 90924 s2 adj +9654 path delay 53481 ptp4l[1821233.508]: master offset 93511 s2 adj +10006 path delay 53481 ptp4l[1821234.508]: master offset 92060 s2 adj +9953 path delay 53481 ptp4l[1821235.508]: master offset 93137 s2 adj +10154 path delay 53481 ptp4l[1821236.508]: master offset 102429 s2 adj +11186 path delay 53481 ptp4l[1821237.507]: master offset 109941 s2 adj +12047 path delay 53481 ptp4l[1821238.507]: master offset 106116 s2 adj +11771 path delay 53184 ptp4l[1821239.507]: master offset 113817 s2 adj +12655 path delay 53184 .... It is not clear to me how the master offset is expressed: Is it in ns? Could you explain the meaning of the different values? Thanks William |
|
From: Ledda W. E. <Wil...@it...> - 2013-05-15 07:49:35
|
Hi all, I'm newbie user of linuxptp. I need some help to understand the output produced by ptp4l. ptp4l[1821211.588]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[1821211.592]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[1821212.510]: port 1: new foreign master 008063.fffe.db5e00-15 ptp4l[1821216.510]: selected best master clock 00a069.fffe.01c094 ptp4l[1821216.510]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[1821216.705]: port 1: minimum delay request interval 2^3 ptp4l[1821218.509]: master offset 171578 s0 adj +0 path delay 53481 ptp4l[1821219.509]: master offset 172021 s0 adj +0 path delay 53481 ptp4l[1821220.510]: master offset 174685 s0 adj +0 path delay 53481 ptp4l[1821221.509]: master offset 177810 s1 adj +0 path delay 53481 ptp4l[1821222.509]: master offset 753 s2 adj +76 path delay 53481 ptp4l[1821222.509]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[1821223.509]: master offset 17736 s2 adj +1792 path delay 53481 ptp4l[1821224.509]: master offset 17754 s2 adj +1812 path delay 53481 ptp4l[1821225.508]: master offset 38232 s2 adj +3898 path delay 53481 ptp4l[1821226.508]: master offset 47856 s2 adj +4908 path delay 53481 ptp4l[1821227.508]: master offset 57136 s2 adj +5893 path delay 53481 ptp4l[1821228.508]: master offset 67594 s2 adj +7006 path delay 53481 ptp4l[1821229.508]: master offset 75302 s2 adj +7853 path delay 53481 ptp4l[1821230.508]: master offset 71573 s2 adj +7551 path delay 53481 ptp4l[1821231.508]: master offset 77021 s2 adj +8173 path delay 53481 ptp4l[1821232.508]: master offset 90924 s2 adj +9654 path delay 53481 ptp4l[1821233.508]: master offset 93511 s2 adj +10006 path delay 53481 ptp4l[1821234.508]: master offset 92060 s2 adj +9953 path delay 53481 ptp4l[1821235.508]: master offset 93137 s2 adj +10154 path delay 53481 ptp4l[1821236.508]: master offset 102429 s2 adj +11186 path delay 53481 ptp4l[1821237.507]: master offset 109941 s2 adj +12047 path delay 53481 ptp4l[1821238.507]: master offset 106116 s2 adj +11771 path delay 53184 ptp4l[1821239.507]: master offset 113817 s2 adj +12655 path delay 53184 .... It is not clear to me how the master offset is expressed: Is it in ns? Could you explain the meaning of the different values? Thanks William |
|
From: Keller, J. E <jac...@in...> - 2013-05-14 21:01:26
|
Hi Andrian! > -----Original Message----- > From: Adrian Knoth [mailto:ad...@dr...] > Sent: Tuesday, May 14, 2013 9:42 AM > To: lin...@li... > Subject: [Linuxptp-users] phc2sys doesn't adjust CLOCK_REALTIME > > Hi! > > First off, I have no clue whatsoever, absolutely zero PTP experience. > > Given two machines, I want to synchronise their CLOCK_REALTIME via > HW-stamped PTP. Both machines feature an Intel I210 card. > > >From ethtool -i: > driver: igb_avb > version: 4.1.2.1_AVB > > Kernel is 3.8.2 on both machines. > > > Machine 1: > # ptp4l -q -m -2 -i eth4 -H > [..] > ptp4l[882984.471]: driver changed our HWTSTAMP options > ptp4l[882984.471]: tx_type 1 not 1 > ptp4l[882984.471]: rx_filter 1 not 12 > ptp4l[882984.471]: port 1: FAULTY to LISTENING on FAULT_CLEARED > ptp4l[882985.441]: port 1: new foreign master a0369f.fffe.10cd74-1 > ptp4l[882989.441]: selected best master clock a0369f.fffe.10cd74 > ptp4l[882989.441]: port 1: LISTENING to GRAND_MASTER on > RS_GRAND_MASTER > > Also on this machine, I use phc2sys in opposite direction to sync the > GMC's PHC to CLOCK_REALTIME: > > # phc2sys -q -m -w -i eth4 -s CLOCK_REALTIME -c /dev/ptp0 > [..] > This isn't what you want to do here. This is tricky because while you set -s as CLOCK_REALTIME, the -i option also sets the master device as well, conflicting with your -s setting. You should avoid using the -i option if you intend to set the phc as the slave. I will look at patching phc2sys to fix this issue, as what I believe you are doing is setting the ptp0 clock to itself in this case (assuming eth4 links to /dev/ptp0, which I don't believe I see in your output so I am unsure). If /dev/ptp0 is the correct ptp device, then you should do # phc2sys -q -m -w -s CLOCK_REALTIME -c /dev/ptp0 phc2sys[883924.188]: phc offset 89 s2 freq -607443 delay 7652 > phc2sys[883925.189]: phc offset 23 s2 freq -607482 delay 7748 > phc2sys[883926.189]: phc offset -59 s2 freq -607557 delay 7764 > phc2sys[883927.189]: phc offset 38 s2 freq -607478 delay 7717 > > Despite the output, this doesn't really work: > > PHC: 1368546365.238242344 or Tue May 14 17:46:05 2013 > SYS: 1368546330.241092974 or Tue May 14 17:45:30 2013 > > However, I can use testptp -s (from KSRC/Documentation/ptp/) to set > the PHC > from sys. This more or less works (insufficient accuracy): > > PHC: 1368546556.276594970 or Tue May 14 17:49:16 2013 > SYS: 1368546556.279495482 or Tue May 14 17:49:16 2013 > > I then run phc2sys again: > # ./phc2sys -q -m -w -i eth4 -s CLOCK_REALTIME -c /dev/ptp0 > phc2sys[884512.128]: phc offset -35000006267 s0 freq +0 delay 7973 > phc2sys[884513.129]: phc offset -35000006220 s1 freq -607487 delay 7989 > phc2sys[884514.129]: phc offset -5506 s2 freq -612993 delay 7973 > phc2sys[884515.129]: phc offset 26 s2 freq -609113 delay 7973 > phc2sys[884516.130]: phc offset 1568 s2 freq -607563 delay 8053 > phc2sys[884517.130]: phc offset 1640 s2 freq -607021 delay 7876 > phc2sys[884518.130]: phc offset 1131 s2 freq -607038 delay 7893 > phc2sys[884519.130]: phc offset 671 s2 freq -607158 delay 7989 > phc2sys[884520.131]: phc offset 311 s2 freq -607317 delay 8069 > phc2sys[884521.131]: phc offset 165 s2 freq -607370 delay 7989 > phc2sys[884522.131]: phc offset -62 s2 freq -607547 delay 7989 > phc2sys[884523.131]: phc offset 87 s2 freq -607417 delay 7989 > phc2sys[884524.131]: phc offset -83 s2 freq -607561 delay 7060 > phc2sys[884525.132]: phc offset 41 s2 freq -607462 delay 8005 > > And the clocks are off again: > > PHC: 1368546656.953321340 or Tue May 14 17:50:56 2013 > SYS: 1368546621.956175748 or Tue May 14 17:50:21 2013 > Again, I believe you aren't using the correct /dev/ptpX device (as each port gets its own /dev/ptpX device you need to ensure you used the right one), and you are infact overriding the command line option for -I and -s are incompatible. I think phc2sys needs to be fixed to enable selecting by Ethernet device. I'm unsure how to do this correctly though. I will take a look. > > Similar story on machine 2. The PHC is close to the master's PHC: > > Machine 2: > # ptp4l -i eth2 -m -2 -H > [..] > ptp4l[885426.731]: master offset -74 s2 freq -612308 path delay 2246 > ptp4l[885427.731]: master offset 41 s2 freq -612215 path delay 2240 > ptp4l[885428.731]: master offset 58 s2 freq -612186 path delay 2238 > ptp4l[885429.731]: master offset 18 s2 freq -612209 path delay 2238 > ptp4l[885430.730]: master offset -99 s2 freq -612320 path delay 2240 > ptp4l[885431.730]: master offset -79 s2 freq -612330 path delay 2239 > ptp4l[885432.730]: master offset 20 s2 freq -612255 path delay 2231 > > > testptp -g looks good, however, phc2sys cannot set CLOCK_REALTIME to > something that at least vaguely resembles the PHC: > Here you will see an issue with setting CLOCK_REALTIME. > # ./phc2sys -q -m -i eth2 -c CLOCK_REALTIME > phc2sys[885535.273]: sys offset 188865243846 s0 freq +0 delay 8507 > phc2sys[885536.273]: sys offset 188865166303 s1 freq -500000 delay 8033 > phc2sys[885537.273]: sys offset -76877 s2 freq -500000 delay 8416 > phc2sys[885538.273]: sys offset -154510 s2 freq -500000 delay 8039 > phc2sys[885539.274]: sys offset -231745 s2 freq -500000 delay 8076 > phc2sys[885540.274]: sys offset -309371 s2 freq -500000 delay 8004 > phc2sys[885541.274]: sys offset -387673 s2 freq -500000 delay 7304 > phc2sys[885542.274]: sys offset -464191 s2 freq -500000 delay 8504 > [..] > phc2sys[885574.279]: sys offset -2937698 s2 freq -500000 delay 6939 > phc2sys[885575.279]: sys offset -3014393 s2 freq -500000 delay 8079 See here where freq is set to -500000. This means that you are correcting 500,000 parts per billion every cycle. The issue is that this is a really small correction and will take a while to stabilize. This is due to the fact that CLOCK_REALTIME is not able to be adjusted very fast. You should see this converge if you left it running. It will take a while to converge because it is doing frequency slewing as fast as it can. Once the freq value is no longer pegged to the max value you should be much closer to correct, but I can't say how long that would take. > > > > But the resulting accuracy isn't exactly overwhelming: > > PHC: 1368549596.767994860 or Tue May 14 18:39:56 2013 > SYS: 1368549596.627707358 or Tue May 14 18:39:56 2013 > > > Am I doing it wrong? > > > > TIA > > -- > mail: ad...@th... http://adi.thur.de PGP/GPG: key via > keyserver > > Your main issue is that on the grandmaster side you were not correctly setting the phc2sys options. This, I believe, is partly due to how phc2sys selects slave and master clocks, and I will look at patching the program to be easier to use in this case. Hope this helps! Thanks! - Jake |
|
From: Adrian K. <ad...@dr...> - 2013-05-14 16:42:29
|
Hi! First off, I have no clue whatsoever, absolutely zero PTP experience. Given two machines, I want to synchronise their CLOCK_REALTIME via HW-stamped PTP. Both machines feature an Intel I210 card. >From ethtool -i: driver: igb_avb version: 4.1.2.1_AVB Kernel is 3.8.2 on both machines. Machine 1: # ptp4l -q -m -2 -i eth4 -H [..] ptp4l[882984.471]: driver changed our HWTSTAMP options ptp4l[882984.471]: tx_type 1 not 1 ptp4l[882984.471]: rx_filter 1 not 12 ptp4l[882984.471]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[882985.441]: port 1: new foreign master a0369f.fffe.10cd74-1 ptp4l[882989.441]: selected best master clock a0369f.fffe.10cd74 ptp4l[882989.441]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER Also on this machine, I use phc2sys in opposite direction to sync the GMC's PHC to CLOCK_REALTIME: # phc2sys -q -m -w -i eth4 -s CLOCK_REALTIME -c /dev/ptp0 [..] phc2sys[883924.188]: phc offset 89 s2 freq -607443 delay 7652 phc2sys[883925.189]: phc offset 23 s2 freq -607482 delay 7748 phc2sys[883926.189]: phc offset -59 s2 freq -607557 delay 7764 phc2sys[883927.189]: phc offset 38 s2 freq -607478 delay 7717 Despite the output, this doesn't really work: PHC: 1368546365.238242344 or Tue May 14 17:46:05 2013 SYS: 1368546330.241092974 or Tue May 14 17:45:30 2013 However, I can use testptp -s (from KSRC/Documentation/ptp/) to set the PHC from sys. This more or less works (insufficient accuracy): PHC: 1368546556.276594970 or Tue May 14 17:49:16 2013 SYS: 1368546556.279495482 or Tue May 14 17:49:16 2013 I then run phc2sys again: # ./phc2sys -q -m -w -i eth4 -s CLOCK_REALTIME -c /dev/ptp0 phc2sys[884512.128]: phc offset -35000006267 s0 freq +0 delay 7973 phc2sys[884513.129]: phc offset -35000006220 s1 freq -607487 delay 7989 phc2sys[884514.129]: phc offset -5506 s2 freq -612993 delay 7973 phc2sys[884515.129]: phc offset 26 s2 freq -609113 delay 7973 phc2sys[884516.130]: phc offset 1568 s2 freq -607563 delay 8053 phc2sys[884517.130]: phc offset 1640 s2 freq -607021 delay 7876 phc2sys[884518.130]: phc offset 1131 s2 freq -607038 delay 7893 phc2sys[884519.130]: phc offset 671 s2 freq -607158 delay 7989 phc2sys[884520.131]: phc offset 311 s2 freq -607317 delay 8069 phc2sys[884521.131]: phc offset 165 s2 freq -607370 delay 7989 phc2sys[884522.131]: phc offset -62 s2 freq -607547 delay 7989 phc2sys[884523.131]: phc offset 87 s2 freq -607417 delay 7989 phc2sys[884524.131]: phc offset -83 s2 freq -607561 delay 7060 phc2sys[884525.132]: phc offset 41 s2 freq -607462 delay 8005 And the clocks are off again: PHC: 1368546656.953321340 or Tue May 14 17:50:56 2013 SYS: 1368546621.956175748 or Tue May 14 17:50:21 2013 Similar story on machine 2. The PHC is close to the master's PHC: Machine 2: # ptp4l -i eth2 -m -2 -H [..] ptp4l[885426.731]: master offset -74 s2 freq -612308 path delay 2246 ptp4l[885427.731]: master offset 41 s2 freq -612215 path delay 2240 ptp4l[885428.731]: master offset 58 s2 freq -612186 path delay 2238 ptp4l[885429.731]: master offset 18 s2 freq -612209 path delay 2238 ptp4l[885430.730]: master offset -99 s2 freq -612320 path delay 2240 ptp4l[885431.730]: master offset -79 s2 freq -612330 path delay 2239 ptp4l[885432.730]: master offset 20 s2 freq -612255 path delay 2231 testptp -g looks good, however, phc2sys cannot set CLOCK_REALTIME to something that at least vaguely resembles the PHC: # ./phc2sys -q -m -i eth2 -c CLOCK_REALTIME phc2sys[885535.273]: sys offset 188865243846 s0 freq +0 delay 8507 phc2sys[885536.273]: sys offset 188865166303 s1 freq -500000 delay 8033 phc2sys[885537.273]: sys offset -76877 s2 freq -500000 delay 8416 phc2sys[885538.273]: sys offset -154510 s2 freq -500000 delay 8039 phc2sys[885539.274]: sys offset -231745 s2 freq -500000 delay 8076 phc2sys[885540.274]: sys offset -309371 s2 freq -500000 delay 8004 phc2sys[885541.274]: sys offset -387673 s2 freq -500000 delay 7304 phc2sys[885542.274]: sys offset -464191 s2 freq -500000 delay 8504 [..] phc2sys[885574.279]: sys offset -2937698 s2 freq -500000 delay 6939 phc2sys[885575.279]: sys offset -3014393 s2 freq -500000 delay 8079 But the resulting accuracy isn't exactly overwhelming: PHC: 1368549596.767994860 or Tue May 14 18:39:56 2013 SYS: 1368549596.627707358 or Tue May 14 18:39:56 2013 Am I doing it wrong? TIA -- mail: ad...@th... http://adi.thur.de PGP/GPG: key via keyserver |
|
From: Richard C. <ric...@gm...> - 2013-04-27 16:03:18
|
On Tue, Apr 23, 2013 at 08:16:22AM -0400, Chris LaRocque wrote: > > What would really be convenient is if I can get the tigger input to start > one of the fiper which would then toggle an alarm pin in one of two modes: > oneshot or periodic at an arbitrary interval; without interupting the > processor. I need time stamping of events occuring at rates of 1 kHz or > greater. I am not too sure what you meant, but I think the external triggers (time stamping external signals) should be working fine on your board. The external time stamps are held in a buffer of size 128, see drivers/ptp/ptp_private.h. If your application cannot read out all of the 1+ kHz time stamps on time, then you can increase the hard coded buffer size. As far as the fipers go, I think you could fairly easily add an ioctl to turn them on and off again (or abuse the existing ptp ioctls). However, the fipers are always in phase with the clock, and the interval must be an exactly divide 1 Hz (ie integer Hz values only). It might in fact be possible to program the fipers for arbitrary periods and phases, but I never figured out how to do it. It was hard enough getting the 1 Hz and 10 kHz signals working. Freescale's documents are a bit weak and their tech support is even worse, in my experience. HTH, Richard |
|
From: Chris L. <cl...@gm...> - 2013-04-23 12:16:34
|
On Tue, Apr 23, 2013 at 2:00 AM, Richard Cochran <ric...@gm...>wrote: > On Mon, Apr 22, 2013 at 05:18:30PM -0400, Chris LaRocque wrote: > > > > Could one of you kind folks point me toward the files where the gianfar > > timer functionality could or would be implemented? > > - kernel/time/posix-clock.c > - drivers/net/ethernet/freescale/gianfar_ptp.c > > > Was / is there an example or two which would show me the light? > > You can see the original version at > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082433.html > > but this was before the posix clock idea came along. > > > I need to know the magnitude of the task before I take this info to > > management. > > Maybe you can just use normal timers using CLOCK_REALTIME or > CLOCK_MONOTONIC? > > This what I recommend. PHC timer support has been designed into the > API, but it has not been implemented. There are two reasons why it is > still missing. > > First, adding the logic would be a non-trivial exercise (see how the > hrtimer stuff works, to get an idea). > > Second, it is doubtful whether having direct PHC timers would perform > much better than just synchronizing the system clock to the PHC, and > using normal timers. > > I did a whole paper on that second point, and I am convinced that it > just isn't worth the effort to implement PHC timers. However, I would > support the addition of the code, if you or someone else wants to > develop it. > > HTH, > Richard > Thank You I have already looked into the hrtimer source and also found the discussions you had back in 2010 about the API. Of course I have also read your paper. If we were just syncing the clocks I'd be done. Unfortunately, I had counted on the alarm output to drive data acquisition within our distributed system. I am now investigating timers and gpio to accomplish the same goal; as long as the triggers will generate and queue the timestamps the project will succeed. I'm just not as far along as I had believed. Your comment about multiplexing of the pin function is apropos. I should have recognized something was amiss when TSEC_TMR_GCLK was not present on the 1588 header. I am looking into where the changes to the config register should be accomplished. What would really be convenient is if I can get the tigger input to start one of the fiper which would then toggle an alarm pin in one of two modes: oneshot or periodic at an arbitrary interval; without interupting the processor. I need time stamping of events occuring at rates of 1 kHz or greater. Pointers appreciated. Regards Chris |
|
From: Richard C. <ric...@gm...> - 2013-04-23 10:15:40
|
On Tue, Apr 23, 2013 at 10:04:54AM +0200, Mozhdeh Kamel wrote: > > > According to your previous posts, P2020 is a machine that have a shared > clock for it's ports. So, how you measured master/slave offset between > different ports of it? Didn't they had the same clock? I meant the offset to the remote grand master clock. Thanks, Richard |
|
From: Mozhdeh K. <kam...@gm...> - 2013-04-23 08:05:24
|
> I don't have a P2020, but I used to work with one in a PTP test > lab. There we measured the master/slave offset using a PPS signal, > and IIRC, the P2020 as slave synchonized to within 100 nanoseconds > of the master. > > HTH, > Richard > > According to your previous posts, P2020 is a machine that have a shared clock for it's ports. So, how you measured master/slave offset between different ports of it? Didn't they had the same clock? -- Mozhdeh |
|
From: Richard C. <ric...@gm...> - 2013-04-23 06:00:43
|
On Mon, Apr 22, 2013 at 05:18:30PM -0400, Chris LaRocque wrote: > > Could one of you kind folks point me toward the files where the gianfar > timer functionality could or would be implemented? - kernel/time/posix-clock.c - drivers/net/ethernet/freescale/gianfar_ptp.c > Was / is there an example or two which would show me the light? You can see the original version at https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082433.html but this was before the posix clock idea came along. > I need to know the magnitude of the task before I take this info to > management. Maybe you can just use normal timers using CLOCK_REALTIME or CLOCK_MONOTONIC? This what I recommend. PHC timer support has been designed into the API, but it has not been implemented. There are two reasons why it is still missing. First, adding the logic would be a non-trivial exercise (see how the hrtimer stuff works, to get an idea). Second, it is doubtful whether having direct PHC timers would perform much better than just synchronizing the system clock to the PHC, and using normal timers. I did a whole paper on that second point, and I am convinced that it just isn't worth the effort to implement PHC timers. However, I would support the addition of the code, if you or someone else wants to develop it. HTH, Richard |
|
From: Chris L. <cl...@gm...> - 2013-04-22 21:18:37
|
On Mon, Apr 22, 2013 at 1:47 PM, Richard Cochran <ric...@gm...>wrote: > On Mon, Apr 22, 2013 at 07:35:40PM +0200, Richard Cochran wrote: > > On Mon, Apr 22, 2013 at 12:36:03PM -0400, Chris LaRocque wrote: > > > > > > However, I get an error when I try to set a oneshot or periodic alarm. > > > "timer_create: Operation not supported". > > > > The driver says it has one alarm, but that is a bug. An early version > > of the patch series did implement one alarm, but that code was > > dropped. So the error message is the expected response. Although the > > API allows timers, none of the drivers have that implemented. > > > > I will submit a patch to fix the wrong capability result. > > May I add your "Reported-by:" tag to the patch, to give you credit in > the Linux commit history? > > Thanks, > Richard > Hello Could one of you kind folks point me toward the files where the gianfar timer functionality could or would be implemented? Was / is there an example or two which would show me the light? I need to know the magnitude of the task before I take this info to management. Thank You Chris |
|
From: Richard C. <ric...@gm...> - 2013-04-22 17:47:44
|
On Mon, Apr 22, 2013 at 07:35:40PM +0200, Richard Cochran wrote: > On Mon, Apr 22, 2013 at 12:36:03PM -0400, Chris LaRocque wrote: > > > > However, I get an error when I try to set a oneshot or periodic alarm. > > "timer_create: Operation not supported". > > The driver says it has one alarm, but that is a bug. An early version > of the patch series did implement one alarm, but that code was > dropped. So the error message is the expected response. Although the > API allows timers, none of the drivers have that implemented. > > I will submit a patch to fix the wrong capability result. May I add your "Reported-by:" tag to the patch, to give you credit in the Linux commit history? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-04-22 17:36:01
|
On Mon, Apr 22, 2013 at 12:36:03PM -0400, Chris LaRocque wrote: > > I am using buildroot 2013.02 and have a working system. I have been trying > to use the testptp application to verify operation of the 1588 pps, alarm, > and trigger interface. The code compiles and executes. I get the ptp > capabilities listing using "-c" and it is consistent with the data in > /sys/class/ptp/ptp0; alarm=1, external trigger=2, pps = 1, periodic=0. > > However, I get an error when I try to set a oneshot or periodic alarm. > "timer_create: Operation not supported". The driver says it has one alarm, but that is a bug. An early version of the patch series did implement one alarm, but that code was dropped. So the error message is the expected response. Although the API allows timers, none of the drivers have that implemented. I will submit a patch to fix the wrong capability result. > Further, when I enable pps output, > "echo '0 1' > /sys/class/ptp/ptp0/pps_enable", none of the pps pins toggle > though no error is indicated. The 'PPS' here is an interrupt from the ETSEC to the CPU. This provides a PPS event just like an external GPS would, for synchronizing the Linux system time to the PTP time. However, you should see a 1 PPS and a 10000 PPS on the fiper output pins. Check your datasheet to see if those pins are multiplexed. You can change the second fiper frequency (but not phase) using the "fsl,tmr-fiper2" device tree property. (I never worked with your board, but I did once try the similar MPC8313, so there might be some gotchas.) An alternative way to measure the synchronization is to feed an external PPS (like from the master clock) into the external time stamp inputs. > As far as I can tell this should work. The one other piece of information I > can offer is that the DAC which drives the VCXO supplyingTSEC_TMR_CLK is > not populated so no external clock is supplied to the interface. This > shouldn't matter as TMRCK is available internally. Right. Please check that the clock settings are correct in the device tree file for your SoC. > What am I missing? Sorry about the confusion. Hope this is clear to you now. Thanks, Richard |
|
From: Chris L. <cl...@gm...> - 2013-04-22 16:36:10
|
Hello I am using buildroot 2013.02 and have a working system. I have been trying to use the testptp application to verify operation of the 1588 pps, alarm, and trigger interface. The code compiles and executes. I get the ptp capabilities listing using "-c" and it is consistent with the data in /sys/class/ptp/ptp0; alarm=1, external trigger=2, pps = 1, periodic=0. However, I get an error when I try to set a oneshot or periodic alarm. "timer_create: Operation not supported". Further, when I enable pps output, "echo '0 1' > /sys/class/ptp/ptp0/pps_enable", none of the pps pins toggle though no error is indicated. Kernel 3.7.1 uclibc 0.9.33.2 with NPTL As far as I can tell this should work. The one other piece of information I can offer is that the DAC which drives the VCXO supplyingTSEC_TMR_CLK is not populated so no external clock is supplied to the interface. This shouldn't matter as TMRCK is available internally. What am I missing? Regards Chris LaRocque Virginia, USA |
|
From: Richard C. <ric...@gm...> - 2013-04-22 13:19:31
|
On Mon, Apr 22, 2013 at 12:26:08PM +0200, Mozhdeh Kamel wrote: > I think I found the answer: > > There is no hardware timestamping in VSC7385 L2 switch. Time stamping in > P2020 has done in the MAC before the FIFO, so it's still in hardware. Yes, the P2020 does MAC time stamping on all three ports. The switch in front of the one port is not a PTP switch, and so it will degrade the PTP performance slightly. > So, is this accuracy enough? or maybe it is enough for testing? I don't have a P2020, but I used to work with one in a PTP test lab. There we measured the master/slave offset using a PPS signal, and IIRC, the P2020 as slave synchonized to within 100 nanoseconds of the master. HTH, Richard |
|
From: Mozhdeh K. <kam...@gm...> - 2013-04-22 10:26:34
|
I think I found the answer: There is no hardware timestamping in VSC7385 L2 switch. Time stamping in P2020 has done in the MAC before the FIFO, so it's still in hardware. So, is this accuracy enough? or maybe it is enough for testing? -- *Mozhdeh * On Mon, Apr 22, 2013 at 11:20 AM, Mozhdeh Kamel <kam...@gm...>wrote: > > Hi, > > I thought it is better to open a new discussion for this topic :) > > I am a bit getting confusion about accuracy of P2020 reference board. I > could not find any timestamping accuracy in its datasheet. Ii seems it uses > > — 10/100/1000 BaseT Ethernet ports: > – eTSEC1, RGMII: four 10/100/1000 ports using Vitesse™ VSC7385 L2 switch > – eTSEC2, SGMII: one 10/100/1000 port using Vitesse™ VSC8221 > – eTSEC3, RGMII: one 10/100/1000 port Vitesse™ VSC8641 > > > I know VSC8221 and VSC8641, doesn't have hardware timestamping. But how > about VSC7385 L2 switch? I could not find in its datasheet, but maybe I > made a mistake!! > > If none of these ports doesn't have hardware timestamping, how P2020 can > be accurate enough to even consider as a boundary clock? > > -- > *Mozhdeh * > |
|
From: Mozhdeh K. <kam...@gm...> - 2013-04-22 09:21:11
|
Hi, I thought it is better to open a new discussion for this topic :) I am a bit getting confusion about accuracy of P2020 reference board. I could not find any timestamping accuracy in its datasheet. Ii seems it uses — 10/100/1000 BaseT Ethernet ports: – eTSEC1, RGMII: four 10/100/1000 ports using Vitesse™ VSC7385 L2 switch – eTSEC2, SGMII: one 10/100/1000 port using Vitesse™ VSC8221 – eTSEC3, RGMII: one 10/100/1000 port Vitesse™ VSC8641 I know VSC8221 and VSC8641, doesn't have hardware timestamping. But how about VSC7385 L2 switch? I could not find in its datasheet, but maybe I made a mistake!! If none of these ports doesn't have hardware timestamping, how P2020 can be accurate enough to even consider as a boundary clock? -- *Mozhdeh * |
|
From: Mozhdeh K. <kam...@gm...> - 2013-04-22 07:29:10
|
I could not find time stamping accuracy of Freescale P2020, do you know the exact accuracy of it? BR, Mozhdeh On Thu, Mar 21, 2013 at 7:58 PM, Richard Cochran <ric...@gm...>wrote: > On Thu, Mar 21, 2013 at 01:28:04PM +0100, Mozhdeh Kamel wrote: > > > > Can anyone help me with the list of boundary clocks?I wonder whether > > boundary clocks are simple switch with hardware time stamping? what > special > > characteristics it must have? > > A boundary clock (BC) is more like a router than a switch. It must > intercept incoming PTP messages, and it does not forward them (except > for management messages). > > Although linuxptp is designed to work as a BC, I don't know of any > that are using linuxptp. If you want to try the code out, then you > need a computer with two or more ports, all of which share a common > PTP Hardware Clock (PHC). I can think of two ways to do this. > > 1. Use a computer whose ports all support SW time stamping. This will > not perform very well, but at least you can see how it works. > > 2. Get a computer with true HW time stamping support. Note that you > cannot just use a box with multiple PCI cards, for example. The > ports must all share *one* clock. > > Some ready made system on chips have this, like the Freescale P2020, > the MPC8306, and the MPC8309. If you have one of these kits, then > the ptp4l program should work fine. > > Another possibility is to use the DP83640 PHY, but you must make > sure to connect the GPIOs in your design so that the PHYs can > synchronize each other. > > HTH, > Richard > -- *Mozhdeh * |
|
From: Mozhdeh K. <kam...@gm...> - 2013-04-21 15:58:33
|
Thank you so much! I am not insisting on one brand, so if you know anything rather than Intel that has a fair price, don't hesitate to introduce it to me. BR, Mozhdeh On Fri, Apr 19, 2013 at 10:14 PM, Keller, Jacob E <jac...@in...>wrote: > > -----Original Message----- > > From: Richard Cochran [mailto:ric...@gm...] > > Sent: Friday, April 19, 2013 8:43 AM > > To: Mozhdeh Kamel > > Cc: lin...@li... > > Subject: Re: [Linuxptp-users] List of Boundary clocks > > > > On Thu, Apr 18, 2013 at 07:00:50PM +0200, Mozhdeh Kamel wrote: > > > Thank you so much for your answers. > > > > > > So, by having a real BC, and those NICS (such as Intel's 82576 chip or > > Intel > > > 82574 ) with linuxptp can I emulate the network? > > > > BTW, if you are going with an Intel card, I can highly recommend the > > i210 card. It is inexpensive and has some nice features, including a 6 > > pin header for the PPS signals. > > > > Thanks, > > Richard > > > > This is the same device I would recommend as well. > > - Jake > > -- *Mozhdeh * |
|
From: Richard C. <ric...@gm...> - 2013-04-20 19:17:51
|
Dear linuxptp users and developers,
The first release was in December and the second in February, and
I have decided to be very modern and agile in starting a two month
release cycle. If the contributions keep coming in at the present
rate, then I think we will be able to sustain this rate.
Today I pushed out a v1.2 tag and released a tar ball on SF. Many
thanks to the contributors, Delio, Geoff, Jacob, Jiri, Ken, Libor,
and Miroslav. The short log is appended, below.
Enjoy,
Richard
Delio Brignoli (7):
Implement neighborPropDelayThresh check in port_capable()
Free peer delay responses and followup messages when sending a new peer delay request
Log changes to asCapable
Explicitly detect and handle changes of the peer's port id by resetting asCapable and the port's nrate
Rename set_tmo() to set_tmo_log(), add set_tmo_lin()
Add support for multiple fault types
Add support for FT_BAD_PEER_NETWORK
Geoff Salmon (5):
support TLVs with flexible size
adds CLOCK_DESCRIPTION struct
support GET CLOCK_DESCRIPTION and USER_DESCRIPTION mgmt messages
pmc: get CLOCK_DESCRIPTION and USER_DESCRIPTION
pmc: avoid printing invalid data from empty TLVs
Jacob Keller (1):
ptp4l: Use poll() instead of a try-again loop
Jiri Benc (2):
hwstamp_ctl: explain ERANGE error better
phc2sys: enable PPS output from PHC
Ken ICHIKAWA (2):
Enable LOG_MIN_PDELAY_REQ_INTERVAL management request
phc2sys: add help messages for -l, -m and -q
Libor Pechacek (1):
Distinguish between ignored and malformed packets
Miroslav Lichvar (17):
phc2sys: Update sync offset periodically with -w.
Move clock_adjtime wrapping to clockadj.c.
phc2sys: Handle leap seconds.
Add missing conversions from tmv_t to nanoseconds.
ptp4l: Handle leap seconds.
Add options to not apply leap seconds in kernel.
ptp4l: Set clock frequency on start.
ptp4l: Read system clock maximum frequency adjustment.
Fix compiler warnings with -O2.
phc2sys: Read maximum frequency adjustment.
phc2sys: Don't try PTP_SYS_OFFSET with system clock as source.
phc2sys: Use phc_open().
phc2sys: Add option to set domain number.
clockadj: Remove clkid parameter from set_leap function.
Let kernel synchronize RTC to system clock.
Add option to set maximum frequency adjustment.
Replace spaces with tabs in configs.
Richard Cochran (23):
Add an all purpose, single byte management TLV.
Add support for the priority1 management request.
Add support for the priority2 management request.
Add support for the domain management request.
Add support for the slave_only management request.
Add support for the clock_accuracy management request.
Add support for the traceability management request.
Add support for the timescale management request.
Add support for the log announce interval management request.
Add support for the announce receipt timeout management request.
Add support for the log sync interval management request.
Add support for the version number management request.
Add support for the delay mechanism management request.
Add support for the log peer delay interval management request.
Align the message buffer to eight bytes.
Merge branch 'mlichvar_leap'
Add a clock method to update the time properties data set.
Let a slaved port update the time properties on every announce message.
Apply utc offset correction even when free running.
clockadj: make Doxygen comment by using two stars.
clockadj: remove useless clockid parameter.
Simplify tests on configuration ranges.
Version 1.2
|
|
From: Keller, J. E <jac...@in...> - 2013-04-19 20:14:13
|
> -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Friday, April 19, 2013 8:43 AM > To: Mozhdeh Kamel > Cc: lin...@li... > Subject: Re: [Linuxptp-users] List of Boundary clocks > > On Thu, Apr 18, 2013 at 07:00:50PM +0200, Mozhdeh Kamel wrote: > > Thank you so much for your answers. > > > > So, by having a real BC, and those NICS (such as Intel's 82576 chip or > Intel > > 82574 ) with linuxptp can I emulate the network? > > BTW, if you are going with an Intel card, I can highly recommend the > i210 card. It is inexpensive and has some nice features, including a 6 > pin header for the PPS signals. > > Thanks, > Richard > This is the same device I would recommend as well. - Jake |
|
From: Richard C. <ric...@gm...> - 2013-04-19 15:43:32
|
On Thu, Apr 18, 2013 at 07:00:50PM +0200, Mozhdeh Kamel wrote: > Thank you so much for your answers. > > So, by having a real BC, and those NICS (such as Intel's 82576 chip or Intel > 82574 ) with linuxptp can I emulate the network? BTW, if you are going with an Intel card, I can highly recommend the i210 card. It is inexpensive and has some nice features, including a 6 pin header for the PPS signals. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-04-19 05:42:06
|
On Thu, Apr 18, 2013 at 07:00:50PM +0200, Mozhdeh Kamel wrote: > Thank you so much for your answers. > > So, by having a real BC, and those NICS (such as Intel's 82576 chip or Intel > 82574 ) with linuxptp can I emulate the network? I am not sure how well you can "emulate the network", but a commercial BC plus Ordinary Clocks using a PHC running linuxptp should work fine. > It is written in linuxptp readme that it implements the boundary clock, is > it means by having a real BC and connect it to the linux which has > linuxptp, it will recognize it and can be a slave for it? No, it means that linuxptp itself can be a boundary clock. However, as I described before, you need a special hardware setup in order to implement a BC. HTH, Richard |
|
From: Mozhdeh K. <kam...@gm...> - 2013-04-18 17:01:18
|
Thank you so much for your answers. So, by having a real BC, and those NICS (such as Intel's 82576 chip or Intel 82574 ) with linuxptp can I emulate the network? It is written in linuxptp readme that it implements the boundary clock, is it means by having a real BC and connect it to the linux which has linuxptp, it will recognize it and can be a slave for it? Mozhdeh On Mon, Apr 15, 2013 at 6:17 PM, Richard Cochran <ric...@gm...>wrote: > On Sun, Apr 14, 2013 at 04:33:36PM +0200, Mozhdeh Kamel wrote: > > I am totally getting confused regarding the hardware you introduced me. > As > > what I found, these are reference design board.. I confused how I can use > > those. > > Your question was... > > On Sun, Apr 14, 2013 at 02:35:11PM +0200, Mozhdeh Kamel wrote: > > Can you please tell me the list of hardware which support both HW > > timestamps and boundary clocks? > > and the answer is that, as far as I know, only the Freescale boards > will work "out of the box" as a BC, with the Linux kernel and the > linuxptp stack. For example, the P2020RBD has three Ethernet ports. > It is a complete embedded computer, and so you could run ptp4l on the > three ports as a BC. > > > I think you have read my scenario for testing IEEE1588 (bu using virtual > > machines and NIC). Before that, I thought I can have a proper network > > interface card that support hardware timestamps and use linuxptp .. > then I > > can have boundary clock and ordinary clock and etc .. Is it wrong? But > with > > what you introduce.. I don't know how I can use it. > > The important point is that a BC must have _two_or_more_ ports. > Just having one PCI card with HW time stamps is not enough. The BC > must have multiple ports all sharing the same clock. > > If I understood your project idea, you are interested in the effects > of using PTP over BCs in a WAN, and you want to simulate different > kinds of network delay and jitter. In this case, I would recommend > just using a commercial BC. Getting you own home made BC working is a > whole project in itself. > > HTH, > Richard > |
|
From: Richard C. <ric...@gm...> - 2013-04-17 07:36:40
|
On Wed, Apr 17, 2013 at 11:25:40AM +0530, Akhil Nair wrote: > > Ok. Is there any way to configure TC on above mentioned multi-homed, > general purpose computer running with linux as a Transparent Clock if > the performance is not a main concern ? Well, you cannot simply configure it. You would have to develop this. But it can be done, I think. Richard |
27 messages has been excluded from this view by a project administrator.
