Hello, I'm going to attempt to give you a cleaner set of instructions on how to enable NTPSHM servo.
I assume that eth0 is your NIC, and that eth0 has hardware timestamping support. I am going to use linreg servo for ptp4l, and ntpshm servo for phc2sys. Note this uses default hardware timestamping, E2E, over ipv4 $cat config.cfg [global] clock_servo linreg uds_address /var/run/ptp4l #background the process $ptp4l -f config.cfg & OR (for testing) #forground the process and print to stdout $ptp4l -f config.cfg -m Now, after this starts, I can start phc2sys in automatic mode. Note that automatic mode does not mean all configuration is automatic (contrary to its name). What it means is that port configuration is automatically pulled from ptp4l and it follows state changes in ptp4l. Thus, to get phc2sys to run with NTPSHM servo -a for automatic, -r for system time -E ntpshm and again -m to log to stdout $phc2sys -a -r -E ntpshm -m I put the following refclock in my chrony.conf refclock SHM 0 poll 3 refid PTP0 Doing these steps works fine for me. I have more comments below, but hopefully this outline will help you solve your issue. I believe the key insight is that you tried to configure ptp4l as the NTP SHM instead of phc2sys as the NTP SHM On Mon, 2015-02-23 at 15:22 -0800, Gary E. Miller wrote: > Yo Jacob E! > > On Mon, 23 Feb 2015 22:40:17 +0000 > "Keller, Jacob E" <jacob.e.kel...@intel.com> wrote: > > > > 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. > > Fair enough. > > > > 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 > > Understood. > > > 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. > > Are you saying options like -M are ignored in hardware timestamp mode? > -M is a phc2sys switch. It specifically modifies ntpshm servo's settings. It is not a command line option for ptp4l, but for ptp4l, we use a configuration file. In this case, ntpshm is a servo which is supposed to control the clock. > If so should not -M be an illegal option in hardware mode? > phc2sys doesn't have "software" and "hardware" modes as its job is purely to do clock syntonization/synchronization. > > 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. > > I would never suggest a thing. That is a job for ntpd and some sort > of refclock shimm (maybe hpc2sys). > > > There really doesn't make any sense for ptp4l to attempt to relate > > them to the software kernel clock at all. > > Nor would I suggest such a thing. If possible, both the hardware > and software timestamps should be independent and both accessible. > They are, though ptp4l doesn't use both at the same time. > > 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. > > Lost me. Whether you partition a thing into two programs, or one > program with two threads, or some other combo does not follow from your > argument. It wasn't an argument. I was explaining how it works. > > Conceptually, and I suggest not seriously (yet), hpc2sys could easily > just be a thread launched inside ptp4l when in hardware mode. > It theoretically could. It was, however, designed as a separate program. I do not know specific reasons for this. > > *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. > > Uh, no. Not in my case, I have ptp4l driving ptp4l driving ntpd > which drives the kernel clock. This is the point of this config > line in my /usr/local/etc/ptp4l.conf: > > clock_servo ntpshm > That seems wrong. You should only have one instance of ptp4l? I assume that was a typo? In your case, you have ptp4l driving ntpd, via ntpshm yes. For hardware timestamp modes what you want to do is: ptp4l using linreg or pi servo, driving the hardware clock phc2sys using servo ntpshm via the "-E" switch, and -M switch to set NTPSHM segment information. By default phc2sys uses PI servo. > > > In hardware mode we are not driving the clock directly but only > > indirectly. > > Unclear who 'we' is. > Sorry, "we" is ptp4l. To clarify, when using hardware timestamps ptp4l does not drive the system clock directly. It does in software mode, but only because there is no other clock to drive. > > I hope this makes sense? > > Nope. > > > > > 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? > > Well, I am trying, and failing. Automatic mode fails flagrantly and > any manual mode I try either fails, does nothing, or totally flalis my > system clock. > > > > > 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. > > And ptp4l sends the acquired timestamps to ntpshm in software mode. Seems > to me it just needs to instead read the hardware timestamp and sent it? > It can't send hardware timestamp directly. This is because hardware timestamps are relative to the MAC internal clock which has zero basis for comparison to the system clock (ie: they aren't running at the same rate and definitely can't be compared as if they're in the same domain). If you sent hardware timestamps directly to NTPSHM the result would be very bad. > Or ptp4l could spawn htc2sys when hardware mode is selected? Or > -a mode could just work? > Theoretically, ptp4l could spawn phc2sys. Again, I'd defer to Richard on why it doesn't today. Most likely your answer will be "Patches welcome". > > > > > 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. > > Understood. I'm trying everything suggested, no matter how odd, because > nothing seems to work. > > I'll try anything you suggest, as long as it brings ntpshm into the > picture. > > > > 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. > > Pending a better idea, and someone to code it, I'll stick to this one. > It would be pretty simple to code. > > gpsd ended up with several tools for real time data visualization. If > someone were to write a pmc-like gui that real time displayed the PTP > data I would love it. The human brain is amazing at seeing patterns in > visual data. But I do not want to suggest work to volunteers beyond > what I need for basic functionality. > > > > 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. > > Remember all the knobs that used to be on TVs and Oscopes? They were > really complicated! But engineers fixed that. > > GPSs and file systems are also complicated. But in 99% of the case I > can just say "gps -n /dev/ttyS0" or "mount /dev/sda /mnt/hd" and things > just work. I enjoy being in the 1% that flips every switch, but we > should not inflict that on the 99%. > > For example, if no -i is given, why not attach to all ethernet ports? > Just like just about every daemon out there. > > As another example, detecting if hardware timestamping is possible is > trivial. Then the defaults can be automatically adjusted. If hardware > timestamping is possible, spawn()ing or pthreading ph2sys should be > easy. Else if hardware timestamping is not possible then just fall back > to software timestamping. > > But for now, I'll be happy if I can get a working HOWTO that is not > 10 pages. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 > g...@rellim.com Tel:+1(541)382-8588 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
