signal quality and cable diagnostic

signal quality and cable diagnostic

[Oleksij Rempel]

Hi Andrew,

First of all, great work! As your cable diagnostic patches are in
net-next now and can be used as base for the follow-up discussion.

Do you already have ethtool patches somewhere? :=) Can you please give a
link for testing?

I continue to work on TJA11xx PHY and need to export some additional
cable diagnostic/link stability information: Signal Quality Index (SQI).
The PHY data sheet describes it as following [1]:
================================================================================
  6.10.3   Link stability

The signal-to-noise ratio is the parameter used to estimate link
stability. The PMA Receive function monitors the signal-to-noise ratio
continuously. Once the signal-to-noise ratio falls below a configurable
threshold (SQI_FAILLIMIT), the link status is set to FAIL and
communication is interrupted. The TJA1100 allows for adjusting the
sensitivity of the PMA Receive function by configuring this threshold.
The microcontroller can always check the current value of the
signal-to-noise ratio via the SMI, allowing it to track a possible
degradation in link stability.
================================================================================

Since this functionality is present at least on TJA11xx PHYs and
mandatory according to Open Alliance[2], I hope this functionality is
present on other 100/1000Base-T1 PHYs. So may be some common abstraction
is possible. What would be the best place to provide it for the user
space? According to the [2] SQI, is the part of Dynamic Channel Quality
(DCQ) together with Mean Square Error (MSE) and Peak MSE value (pMSE).

[1] https://www.nxp.com/docs/en/data-sheet/TJA1100.pdf
[2] http://www.opensig.org/download/document/218/Advanced_PHY_features_for_automotive_Ethernet_V1.0.pdf
    http://www.opensig.org/download/document/225/Open_Alliance_100BASE-T1_PMA_Test_Suite_v1.0-dec.pdf

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: signal quality and cable diagnostic

[Andrew Lunn]

On Mon, May 11, 2020 at 04:13:10PM +0200, Oleksij Rempel wrote:
> Hi Andrew,
> 
> First of all, great work! As your cable diagnostic patches are in
> net-next now and can be used as base for the follow-up discussion.
> 
> Do you already have ethtool patches somewhere? :=) Can you please give a
> link for testing?

Hi Oleksij

It was mentioned in the cover note

https://github.com/lunn/ethtool/tree/feature/cable-test-v4

> 
> I continue to work on TJA11xx PHY and need to export some additional
> cable diagnostic/link stability information: Signal Quality Index (SQI).

Is this something you want to continually make available, or just as
part of cable diagnostics. Additional nested attributes can be added
to the cable test results structure, and the user space code just
dumps whatever it finds. So it should be easy to have something like:

Pair A: OK
Pair A: Signal Quality Index class D

Are the classes part of the Open Alliance specification? Ideally we
want to report something standardized, not something proprietary to
NXP.

	Andrew

Re: signal quality and cable diagnostic

[Oleksij Rempel]

On Mon, May 11, 2020 at 04:33:37PM +0200, Andrew Lunn wrote:
> On Mon, May 11, 2020 at 04:13:10PM +0200, Oleksij Rempel wrote:
> > Hi Andrew,
> > 
> > First of all, great work! As your cable diagnostic patches are in
> > net-next now and can be used as base for the follow-up discussion.
> > 
> > Do you already have ethtool patches somewhere? :=) Can you please give a
> > link for testing?
> 
> Hi Oleksij
> 
> It was mentioned in the cover note
> 
> https://github.com/lunn/ethtool/tree/feature/cable-test-v4
> 
> > 
> > I continue to work on TJA11xx PHY and need to export some additional
> > cable diagnostic/link stability information: Signal Quality Index (SQI).
> 
> Is this something you want to continually make available, or just as
> part of cable diagnostics. Additional nested attributes can be added
> to the cable test results structure, and the user space code just
> dumps whatever it finds. So it should be easy to have something like:
> 
> Pair A: OK
> Pair A: Signal Quality Index class D

At least for automotive, avionics, (rockets till it is deployed :D)
etc... the cable integrity will probably not change, except we have some
sudden water infiltration into the cable, etc :)

However the SQI will probably change on a much shorter timescales, e.g.
crosstalk from other T1 links or EMI from motors, radio transceivers,
etc... We could sample this information during cable test, but also
provide an interface to sample this information later during normal
operation.

