Someone sizing the render-and-stream backbone behind an XR programme opens the switch box, finds a bundle of thick copper cables with the transceivers already moulded onto both ends, and treats them as interchangeable with the optical modules sitting in the next bin. They are not. A direct attach copper (DAC) cable is a fixed-length twinax assembly with a hard reach ceiling — typically a few metres — and no field-swappable optics. Pick it for the wrong run and you cap your rack layout before the first frame renders. DAC is not a lesser optical cable, and it is not a commodity you buy by the metre. It is a distinct interconnect class with a specific job: short, low-latency, low-power links inside a rack. The moment interconnect gets treated as an afterthought — “use whatever ships with the switch” or “put optics everywhere to be safe” — the topology decision has already been made badly. This piece explains what DAC actually is, where it stops working, and how to map it against optics before the GPU power-and-latency audit closes. What is a direct attach copper cable, and what does it mean in practice? A DAC cable is a length of twinaxial copper with the transceiver connectors permanently attached to each end. There is no pluggable optic, no laser, no fibre. The connector housing takes the same form factor as an optical transceiver — SFP+, SFP28, QSFP+, QSFP28, QSFP-DD — so it seats in the same switch and NIC cages, but electrically it is just shielded copper carrying the differential signal end to end. That “permanently attached” detail is the whole story. Because the cable and its connectors are a single assembly, you buy DAC at a fixed length. A 2m QSFP28 DAC is a 2m QSFP28 DAC; you cannot re-terminate it, extend it, or swap the optic when you re-cable the row. When you plan a rack around DAC you are committing to a physical geometry, not just a link speed. This is why the naive “grab the bundled cable” approach quietly bites later: the cable that shipped with a top-of-rack switch was sized for that switch’s assumed layout, not yours. In an XR deployment the relevant runs are the ones that carry render output and streaming traffic between GPU servers and the top-of-rack switch, and between servers on the same NIC fabric. Those are exactly the runs DAC was built for. A modern 800G-class fabric — the kind you see around an 800G NVIDIA ConnectX-8 NIC and its interconnect story — still leans on DAC for the shortest in-rack hops because copper wins on cost and power at those distances. Passive versus active DAC — and how that changes maximum reach The single most consequential distinction is passive versus active, because it sets the reach ceiling that constrains your topology. A passive DAC is exactly what it sounds like: shielded copper with no active electronics in the connector. The signal integrity budget is spent entirely on the copper, so reach is short. At 25G-per-lane and higher signalling rates, passive assemblies are typically usable up to around 3m; the faster the lane rate, the harder that ceiling falls. Passive DAC draws essentially nothing — on the order of 0.1W per end — because there is nothing to power. An active DAC adds a small signal-conditioning chip (an equaliser or redriver) in the connector to reconstruct the waveform, which buys distance. Active assemblies typically extend usable reach to roughly 5–7m at the same lane rates. They cost more than passive and draw slightly more power — still a small fraction of a watt, and still far below an optical link — because the electronics are minimal compared to a laser-driven transceiver. These reach figures are approximations tied to signalling rate and cable gauge, not fixed guarantees; the practical ceiling for a given assembly is what the vendor specifies for that speed grade. The reason they matter is topological. A 3m passive ceiling means every server a DAC serves must sit within about a rack-height of the switch. A 7m active ceiling opens up the adjacent rack or the far end of a wide rack, but not the next row. Cross that line and copper simply stops carrying a clean signal — you are into optical territory whether you planned for it or not. Quick reference: DAC reach and power by type Attribute Passive DAC Active DAC Optical (transceiver pair / AOC) Typical usable reach ~3m ~5–7m tens to hundreds of metres Power per link ~0.1W fraction of a watt ~1–3.5W Relative cost per link lowest low highest Field-swappable optics no no yes (transceiver pairs) Serialisation latency lowest lowest slightly higher Best fit in-rack, short hops in-rack / adjacent rack inter-row, inter-rack, long runs Reach and power values are approximations tied to signalling rate and cable gauge; treat them as planning bands, not guarantees. Verify against the assembly vendor’s specification for the exact speed grade. When should you choose DAC over optical transceivers or AOC in a GPU or XR rack? The decision is not “copper good, optics bad.” It is a reach-and-power mapping, and it resolves cleanly once you name the run. Choose DAC when the run is short — inside the rack, top-of-rack switch to server, or server to server on the same fabric — and the distance sits comfortably under the passive (~3m) or active (~7m) ceiling. In that zone DAC wins on all three axes that a GPU rack cares about: it costs a fraction of an equivalent optical transceiver pair, it draws roughly 0.1W versus the ~1–3.5W an optical link pulls, and it shaves nanoseconds of serialisation latency because there is no electrical-to-optical-to-electrical conversion in the path. Choose optics — pluggable transceiver pairs or an active optical cable, which we cover in its own explainer on when AOC beats copper — when the run crosses the copper ceiling, when you need the flexibility to re-terminate or re-route, or when the density of copper bundles becomes a thermal and cable-management problem in its own right. Optics also earns its cost where the fabric spans rows or racks; the tethered-XR host-to-headset interconnect case shows how the same reach logic plays out at the headset end of the pipeline rather than the switch end. A useful way to hold the trade-off: DAC is the default for anything that stays in the rack, and optics is the exception you reach for when reach, flexibility, or bundle density forces your hand. Inverting that default — optics everywhere “to be safe” — is the expensive mistake, because it inflates both the interconnect bill of materials and the per-rack power draw that a GPU audit is supposed to keep honest. Decision rubric: DAC or optics for this run? Answer these in order; the first “yes” that pushes you past a ceiling ends the DAC case: Is the run under ~3m and in-rack? → Passive DAC. Done. Is the run ~3–7m but still inside a rack or to an adjacent rack? → Active DAC. Does the run cross rows, exceed ~7m, or need to be re-routed later without recabling? → Optics. Is copper-bundle density already a cooling or airflow problem at the switch? → Optics, even under the reach ceiling. Do you need field-swappable optics for phased rollout or spares strategy? → Optics. If you answered “yes” to (1) or (2) and “no” to (3)–(5), DAC is the correct and cheaper choice, and defaulting to optics burns capex and watts for no reach benefit. What are the power, cost, and latency tradeoffs of DAC versus optics per link? The per-link numbers look small in isolation and decisive at rack scale. That compounding is the point. On power: a passive DAC draws on the order of 0.1W per end, while an optical link draws roughly 1–3.5W depending on the transceiver and speed grade (published transceiver specifications are the authority for any specific module). Multiply that delta across every in-rack link in a dense GPU rack and the difference stops being a rounding error — it becomes a line item in the rack power envelope. In a build where the network fabric itself can become the GPU bottleneck, spending watts on optics you did not need is spending them where they buy nothing. On cost: DAC assemblies cost a fraction of an equivalent optical transceiver pair — you are buying copper and connectors, not lasers and precision optics. This is an observed-pattern from how in-rack cabling budgets actually break down across GPU deployments, not a single benchmarked price ratio; the exact multiple depends on speed grade and vendor. The direction is stable regardless: copper is cheaper at short reach. On latency: DAC’s serialisation advantage is measured in nanoseconds, because it skips the electrical-optical-electrical conversion that a transceiver performs. For most workloads that difference is negligible. For tight render-and-stream loops in XR — where every stage of the pipeline is fighting the frame budget — nanoseconds of interconnect latency are worth keeping when they cost you nothing to keep. The claim here is bounded: DAC does not make a slow pipeline fast, it just declines to add avoidable latency on the shortest hops. What reach limits does DAC impose, and how do they constrain rack and row topology? Reach is not a spec you check at the end; it is a constraint you design around from the start. Because DAC is fixed-length and copper-limited, the reach ceiling draws an invisible boundary around every switch. With passive DAC’s ~3m ceiling, a top-of-rack switch can serve the servers within its own rack and not much beyond. That is fine — the top-of-rack model was designed exactly this way. With active DAC’s ~7m ceiling you gain the ability to reach an adjacent rack or the far corner of an oversized rack, which helps in end-of-row or middle-of-row switch designs. But the moment the topology requires a link from one row to another, or from a rack to a spine switch several metres away, copper is out and optics is in. The failure this prevents is the mid-build rewire. Teams that treat interconnect as a purchasing detail discover the reach ceiling only when a cable does not physically reach — or reaches but will not train a clean link — and then they are re-cabling a partially populated rack under schedule pressure, or retrofitting optics into a power envelope they already committed. Getting the mapping right up front means the topology and the cable class agree before hardware is ordered. FAQ How does direct attach copper cables work in practice? A DAC cable is a fixed-length twinaxial copper assembly with the transceiver connectors permanently moulded onto both ends, seating in the same SFP/QSFP cages as an optical module but carrying a plain electrical signal instead of light. In practice that means you buy it at a fixed length, cannot re-terminate or swap the optic, and commit to a physical rack geometry when you choose it — which is why grabbing the switch’s bundled cable without checking your own layout tends to bite later. What is the difference between passive and active DAC, and how does that affect maximum reach? A passive DAC is bare shielded copper with no electronics, so its reach is short — typically around 3m at high lane rates — and it draws essentially nothing (on the order of 0.1W). An active DAC adds a small signal-conditioning chip in the connector that reconstructs the waveform, extending usable reach to roughly 5–7m for slightly more cost and power. The reach ceiling each imposes directly determines which servers a switch can serve over copper. When should you choose DAC over optical transceivers or AOC in a GPU or XR rack? Choose DAC when the run is short and in-rack — top-of-rack switch to server, or server to server on the same fabric — and the distance sits under the passive (~3m) or active (~7m) ceiling, because copper wins on cost, power, and latency in that zone. Choose optics or an active optical cable when the run crosses rows, exceeds the copper ceiling, needs later re-routing, or when copper-bundle density becomes a cooling problem. The mistake is defaulting to optics everywhere “to be safe.” What are the power, cost, and latency tradeoffs of DAC versus optics per link? Per link, passive DAC draws on the order of 0.1W versus roughly 1–3.5W for an optical link, costs a fraction of an equivalent optical transceiver pair, and shaves nanoseconds of serialisation latency by skipping the electrical-optical-electrical conversion. Each delta is small in isolation but compounds across a dense GPU rack, becoming a real line item in both the capex and the rack power envelope. What reach limits does DAC impose, and how do they constrain rack and row topology? Passive DAC’s ~3m ceiling roughly confines a switch to the servers in its own rack, while active DAC’s ~7m ceiling reaches an adjacent rack or the far corner of an oversized one; anything spanning rows or reaching a distant spine switch requires optics. These ceilings should shape the topology from the design stage, because discovering them mid-build forces a rewire or an unplanned optics retrofit into an already-committed power envelope. How does interconnect choice feed the GPU power and latency budget that supports an XR rendering paradigm? Every in-rack link’s power draw and serialisation latency roll up into the per-rack power envelope and the render/stream loop’s timing budget, which is precisely what a GPU audit validates before hardware is committed. Choosing DAC for short runs keeps both numbers lower with no reach shortfall, so interconnect is not a cabling afterthought but an input the audit consumes. Interconnect is where a rack’s power and latency budget gets set quietly, one cable at a time — which is why it belongs inside the GPU planning work that validates a rack before hardware is committed, not bolted on after. Get the DAC-versus-optics mapping wrong and the audit is validating a topology the cabling cannot actually support; get it right and copper does its job invisibly, where it should.
