OCP Global Summit 2026 | Microsoft, Marvell, Ranovus | Edi Roytman, Lenin Patra, Jeff Hutchins, Greg Link | Scale-up Optical Reliability and GPU Resiliency to Link Flaps

1. One Workshop, Three Links in the Supply Chain

This was the Short Reach Optical Interconnect workshop of the OCP Future Technologies Symposium. Moderator Edi Roytman is listed on the slides as Senior Distinguished Engineer at Marvell (ex-Microsoft), and the three speakers map neatly onto the three segments of a link: Lenin Patra, SVP of Data Center Architecture at Marvell, on silicon and telemetry; Jeff Hutchins, Director in the Ranovus CTO office, on optical modules; and Greg Link, who leads firmware architecture for Microsoft's Cobalt and Maia product lines, on the GPU system side.

We have already covered Oracle's breakdown of NPO flap sources and Meta's LPO interruption-rate data. Both ask whether the optics will flap. This session asks the next question: flaps will happen, so how does the GPU job survive? Link opened by changing the definition: "There is no such thing as a link flap, only link down and link up. I don't detect flaps; I detect a link down and hope it comes back."

The metric of success is not link uptime, but uninterrupted AI job execution.

2. The Scale Math: Even a Rare Event Becomes Hourly Across a Hundred Thousand Lanes

Marvell's Patra first cited a 2025 industry model (labeled "2025 MODEL" on the slide): about 3 million GPUs and more than 10 million optical links, with one flap every 48 seconds on average. STT back-calculation: 75 flaps per hour divided by 10 million links is at most about 7,500 FIT per link (7,500 events per billion hours). Each link looks stable; the problem is the count.

Microsoft's table brings this down to a single pod. It is explicitly "not indicative of field data", just a sweep of Flap-FIT from 10 to 1 million and pod sizes from 16 to 1,024 GPUs. Working backwards from the numbers, the table assumes 128 lanes per GPU.

▲ Microsoft's sweep of Flap-FIT versus pod size: at a Flap-FIT of 10,000, a 1,024-GPU pod flaps on average every 0.76 hours, with a 50% chance of hitting the first flap within 30 minutes (Image source: Microsoft | 2026 OCP Global Summit presentation (p. 28))

Flap-FIT	MTBF, 128 GPUs	MTBF, 1,024 GPUs	Flaps per day, 1,024 GPUs (STT estimate)
100	610 hours	76.3 hours	about 0.3
1,000	61.0 hours	7.63 hours	about 3
10,000	6.10 hours	0.76 hours	about 31

▲ As a pod grows from 16 to 1,024 GPUs, MTBF shrinks 64x; at the roughly 7,500 FIT back-calculated from the 2025 industry model cited by Marvell, a thousand-GPU pod flaps about once an hour (Image source: Simple Tech Trend original, data from Microsoft, Marvell 2026 OCP Global Summit presentation)

For a 1,024-GPU pod to flap only once a week, Flap-FIT per lane would have to fall to about 45 (STT estimate). Link also cautioned that the 0.1 FIT figure quoted by an earlier speaker is most likely a permanent hardware failure rate, not a flap rate, and the two should not be mixed. Optical quality is necessary, but on its own the math for a 1,024-GPU pod does not work.

3. The GPU Side: When One Lane Drops, Does the Job Die With It?

Why do switches cope while GPUs don't? Link's explanation: an AI job is a dependency graph, and once a message is queued in a given NIC it has to leave from that NIC. If the NIC's lanes go down and the data is stuck, the graph cannot complete, and customers would rather abort than wait minutes for a lane to return. TCP retransmission is tied to a fixed source and destination; MRC can switch paths, but the data is already inside that NIC, and pulling it out to another one means rewriting the software stack.

