Big Test MFG says our Ethernet Chip violates the IEEE standard - are they right? - Page 1
Forum section: electronics / general

author: metrologist
author_rank: Super Contributor
timestamp: October 19, 2021, 07:45:16 pm
content: Edit: it is a test equipment manufacturer acting as a customer to evaluate one of our new products - they were simply trying to connect to the instrument through Ethernet using a cat3 cable probably wired with a modular 8P4C plug (1236), and there was no talking until they went to a cat5 8P8C. So would this be an implementation flaw?=== fake news:A big one you will all know and love says that because our Ethernet port (RJ45 plugs), has a design flaw because it does not support a cat3 cable (RJ11 plugs).Does the IEEE standard actually state that the physically different plug must be supported?

author: wraper
author_rank: Unknown
timestamp: October 19, 2021, 08:21:31 pm
content: Title says it's the chip but it's about the port. What IEEE standard in particular? There are many. Sounds like utter BS, even latching mechanism is not compatible between them.

author: ve7xen
author_rank: Super Contributor
timestamp: October 19, 2021, 08:23:01 pm
content: Do they call out the clause and standard they think is being violated?The only IEEE 802.3 PMA supporting Cat3 that would be relevant is 10base-T. Clause 14.5.1 of 802.3-2018 (in the 10base-T MDI section) says:QuoteSo I don't see anything requiring the RJ-11 (6P2C, or the RJ14/RJ25 variants with more conductors) be compatible with the jack, and they specifically require an 8-pin connector (RJ11 etc. are 6-position), however I don't have access to IEC 60603-7:1990, which perhaps does specify a mechanical backwards-compatibility. This requirement also doesn't make sense in context, since pin 1 is used in 10base-T, and this outer pin is missing in RJ11, so you would never achieve a functional link using those connectors with any 10base-T or any other -T PMA; they all use pin 1.

author: wraper
author_rank: Unknown
timestamp: October 19, 2021, 08:37:05 pm
content: Also CAT3 does not mean 6 wires. It can easily have 8 wires or 200.

author: ejeffrey
author_rank: Super Contributor
timestamp: October 19, 2021, 09:55:58 pm
content: Definitely they should cite which standard and the specific section they think you are violating. You should be able to look at the cited text to see if what they are claiming makes sense.8P8C jacks are designed to (poorly) accommodate 6P/2C plugs and cables. In some cases this was used to allow a combined ethernet/phone jack with the phone on pins 4/5 which are not used on 10baseT or 100baseT. I guess somehow an 8P8C jack that can't physically fit a 6P2C cable plug might be in violation of the mechanical standard for the jacks. I'm not sure exactly how you would make such a jack, and if you did I would consider it a feature since 1G networks use all 4 pairs and so plugging a phone in can't work, and any actual ethernet standard needs pin 1.Cat3 is the cable standard, not the plug/jack.

author: metrologist
author_rank: Super Contributor
timestamp: October 19, 2021, 10:06:28 pm
content: OK, then I did not know cat3 was/could be or is required to be 8-pin. I think the difference has something to do with the twisting rate and wiring.Then why wouldn't a cat3 cable work? As far as I know there are two wiring standards, TIA/EIA 568A and TIA/EIA 568B, and does it matter if they were using a crossover cable?They specifically said it was an older Cat3 cable, which often has fewer wires, or just 4 (1,2,3,6), whereas cat5 has all 8. I assume they were using two twisted pairs in that configuration (maybe as 8P4C), but then is that cable required to be supported in the Ethernet standard?

author: ve7xen
author_rank: Super Contributor
timestamp: October 19, 2021, 11:19:30 pm
content: What does the report *actually say*. It seems like at least part of the problem here is that you don't have enough domain knowledge to properly interpret the report. Does the cable not mate with the connector? Not establish link? Not pass data? Have an excessive loss rate? What are the details of the test setup ... etc.With the new information it sounds like they may be testing a cable with only 2 pairs, which is adequate for 100base-TX or 10base-T. It would still use the 8P8C connector. It should still work *for 10base-T or 100base-TX*, however 1000baseT+ equipment configured for autoneg would negotiate 1000base-T but due to the missing pairs, fail to work. This would be the expected outcome; there is no requirement for link segment testing, and most equipment doesn't do anything of the sort.Crossover 'matters' if neither side supports AutoMDIX, but I'd expect a test house to be using the 'correct' type of cable for their test environment regardless of AutoMDIX. Which type they should use depends on what they are wiring the DUT to.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 19, 2021, 11:30:03 pm
content: Why do you care what they say?

