netdev - Re: signal quality and cable diagnostic

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-next>] [day] [month] [year] [list]

Message-ID: <AM0PR04MB7041E1F0913A90F40DFB31A386BC0@AM0PR04MB7041.eurprd04.prod.outlook.com>
Date:   Thu, 14 May 2020 08:42:34 +0000
From:   Christian Herber <christian.herber@....com>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
CC:     Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Michal Kubecek <mkubecek@...e.cz>,
        David Jander <david@...tonic.nl>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        "mkl@...gutronix.de" <mkl@...gutronix.de>,
        Marek Vasut <marex@...x.de>
Subject: Re: signal quality and cable diagnostic

On Tue, May 14, 2020 at 08:28:00AM +0000, Oleksij Rempel wrote:
> On Thu, May 14, 2020 at 07:13:30AM +0000, Christian Herber wrote:
> > On Tue, May 12, 2020 at 10:22:01AM +0200, Oleksij Rempel wrote:
> >
> > > So I think we should pass raw SQI value to user space, at least in the
> > > first implementation.
> >
> > > What do you think about this?
> >
> > Hi Oleksij,
> >
> > I had a check about the background of this SQI thing. The table you reference with concrete SNR values is informative only and not a requirement. The requirements are rather loose.
> >
> > This is from OA:
> > - Only for SQI=0 a link loss shall occur.
> > - The indicated signal quality shall monotonic increasing /decreasing with noise level.
> > - It shall be indicated in the datasheet at which level a BER<10^-10 (better than 10^-10) is achieved (e.g. "from SQI=3 to SQI=7 the link has a BER<10^-10 (better than 10^-10)")
> >
> > I.e. SQI does not need to have a direct correlation with SNR. The fundamental underlying metric is the BER.
> > You can report the raw SQI level and users would have to look up what it means in the respective data sheet. There is no guaranteed relation between SQI levels of different devices, i.e. SQI 5 can have lower BER than SQI 6 on another device.
> > Alternatively, you could report BER < x for the different SQI levels. However, this requires the information to be available. While I could provide these for NXP, it might not be easily available for other vendors.
> > If reporting raw SQI, at least the SQI level for BER<10^-10 should be presented to give any meaning to the value.

> So the question is, which values to provide via KAPI to user space?
>
> - SQI
>  The PHY can probably measure the SNR quite fast and has some internal
>   function or lookup table to deduct the SQI from the measured SNR.
>
>   If I understand you correctly, we can only compare SQI values of the
>   same PHY, as different PHYs give different SQIs for the same link
>   characteristics (=SNR).
> - SNR range
>   We read the SQI from the PHY look up the SNR range for that value from
>  the data sheet and provide that value to use space. This gives a
>   better description of the quality of the link.
> - "guestimated" BER
>   The manufacturer of the PHY has probably done some extensive testing
>   that a measured SNR can be correlated to some BER. This value may be
>   provided in the data sheet, too.
>
> The SNR seems to be most universal value, when it comes to comparing
> different situations (different links and different PHYs). The
> resolution of BER is not that detailed, for the NXP PHY is says only
> "BER below 1e-10" or not.

The point I was trying to make is that SQI is intentionally called SQI and NOT SNR, because it is not a measure for SNR. The standard only suggest a mapping of SNR to SQI, but vendors do not need to comply to that or report that. The only mandatory requirement is linking to BER. BER is also what would be required by a user, as this is the metric that determines what happens to your traffic, not the SNR.

So when it comes to KAPI parameters, I see the following options
- SQI only
- SQI + plus indication of SQI level at which BER<10^-10 (this is the only required and standardized information)
- SQI + BER range (best for users, but requires input from the silicon vendors)

SNR in my opinion is neither an option nor helpful.

Regards,

Christian