FEC Corrected Errors Are Not Lost Packets: Read GPU Ethernet Evidence Correctly

Why corrections and clean packet counters can coexist

Forward error correction adds redundancy before transmission. Within the correction capability of the particular code, the receiver uses that information to recover the message before passing it upward. Cisco's explanation, updated May 13, 2022, describes this process and distinguishes the correction operation from retransmitting a frame. The capability depends on the code; the explanation supplies no universal acceptable error count.

That mechanism matters when a GPU Ethernet report shows correction activity beside a clean packet-error counter. The observations can coexist: correction may have dealt with an error before it became a packet error. Calling every correction a lost packet would erase the very distinction FEC introduces.

The opposite shortcut is also unsound. A clean packet counter does not establish that no correction occurred, and successful correction does not by itself establish remaining correction margin, future behavior or an acceptable channel. Those conclusions require evidence beyond an accumulated count.

References: [C1]

Keep the counted event with the number

The Linux ethtool netlink FEC_GET documentation defines corrected_blocks as received blocks corrected by FEC and uncorrectable_blocks as received blocks it could not correct. Its corrected_bits field counts individual corrected bit changes and is explicitly non-standard. These are separate quantities, with no packet-loss conversion supplied by their definitions.

A label such as FEC errors removes information the buyer needs. Restore the original field name and unit before interpreting the number. A corrected block records a correction event at the block level; it is not an additional independent fault to add to the bits corrected within that observation. An uncorrectable block likewise cannot be relabeled as one lost packet without evidence establishing that relationship.

References: [K1]

Driver-specific fields need their actual definitions

In the Linux kernel /next/ documentation for the mlx5 Ethernet driver, rx_corrected_bits_phy counts bits corrected under active FEC. rx_crc_errors_phy counts received packets dropped for frame check sequence errors. rx_pcs_symbol_err_phy counts symbol errors not corrected by FEC, or occurring while FEC is inactive. Similar-looking names therefore do not establish the same event unit.

The same document describes rx_bits_phy as traffic that could have been received. It names a corrected-bit ratio using rx_corrected_bits_phy and rx_bits_phy over a specific time frame. Preserve that driver-defined basis; do not substitute delivered payload bytes or turn a symbol-error count into a bit-error count.

For a proposed ratio, the reviewer needs corresponding numerator and denominator differences for the same port and interval, with their actual definitions. A dashboard heading saying BER does not supply that basis. These examples concern the cited mlx5 Ethernet documentation as read on October 20, 2026 UTC. They are not definitions for every NIC, switch, driver release or InfiniBand counter.

References: [K2]

Establish the interval and avoid double-counting

An accumulated value and its increase during an observation answer different questions. A difference is usable only when the two readings describe the same counter and continuous counting history. A reset, device replacement, counter rollover or changed collection scope must be resolved before a subtraction is interpreted as newly observed events. This is a condition for reading supplied evidence, not an instruction to reset or collect counters.

The ethtool FEC statistics representation places a port total before any lane/PCS-instance counts; support may provide no statistics, a total alone or a per-lane breakdown. Adding the total to its constituent lanes counts the same events twice. An absent or unsupported field is not an observed zero.

The report should also identify the active FEC mode. Preserve the installed device, driver and firmware context with the supplied result so its reviewer can establish which definitions and fields apply. The cited kernel pages are moving documentation branches, not evidence of the project's installed software.

References: [K1]

Work a fictional sixty-second observation

Consider fictional record EX-FEC-01 at one receiving port. Assume its supported fields have been identified and its counting history is continuous over the stated 60 seconds. The corrected-bit counter rises from 20,000 to 21,200; corrected blocks rise from 400 to 430; uncorrectable blocks remain at 5; and the CRC-dropped-packet counter remains at 2. All identities, readings and conditions are invented for this arithmetic example.

The interval differences are 1,200 corrected bits, 30 corrected blocks, 0 uncorrectable blocks and 0 CRC-dropped packets. The historical totals of 5 and 2 do not become new events merely because they appear in the final snapshot. Conversely, zero interval increases do not erase the earlier totals. The zero CRC difference concerns that named counter; it establishes no result for other loss mechanisms or GPU workload delivery.

There are not 1,230 independent faults and not 30 demonstrated lost packets. The two correction fields describe activity in different units. Dividing by the stipulated duration gives 20 corrected bits per second and 0.5 corrected blocks per second. These are event-count rates, not BER: the example supplies no applicable total-bit denominator. Nor does an average over 60 seconds reveal how activity was distributed within that interval.

A second record showing 600 corrected bits, without its duration or applicable bit-count basis, cannot be ranked as a better channel from the smaller number. Even a technically valid normalized comparison would still need the actual platform context and applicable acceptance requirement. This example establishes arithmetic and evidence limits, not measured performance or a pass/fail threshold.

Place fiber reports beside receiver evidence

A receiver counter observes the incoming direction at an identified endpoint. Relate it to both endpoint identities and the intervening assembly or channel. That locates the observation in the connection record; it does not identify which component caused it. A count at endpoint B is not, by itself, proof that a particular patch cord between A and B needs replacement.

For a separately defined passive-fiber path, Fluke distinguishes OLTS total insertion-loss measurement from OTDR characterization of events along the fiber. Connector inspection addresses the observed end face. Their measurement objects differ from a running receiver's correction activity. Keep the actual covered fibers, endpoints, measurement context and applicable criterion attached to each supplied optical result.

An optical PASS and ongoing corrections are therefore not automatically contradictory. The optical report answers its recorded physical question; the live observation concerns its receiver and operating conditions. First establish whether the records describe the same physical path and change state. Then determine what each leaves unresolved. Neither a clean CRC counter nor an earlier passive report fills the other's missing evidence.

The existing fiber-report guide develops OLTS, OTDR and inspection report review in detail. The additional question here is whether a proposed measurement can resolve the specific uncertainty exposed by the Ethernet evidence.

References: [F1]

Choose the next purchase by the open question

For cable remediation, ask what evidence identifies the affected physical item and supports the proposed correction. A quotation to replace fiber because a receiver corrected bits has not established the component-level cause. If a separately confirmed label, route or physical defect needs correction, scope that finding directly and retain the Ethernet investigation as its own question.

For another passive measurement, identify the missing physical answer. Overall insertion loss, a located event and an end-face observation require different evidence. Repeating an already applicable result without naming the unresolved question may add a file while leaving the buying decision unchanged. The responsible test owner should define the necessary method, coverage and criterion for that question.

For endpoint or network investigation, retain the exact counter semantics and the limited conclusions already established. If passive evidence covers its requirement but receiver behavior remains unexplained, the appointed network or equipment specialists need to assess that behavior in the actual system. Existing physical evidence can inform their investigation without proving that every possible physical cause has been excluded.

A useful proposal states which uncertainty its work will resolve and what evidence it will return. That gives the buyer a basis for comparing remediation, additional measurement and endpoint investigation without pretending that one counter selects the answer.

Scope the physical-verification request

For a physical-verification inquiry, share the site, affected connection identities, available physical records and the specific inspection, documentation or measurement question. Leviathan can discuss agreed visual, cable-ID, labeling and physical-connectivity checks, defect records and handoff documentation through its physical-verification service.

Formal OLTS, OTDR or other measurements require confirmation of the actual equipment, qualified personnel, method, coverage and acceptance criteria for the engagement. Endpoint diagnostics and network/software commissioning remain with the appointed specialists. This article explains evidence for a purchasing decision; it supplies no field procedure or approval to work on a live connection.