author: metrologist
author_rank: Super Contributor
timestamp: October 19, 2021, 11:59:05 pm
content: Guise, I just have an email. It's not a report. They are not testing a cable.They want to interface with the equipment via SCPI commands using our Ethernet port. They grabbed an old cat3 cable and spent a while trying to resolve a no communication issue. They emailed us back saying they figured out the problem, they used a cat5 cable and it worked fine; therefore, they conclude we have a design flaw because the "Ethernet specification" says cat3 cables should be supported.I'm trying to understand what the issue could be (if it's not just an old broken cable, and I'd expect they'd know better, or maybe not if they are using crusty old cat3 cables???). It was my mistake to assume they were using a 6p connector, and maybe they were, the email did not really say, but I now assume it's an 8P type of ethernet cable marked cat3.So, is it likely we have a design flaw and what could it be? I'm sure we are using a COTS Ethernet chip, I could probably find out which one. Maybe it's the PCB layout and pin configuration?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 20, 2021, 12:15:37 am
content: Quote from: metrologist on October 19, 2021, 11:59:05 pmSounds like a total non-issue - who hasn't got cat5 cables coming out of their ears?How many people have even heard of cat3?

author: ve7xen
author_rank: Super Contributor
timestamp: October 20, 2021, 12:20:58 am
content: I think people (myself included!) have misinterpreted your post to mean that a test house failed you on compliance and provided a report saying so, not that they simply had trouble using your product with a Cat3 cable. I don't think it's really reasonable to expect a Cat3 cable to 'just work' with modern equipment, it won't meet spec for 100base-TX or better, and almost all Ethernet interfaces are 'or better' these days. So outside of curiosity, this seems like a don't care to me.Does your product support 1000base-T (Gigabit Ethernet)? Pretty typical for a Cat3-era cable to only be two-pair, and if they were connecting it to 1000base-T equipment on both sides, a 1000mbps link will be negotiated, but fail to function at all with the missing pairs. It wouldn't meet the integrity requirements for > 10base-T anyway, even if it did link, so there would be no expectation of it working properly (though it likely would, at least for a short run), and most modern equipment is going to want to link up at 1000base-T.If it's 100baseTX or 10baseT, it could be a crossover issue, depending on whether your/their side does AutoMDIX or not. Almost any PC these days will do it, but an old switch or whatnot that's been sitting in their equipment rack for 20 years they might be plugging it into may not.You can mess up the PHY implementation, of course, but not really in a way where an improved cable spec would help (it mostly affects crosstalk and the like), at least that I can think of. This is typically all handled in the COTS PHY and you simply wire it to magnetics and the jack that are also purpose designed. I'd guess it's one of the above things (missing pairs, crossover, out-of-spec) or that the cable is simply bad.

author: metrologist
author_rank: Super Contributor
timestamp: October 20, 2021, 08:22:20 am
content: Thanks - yes - sorry - my OP was poorly constructed. Trying to squeeze something in between doing other things. I did mean to state in the title, Big TestEquipmentMFG...I don't have access to the specification but it seems reasonable that it would state backward compatibility, so I'd expect the system to fall back to 10Base-T, and if our implementation does not do that then I'd be inclined to agree with the customer. The interface supports gigabit, but would only be used for sending settings, like for a function generator. We even supply PC software with a simple interface for remote operation - as simple as entering the IP address.

author: wraper
author_rank: Unknown
timestamp: October 20, 2021, 08:44:23 am
content: Quote from: metrologist on October 20, 2021, 08:22:20 amIf the device on the other end supports more that 10Base-T, it's not surprising that connection would fail. I guess in such case you would need to manually limit your device to 10Base-T for it to work over crappy cable. Or neither or devices supports Auto MDI-X and require crossover cable to work (and they had a straight-through one).

author: tszaboo
author_rank: Super Contributor
timestamp: October 20, 2021, 10:30:37 am
content: Maybe they told you that, because your specification for the test wasn't appropriate (technical sense).Should it even support Cat 3 in the first place? Is there a sectional part of the standard that you should've asked for for the certification?Some testing house will know if your product will fail some obscure, outdated, or rarely used part of a standard, and only test that, and charge you full price for the testing. Because they will know, that 95% of the DUTs will fail and it is less effort for more money.

author: tooki
author_rank: Super Contributor
timestamp: October 20, 2021, 12:24:42 pm
content: A few thoughts/summaries in addition to what’s been said already:- I don’t have access to standards to check, but I suspect that backwards-compatibility is customary, but not required, because I think I’ve seen uplink ports on (gigabit or lower) switches that don’t support all lower speeds.- 10Gbps Ethernet ports seem to have dropped support for 10Mbps Ethernet. (I’m not sure about 2.5Gbps ports.)- 10Mbps Ethernet requires Cat 3 cable (using two pairs), but requires the 8P connector. It cannot be used on a 6P4C connector.- 100Mbps Ethernet requires Cat 5 cable, but still only uses two pairs.- Gigabit requires Cat 5 cable, but requires 4 pairs.- Typically if two gigabit devices are connected with a two-pair cable, it’ll drop down to 100Mbps. (There’s no fallback to 500Mbps or something.)- Auto-MDIX is mandatory for gigabit ports, but optional on lower speed ports. I want to say that I’ve seen or heard of ports that will not do auto-MDIX at 10Mbps, even if they support it at higher speeds.I agree with the suspicion that both devices support at least 100Mbps, and thus expected Cat 5 cable even when just two pairs are in use, so they tried running 100Mbps over Cat 3, which is unlikely to succeed, and indeed did not.Given the fact that Cat 5 patch cables were the norm even back in the heyday of 10Mbps Ethernet, Cat 3 cable certainly isn’t a usage scenario I’d worry about. I can’t even remember if I ever saw Cat 3 patch cables in the wild other than as pack-in cables with things like DSL modems. It seems to me that most Cat 3 cable was the stuff installed in the walls.

author: metrologist
author_rank: Super Contributor
timestamp: October 20, 2021, 02:13:25 pm
content: So I see mention of MDI and MDIX and what I see are two twisted pairs 8P4C, pins 1236. I also see token ring configuration using pins 3456. I suppose the latter would not be compatible with modern 10/100/1000 networks.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: October 20, 2021, 03:59:37 pm
content: Ask them to test some PCs with the suspect cable and confirm your device is specifically failing.Though if your interface is missing those nice features (AutoMDIX), the cable fault might be hidden because almost everything does support it. The question then would be, why doesn't yours? So, a possibility there, or have them try other cables, or more closely replicate your configuration in case it really is something.Tim

author: PaulAm
author_rank: Frequent Contributor
timestamp: October 20, 2021, 05:11:55 pm
content: And maybe, since they used a cable with an RJ11 connector, it was just an old phone cord.Who would plug in an RJ11 into an RJ45 jack and expect it to work?Even when I was running wires in the dim past, I only used Cat3 for phone lines and everything else was cat5. And that's gotta be at least 15 years ago.And I hear you say "phone line? what's a phone line?"

author: metrologist
author_rank: Super Contributor
timestamp: October 20, 2021, 06:23:38 pm
content: If I can get access to an instrument, I'd probably make or find a cable straight wired pins 1236 and try it through the LAN or direct to NIC. If both connections work then we don't have an issue on our end.

author: ve7xen
author_rank: Super Contributor
timestamp: October 20, 2021, 07:30:10 pm
content: Quote from: metrologist on October 20, 2021, 08:22:20 amThat's not the case. Autonegotiation is completely unaware of cabling limitations, and doesn't compensate for them. The two devices will negotiate their highest-common-denominator and attempt to establish link. If pairs are missing, and that HCD is 1000base-T (or 10GBASE-T), then link will simply fail to establish and the autoneg process will repeat ad infinitum. Some clever PHYs will retry autoneg without offering 1000base-T after repeated failed attempts, and succeed at 100base-TX link, but this isn't required (or even mentioned) by the spec, and I can confirm it is not implemented in many popular PHYs/drivers. Typically link will just fail if there are missing or broken pairs. If the cable is complete but out of spec (e.g. using Cat3 for 1000base-T), link may or may not come up, and may or may not work at an acceptable loss rate, it's simply operating out of spec, similar to going beyond 100m.tl;dr you should not expect a 2-pair cable to work at all between two 1000base-T+ interfaces, unless you manually force them 100mbps.And as tooki points out, the 10base-T PMA isn't required to be implemented, and modern equipment is starting to omit it, though plenty of 10GBASE-T stuff does.Auto-MDIX, if implemented on one side, should work even if it's not supported by the link partner, on any PMA including 10base-T (it happens prior to autonegotiation). It's actually optional for 1000base-T PHYs, but is almost always implemented; it's required as of 10GBASE-T.

author: Ranayna
author_rank: Super Contributor
timestamp: October 20, 2021, 07:43:25 pm
content: Huh, i don't think that that is correct about auto negotiation. At least not in any implementation i ever saw. It also does not really make sense. It should be trivial to detect that pairs are missing, so that gigabit negotiation would be pointless.It has been a while, but a couple of years ago, one of our office buildings was still wired with what we in germany like to call "Sparverdrahtung". Essentially one CAT 5 cable for a double ethernet jack, so just 2 pairs on 12 and 36.I do not remember that we ever had to set 100 Mbit/s on any of our networking gear. And it is not that the cable itself or the jacks did not support gigabit. In several instances where speed was required we re-wired the jacks on both ends to have one gigabit capable port, and those worked fine.

author: nctnico
author_rank: Super Contributor
timestamp: October 20, 2021, 08:51:41 pm
content: Quote from: tooki on October 20, 2021, 12:24:42 pmAFAIK Cat 5E actually. I had to redo a lot of wiring to replace plain CAT5 because it didn't work for 1Gbit.

author: ve7xen
author_rank: Super Contributor
timestamp: October 20, 2021, 09:28:00 pm
content: Quote from: Ranayna on October 20, 2021, 07:43:25 pmIt's correct. 802.3 says to always try the highest-common-denominator. The only way out is for one side to lower its advertised capabilities based on the link failures (or the administrator's awareness of the cabling limitations), to change the resolved HCD. Many 1000base-T PHYs do implement this (often called 'automatic downshift' or 'speed fallback'), kind of like AutoMDIX (though somewhat less common), but it's not part of the spec. In theory I suppose you could even do it in the driver. Many ports explicitly don't do this, particularly in networking equipment, as down link is often a better situation than a downgraded link, with the assumption that if this is desirable end-stations may implement it (and commonly do).Quote from: IEEE 802.3-2018 28.1.4

