Yo Richard!
On Wed, 25 Feb 2015 10:35:41 +0100
Richard Cochran <richardcoch...@gmail.com> wrote:
> I have been out with the flu, but let us take a look...
Well, don't get up on my account. :-)
> > kong ~ # cat ptp.conf
> > [global]
> > clock_servo linreg
>
> I recommend using the pi servo. See recent post on -users list.
Reading that thread, Miroslav recommends linreg for the casual user.
> > ptp4l[359.341]: selected best master clock 003048.fffe.345fe2
> > ptp4l[359.341]: foreign master not using PTP timescale
>
> Your master isn't using the PTP timescale? That is suspicious. What
> is your grand master?
Here is how I run my grand master:
ptp4l -f /usr/local/etc/ptp4l.conf &
With this config file:
[global]
time_stamping software
summary_interval 10
clock_servo ntpshm
ntpshm_segment 2
# default priority = 128
priority1 10
priority2 10
[eth0]
Suuggestions welcome.
> The path delay is enormous. I guess your master uses software time
> stamping, or you have several switches in line.
Yes, and yes. Hardware timestamping being a bear for me. 3 switches
in the path. The 6uS jitter I see seems pretty good to me.
> > WTF was that???
>
> Looking two lines further...
>
> > ptp4l[365.571]: clockcheck: clock jumped forward or running
> > faster than expected! ptp4l[365.571]: master offset 70368744176888
> > s0 freq -9485 path delay 58263
>
> The ptp4l program has measured a 19.5 hour offset between the local
> PHC and the GM clock.
>
> There are three possible explanations:
>
> 1. Someone reset the PTP Hardware Clock (PHC) behind our backs.
Not possible.
> 2. Someone reset the grand master's clock.
Not possible.
> 3. The GM is buggy and delivers broken time stamps.
Not possible.
On further testing, replacing the i217-LM with a 82574L, bth using the
same e1000e driver fixed the problem.
So, explanations 4 and 5
4. Buggy NIC
5. Buggy NIC driver
> Inspecting the protocol time stamps (wireshark, tcpdump) will narrow
> it down to #1 versus 2/3.
But not 4 versus 5.
> The whole rest of the trace just shows how ptp4l tries to correct an
> almost 20 hour offset.
Which is itself pretty laughable and merits its own bug.
> At this point, I would investigate the cause of the sudden, huge
> offset. You can test the problem using ptp4l in isolation. No point
> in running phc2sys if you've got such massive GM errors.
Done yesterday, email sent to list with results. Nothing obvious.
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
