Hi, On Mon, 2015-02-23 at 13:48 -0800, Gary E. Miller wrote: > Yo Jacob E! > > On Mon, 23 Feb 2015 21:09:01 +0000 > "Keller, Jacob E" <jacob.e.kel...@intel.com> wrote: > > > > Ouch... But I guess pure theory until a WiFi driver has real > > > support. > > > > > > > NTP and PTP are generally considered solutions to different but > > related problems, so this shouldn't really be an issue. > > As a gpsd maintainer and longtime chronyd/ntpd user I 100% disagree! > > Not having chronyd or ntpd in the loop is a total non-starter for me. >
I think I was mis-leading in my original comment here. I meant to say that accuracy of PTP vs NTP over WiFi could very well be different simply because they are very different algorithms with somewhat related but differing goals. I did not mean to say that a full solution would not use ntpd or chronyd or similar. > > > Odd, so automatic configuration not so automatic. I told ptp4l to > > > use ntpshm, that should be passed along. > > > > > > > ptp4l in hardware timestamp mode controls a hardware clock, which is > > completely unrelated to the system time clock. > > Understood. > > > Then, phc2sys controls > > the system clock based on the hardware clock which is set by ptp4l > > Gack, maybe that is one way, but not a good way. Certainly not the > only way. > > Since ptp4l can control the ntpshm in software timestamping mode why > can it not do so in hardware timestamping mode? Does ptp4l in hardware > mode ignore ntpsm in hardware mode, or does it continue to post parallel > software mode timing? > This is a complex problem. Hardware timestamping is done by varying hardware at the MAC (or PHY) level. Each hardware has its own internal clock to do this. These clocks are in *no* way driven by or in sync with the kernel clocks. Thus, the ptp kernel core exposes these each as their own clock device /dev/ptpX ptp4l in hardware mode completely ignores anything related to the software kernel clock world. This is because hardware NICs have their own internal clocks for doing hardware timestamping. Thus all timestamps are relative to the clock on the MAC, not to any clock on the motherboard. There have been attempts in the past for hardware to "sync" to the kernel clock but these were almost all faulty for various reasons including that they can't run a full servo in the kernel. There really doesn't make any sense for ptp4l to attempt to relate them to the software kernel clock at all. Thus, ptp4l will drive the ptp hardware clock from PTP on the network. Then a separate program (phc2sys or other) drives the software->hardware sync. *however* when in software timestamp mode the origin of the timestamps *is* the kernel clock, so thus we drive the kernel timer from ptp4l directly. In hardware mode we are not driving the clock directly but only indirectly. I hope this makes sense? > > This is sort of the flow. > > > > network -> ptp4l -> NIC hardware clock -> phc2sys -> system clock > > So how do I get ntpshm in there? > I assume you tell phc2sys to use ntpshm? > And not valid for a local PPS based PTP master, maybe mmore like: > > PPS -> ntpd -> local sysclock -> ptp4l -> NIC hardware clock -> phc2sys -> > ntpshm > > And it has to be a loop, so when PPS is lost that host can feed the hardware > clock back into ntpd. > > > Telling ptp4l to use the ntpshm doesn't work unless ptp4l is in > > software mode because ptp4l doesn't control teh software clock in > > hardware timestamp mode. > > Weird. Why are not ptp4l and phc2sys one program? They are certainly > deeply intertwined. And ptp4l in software mode already does most of what > phc2sys does in hardware mode. I'll leave Richard and others to answer this question, though I suspect because ptp4l controls only the one clock which is handling timestamping. It just happens that in software mode this is the kernel clock. > > > > kong ~ # phc2sys -a -r -i eth0 -m -q > > > '-i' has been deprecated. please use '-s' instead. > > > autoconfiguration cannot be mixed with manual config options. > > Yea, I think you just need to drop the -i eth0 part. > > With no -i phc2sys complains it has not port to connect to > > And not replace with the -s? A bug in the error message? > I am unsure, but... it should be connecting to the ptp4l Unix socket to get its configuration from the ptp4l daemon. I'll defer to someone who is more familiar with automatic mode. > > > Which will not start for me: > > > > > > kong ~ # ptp4l > > > no interface specified > > > > > > ptp4l does not by default look up any configuration file. > > Understood. Another reason why I have only been runnning in default > mode when asked to do that, to prove that default mode does not work. > I only mentioned you had to pass -f because you said you ran "ptp4l" on its own without passing the -f parameter. This means anything in your configuration wouldn't be applied. > > default.cfg > > is provided to show the default settings. You must specify the > > configuration file via "-f" option. > > Yup, if you look at my incomplete HOWTO you see I do that: > > http://www.catb.org/gpsd/gpsd-time-service-howto.html > > > > But this works: > > > > > > kong ~ # ptp4l -i eth0 & > > This won't do what you think because you didn't actually provide the > > configuration file. > > Clearly it is non-functional. But it does what I was asked to try and > proved it does not work in any rational manner. > > > > > I admit the options for phc2sys are really confusing. On the one > > > > hand, the phc2sys underwent a "organic" development process, and > > > > on the other hand, there really are a great many ways to > > > > configure the system clock and one (or more!) PTP hardware > > > > clocks. I always have to re-read the man page every time. > > > > > > > I am (slowly) working on updating the configuration code for all our > > utilities which should help alleviate some of these issues. > > I look forward to that, but I've been told this can work as it exists > now. Not found any way to make hardware mode work (with ntpshm) yet. > Hopefully we can get that sorted out. I don't have a solution to it offhand, > > > And another cesspool is pmc. I see it makes a nice low level tool, > > > but time for a simple way to use it like 'pmc -a' and 'pmc -A' > > > which would dump all possible data in short and long form, like > > > 'hdparm -i' and 'hdparm -I' do for disks. > > > > > > > pmc is used to directly talk the management protocol specified by the > > PTP standard. I don't know if pmc -a or pmc -A make sense. > > Why not? hdparm implements the SATA spec at low and high levels. Ditto > sdparm for SCSI and stty for RS-232. > I mean to say that I am unsure if pmc should be the "hdparm" equivalent. I am not sure the management protocol is exactly what you are looking for here. Maybe it is. > This stuff needs to be de-mystified nand automated if real users are > going to use it. RedHat has 10 pages of HOWTO and they still don't > get it right. > PTP is quite complicated, so this is not entirely unsurprising. > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 > g...@rellim.com Tel:+1(541)382-8588 ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