He used an 800G, four-lane NIC as the example (borrowed, he said, from Meta's NIC):

• 1x800 mode: one lane flaps, the whole endpoint fails, and the job aborts.

• 4x200 mode: one lane flaps, the link degrades to 3x200 or 2x200, and the job keeps running.

• All four flap together: the NIC is blocked, and the job survives only if traffic can be moved to another NIC in time.

The key is the probability of that last case. If the four lanes sit in the same flap fault domain (same laser, same connector, same optical engine), multi-lane flaps are "quite common"; spread across different fault domains, the probability falls to roughly P^4.

▲ Three configurations of the same 800G endpoint: in 1x800, a single lane flap aborts the job; 4x200 within one fault domain can hang as a group; with 4x200 across fault domains, the probability of all four dropping together is about P⁴ (Image source: Simple Tech Trend original, data from Microsoft 2026 OCP Global Summit presentation)

This collides head-on with the integration trend. Microsoft's slide is explicit: moving from QSFP and OSFP to 32–64 lane OBO, XPO and CPO puts more lanes on every fault domain, every laser and every connector. Pluggable and on-board optics spread lanes using copper traces on the board (swizzling), and Link admitted this intermediate stage has the worst routing crossover issues; with CPO the swizzling moves inside the SoC die, which he thinks actually gets easier in some ways, at the cost of optical engines (E/O) that cannot be replaced individually.

4. Recovery Speed: Marvell Writes the Timescales Out in Five Layers

Marvell's answer is "3R": redundancy (independent data paths, so no job abort), resiliency (local hardware detection and failover without waiting for software) and reliability (telemetry and fleet remediation to cut repeat flaps). The product behind it is RELIANT telemetry, which states the recovery time at each layer:

• Physical layer (PCS plus optical PMD): real-time monitoring of BER, lane errors, FEC bins and equalizer statistics

• Link-level retry: near-instant retransmission of failed transactions

• Link-layer traffic management: load balancing, rerouting and CBFC, under 1 millisecond

• Application layer: workload recovery using shadow state, about 500 milliseconds

• System layer: fleet health and orchestration, over 1 second

▲ The five-layer architecture and recovery times of Marvell's RELIANT telemetry: under 1 ms at the link layer, about 500 ms at the application layer, and over 1 s at the system layer (Image source: Marvell | 2026 OCP Global Summit presentation (p. 14))

Another Marvell table is candid: scale-up optics beat copper on reach (over 20 meters) and bandwidth per AI SoC (over 50 Tbps per direction), tie on pre-FEC BER (below 1e-9) and FEC latency (below 75 ns), and lose on flaps (target: under 1% of links) and in-field serviceability. This is the same line as the scale-up optics strategy we covered in Marvell Investor Day 2026; this time it fills in the reliability side.

In Q&A someone asked bluntly: predictive failure has been promised for decades and never worked, so what is different now? Patra's answer was small language models deployed across the fleet and on MCUs to catch early signals such as a slight drop in laser power. No public accuracy data backs this claim yet.

5. The Module Side: Low Latency and Low BER Push Scale-Up Toward Slower Lanes

Ranovus' Hutchins came at it from the other end. Scale-up uses flow control such as CBFC, where the next block is sent only after the previous one arrives correctly; when retries exceed the limit, the result is a link flap. So the target is not average BER but burst errors.

Taking a maximum retry rate of 3.2e-5 as the example:

• Ethernet RS(544,514) FEC with random errors only: a BER of about 1e-3 is enough

• Same FEC, allowing only 3 codeword errors to leave burst margin: BER must be about 3e-5

• PCIe6-style CRC with weak FEC (lower latency): BER must be about 1e-8

▲ Ranovus' retry-rate analysis: the weaker the FEC and the lower the latency, the tighter the random BER requirement, from about 1e-3 to about 1e-8; lowering the line rate is one path, and OCI-MSA is a recent example (Image source: Ranovus | 2026 OCP Global Summit presentation (p. 22))

The chain of reasoning is clear: low latency needs weak FEC, weak FEC needs low BER, and low BER pushes toward lower lane rates. His example was OCI-MSA, a spec we broke down in Meta, Broadcom and AMD Define the OCI 200G Line-Side Spec. Hutchins also listed seven categories of burst-error sources, from mechanical shock, thermal and power-supply transients, connector dust and MPI, to laser reflections and firmware interoperability; some can be detected early, others appear suddenly. The moderator added that connector contamination is one of the leading causes of flaps; Hutchins' view was that when dust makes insertion loss jump sharply the receiver runs into trouble, and he could not think of a good link-level remedy.

6. Risks and Counterarguments

• The table is not field data: Microsoft's MTBF table is only an assumed range, and 128 lanes per GPU is an STT back-calculation; Marvell counts "links" while Microsoft counts "lanes", so 7,500 FIT is an order-of-magnitude reference only.

• Redundancy costs money: Link himself pushes back on some redundancy; one extra NIC is 25% (out of four) to 2.5% (out of forty) of idle performance, and moving perf/TCO by even 3% needs a compelling reason.

• Early 200G flaps more: in Q&A a panel speaker acknowledged that first-generation 200G flaps more than mature 100G and expects convergence with volume, but gave no numbers.

• CPO may not be the flap cure: CPO has lower end-to-end power and higher bandwidth density, but deeper integration puts more lanes on every fault domain, laser and connector, and the optical engine cannot be serviced on its own.

7. What It Means for Taiwan's Supply Chain

• The slides name no Taiwanese companies, so this section covers positions only, without company pairings.

• Board and rack design: lane swizzling for pluggable and on-board optics is done with copper traces on the board, which is system ODM design work. Fault domains will become a new design rule for scale-up motherboards, not just an optical-module issue.

• Optical modules and connectors: Microsoft listed the data it wants from suppliers, including long-term laser and module reliability, connector tolerance to dust and assembly variation, and flap statistics from pod-scale PoCs. Ranovus called for standardized burst-error test methods. Being able to deliver this data is closer to the scale-up procurement bar than yield alone.

8. Conclusion

This workshop moved the optical scale-up debate from "will the optics fail" to "will the job stop when they do". By Microsoft's math, flap intervals in a 1,024-GPU pod are measured in hours, and even an order-of-magnitude improvement in optics does not get past a day. What turns a flap into lost bandwidth instead of a job abort is multi-ported NICs, lane layouts that span fault domains, millisecond-scale local failover, and telemetry that can tell the system how long a link-down will last.

In 2026 OCP APAC Summit | Broadcom | CPO's Third-Generation Report Card we saw component-level reliability improving; this session is the reminder that once the component data is in, the GPU-side fault domains and software stack are the next gate.

In the copper era GPUs rarely had to learn to handle flaps; in the optical era they must. Whoever builds that into the NIC and XPU first gets the ticket to 1,000-GPU optical pods.

This article is for technology and industry trend analysis only and does not constitute investment advice.