A tethered XR rig looks like it should just work: pick a cable with the right connector and the right length, plug the headset into the compute host, and move on. The cable is inert plumbing, or so the assumption goes. That framing is where a surprising number of latency problems begin — not in the renderer, not in the perception model, but in the copper between them.

A direct attach copper (DAC) cable is a fixed-assembly link with transceiver housings permanently terminated on both ends. You do not plug a separate optic into a cage; the cable is the assembly. In a tethered XR architecture — where some perception stages run host-side and pose updates must reach the renderer inside a timewarp-friendly window — that assembly is not neutral. It sits on the critical path, and its physical limits map directly onto the latency and integrity budget the headset has to hold.

What does a DAC cable do in a host-to-headset link?

The short version: a DAC carries a high-speed serial signal over shielded twinax copper between two ports, with the transceiver electronics built into the connector shells. Passive DAC does no signal conditioning — the copper simply conducts. Active DAC adds retiming or equalisation silicon in the housings to recover the signal over longer runs.

For a tethered headset, the link is usually one segment of a longer path: sensor capture, host-side perception (segmentation, depth, pose estimation), the interconnect back to the headset, and the renderer’s final warp. The interconnect might be the tether itself, or it might be a rack-internal hop between the node running perception and the node driving the display. Either way, the DAC is one measured segment of an end-to-end path, and it competes for the same millisecond budget as everything else.

The load-bearing claim here is simple and worth stating cleanly: the interconnect is part of the latency budget, not a fixed cost you can ignore. Passive copper is cheap and adds sub-microsecond serialisation latency at typical reach — but it is reach-limited, and past that limit you pay in retiming latency, errors, or a jump to optical (approximation; exact numbers depend on the link standard and cable gauge). Treating the cable as plumbing means you discover its limit as jitter in a pipeline you have already tuned everywhere else.

Passive vs active DAC: when does reach force the choice?

The difference between passive and active DAC is not cosmetic. It is the single decision that most often determines whether a tethered link stays inside budget.

Passive DAC relies entirely on the copper and the shielding to preserve signal integrity. As frequency rises and cable length grows, insertion loss accumulates, the eye closes, and the receiver starts guessing. At 25G, 50G, and 100G+ per lane, passive copper’s usable reach shrinks with every bump in signalling rate — a common pattern is passive DAC being practical only in the low-single-digit-metre range at the higher rates (observed pattern across interconnect deployments; the exact ceiling is set by the standard and the gauge, not by a universal number).

Active DAC re-opens the eye. Equalisation and retiming silicon in the housing reconstruct the signal, extending usable reach at the cost of more power, more latency, and more money per cable. That retiming step is where the trap lives for XR: retiming adds latency and, if the active components are marginal or poorly matched, it can add jitter — the enemy of a renderer trying to hold a stable anchor.

Here is the decision in one place.

DAC selection for a tethered XR link

Factor	Passive DAC	Active DAC	Optical (AOC)
Typical reach	Short (~1–3m at high rates)	Extended (mid-single-digit metres)	Long (tens of metres+)
Added latency	Sub-microsecond serialisation	Serialisation + retiming	Serialisation + E/O + O/E conversion
Jitter risk	Lowest (no active silicon)	Moderate (depends on retimer quality)	Low-moderate (well-designed)
Power draw	Negligible	Higher (active components)	Higher (optical engines)
Cost per link	Lowest	Higher	Highest
Best when	Host and headset are close, rate is high	Reach exceeds passive limit, still copper-friendly	Reach or EMI rules out copper entirely

Reach figures are approximate and set by the link standard and cable gauge, not a universal spec — treat them as planning heuristics, not guarantees.

The rubric that follows the table: if the host and headset sit within passive copper’s reach at your signalling rate, passive DAC is almost always the right answer — it is the lowest-latency, lowest-jitter, cheapest option. Cross that reach and you are choosing between active DAC (still copper, more latency and power) and an active optical cable, which trades copper’s reach limit for optical conversion overhead. The choice is not “which is better” — it is “what does my reach force on me.”

How does DAC latency and integrity hit the XR pipeline?

The reason interconnect choice matters more in XR than in a generic data link is the renderer’s tolerance window. A tethered headset relies on timewarp (or asynchronous reprojection) to correct the last-moment pose before display. That correction can only absorb so much staleness. If host-side pose updates arrive late — because the link added retiming latency, or because a marginal active cable is injecting jitter — the warp works from an old pose, and the user sees swim, judder, or a mispositioned anchor.

Serialisation latency on a healthy passive DAC is small enough to be a rounding error against the frame budget. The problem is not the nominal latency of a well-chosen link; it is the variance and the retransmission that appear when the link is run past its integrity margin. Bit errors trigger correction or retry at higher layers, and retries are jitter by another name. In our experience, interconnect-induced jitter is one of the harder XR latency faults to diagnose precisely because everyone looks at the renderer and the model first, and the cable is the last suspect.

This is the same latency-budget discipline that governs unified virtual memory and the XR rendering budget on the host side — every segment of the perception-to-render path has to fit, and the interconnect is a segment like any other. It is also why the standalone vs PC-tethered headset trade-off is really a question about where the compute lives and what the link between compute and display has to carry.

