On Thu, 2015-02-26 at 10:03 -0800, Gary E. Miller wrote: > Yo Jacob E! > > On Thu, 26 Feb 2015 17:43:36 +0000 > "Keller, Jacob E" <jacob.e.kel...@intel.com> wrote: > > > > > ptp4l will try HWTSTAMP_FILTER_ALL if its available and degrade to > > > > more general filters until it finds either a working combination > > > > or exits saying required mode isn't supported. > > > > > > I'm trying to make this real simple. :-) > > > > > > So, if HWTSTAMP_TX_ON is present, can I know the NIC should be > > > supported for hardware time? > > > > > > > If HWTSTAMP_TX_ON is present, you support Tx timestamps. > > Is supporting Tx timestamps necessary and sufficient for supporting > linuxptp timestamp hardware mode? > > I'm just trying to get a minimum baseline here. > > > If any HWTSTAMP_FILTER_(type) is present you support some category of > > filtered Rx timestamps. The most general is HWTSTAMP_FILTER_ALL, and > > they get more specific from there. > > So the absolute minimum requirement would be HWTSMAP_TX_ON and at > least one of HWTSTAMP_FILTER_* ? >
The absolute minimum HWTSTAMP_TX_ON for Transmit timestamps and HWTSTAMP_FILTER_V2_L4_SYNC if you are a slave in L4 (ipv4 or ipv6) mode. You would never be able to support master. HWTSTAMP_FILTER_V2_L4_DELAY_REQ if you are a master, in L4, never able to be a slave. (swap those for L2 if you are in L2 mode) This wouldn't work with P2P delay model, because those are yet another type of packet you'd have to Rx timestamp. The "best" minimal answer is "HWTSTAMP_FILTER_V2_EVENT" Almost all hardware supports some form of V2_EVENT, and honestly I wouldn't suggest hardware that does not support V2_EVENT, as it requires ptp4l to reconfigure timestamp mode upon state change from master to slave if you can't support the generic V2_EVENT. > > > Agreed. But the php2sys failure always happens in under 60 seconds > > > and I could never get the failure to happen with just ptp4l. Since > > > I could never duplicate the failure in ptp4l mode nothing to show. > > > > Yes, so it is possible there is some related thing going on by > > accessing the clock in phc2sys, that causes the failed > > hardware/driver state. > > Seemingly confirmed by other recent email on this list. > Yep. Regards, Jake > > > BTW, are you in Hillsboro? > > Yep :) > > I'll buy you a beer or two if you get to Bend. > > 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