The NXP phy additionally offers the possibility to specify a warning
threshold for the SQI, to generate a warning interrupt. There is a
configurable fault threshold, too. However the spec doesn't mention
this. If needed (in the future), polling for SQI in the kernel would be
easier to implement if the PHY doesn't support interrupts.

According to the IEEE802.3bw paper we expect following noise sources:
================================================================================
a) Echo from the local transmitter on the same cable pair, is caused by
the hybrid function for bidirectional data transmission in the
BroadR-Reach duplex channel and by the impedance discontinuities in the
link segment. Echo cancellation techniques, up to each PHY implementer,
shall be used to achieve the objective BER level.

b) The typical background noise is mainly due to thermal noise.  Thermal
noise, with level roughly at -140 dBm/Hz, is not a critical contributor
that would impact performance. BroadR- Reach signaling allows a robust
margin over a 15m UTP channel to combat thermal noise.

c) There is no FEXT or NEXT as BroadR-Reach is a one pair solution. When
multiple cable pairs are bundled, the alien XTALK (NEXT/FEXT) become
interference sources.  Since the transmitted symbols from the alien
noise source in one cable are not available to another cable,
cancellation cannot be done.  When there are multiple pairs of UTP
cables bundled together, where all pairs carry 100 Mb/s links, then each
duplex link is disturbed by neighboring links, degrading the signal
quality on the victim pair.
================================================================================

according to the "c", I would expect worst SQI as soon as communication
will start on other bundled cable pairs.

When it comes to SQI the NXP data sheet and the opensig spec gives us:

https://www.nxp.com/docs/en/data-sheet/TJA1100.pdf
SQI=0 | worse then A | unstable link  |
SQI=1 | Class A      | unstable link  |
SQI=2 | Class B      | unstable link  |
SQI=3 | Class C      | good link      |
SQI=4 | Class D      | good link      | BER < 10^-10
SQI=5 | Class E      | good link      |
SQI=6 | Class F      | very good link |
SQI=7 | Class G      | very good link |

http://www.opensig.org/download/document/218/Advanced_PHY_features_for_automotive_Ethernet_V1.0.pdf
SQI=0 |             < 18dB | 
SQI=1 | 18dB <= SNR < 19dB | BER > 10^-10
SQI=2 | 19dB <= SNR < 20dB |
------+--------------------+--------------
SQI=3 | 20dB <= SNR < 21dB |
SQI=4 | 21dB <= SNR < 22dB | BER < 10^-10
SQI=5 | 22dB <= SNR < 23dB |
SQI=6 | 23dB <= SNR < 24dB |
SQI=7 | 24dB <= SNR        |

So I think we should pass raw SQI value to user space, at least in the
first implementation.

What do you think about this?

> Are the classes part of the Open Alliance specification? Ideally we
> want to report something standardized, not something proprietary to
> NXP.
> 
> 	Andrew
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: signal quality and cable diagnostic

[Robert Schwebel]

On Tue, May 12, 2020 at 10:22:01AM +0200, Oleksij Rempel wrote:
> > Pair A: OK
> > Pair A: Signal Quality Index class D
> 
> At least for automotive, avionics, (rockets till it is deployed :D)
> etc... the cable integrity will probably not change, except we have some
> sudden water infiltration into the cable, etc :)

As some of our applications are running on agricultural equipment, water
in the cable is not completely implausible :-)

rsc
-- 
Pengutronix e.K.                           | Dipl.-Ing. Robert Schwebel  |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |

RE: [EXT] Re: signal quality and cable diagnostic

[Christian Herber]

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.

Regards,

Christian

Re: [EXT] Re: signal quality and cable diagnostic

[Oleksij Rempel]

Hi Christian,

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.

> While I could provide these for NXP, it might not be easily available
> for other vendors.

It will be great if you can provide this information. It may force other
vendors to do the same :)

The actual procedure to measure the BER is the following testing
strategy suggested by opensig[1]:
--------------------------------------------------------------------------------
Procedure:
1. Configure the DUT as MASTER.
2. Connect the packet monitoring station to the automotive cable.
3. Connect the DUT to the automotive cable.
4. Send 2,470,000 1,518-byte packets (for a 10 -10 BER) and the monitor will
   count the number of packet errors.
5. Repeat step 4 for the remaining automotive cables.
6. Repeat steps 4-5 with the DUT configured as SLAVE.
--------------------------------------------------------------------------------

