netdev - RE: [PATCH 2/2] net: stmmac: Fix sub-second increment

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <BN8PR12MB32661DCB43EFE9F9235431A4D3DA0@BN8PR12MB3266.namprd12.prod.outlook.com>
Date:   Tue, 14 Apr 2020 11:14:04 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Julien Beraud <julien.beraud@...lia.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        "David S . Miller" <davem@...emloft.net>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH 2/2] net: stmmac: Fix sub-second increment

From: Julien Beraud <julien.beraud@...lia.com>
Date: Apr/14/2020, 10:46:49 (UTC+00:00)

> The numbers I have in the documentation say that the minimum clock 
> frequency for PTP is determined by "3 * PTP clock period + 4 * GMII/MII 
> clock period <= Minimum gap between two SFDs". The example values say 
> 5MHz for 1000-Mbps Full Duplex. Is this documentation incorrect ?

I meant for fine update method (which is the one currently used), the 
clock frequency must be higher than the desired accuracy (which is 
50MHz).

> Apart from that, the existing logic doesn't work. The calculation is off 
> by a factor 2, making the ptp clock increment twice slower as it should, 
> at least on socfpga platform but I expect that it is the same on other 
> platforms. Please check commit 19d857c, which has kind of been reverted 
> since for more explanation on the sub-seconds + addend calculation.
> Also, it artificially sets the increment to a value while we should 
> allow it to be as small as posible for higher frequencies, in order to 
> gain accuracy in timestamping.

I'm sorry but I don't see any "off by factor of 2". I also don't 
understand this:
 "the accumulator can only overflow once every 2 additions"

Can you please provide more details ?

BTW, I applied your patch and I saw no difference at all in my setup 
except for path delay increasing a little bit.

---
Thanks,
Jose Miguel Abreu