Hi, On Wed, 2015-02-25 at 17:47 -0800, Gary E. Miller wrote: > Yo Jacob E! > > On Thu, 26 Feb 2015 01:01:36 +0000 > "Keller, Jacob E" <jacob.e.kel...@intel.com> wrote: > > > > So what is the minimmum for hardware mode timestamping? Like this? > > > > > > HWTSTAMP_TX_OFF > > > HWTSTAMP_TX_ON > > > HWTSTAMP_FILTER_ALL > > > > > > > > > > HWTSTAMP_TX_OFF is always supported. HWTSTAMP_TX_ON is required for > > Hardware Tx timestamps. > > > > HWTSTAMP_FILTER_ALL is best, otherwise you need the requisite modes > > for your configuration. > > > > Mostly for V2 layer4, with End to end, you need > > HWTSTAMP_FILTER_V2_SYNC and > > HWTSTAMP_FILTER_V2_DELAY_REQ > > > > For P2P delay protocol you need to be able to timestamp PDELAY_REQ and > > PDELAY_RESPONSE messages, > > > > and for L2 mode you have to be able to timestamp L2 equivalents of > > these. The most general non-timestamp-all mode is > > > > HWTSTAMP_FILTER_V2_EVENT > > > > 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. 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. > > The output you had there didn't showcase the actual failure with the > > clockcheck showing a massive change in the clock. Either it didn't run > > long enough or the failure case was triggered by phc2sys or some other > > setup. > > 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. > > > Many NIC choices in the world, I'm not gonna waste my time on any > > > one of them. > > Yep. Well, I'll try to forward what we do have to validation for that > > part here. Thanks for the effort so far at least :) I understand that > > it isn't worth too much effort on your end. > > Where can I send my consulting bill? :-) > > If some engineer, that would really fix something, would look at it > I would revisit the part. > > > I am glad that you were able to get to at least a somewhat sane setup > > finally. > > I have two now. More on that in another email. > > BTW, are you in Hillsboro? > Yep :) 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