author: ejeffrey
author_rank: Super Contributor
timestamp: October 20, 2021, 10:04:59 pm
content: Quote from: nctnico on October 20, 2021, 08:51:41 pmReally? I've haven't looked a that extensively but I have never seen a cat5 cable fail at a gigabit speeds. The initial version of 1000Base-T specifically called for cat5 but with slightly modified specs -- I think only for NEXT which was not specified in the cat5 standard but which most existing cat5 cables supported. Cat5e was then published and cat5 withdrawn and the ethernet spec modified to call for cat5e.

author: metrologist
author_rank: Super Contributor
timestamp: October 21, 2021, 12:06:12 am
content: Regarding cat5 vs. cat5e, I think it may be because the spec is guaranteed to 100m. Who here has tested this? I think short runs, 3m patch cables, is why I see reported Gbit speeds on cat3.Some of the reporting here seems contradictory, but I am not a standards expert. Negotiating the highest common denominator is what I would expect. I only really care about what's happening at the port.So I took a peak at the digital board and foundhttps://www.ti.com/lit/ds/symlink/dp83867ir.pdfin qfn. I see all 16 data lines go off the backboneEdit: one thing I wanted to mention is that I had fiber installed and a new router. My PC had Gbit NIC, but I was only getting 10Mbps (simple speedtest.net). I changed the 10m patch cable and then got near the specified 1000mbps. I did not keep track of that cable.

