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  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]
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

Powered by blists - more mailing lists