Re: [Linuxptp-users] phc2sys doesn't adjust CLOCK_REALTIME
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
Re: [Linuxptp-users] phc2sys doesn't adjust CLOCK_REALTIME
|
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 |
