Yo Jacob E!
On Tue, 24 Feb 2015 00:38:12 +0000
"Keller, Jacob E" <jacob.e.kel...@intel.com> wrote:
> I'm going to attempt to give you a cleaner set of instructions on how
> to enable NTPSHM servo.
Thank you.
> I assume that eth0 is your NIC, and that eth0 has hardware
> timestamping support.
Yup. Seemingly so:
kong ~ # ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC)
ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
Any idea what the minimum possible to support hardware timestamp mode
would be?
> I am going to use linreg servo for ptp4l, and
> ntpshm servo for phc2sys.
I can't find much doc on what linreg is/does. Can you confirm it does not
ever write to sysclock? Looks that way to me, in which case seems lotta
work for little...
> Note this uses default hardware timestamping, E2E, over ipv4
Not bad defaults, but as a rule (RFC) IPv6 is to be prefered over IPv4
when available.
>
> $cat config.cfg
> [global]
> clock_servo linreg
> uds_address /var/run/ptp4l
uds_address is the default socket, so not needed?
> #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
Plus "-M 2", since my ntp already has 2 SHMs.
> I put the following refclock in my chrony.conf
>
> refclock SHM 0 poll 3 refid PTP0
In my case:
refclock SHM 2 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.
Well, the results were ugly, I stopped it when it tried to servo
my clock 35183 seconds.
kong ~ # phc2sys -a -r -E ntpshm -m -M 2
phc2sys[102865.368]: reconfiguring after port state change
phc2sys[102865.368]: selecting CLOCK_REALTIME for synchronization
phc2sys[102865.368]: selecting eth0 as the master clock
phc2sys[102865.368]: phc offset -38203 s0 freq +0 delay 1520
phc2sys[102866.368]: phc offset -38129 s0 freq +0 delay 1507
phc2sys[102867.368]: phc offset -38041 s0 freq +0 delay 1517
phc2sys[102868.368]: phc offset -37890 s0 freq +0 delay 1516
phc2sys[102869.368]: phc offset -37718 s0 freq +0 delay 1516
phc2sys[102870.369]: phc offset -37629 s0 freq +0 delay 1516
phc2sys[102871.369]: phc offset -37547 s0 freq +0 delay 1517
phc2sys[102872.369]: phc offset -37502 s0 freq +0 delay 1580
phc2sys[102873.369]: phc offset -37342 s0 freq +0 delay 1579
phc2sys[102874.370]: phc offset -37164 s0 freq +0 delay 1642
phc2sys[102875.370]: phc offset -36963 s0 freq +0 delay 1516
phc2sys[102876.370]: phc offset -36865 s0 freq +0 delay 1517
phc2sys[102877.370]: phc offset -36724 s0 freq +0 delay 1580
phc2sys[102878.370]: phc offset -36511 s0 freq +0 delay 1516
phc2sys[102879.371]: phc offset -36326 s0 freq +0 delay 1516
phc2sys[102880.371]: phc offset -36150 s0 freq +0 delay 1516
phc2sys[102881.371]: phc offset -70368744213708 s0 freq +0 delay 1517
phc2sys[102882.371]: port 002590.fffe.f355da-1 changed state
phc2sys[102882.371]: reconfiguring after port state change
phc2sys[102882.371]: master clock not ready, waiting...
phc2sys[102885.372]: port 002590.fffe.f355da-1 changed state
phc2sys[102885.372]: reconfiguring after port state change
phc2sys[102885.372]: selecting CLOCK_REALTIME for synchronization
phc2sys[102885.372]: selecting eth0 as the master clock
phc2sys[102885.372]: phc offset -70368225388909 s0 freq +0 delay 1516
phc2sys[102886.372]: phc offset -70367625256973 s0 freq +0 delay 1792
phc2sys[102887.372]: phc offset -70367025106507 s0 freq +0 delay 1517
phc2sys[102888.373]: phc offset -70366424969228 s0 freq +0 delay 1890
phc2sys[102889.373]: phc offset -70365824785558 s0 freq +0 delay 1516
^Cphc2sys[102889.479]: phc offset -70365760953346 s0 freq +0 delay
1516
kong ~ #
And why is it saying anything about CLOCK_REALTIME? That is the time input
not output?
> I believe the key insight is that you tried to configure ptp4l as the
> NTP SHM instead of phc2sys as the NTP SHM
Could be, more insights needed.
> > 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.
Odd, then why do I not need to run ptp2sys in software only mode? I
know for a fact I only need ptp2sys in hardware mode. If phc2sys can
run in software mode why is ptp4l touching my clock/ntpshm 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.
A pity. We learn a lot in gpsd running serial (sentence) and hardware
(PPS) time in parallel.
> > > 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.
Fair enough. At some point I gotta find out who to have that
argument with.
> > > *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?
Sorry, yes my bad. ptp4l driving chrony/ntpd which drives the kernel
clock.
> In your case, you have ptp4l driving ntpd, via ntpshm yes.
In software mode. But you are telling me to have phc2sys drive ntpshm
instead in hardware mode.
> 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.
Like this?
kong ~ # phc2sys -a -r -E ntpshm -m -M 2
Except that fails...
> >
> > > 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.
Or, in mmy case, driving ntpd/chronyd which is driving the system 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.
OK, send the hardware timestamp to NTPSHM after the proper conversion
process is performed. I never assumed no translation required.
> > 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".
I gotta get it to work once first. Thanks for your help and I'll
kkeep trying.
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
