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?
If so should not -M be an illegal option in hardware mode?
> 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.
> 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.
Conceptually, and I suggest not seriously (yet), hpc2sys could easily
just be a thread launched inside ptp4l when in hardware mode.
> *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
> In hardware mode we are not driving the clock directly but only
> indirectly.
Unclear who 'we' is.
> 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?
Or ptp4l could spawn htc2sys when hardware mode is selected? Or
-a mode could just work?
> > > > 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
------------------------------------------------------------------------------
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
