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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <65ecb62de9940991971b965cbd5b902ae5daa09b.camel@hs-offenburg.de>
Date:   Mon, 12 Oct 2020 14:53:58 +0200
From:   Kamil Alkhouri <kamil.alkhouri@...offenburg.de>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Kurt Kanzenbach <kurt@...utronix.de>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Richard Cochran <richardcochran@...il.com>,
        ilias.apalodimas@...aro.org
Subject: 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:
> > Hello dears,
> > 
> > On Thu, 2020-10-08 at 12:01 +0200, Kurt Kanzenbach wrote:
> > > On Thu Oct 08 2020, Vladimir Oltean wrote:
> > > > On Thu, Oct 08, 2020 at 10:34:11AM +0200, Kurt Kanzenbach
> > > > wrote:
> > > > > On Wed Oct 07 2020, Vladimir Oltean wrote:
> > > > > > On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbach
> > > > > > wrote:
> > > > > > > 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