author: ve7xen
author_rank: Super Contributor
timestamp: October 21, 2021, 12:37:44 am
content: Quote from: metrologist on October 21, 2021, 12:06:12 amYeah, the cable quality is likely only going to matter near the edges of the spec, in an alien crosstalk environment (ie. cable bundle) and when EMI is a problem etc. In practice you can use a compliant cable at considerably longer than spec'd distance and it will work fine, and likewise an underspecced cable will often work just fine too. Like any spec, it's 'guaranteed' to work when you are in compliance, and outside of that the behaviour is undefined, not guaranteed to break - and if it's going to break will break in the most annoying, intermittent way possible.The PHY doesn't normally do any evaluation of the cable quality, so if it has sub-par characteristics, it will generate errors and a high loss-rate, but link will almost certainly come up unless it's extremely bad, or as previously discussed, is missing pairs. Even a 'low' loss-rate of like 1% will have a serious impact on throughput in most applications, because it causes many retries and messes with the rate estimation / congestion control algorithms at higher layers. It's up to the user to supply appropriate cabling or configure the equipment to match the supplied cable's limitations, the spec will not aid you here.The PHY you found looks like it supports downshift (called 'speed optimization' here), but it seems to be disabled by default. AutoMDIX is also supported and enabled by default. So the most likely scenario is that the link partner also does not do speed downshift, and both sides were trying to link at 1G over a two-pair cable.