Worked example: does the link fit the budget?

Assume a headset running at 90Hz, giving roughly an 11ms frame budget. Suppose the perception-to-render path is provisionally allocated as: sensor capture and host-side perception ~6ms, interconnect ~0.5ms, renderer and warp ~4ms, leaving a thin margin.

• With a passive DAC inside its reach limit, the interconnect’s ~sub-microsecond serialisation cost sits comfortably inside the 0.5ms allocation. The budget holds.
• Push the same link past passive reach and the receiver starts erroring. Retransmission at the transport layer turns an occasional bad frame into a variable multi-millisecond spike. That spike does not fit in 0.5ms — it eats the renderer’s margin and the warp goes stale.
• Switch to active DAC to recover reach and the deterministic retiming latency rises but stays bounded; if the allocation was drawn with that in mind, the budget still holds. If it was drawn assuming passive, you are now over.

Frame and allocation numbers are illustrative planning figures, not measured results — the point is the shape of the trade, not the specific milliseconds.

The lesson is that the interconnect decision has to be made against the budget, before the cable is bought. A DAC chosen for connector convenience and re-checked against latency later is a decision made in the wrong order.

Which connector and length constraints actually bind?

Two physical constraints do most of the work in narrowing the choice. The first is the connector and lane rate — QSFP, SFP, OSFP and their generations each define a signalling rate per lane, and that rate sets how far passive copper can reasonably carry the signal. The second is length: reach is not a knob you turn continuously, it is a cliff. Inside the passive limit you are fine; a metre past it you are in error-correction territory.

Cable gauge matters too — thicker twinax carries the signal further before the eye closes, at the cost of stiffness and weight, which is a real ergonomic concern for a cable a person wears on their head. And the connector must match the ports on both the host GPU node’s network interface and the headset’s ingress. This is the same interconnect reasoning that shows up one level out in a rack, where DAC cabling in GPU compute clusters trades reach against cost node-to-node; the XR tether is that problem shrunk to a single wearable link with a hard jitter tolerance. If the interconnect segment is contributing to a broader GPU bottleneck, our approach to GPU performance and latency-budget engineering treats it as one measured hop in the end-to-end path rather than an afterthought.

FAQ

How does direct attach copper (DAC) cables actually work?

A DAC is a fixed-assembly cable with transceiver housings terminated permanently on both ends, carrying a high-speed serial signal over shielded twinax copper. Passive DAC just conducts the signal; active DAC adds retiming or equalisation silicon in the housings. In practice it means the interconnect is a single measured segment of the perception-to-render path, not neutral plumbing you can ignore.

What is the difference between passive and active DAC, and when does reach force one over the other?

Passive DAC relies entirely on the copper and shielding to preserve the signal, which limits usable reach as signalling rate rises. Active DAC adds silicon that re-opens the signal eye and extends reach, at the cost of more power, more latency, and more money. Reach forces the switch when the run exceeds what passive copper can carry cleanly at your lane rate — a limit set by the link standard and cable gauge, not a universal number.

How does DAC latency and signal integrity affect the host-to-headset link in a tethered XR pipeline?

On a healthy passive DAC inside its reach limit, serialisation latency is a rounding error against the frame budget. The problem appears when the link is run past its integrity margin: bit errors trigger retransmission, and retransmission is jitter, which the renderer’s timewarp window cannot absorb. Interconnect-induced jitter is hard to diagnose because engineers check the renderer and model before the cable.

When should a tethered XR interconnect move from passive DAC to active DAC or optical (AOC)?

Stay on passive DAC while the host and headset sit within passive copper’s reach at your signalling rate — it is lowest-latency, lowest-jitter, and cheapest. Move to active DAC when reach exceeds the passive limit but the link is still copper-friendly. Move to optical (AOC) when reach or electromagnetic constraints rule out copper entirely, accepting the optical conversion overhead in exchange for long reach.

How does the interconnect choice fit into the perception-to-render latency budget the headset renderer must meet?

Every segment of the perception-to-render path competes for the same frame budget, and the interconnect is one of those segments. A passive DAC inside its limit fits comfortably; a link run past its integrity margin injects variable spikes that eat the renderer’s margin and stale the warp. The interconnect must therefore be chosen against the budget before the cable is bought, not re-checked afterward.

What connector and cable-length constraints matter when selecting DAC for host-to-headset compute links?

The connector and lane rate — QSFP, SFP, OSFP and their generations — set the signalling rate per lane, which determines how far passive copper can carry the signal. Length is a cliff, not a dial: inside the passive limit you are fine, a metre past it you are in error-correction territory. Cable gauge affects reach and stiffness, and the connector must match the ports on both the host node and the headset.

The question worth holding

The useful discipline in tethered XR is not “which cable is best” but “what does my reach force, and does that fit the frame budget my renderer has to meet?” Pick the interconnect against the perception-to-render latency budget, in that order, and passive copper’s cheapness is a gift rather than a trap. Get the order wrong and the cable becomes the segment nobody profiled — the failure class an end-to-end GPU audit exists to catch, by measuring each hop of the path against the budget it has to hold.