You finish the algorithmic redesign that turns a multi-day RF propagation simulation into a few hours on a GPU cluster, size the nodes, order the switch — and then someone asks what cables connect the nodes to it. The honest answer is that the cabling decision is not an afterthought. It quietly caps how far the algorithmic gains scale, because the interconnect is where a parallelised workload either stays coupled or starts stalling on communication overhead. Direct attach copper (DAC) is the right link for short, in-rack GPU-to-switch hops — and knowing exactly where it stops being right is the whole point of this article.

The failure pattern is predictable. A team treats cabling as whatever ships with the switch, wires the first rack, sees it work, and assumes the same choice extends to the next row. Then node count grows, the topology spreads beyond a rack, port speeds climb, and the copper links that were fine at 3 metres either won’t reach or won’t run clean at the higher signalling rate. At that point the fabric becomes the new serial bottleneck — the exact thing the GPU port was meant to remove.

What should you know about direct attach copper in practice?

A DAC is a fixed assembly: two transceiver-shaped connectors (SFP+, SFP28, QSFP28, QSFP-DD, OSFP, depending on the port) with a length of twinaxial copper cable permanently bonded between them. You don’t plug a separate optical module into a cage and then run fibre — the connector housings and the copper are one part. Electrically, the host’s SerDes drives the signal straight down the copper pair to the switch’s SerDes at the other end. There is no electrical-to-optical conversion, no laser, no photodiode.

That absence is the whole story. Because a passive DAC has no active components inside the connector, it draws essentially no power beyond what the ports already spend on their SerDes, and it adds almost no latency — the signal is just electrons on a wire over a couple of metres. Compared with an optical transceiver, which has to run a laser and its driver, a DAC link saves roughly a watt or two per link (vendor-published transceiver and DAC power specs; compare a given part’s datasheet). In a single-node lab that is noise. Across a fabric with hundreds of links, it is a real line item in both the power budget and the cooling budget.

The trade-off DAC makes is reach. Copper attenuates and picks up crosstalk as frequency rises, so the faster the link, the shorter the cable can be before the signal degrades below what the receiver can recover. This is why a DAC is a deliberate short-reach choice, not a general-purpose one. When it fits, it is the cheapest, coolest, lowest-latency way to get a GPU node onto the switch. When it doesn’t, forcing it is how you introduce link errors that show up as retransmits and tail latency in your collective operations.

Where does DAC fit in a GPU simulation cluster versus optical interconnect?

Think of the fabric in two zones. Inside a rack, the top-of-rack switch sits a metre or two from the GPU nodes it serves. Those GPU-to-switch hops are short by construction, and DAC is the natural fit — low cost, low power, low latency, and no optical modules to fail. Between racks, across rows, or up to a spine switch, the distances jump to tens of metres, and copper simply cannot carry the signal that far at cluster speeds. That is optical territory: either active optical cables (AOC), which bond the transceivers to a fibre in one assembly, or pluggable optical transceivers with separate fibre runs.

The decision is not DAC-versus-optical as a philosophy. It is a per-link question answered by two variables: distance and port speed. A short link at a moderate speed is a DAC. A long link, or a short link at a very high speed, is optical. Most well-designed simulation clusters use both — DAC for the dense in-rack layer, optical for the row-to-spine layer — and the skill is drawing the line correctly rather than picking one for the whole build.

DAC vs optical: which link for which hop?

Link characteristic	DAC (passive)	DAC (active)	AOC	Optical transceiver + fibre
Typical reach	~1–3 m (shorter as speed rises)	up to ~5–7 m	~3–30 m	tens of metres to km
Power per link	~0 W beyond SerDes	~0.5–1.5 W	~1–2 W each end	~2–5 W+ each end
Latency added	lowest	low	low	low, plus conversion
Relative cost	lowest	low	moderate	highest (module + fibre)
Best zone	GPU-to-ToR, in-rack	slightly longer in-rack	intra-row, tight ToR-to-spine	row-to-spine, cross-room

Reach and power figures are directional and vary by connector standard, cable gauge, and speed — read the specific part’s datasheet before committing a topology (vendor-published specifications).

For the optical side of this same decision, our explainer on how active optical cables work and when AOC beats copper covers the reach and power trade-offs from the fibre end. The two articles are the two halves of the same fabric-layer choice.

What are the reach and port-speed limits of DAC, and when do you switch to optical?

There is no single number, because the reach ceiling moves with the port speed. A 10G or 25G link tolerates a longer copper run than a 100G or 400G link, because the higher the signalling rate, the more the copper’s frequency-dependent loss bites. As the industry pushes from 25G-per-lane to 50G and 100G-per-lane PAM4 signalling on 400G and 800G ports, the practical passive-DAC reach shrinks — often to around a metre or two at the top speeds (vendor-published DAC reach specifications by standard). This is exactly why the 800G class of interconnect leans harder on optical and active copper; our note on the 800G ConnectX-8 NIC and when interconnect matters sits on the same escalation curve.

The signal-integrity trigger to switch is not a clean threshold you cross once. In practice you watch for it: link training that takes multiple attempts, forward-error-correction (FEC) counters climbing, or intermittent link flaps under thermal load. When a copper link is marginal, it usually works on the bench and fails under sustained cluster load — the worst possible time to discover it. The safe rule is to stay well inside the vendor’s rated reach for your port speed rather than at its edge, and to move to optical the moment a run would leave the rack.

A worked reach-budget example (illustrative)

Assume a 400G leaf-spine build. Each rack has 8 GPU nodes and one top-of-rack switch mounted centrally, so the longest GPU-to-ToR run is about 2 metres. The spine switches sit two rows away, roughly 25 metres of cable path once you account for tray routing.

