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 |
