Hi, > -----Original Message----- > From: Gary E. Miller [mailto:g...@rellim.com] > Sent: Tuesday, February 24, 2015 2:25 PM > To: Keller, Jacob E > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] ntp SHMs > > Yo Jacob E! > > On Tue, 24 Feb 2015 21:41:52 +0000 > "Keller, Jacob E" <jacob.e.kel...@intel.com> wrote: > > > > And drop the bomb: > > > > > > kong ~ # phc2sys -a -r -E ntpshm -m -M 2 > > > phc2sys[354.145]: uds: sendto failed: No such file or directory > > > > > > > Apparently it recovers, because you seem to have it working. The > > default should be fine. I am going to assume this is a transient > > problem due to timing between when you start ptp4l and phc2sys, where > > the us address isn't up yet. > > Confirmed. Adding a 'sleep 3' to my test script fixes it. I would > suggest the error message make some mention of what it was trying > to send where for debug purposes. > > > > phc2sys[365.199]: phc offset -70353239245525 s0 freq +0 > > > delay 1348 > > > > > > WTF was that??? > > > > This is telling you that your clock time (CLOCK_REALTIME) is off by > > 70,000 seconds. That's not happy. > > Except my clock time is off by about 60 uSec. At least until phc2sys > tries to 'fix' the problem. >
No. That is a mis-understanding. Your internal NIC clock is off by 60 uSec. Your REALTIME clock is not the NIC clock, but actually the kernel time, and *that* is what phc2sys offset is for. > > > > I stopped it here as it tried to step my good clock by -70356s. > > > > > > > So this looks quit suspicious as a driver bug. Especially as it > > appears to be toggling between a large positive and negative value I > > am recalling something similar. > > Ouch. I am on an Intel I217-LM with the e1000e driver. Ya. I looked at the driver for this, but nothing was obvious. The issue I thought might be related appears to be fine in the 3.19 kernel. > > Maybe time for me to try another NIC. > > > What happens if you just run ptp4l without running phc2sys and > > without running chronyd etc? I want to see ptp4l running stable with > > hardware timestamping before adding extra messages. > > Got a suggested config and procedure for that? Please just run your setup without running phc2sys, and use -l6 on ptp4l instead of -l7. See if you get the same clock jump issue or not. Also if you have the kernel documentation installed, you can use Documentation/ptp/testptp.c in order to read the PTP hardware clock directly. Try building that and running ./testptp -g -d /dev/ptpX Where ptpX is your device's ptp device, which you can see via ethtool -T You can use that to sanity check whether the PTP device is being set correctly. It should match your remote PTP master's time. > > Since in the present config my ptp4l is in linreg mode, is it just a > matter of starting ptp4l in linreg mode, not runnning phc2sys, and > looking at the ptp4l debug output? > Yes. > > Also what is your > > dmesg output here, so that we can see if there is any kernel message > > related to this. > > Nothing at all in dmesg. Ok so it's not the result of a tx hang causing a reset on the clock device. That's good. 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