• GPU-to-ToR (2 m, 400G): inside passive-DAC reach for 400G in most vendor tables — use DAC. Power saved versus optical: on the order of a few watts per link, times 8 nodes per rack, times the rack count.
• ToR-to-spine (25 m, 400G): far beyond copper reach at this speed — use optical transceivers over fibre. No DAC option exists here regardless of cost.

The point of the example is not the exact metres. It is that the same 400G fabric wants both link types, and the boundary falls at the rack edge — which is where you should expect it to fall in most simulation-cluster topologies.

Does interconnect choice affect whether a GPU-accelerated simulation scales across multiple nodes?

Yes, directly, and this is the part teams underestimate. A multi-node simulation — RF propagation, physics solvers, any workload that partitions across GPUs — spends real wall-clock time in inter-node communication: gradient or state exchange, halo swaps, all-reduce collectives over NCCL or the fabric’s equivalent. If those exchanges are tightly coupled, the fabric’s latency and sustained throughput sit directly on the critical path. A link that adds latency or drops into FEC-heavy error recovery under load erodes the parallel speedup you paid a GPU port to get.

DAC helps here in two ways that compound at scale. Lower per-hop latency on the in-rack links keeps tightly coupled nodes responsive, and lower per-link power means more of the rack’s thermal and electrical budget goes to compute rather than to interconnect. When many planning scenarios per day depend on that node coupling, sustained fabric throughput — not the peak number on the switch datasheet — is what preserves the multi-day-to-hours speedup as the cluster grows. This is the same lesson our piece on MLOps architecture for GPU clusters draws from the operations side: the fabric is a first-class design variable, not plumbing.

Interconnect choice is also one of the fabric decisions a proper GPU audit has to account for before it certifies that a parallelised workload will actually scale. Deciding whether a simulation needs algorithmic redesign for GPU acceleration is only half the work; the other half is confirming the cluster it lands on won’t re-serialise it at the wire. You can start that conversation from our GPU acceleration practice page.

What are passive versus active DAC cables, and when do you need active?

A passive DAC is just the twinax and the connectors — no electronics. It relies entirely on the host and switch SerDes to drive and equalise the signal. It is the cheapest, lowest-power option, and it is the right default for the shortest links.

An active DAC adds signal-conditioning electronics (equalisers, sometimes retimers) inside the connector housings to clean up and re-drive the signal. That lets copper reach a little farther — a few extra metres — at a given speed, at the cost of a small amount of power (still well below an optical transceiver) and a slightly higher price. You reach for active DAC when a link is a touch too long for passive at your port speed but still short enough that going optical would be overkill.

The ordering of the choice is: passive DAC first, active DAC when passive won’t reach, optical when even active copper won’t. Skipping straight to optical for a 2-metre link wastes power and money; forcing passive copper across a marginal run wastes debugging time chasing intermittent FEC errors. The discipline is matching the link type to the actual distance and speed of each hop.

FAQ

What does working with direct attach copper involve in practice?

A DAC is a single fixed assembly — transceiver-shaped connectors bonded to a twinaxial copper cable — that carries the electrical signal straight from the host’s SerDes to the switch’s SerDes with no optical conversion. Because a passive DAC has no active components or laser, it adds almost no latency and draws essentially no power beyond the ports themselves. In practice it is the cheapest, coolest, lowest-latency way to connect a GPU node to a nearby switch, at the cost of limited reach.

Where does DAC fit in a GPU simulation cluster versus optical interconnect (AOC or transceivers)?

DAC fits the short, in-rack GPU-to-switch hops, where the top-of-rack switch sits a metre or two from the nodes. Optical — active optical cables or pluggable transceivers over fibre — takes over for row-to-spine and cross-room links measured in tens of metres. Most well-designed clusters use both, and the design skill is drawing the boundary per link based on distance and port speed rather than picking one type for the whole build.

What are the reach and port-speed limits of DAC, and when do you have to switch to optical?

There is no single reach number because the ceiling shrinks as port speed rises: copper’s frequency-dependent loss bites harder at 100G, 400G, and 800G, often cutting passive-DAC reach to a metre or two at the top speeds. Switch to optical when a run leaves the rack, or when signal-integrity symptoms appear — repeated link training, climbing FEC counters, or link flaps under sustained thermal load. Stay well inside the vendor’s rated reach for your speed rather than at its edge.

How much power and cost does DAC save per link compared with optical, and why does that add up at cluster scale?

A DAC link saves roughly a watt or two per link versus an optical transceiver, which has to power a laser and its driver, and it costs less because there is no optical module. On a single node that is negligible, but across a fabric with hundreds of links it becomes a real line in both the power and cooling budgets — power the rack can then spend on compute instead of interconnect.

Does interconnect choice affect whether a GPU-accelerated simulation scales across multiple nodes?

Yes. A multi-node simulation spends real wall-clock time in inter-node communication such as all-reduce collectives over NCCL, and that traffic sits on the critical path when nodes are tightly coupled. A link that adds latency or drops into error recovery under load erodes the parallel speedup, so sustained fabric throughput — not peak switch specs — is what determines whether the workload scales linearly or stalls on communication overhead.

What are passive versus active DAC cables, and when do you need active?

A passive DAC is just the twinax and connectors, relying on the host and switch SerDes to drive the signal — the cheapest, lowest-power option and the right default for the shortest links. An active DAC adds signal-conditioning electronics inside the connectors to reach a few extra metres at a given speed, drawing a little more power. You need active DAC when a link is slightly too long for passive at your port speed but still too short to justify going optical.

The interconnect line on a cluster diagram looks like the least interesting decision on the page. It is often the one that decides whether the algorithmic work upstream survives contact with a real fabric — the reach-versus-speed boundary is where a scaling story quietly becomes a serialisation story, and the audit that catches it before the cluster ships is the one worth doing.