author: tooki
author_rank: Super Contributor
timestamp: October 21, 2021, 03:06:47 am
content: Quote from: nctnico on October 20, 2021, 08:51:41 pmNope. It’s a common misconception that gigabit requires Cat 5e. It does not.But 5e’s superior performance will get you a bit more length.I suspect that cases where replacing 5 with 5e made gigabit work are actually due to either the old cable being substandard, or even more likely, the jacks being terminated poorly. I’ve seen many a jack where the pairs were untwisted far too long, which 100Mbps might tolerate, but gigabit will not.

author: tooki
author_rank: Super Contributor
timestamp: October 21, 2021, 03:10:54 am
content: Quote from: ejeffrey on October 20, 2021, 10:04:59 pmEvery resource I’ve checked still says Cat 5, not 5e, as the minimum for gigabit.

author: Ranayna
author_rank: Super Contributor
timestamp: October 21, 2021, 12:19:40 pm
content: Wasn't there some change in the specs some years ago?I always heard that CAT 5e was essentially "backported" into CAT 5, making CAT 5e obsolete.

author: nctnico
author_rank: Super Contributor
timestamp: October 21, 2021, 01:30:43 pm
content: Quote from: tooki on October 21, 2021, 03:06:47 amWell, I have seen CAT5 cables fail at 1Gbit where CAT5E worked. The failing cables where only a few meters long. So explain that to me...

author: wraper
author_rank: Unknown
timestamp: October 21, 2021, 02:02:52 pm
content: Quote from: tooki on October 21, 2021, 03:06:47 amIt's not a misconception. CAT5 cable is not up to spec for gigabit ethernet. It should work for shorter runs or even may be as good as 5e spec but nothing is guaranteed.

author: rsjsouza
author_rank: Super Contributor
timestamp: October 21, 2021, 03:23:52 pm
content: Quote from: nctnico on October 21, 2021, 01:30:43 pmThat is my experience as well. The standard may say one thing, but for about a decade or so doing Eth evaluations in various scenarios I can tell that, in practice, GigE with anything longer that your run of the mill freebie-accessory length (1m or 1.5m) is extremely flaky with Cat5 and even ultra-cheap Cat5e. Reasonable quality Cat5e creates solid GigE connections.

author: ve7xen
author_rank: Super Contributor
timestamp: October 21, 2021, 07:31:20 pm
content: Quote from: tooki on October 21, 2021, 03:06:47 amWhen 1000base-T was specified, Cat5e didn't exist. So the standard references plain Cat5, but stipulates additional requirements that were not part of the Cat5 standard. These requirements were ultimately rolled into Cat5e. So while 1000base-T spec doesn't call out Cat5e, it does require cable that is more stringently specified than Cat5, and Cat5e meets those requirements.The new requirements were regarding return loss and several forms of crosstalk. I find it somewhat hard to believe that people had actual problems with Cat5 patch cables because they were not Cat5e, since most would be compliant anyway, and you can't really get them anymore even if you wanted to, but the specs don't offer any guarantees (without the specified RL/crosstalk parameters of the cable), I suppose. IME problems with cabling are practically always due to poor termination or damaged cable.

author: helius
author_rank: Super Contributor
timestamp: October 21, 2021, 08:02:52 pm
content: Quote from: ve7xen on October 19, 2021, 08:23:01 pm100baseT4 also operates over Category 3 cable (using 4 pairs).

author: tooki
author_rank: Super Contributor
timestamp: October 21, 2021, 08:44:49 pm
content: Quote from: Ranayna on October 21, 2021, 12:19:40 pmNo, the other way around: the Cat 5 standard was deprecated, meaning that the Cat 5e standard effectively replaced the Cat 5 standard.Quote from: wraper on October 21, 2021, 02:02:52 pmItisa misconception: as ve7xen said, the Cat 5e standard didn’t even exist when gigabit was created!Clearly, 5 is being pushed to its limits on gigabit, and it wouldn’t surprise me at all if low grade cables didn’t actually meet their claimed Cat 5 standard, which would explain those cables failing. (Noncompliant cables remain extremely widespread in the computer industry, and it’s only because we often are nowhere near length limits that some cables work at all.) Also, even a compliant cable could become noncompliant if mechanically abused, so this is another source of potential bad cables.It’s all academic anyway, since practically all Ethernet cable these days is Cat 5e, 6, or 7.Quote from: ve7xen on October 21, 2021, 07:31:20 pmThanks for the info!

