Bad PCIe cables can really mess up your lab and cause chaos in a data centre.
If you plug in a cable and nothing happens at all, you will ‘probably’ notice that it did not link up. Some other failures can be harder to detect, though.
Cables that break the specification in some minor way can work fine until a system upgrade and then suddenly you start to see problems.
We used our new Cable Tester to decode and validate the identification data on cables in our lab and found some interesting issues.
Active cables contain an EEPROM on each end, which allows them to communicate basic details to the host system. The Quarch Cable Tester can decode and display these.
Here is a part of a decode. I have cut off the rest to hide the manufacturer and avoid embarrassing them!
This is a 16g, 4x, Mini Multilane HD cable. You would not guess that from the decode, though!
External PCIe 4 cables with incorrect speed rating
These cables specify the data rate they run in an EEPROM register BUT the spec currently only goes to 8Gb/s (Gen3). There is a reasonable assumption over what the ID bits will be for Gen4, but it is not official and many Gen4 cables we have seen still only report as 8Gb speed compatible. If a later update in your system starts looking for Gen4 cable compatibility, it might cause an issue.
External PCIe 4 cable, No cable ID
There is an EEPROM register specified for Cable ID, which is a primary way to identify what the cable claims to be. As seen above, a major manufacturer set this to 0 (Unknown) instead of the correct value to specify it as a “Shielded Mini Multilane HD 4X”. If your system does not check this, it will not matter…for now.
SAS / PCIe Spec conflict
One cable that caused us trouble recently specified some information for both SAS and PCIe EEPROM values. This meant we were unable to work out which interface the cable was designed for.
Several cables we have tested appear to have unusual characters in strings, such as the vendor serial number. These are intended to be standard text characters for a user to read, but if they are not, then anything parsing the data later may fail. We had a problem in our own software where we were creating log files based on the serial number of the cable. The ones with bad characters caused an exception, as we had generated an invalid file name.
Summary
All these cables passed link training, mapping and BERT tests (testing for data corruption errors). They also show nice, clean eye-diagrams. They would all work fine IF you did not care about what they claimed to be. If your system reads and uses the EEPROM data in any way, there is a potential for problems.
Given that, I would suggest you verify the data loaded on by the manufacturer, to make certain the cable you buy today is not going to cause problems tomorrow!