[1] http://www.opensig.org/download/document/225/Open_Alliance_100BASE-T1_PMA_Test_Suite_v1.0-dec.pdf

Regards,
Oleksij & Marc

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: signal quality and cable diagnostic

[Michal Kubecek]

On Mon, May 11, 2020 at 04:13:10PM +0200, Oleksij Rempel wrote:
> 
> I continue to work on TJA11xx PHY and need to export some additional
> cable diagnostic/link stability information: Signal Quality Index (SQI).
> The PHY data sheet describes it as following [1]:
> ================================================================================
>   6.10.3   Link stability
> 
> The signal-to-noise ratio is the parameter used to estimate link
> stability. The PMA Receive function monitors the signal-to-noise ratio
> continuously. Once the signal-to-noise ratio falls below a configurable
> threshold (SQI_FAILLIMIT), the link status is set to FAIL and
> communication is interrupted. The TJA1100 allows for adjusting the
> sensitivity of the PMA Receive function by configuring this threshold.
> The microcontroller can always check the current value of the
> signal-to-noise ratio via the SMI, allowing it to track a possible
> degradation in link stability.
> ================================================================================
> 
> Since this functionality is present at least on TJA11xx PHYs and
> mandatory according to Open Alliance[2], I hope this functionality is
> present on other 100/1000Base-T1 PHYs. So may be some common abstraction
> is possible. What would be the best place to provide it for the user
> space? According to the [2] SQI, is the part of Dynamic Channel Quality
> (DCQ) together with Mean Square Error (MSE) and Peak MSE value (pMSE).

IIUC these would be read-only parameters describing current state of the
link which can be queried at any time. If this is the case, adding them
as attributes to ETHTOOL_MSG_LINKSTATE_GET_REPLY message seems most
fitting.

As for getting / setting the threshold, perhaps ETHTOOL_MSG_LINKINFO_GET
and ETHTOOL_MSG_LINKINFO_SET. Unless you expect more configurable
parameters like this in which case we may want to consider adding new
request type (e.g. link params or link management).

Michal

Re: signal quality and cable diagnostic

[Oleksij Rempel]

On Mon, May 11, 2020 at 04:59:26PM +0200, Michal Kubecek wrote:
> On Mon, May 11, 2020 at 04:13:10PM +0200, Oleksij Rempel wrote:
> > 
> > I continue to work on TJA11xx PHY and need to export some additional
> > cable diagnostic/link stability information: Signal Quality Index (SQI).
> > The PHY data sheet describes it as following [1]:
> > ================================================================================
> >   6.10.3   Link stability
> > 
> > The signal-to-noise ratio is the parameter used to estimate link
> > stability. The PMA Receive function monitors the signal-to-noise ratio
> > continuously. Once the signal-to-noise ratio falls below a configurable
> > threshold (SQI_FAILLIMIT), the link status is set to FAIL and
> > communication is interrupted. The TJA1100 allows for adjusting the
> > sensitivity of the PMA Receive function by configuring this threshold.
> > The microcontroller can always check the current value of the
> > signal-to-noise ratio via the SMI, allowing it to track a possible
> > degradation in link stability.
> > ================================================================================
> > 
> > Since this functionality is present at least on TJA11xx PHYs and
> > mandatory according to Open Alliance[2], I hope this functionality is
> > present on other 100/1000Base-T1 PHYs. So may be some common abstraction
> > is possible. What would be the best place to provide it for the user
> > space? According to the [2] SQI, is the part of Dynamic Channel Quality
> > (DCQ) together with Mean Square Error (MSE) and Peak MSE value (pMSE).
> 
> IIUC these would be read-only parameters describing current state of the
> link which can be queried at any time. If this is the case, adding them
> as attributes to ETHTOOL_MSG_LINKSTATE_GET_REPLY message seems most
> fitting.

ok

> As for getting / setting the threshold, perhaps ETHTOOL_MSG_LINKINFO_GET
> and ETHTOOL_MSG_LINKINFO_SET. Unless you expect more configurable
> parameters like this in which case we may want to consider adding new
> request type (e.g. link params or link management).

Currently in my short term todo are:
- SQI
- PHY undervoltage
- PHY overtemerature

So far, I have no idea for PHY health diagnostic.

If we consider at least the  mandatory properties listed in the opensig, then
we would get following list:

