Yo Jacob E!

On Tue, 24 Feb 2015 23:31:37 +0000
"Keller, Jacob E" <jacob.e.kel...@intel.com> wrote:

> > Hmm, I see the confusion, I never mentioned my phc2sys offest.
> > Until it goes to 70,000 seconds....
> > 
> 
> Correct. I was not assuming that you had another way to measure
> system time offset from the master.

Not much of a test if no baseline time standard.

> > > See if you get the same clock jump issue or not.
> > 
> > Since my ptp4l is in linreg mode, it can not jump my system clock.
> 
> To be clear, linreg is just a linear regression servo which could
> control the system clock, if you were doing software timestamping. In
> this case linreg is controlling the hardware MAC clock.

Hmm, that could be documented better.  So the invisible hand inside
turns off the linreg->sysclock connection when hardware timestamping
enabled...


> > I just did that, looks ugly, but I really have no idea:
> > 
> 
> This doesn't look ugly, you just likely mis-understand the output.

I stand by my statement.  Taking a perfectly good receently synced clock
and whacking it by 600mSec is not good.  The PLL startup is whacko.

> > delay 55328
> > ptp4l[52370.211]: master offset    -134962 s1 freq +599994160 path
> > delay 55306
> > ptp4l[52371.211]: master offset -599870879 s2 freq +186802553 path
> > delay 55306
> > ptp4l[52371.211]: port 1: UNCALIBRATED to SLAVE on
> > MASTER_CLOCK_SELECTED
> > ptp4l[52372.211]: master offset -786797418 s2 freq -149872567 path
> > delay 55306
> > ptp4l[52373.211]: master offset -637009628 s2 freq -599999999 path
> > delay 58203
> > ptp4l[52374.211]: master offset  -37092094 s2 freq -37208915 path
> > delay 60342
> > ptp4l[52375.211]: master offset     244012 s2 freq +177926 path
> > delay 58203

> You didn't let it run long enough to stabilize but restarting is
> probably fine.

Taking long to stablize, from a stable condition, is not fine, possibly
tolerable.  As long as the time not passed to ntpshm, which I suspect
it is.

> > It is possible the PLL is going nuts on startup?
> 
> It's probably due to starting in the weird state you did. If you let
> it run long enough it should stabilize.

Weird state?  What would you expect after a power cycle?  The whole
point of an initialization is nothing is initialized yet!

> If you leave this running do you *ever* see "clock check" errors like
> we were seeing before with both phc2sys and ptp4l?

My eyes glaze over.  Since ptp4l software mode works I assume that part
works.

> Try building it like "make M=Documentation/ptp/" from the top level.

That worked.  Maybe that should be documented?

In any case, I have given up on the i217-LM.  I have determined the
82574L and the I210, on the same host, everything else identical work
fine for me.

So the either the i217-LM or the way the e1000e drives it, is buggy.

Imagine some poor Ubuntu user trying to figure that out...

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

Reply via email to