Define the acceptance question first
A sample test should answer whether the candidate module or cable works under a recorded set of host, software, port, channel and environmental conditions. “Link up” alone is not a sufficient acceptance criterion. Before the sample arrives, name the endpoint equipment, software/firmware, port mode, PMD, FEC, fiber path, traffic condition, test duration and responsible reviewer.
Use the exact production use case where practical. A result from a different switch family, an unknown software release or a short clean patch cord should be marked as limited evidence rather than extended to the final deployment.
Eight-stage validation record
- Identity and traceability: record purchase source, part number, serial number, hardware/revision labels, EEPROM/CMIS identity, host, port and both endpoints.
- Inspection and cleanliness: inspect packaging, latch and heat-sink condition. Inspect and clean optical connector end faces before mating, then record the method and any rejected item.
- Power-up and recognition: retain host commands showing module presence, identifier, speed capability, warnings and software version.
- Configuration: record active speed, lane mapping, breakout, auto-negotiation and FEC at both endpoints. Resolve mismatches before judging the sample.
- DOM baseline: capture temperature, voltage, Tx/Rx power, bias and alarm state per lane where available, together with ambient or chassis context.
- Traffic and error exposure: run controlled traffic or PRBS under a documented pattern, load and duration. Retain pre-FEC/raw indicators, corrected blocks, post-FEC/effective results and uncorrectable blocks.
- Stability and recovery: observe thermal behavior under representative adjacent-port loading; perform agreed port flaps, module reseats or host reboots and document recovery time and exceptions.
- Decision and archive: sign off pass, conditional pass or fail against written criteria. Preserve raw commands/CSV, photos, DOM snapshots, counter timelines and the tested sample identity.
Acceptance matrix
| Gate | Example evidence | Boundary to record |
|---|---|---|
| Physical/channel | End-face inspection, fiber type, connector, loss and polarity | Inspection method and actual route |
| Host recognition | Platform command output and absence/presence of warnings | Device and software release |
| Link quality | Traffic/PRBS, BER/FEC counters and link events | Pattern, load, duration and counter reset |
| Thermal stability | Temperature/DOM trend and host alarms under load | Airflow, ambient and adjacent-port state |
| Recovery | Port flap, reseat or reboot outcomes | Procedure, repetitions and recovery time |
Pass/fail language
Write conclusions narrowly: “passed in the recorded platform and configuration during this test window” is defensible. Avoid “universally compatible,” “zero-error” or “guaranteed” unless a separate controlled qualification and contractual definition supports the claim. A conditional pass should list the required software, FEC, port mode, temperature or channel restrictions.
Connector-inspection criteria should follow the project's accepted standard, connector type and customer contract. FEC/BER fields should retain the host's terminology and active mode. If a tool cannot expose a required metric, record the missing evidence and plan a second test rather than treating the absence as a pass.
Official implementation references
- OIF CMIS 5.0 — module identity, status, monitoring and management context.
- NVIDIA mlxlink utility documentation — link, module, FEC and BER observations available on supported platforms.
- Fluke Networks implementation guidance for IEC 61300-3-35 inspection — connector end-face inspection workflow and edition context.