- DCQ (dynamic channel group)
  - SQI (Signal Quality Index)
- HDD (Harness defect detection group)
  - OS (Open/Short detection) ----------------- implemented, cable test
    request.
- LQ (Link Quality)
  - LTT (Link-training time. The time of the last link training)
  - LFL (Link Failures and Losses. Number of link losses since the last
    power cycle)
  - COM (communication ready) ----------------- implemented?
- POL (Polarity detection & correction)
  - DET (Polarity detect)

I personally would add RE_ERR counter in this list as well.

Probably some one, soon or later, will try to implement them.

If I see it correctly, some of this properties are already implemented
within other request types. Is it worth to a add a new request type for
the rest of them?

Regards,
Oleksij

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: signal quality and cable diagnostic

[Andrew Lunn]

> > As for getting / setting the threshold, perhaps ETHTOOL_MSG_LINKINFO_GET
> > and ETHTOOL_MSG_LINKINFO_SET. Unless you expect more configurable
> > parameters like this in which case we may want to consider adding new
> > request type (e.g. link params or link management).
> 
> Currently in my short term todo are:
> - SQI


> - PHY undervoltage
> - PHY overtemerature

Do you only have alarms? Or are current values available for voltage
and temperature?

Both of these would fit hwmon. It even has the option to set the alarm
thresholds. The advantage of hwmon is that they are then just more
sensors. You could even include the temperature sensor into a thermal
zone to influence cooling. There are a couple of PHYs which already do
hwmon, so there is code you can copy.

> So far, I have no idea for PHY health diagnostic.
> 
> If we consider at least the  mandatory properties listed in the opensig, then
> we would get following list:
> 
> - DCQ (dynamic channel group)
>   - SQI (Signal Quality Index)
> - HDD (Harness defect detection group)
>   - OS (Open/Short detection) ----------------- implemented, cable test
>     request.
> - LQ (Link Quality)
>   - LTT (Link-training time. The time of the last link training)
>   - LFL (Link Failures and Losses. Number of link losses since the last
>     power cycle)
>   - COM (communication ready) ----------------- implemented?
> - POL (Polarity detection & correction)
>   - DET (Polarity detect)

Voltage and temperature are about the package. These are about the
link. So they better fit ETHTOOL_MSG_LINKINFO_SET or similar.

It sounds like LFL are statistic counters? PHYs can have their own
counters, which ethtool -S will return.

Does POLL somehow map to MDI MDIX? I guess not, since this is a T1.

     Andrew

Re: signal quality and cable diagnostic

[Pavel Machek]

On Tue 2020-05-12 15:04:18, Andrew Lunn wrote:
> > > As for getting / setting the threshold, perhaps ETHTOOL_MSG_LINKINFO_GET
> > > and ETHTOOL_MSG_LINKINFO_SET. Unless you expect more configurable
> > > parameters like this in which case we may want to consider adding new
> > > request type (e.g. link params or link management).
> > 
> > Currently in my short term todo are:
> > - SQI
> 
> 
> > - PHY undervoltage
> > - PHY overtemerature
> 
> Do you only have alarms? Or are current values available for voltage
> and temperature?
> 
> Both of these would fit hwmon. It even has the option to set the alarm
> thresholds. The advantage of hwmon is that they are then just more

> sensors. You could even include the temperature sensor into a thermal zone to influence 
> cooling. There are a couple of PHYs which already do hwmon, so there is code you can 
> copy.

Yes, hwmon can do a lot of stuff. OTOH figuring out "what hwmon device corresponds to what
network device is going to be tricky, and Im not sure if we want utilities like mii-tool to
start using hwmon interfaces...

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: signal quality and cable diagnostic

[Christian Herber]

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

Re: signal quality and cable diagnostic

[Pavel Machek]

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

Last option looks best to me... and it will mean that hopefully silicon vendors standartize
something in future.

Best regards,

										Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: signal quality and cable diagnostic

[Russell King - ARM Linux admin]

On Sun, May 24, 2020 at 11:27:57PM +0200, Pavel Machek wrote:
> > > 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)
> 
> Last option looks best to me... and it will mean that hopefully silicon vendors standartize
> something in future.

It already has been for > 1G PHYs, but whether they implement it is
another question altogether.  It's a 22-bit limiting counter in the
PCS.  There's also indications of "high BER".

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up