Before you replace a transceiver, read its DOM. Two numbers — transmit power and receive power — split a dead link into three buckets in under a minute: the module isn't transmitting, light isn't arriving from the far end, or light is arriving fine and the problem is configuration. Most optics that get returned as faulty are transmitting normally.
What DOM is
Digital Optical Monitoring, also called DDM (Digital Diagnostics Monitoring), is a set of live measurements the transceiver reports about itself over its management interface. Every modern optic supports it. The core readings are:
- Transmit power — how much light the module is putting into the fiber, in dBm
- Receive power — how much light is arriving from the far end, in dBm
- Transmit bias current — the drive current feeding the laser, in mA
- Module temperature and supply voltage
On parallel optics — SR4, DR4, SR8 — power and bias are reported per lane. That per-lane detail is the single most useful thing in the output, and we will come back to it.
How to read it
On Linux, ethtool -m <interface> dumps the module's diagnostic page. On NVIDIA ConnectX hardware, mlxlink -d <device> -m gives a cleaner formatted view. Switch platforms have their own equivalents — Cisco, Arista and Juniper all expose transceiver diagnostics from the CLI.
Whatever the tool, you are looking for the same handful of numbers.
The three-bucket triage
Bucket 1: transmit power is low or absent
If the module's own Tx power reads far below its rated launch power, or reads as no light at all, the problem is on your side of the link and it is not the fiber. Either the module has failed, it is not fully seated, the port is administratively down, or the module is in a low-power state because the host hasn't brought it up. Check seating and port state before condemning the optic.
Bucket 2: transmit is normal, receive is absent
Your module is putting light into the fiber and nothing is coming back. The fault is in the path or at the far end. In rough order of likelihood: wrong or incompatible patch cord, a contaminated connector, polarity error, a break or excessive bend in the run, the far-end module not transmitting, or the far-end port being down.
This is the bucket where people swap modules and change nothing, because the module was never the problem.
Bucket 3: both powers are healthy and the link still won't come up
Light is crossing the link in both directions and the physical layer is fine. What's left is configuration: FEC mismatch, speed or lane-width mismatch, auto-negotiation disagreement, protocol mismatch (InfiniBand versus Ethernet), or a coding or compatibility rejection at one end. Nothing you do to the fiber will help.
The per-lane tell
On a four-lane or eight-lane parallel optic, compare the lanes against each other. Three lanes reading healthy and one reading several dB low is not a failing module — modules do not usually fail one lane at a time. It is almost always a single contaminated or damaged fiber position in the MPO path.
That is a repair you can make in five minutes with an inspection scope and a cleaner, and it is invisible if you only look at aggregate link state. See our guide to MPO inspection and cleaning for the procedure.
The loss budget, and why connectors are the whole story
The optical loss budget is simple arithmetic: the module's minimum launch power minus the receiver's sensitivity gives you the total loss the link can absorb. Everything in the path spends against that budget.
What spends it:
- Connector junctions — up to about 0.75 dB each for standard-grade MPO, 0.35 dB or lower for low-loss grade
- Fiber attenuation — on the order of 3 dB per kilometer for OM4 at 850nm, around 0.35 dB per kilometer for OS2 at 1310nm
- Splices — typically small, but they count
Now run the numbers for a real data center link. A 50-metre OM4 run contributes roughly 0.15 dB of fiber attenuation. A single standard-grade connector junction can contribute five times that. At data center distances the fiber is essentially free and the connectors are the entire budget.
This is why a path through two patch panels — four connector junctions — can be marginal at 50 metres while a point-to-point cord at the same length has enormous headroom. It is also why NVIDIA's 50m OM4 rating for the MMA4Z00-NS400 already assumes two patch panels in the link rather than treating that as headroom on top. Add junctions beyond that and you have to derate.
Practical consequence: specify low-loss connectors on anything that will sit in a structured path. The price difference is small and it is the difference between a link with margin and a link that works until someone touches the panel.
Secondary signals worth reading
Bias current rising while transmit power falls. The module is driving the laser harder to hold output. That is the classic signature of a laser approaching end of life. It is not urgent, but it is a module to schedule out rather than wait on.
Temperature near the top of the operating range. High-density 400G and 800G modules run hot, and an optic that is thermally stressed will show degraded margin before it shows hard errors. Check airflow direction and whether every port in a fully populated switch is getting the cooling the module needs.
Supply voltage out of range. Rare, but it points at the host or the cage rather than the module.
What DOM will not tell you
DOM is an optical measurement. It is blind to several of the most common link failures:
- Polarity errors. A Type A cord where Type B was needed puts transmit into transmit. Your Tx power reads normal, your Rx power reads nothing, and everything looks like a broken fiber.
- FEC mismatch. Both sides are transmitting healthy light and the link still will not train.
- Coding or compatibility rejection. Some platforms refuse a module regardless of its optical health.
- Errors after the link comes up. A link can be up, passing traffic, and quietly correcting a high raw error rate. DOM shows healthy power; the error counters tell the real story.
For that last one you need link-layer counters rather than optical readings. On NVIDIA hardware that means mlxlink -c, covered in our field guide to mlxlink and mst.
A working sequence
- Read DOM on the local module. Note Tx and Rx power, per lane.
- No Tx? Check seating and port state before anything else.
- Tx fine, no Rx? Read DOM on the far end. If the far end is also transmitting, the path is at fault — inspect and clean, then verify polarity.
- One lane low out of four? Contamination in that fiber position. Inspect and clean.
- Both directions healthy, no link? Stop looking at the fiber and start comparing FEC, speed, lane width and protocol settings on both ends.
- Link up but erroring? Move to counters and BER.
Frequently asked questions
What is a normal receive power reading?
It depends entirely on the module type, and you should compare against that module's datasheet rather than a general rule. What matters more than the absolute number is the relationship: receive power should sit comfortably between the receiver's sensitivity floor and its overload threshold, with margin at both ends. Too much light is also a fault — a short single-mode link without attenuation can saturate a receiver.
My module reports no receive power at all. Is the fiber broken?
Possibly, but check the cheaper causes first. A polarity error, a connector that is not fully seated, a dust cap left on, or the far-end port being administratively down all produce exactly the same reading.
Can DOM tell me whether a third-party transceiver is safe?
DOM tells you whether it is operating within spec, which is the meaningful question. A module reporting launch power, bias current and temperature inside its rated ranges is doing its job regardless of whose label is on it.
Why is one lane lower than the others?
Almost always a single contaminated or damaged fiber position in the MPO path rather than a module fault. Inspect the endface before replacing anything.
Should I monitor DOM continuously?
Trending Rx power and bias current over time is genuinely useful for catching degradation before it becomes an outage. Note that some vendor diagnostic tools are explicitly not designed for continuous polling — NVIDIA says this of mlxlink — so use your monitoring platform's transceiver telemetry rather than scripting a diagnostic CLI in a loop.
Does DOM work on DAC and AOC cables?
Passive DAC has no optics and no meaningful DOM. Active optical cables and active copper report diagnostics much like a transceiver does, because they contain the same class of electronics.
Related reading
- mlxlink and mst: a field guide to diagnosing ConnectX and Quantum links
- The dirty connector problem: MPO inspection and cleaning
- MPO-12/APC vs UPC: why your existing fiber won't work with NDR optics
- Why a 25G or 100G link won't come up: FEC mismatch explained