Hi, Sorry to comment so far back in the thread, but...
On Wed, 2015-02-25 at 17:34 -0800, Gary E. Miller wrote: > 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. Yes this makes sense. > > > > > 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... > .... If you use software timestmaps you are controlling the clock that made those (software) timestamps. If you do hardware timestamps, you are controlling the clock that made those (hardware) timestamps. ptp4l controls one clock. Sometimes you get "lucky" in that you were doing software timestamps so it could directly control the software clock. You could also run in free-running mode so that it doesn't directly control the clock, or you could expose the timestamps as an NTP SHM and have ntp daemon control the clock. > > > > 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. > The beginning is bad, yes. But we actually don't try to jump the servo until ... > > > 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 Here. After which it already went bonkers due to the large jump. This is probably the result of the same driver issue noticed before. Note that before, it "looked" ok, but the freq value was way off, and once we tried to reset it, it started going crazy. Again, I think this is sign of the broken issue with the i217-LM. > > > 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! > You power cycled the machine? > > 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. Nope. The clock check was only occuring in your output with hardware timestamping. > > > Try building it like "make M=Documentation/ptp/" from the top level. > > That worked. Maybe that should be documented? That is how the Kernel make system works. When you run make in the top level and name testphc, you are using implicit makefile rules, which is why it failed to build the -lrt library inclusion. > > 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. > Yep. > 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... > Yep. I'm hoping to get enough information so I can pass this on to the team that does the driver for the i27-LM and see if they can try to fix it :) Regards, Jake > 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
