Richard Cochran <richardcoch...@gmail.com> writes: > On Wed, Jul 08, 2020 at 03:37:29PM +0300, Sergey Organov wrote: >> Richard Cochran <richardcoch...@gmail.com> writes: >> >> > On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote: >> >> There's no correct answer, I'm afraid. Whatever the default value of the >> >> clock may be, it's bound to be confusing for some reason, _if_ the >> >> reason why you're investigating it in the first place is a driver bug. >> >> Also, I don't really see how your change to use Jan 1st 1970 makes it >> >> any less confusing. >> > >> > +1 >> > >> > For a PHC, the user of the clock must check the PTP stack's >> > synchronization flags via the management interface to know the status >> > of the time signal. >> >> Actually, as I just realized, the right solution for my original problem >> would rather be adding PTP clock ID that time stamped Ethernet packet to >> the Ethernet hardware time stamp (see my previous reply as well). > > I think you misunderstood my point. I wasn't commenting on the > "stacked" MAC/PHY/DSA time stamp issue in the kernel.
I think I did. It's rather that initialization value of PHP clock has consequences in MAC/PHY/DSA, and there is no way to check any flags /there/. And it's exactly the place where I needed the info, see background explanation below. I understand what your point is, but I try to explain that it's irrelevant for my particular use-case. > > I am talking about the question of whether to initialize the PHC time > to zero (decades off from TAI) or ktime (likely about 37 seconds off > from TAI). It does not really matter, because the user must not guess > whether the time is valid based on the value. Instead, the user > should query the relevant PTP data sets in a "live" online manner. I'm implementing PTP master clock, and there are no PTP data sets (yet) in my case, as it's me who will eventually create them. > > For example, to tell whether a PHC is synchronized to anything at all, > you need to check PORT_DATA_SET.portState and probably also > CURRENT_DATA_SET.offsetFromMaster depending on your needs. These are fields of PTP stack software that is not running in my case. > > In addition, if you care about global time, you need to check: > > TIME_PROPERTIES_DATA_SET > currentUtcOffset > currentUtcOffsetValid > ptpTimescale > timeTraceable > frequencyTraceable I'm going to become PTP master clock, I already have very precise estimations of PTP time, I know UTC offset, all this independently from any PTP stack. Moreover, I've already synchronized PHY clock to this time scale with +-5ns accuracy, and then I suddenly get somewhat wrong hardware time stamps for Ethernet packets that I send/receive. You see? Setting initial value of PTP clock to 0 would allow me to figure what happens (time stamp coming from /different/ PTP clock) half a day earlier. Not a big deal, I agree, yet I wanted to help a little bit somebody who might happen to run into a similar trouble in the future. Thanks, -- Sergey
