Forums

"On-line" 100BaseTX hardware diagnostics

Started by Don Y October 12, 2016
What sorts of hooks can I include in my designs to allow
run-time testing of 100BaseTX hardware?

Obviously, I can monitor traffic, throughput, CRC errors,
etc. to give me a feel for degradation of the overall link.

But, what can I do to diagnose things like cabling problems
and failures without impacting the quality of the link
hardware "otherwise"?  (think "built in cable tester")

An even tougher question:  can I leverage a *partially*
functional cable/interface to provide *limited* connectivity
in the event of a failure that impacts the normal NIC-pair?
(even if this is an either-or implementation)
On 2016-10-12, Don Y <blockedofcourse@foo.invalid> wrote:
> What sorts of hooks can I include in my designs to allow > run-time testing of 100BaseTX hardware? > > Obviously, I can monitor traffic, throughput, CRC errors, > etc. to give me a feel for degradation of the overall link. > > But, what can I do to diagnose things like cabling problems > and failures without impacting the quality of the link > hardware "otherwise"? (think "built in cable tester")
You use a PHY that has built in cable tester features.
> An even tougher question: can I leverage a *partially* > functional cable/interface to provide *limited* connectivity > in the event of a failure that impacts the normal NIC-pair? > (even if this is an either-or implementation)
Are we to assume you're using a cable with unused pairs in it? And you want to fail-over to normally unused pairs if the standard wire-pairs aren't working? You'll need to add magnetics for the other two pairs, and implement something to switch the PHY between the two sets of magnetics. Or add another PHY+magnetics, and switch the MII interface back and forth between the two PHYs. On both ends of the cable. Or something link that. -- Grant Edwards grant.b.edwards Yow! I am having FUN... at I wonder if it's NET FUN or gmail.com GROSS FUN?
On Wed, 12 Oct 2016 12:33:12 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>What sorts of hooks can I include in my designs to allow >run-time testing of 100BaseTX hardware? > >Obviously, I can monitor traffic, throughput, CRC errors, >etc. to give me a feel for degradation of the overall link. > >But, what can I do to diagnose things like cabling problems >and failures without impacting the quality of the link >hardware "otherwise"? (think "built in cable tester") > >An even tougher question: can I leverage a *partially* >functional cable/interface to provide *limited* connectivity >in the event of a failure that impacts the normal NIC-pair? >(even if this is an either-or implementation)
Well, other than trying to fall back to 10Mb mode (which will be a smidge more tolerant of marginal cables), not really, at least not without something on both ends of the wire. OTOH, if you *can* put something on both ends of the wire, why not just put a second 100Mb MAC/PHY on your device, and wire it to the other* four wires, and then split the far end of the cable into two RJ-45s, and plug both of those into the switch (or better yet, plug them into separate switches, for redundancy). Or just put two Ethernet ports on your device, and let the user run two cables for redundancy, or use a cable split on both ends to use a single physical cable which would tolerate some damage (or a plain cable if they care about neither). Splitters are available off the shelf for just that sort of application (two Ethernet drops on one cable). Anything else you might do (run RS-422 serial over the unused pairs? autosense for a subset of working wires?), will require custom hardware at the switch end as well (and I doubt it'll cost less to do than just having a second switch). And it's hard to imaging that you could actually add a serial port to your device for meaningfully less than a second Ethernet MAC/PHY. A combination of a wired Ethernet port and a WiFi port has some attractions as well, especially given how much people hate pulling cables. *Obviously that won't work with GigE, which uses all four pairs.
On 10/12/2016 1:33 PM, Grant Edwards wrote:
> On 2016-10-12, Don Y <blockedofcourse@foo.invalid> wrote: >> What sorts of hooks can I include in my designs to allow >> run-time testing of 100BaseTX hardware? >> >> Obviously, I can monitor traffic, throughput, CRC errors, >> etc. to give me a feel for degradation of the overall link. >> >> But, what can I do to diagnose things like cabling problems >> and failures without impacting the quality of the link >> hardware "otherwise"? (think "built in cable tester") > > You use a PHY that has built in cable tester features.
I'm using SoC's so typically have just the network pins as "known" to be available.
>> An even tougher question: can I leverage a *partially* >> functional cable/interface to provide *limited* connectivity >> in the event of a failure that impacts the normal NIC-pair? >> (even if this is an either-or implementation) > > Are we to assume you're using a cable with unused pairs in it?
100BaseTX nominally only uses two pair for *data* (unlike 100BaseT4). And, I'm currently using "Mode A" PoE so I *could* have two spare pairs. But, plan on reserving them to handle cable faults that can't easily be repaired (stringing new runs is prohibitively costly).
> And you want to fail-over to normally unused pairs if the standard > wire-pairs aren't working?
No. All I want to do is be able to determine that there *is* a failure that is *likely* due to cable/connector problems. If some bit of electronics is wonky, there's nothing that can be done short of replacing it. OTOH, a connector that may be poorly seated or cable/connector that has suffered some damage from "handling", vibration, exposure, etc. can typically be repaired (at the cost of a few inches of wire). In the less-likely event that a cable has been damaged somewhere other than the ends, the spare pairs are my fallback (to avoid laying a new cable). I want a way of (effectively) differentiating between: - "line noise" (which may be constant) - intermittent/failed cable - intermittent/failed connector - NIC failure - other The remedies you suggest vary depending on the likely cause of the problem. And, the typical approach of suggesting ALL possible remedies (in some canned order) just puts too much of the onus on the user ("check engine")
> You'll need to add magnetics for the other two pairs, and implement > something to switch the PHY between the two sets of magnetics. > > Or add another PHY+magnetics, and switch the MII interface back and > forth between the two PHYs. > > On both ends of the cable. > > Or something link that. >
On 10/12/2016 3:47 PM, Robert Wessel wrote:
> On Wed, 12 Oct 2016 12:33:12 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> What sorts of hooks can I include in my designs to allow >> run-time testing of 100BaseTX hardware? >> >> Obviously, I can monitor traffic, throughput, CRC errors, >> etc. to give me a feel for degradation of the overall link. >> >> But, what can I do to diagnose things like cabling problems >> and failures without impacting the quality of the link >> hardware "otherwise"? (think "built in cable tester") >> >> An even tougher question: can I leverage a *partially* >> functional cable/interface to provide *limited* connectivity >> in the event of a failure that impacts the normal NIC-pair? >> (even if this is an either-or implementation) > > Well, other than trying to fall back to 10Mb mode (which will be a > smidge more tolerant of marginal cables), not really, at least not > without something on both ends of the wire.
I'm asking what I can add on both ends (I own the switch's design) to accomplish this. The "degraded capability" is just something that I would need to allow the remote device to "get a message through" to some other device that could convey that information to the user (devices don't have UI's). Rather than just saying "something is wrong with SOME ASPECT of the communication link with device X" -- which could be switch related (including cable-end and connection), cable related (including placement and interference from a poor installation) or "remote device" related (etc.) I'd NOT like to have to force the remote device to be removed and checked if the problem happens to be closer to the switch, etc. (and the opposite case is also true)
> OTOH, if you *can* put something on both ends of the wire, why not > just put a second 100Mb MAC/PHY on your device, and wire it to the > other* four wires, and then split the far end of the cable into two > RJ-45s, and plug both of those into the switch (or better yet, plug > them into separate switches, for redundancy).
Adds a significant cost to the system. PoE switch with PTP support. Add a *second* one (i.e., ANOTHER 70 ports?) I'm hoping the two spare pairs are a safety net if I need to replace a bad data pair or move to Mode B for power delivery.
> Or just put two Ethernet ports on your device, and let the user run > two cables for redundancy, or use a cable split on both ends to use a > single physical cable which would tolerate some damage (or a plain > cable if they care about neither). > > Splitters are available off the shelf for just that sort of > application (two Ethernet drops on one cable). > > Anything else you might do (run RS-422 serial over the unused pairs? > autosense for a subset of working wires?), will require custom > hardware at the switch end as well (and I doubt it'll cost less to do > than just having a second switch). And it's hard to imaging that you > could actually add a serial port to your device for meaningfully less > than a second Ethernet MAC/PHY.
Many SoC's *have* serial ports -- that I'm not using. So, it's really just the cost of any level translators, isolation, etc. that MIGHT be involved. The "secondary channel" is intended as a fall back only for diagnostic purposes. So, needn't be very high bandwidth (e.g., a Bell 103 modem would MORE THAN suffice). Consider the alternative: an idiot light that the user examines and conveys the information MANUALLY to <whatever> for resolution (damn near anything is higher bandwidth than involving the user!) The problem is getting whatever "backup" communication mechanism to coexist with the PHY. It can't interfere with (or distort) "normal" comms when everything is working properly. And, I need to be able to ensure the PHY (possibly in a failed state!) doesn't compromise that secondary channel And, to do so without adding considerably to cost/complexity. (a digital I/O could be toggled at something just this side of DC and suffice -- were it not for the isolation and protection issues)
> A combination of a wired Ethernet port and a WiFi port has some > attractions as well, especially given how much people hate pulling > cables.
Hard to deliver power over wireless! :> (and, having dozens of wallwarts scattered around each delivering a few watts to its respective load would represent another hassle: did someone knock a wall wart loose? Did it fail? Did the outlet into which it was plugged get witched off? Has the circuit "blown"? Is there a power outage? etc.
> *Obviously that won't work with GigE, which uses all four pairs.
As would 10/100BaseTX with Mode B PoE (my fallback if Mode A doesn't cut it for a particular drop)