Re: [PATCH net-next v6 4/7] net: dsa: hellcreek: Add support for hardware timestamping

Hi Vladimir,

On Thu, 2020-10-08 at 18:09 +0300, Vladimir Oltean wrote:

Hi Kamil,

On Thu, Oct 08, 2020 at 02:55:57PM +0200, Kamil Alkhouri wrote:

quoted

Hello dears,

On Thu, 2020-10-08 at 12:01 +0200, Kurt Kanzenbach wrote:

quoted

On Thu Oct 08 2020, Vladimir Oltean wrote:

quoted

On Thu, Oct 08, 2020 at 10:34:11AM +0200, Kurt Kanzenbach
wrote:

quoted

On Wed Oct 07 2020, Vladimir Oltean wrote:

quoted

On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbach
wrote:

quoted

For instance the hellcreek switch has actually three ptp
hardware
clocks and the time stamping can be configured to use
either
one of
them.

The sja1105 also has a corrected and an uncorrected PTP
clock
that can
take timestamps. Initially I had thought I'd be going to
spend
some time
figuring out multi-PHC support, but now I don't see any
practical reason
to use the uncorrected PHC for anything.

Just out of curiosity: How do you implement 802.1AS then? My
understanding is that the free-running clock has to be used
for
the

Has to be? I couldn't find that wording in IEEE 802.1AS-2011.

It doesn't has to be, it *should* be. That's at least the outcome
we
had
after lots of discussions. Actually Kamil (on Cc) is the expert
on
this
topic.

According to 802.1AS-2011 (10.1.1): "The LocalClock entity is a
free-
running clock (see 3.3) that provides a common time to the time-
aware
system, relative to an arbitrary epoch.", "... All timestamps are
taken
relative to the LocalClock entity". The same statement holds true
for
802.1AS-2020 (10.1.2.1).

Nice having you part of the discussion.

IEEE 802.1AS-rev draft 8.0, clause F.3 PTP options:

	The physical adjustment of the frequency of the LocalClock
	entity (i.e., physical syntonization) is allowed but not
	required.

what about phase adjustment?
I believe logical syntonization is a main part of 802.1AS-Rev and it is
actually mandatory (7.5.g). Even though physical syntonization is
allowed, the standard clearly states that it is slow and prone to gain
peaking effects (7.3.3). Therefore, it makes sense to use a free-
running clock to get the most benefit of AS-Rev when it comes to the
transport of synchronization information. 

In fact, even if that wasn't explicitly written, I am having a hard
time
understanding how the "B.1.1 Frequency accuracy" requirement for the
LocalClock could be satisfied as long as it is kept free-running.
Otherwise said, what should I do as a system designer if the
LocalClock's frequency is not within +/- 100 ppm offset to the TAI
frequency, and I'm not allowed to correct it.

B.1.1 defines the frequency accuracy of the local clock relative to TAI
and not to grandmaster. In my opinion, this is a physical requirement
of the quartz oscillator used to drive the time and it should be
fulfilled for all local clocks even for the ones in non-slave devices.

By the way, how would you see the split between an unsynchronized and
a
synchronized PHC be implemented in the Linux kernel?

I'm not an expert in kernel implementation but we have plans to discuss
possible approaches in the near future.

Thanks,
-Vladimir

Thanks,
Kamil