author: tooki
author_rank: Super Contributor
timestamp: October 21, 2021, 09:05:40 pm
content: Quote from: nctnico on October 21, 2021, 01:30:43 pmCould have been noncompliant cable (just because a manufacturersaysit’s complaint doesn’t mean it is, see below), or it could have been poorly terminated, or it could have been fully compliant originally but degraded due to damage.Here’sa 2016 test of Cat 6 cables, finding that only 10% met the rated spec.Another test from a few years beforefound a compliance rate of just 30% for Cat 5e cables and 15% for Cat 6 cables.There’s no reason whatsoever to assume this has changed: most of the time the cables are short enough that it works anyway, and a few lost packets here and there aren’t noticeable anyway. But when we push cables to the limits of bandwidth and/or length, suddenly the noncompliant cables become problematic.We see these problems a lot more with HDMI, whose higher bandwidth requirements (and fairly low tolerance for bit loss, thanks to encryption) spotlight the cable problems. Ethernet is just better at masking bad cables…

author: ejeffrey
author_rank: Super Contributor
timestamp: October 22, 2021, 04:57:35 am
content: Quote from: Ranayna on October 21, 2021, 12:19:40 pmNo, the cat5e standard superseded cat5. Honestly anything sold recently as cat5 is somewhat suspect just on the grounds that it is claiming adherence to an obsolete standard.Quote from: nctnicoNew or old cable? Honestly any modern cable labeled as cat5 is suspect. It is a long obsolete standard and as far as I know reputable manufacturers haven't made it in ages. Old cables should be fine as long as they haven't been abused. My understanding at least is that the added specs for cat5e were A) already met by a lot of cat5 but with no guarantee or testing, and B) only required to reach the full 100 meter range including a wall jack and patch panel that interrupt the signal. A 5 meter patch cable directly connecting a device to a switch should definitely work and has worked in every situation I have tried although I haven't used cat5 cables in a long time.

author: wraper
author_rank: Unknown
timestamp: October 22, 2021, 06:51:41 am
content: Quote from: tooki on October 21, 2021, 03:10:54 amEvery resource I checked says that cat5 is sufficient only up to 100Base-TX, including Belden which makes these cables.https://www.belden.com/blogs/why-category-5e-cabling-is-becoming-outdatedQuoteHe also said that it had additional requirements for which Cat 5 spec was not sufficient.

author: mansaxel
author_rank: Super Contributor
timestamp: October 22, 2021, 07:02:04 am
content: Quote from: tooki on October 21, 2021, 09:05:40 pmAlso, Ethernet almost never is run even near its capacity. Sure, the packets are short and fast when they arrive, but there usually is lots of space between them, so retransmissions initiated by TCP will have space to happen, even if they mess the transmission speed up grossly. (A true CSMA/CD net, that is 10Mbit half-duplex, is another story, best forgotten in the bad memories from the 90s). Therefore, as long as there is capacity available, errors will be tolerable to most scenarios. If you're running a protocol that always puts frames on the wire, like SDH, which is much more like the transmission you'll see in HDMI or SDI or AES3 or S/PDIF, there is always a verifiable frame on the wire, increasing the statistical probability that stochastic errors will surface. Try "filling the cable" by running FTP with fast end systems that have tuned operating systems, and a bad cable will sour the day immensely.Similar situations exist with longer or more spliced/patched cables; there is a probable error rate per meter of bad cable, and there is a error rate per patch/IDC splice too; and of course they're cumulative.Finally, to put a metrology slant on this: There is reported verified difference in PDV (packet delay variation) between optical and electrical Gigabit Ethernet interfaces, and the reason for this is that there is a fair amount of error checking in the electrical interface that does not have to happen in the same way for the optical one. Of course, the differences are small, but if you are trying to build the best IEEE 1588-2008 (Precision Time Protocol) infrastructure possible, this will matter, since the assumption that packet time A->B == packet time B->A will not be true as often over copper as over fiber."All broadcast engineers are borderline time-nuts"(Another forum member to me, in privmsg)