A tethered PCVR headset drops frames at 90 fps stereo, and the renderer isn’t the problem. The compositor is masking dropped frames with reprojection, the GPU sits below its power limit, and the frame times look clean up until the moment they don’t. The team profiles the shader passes, chases the encoder, then finally swaps the cable — and the artifacts disappear. The bottleneck was never in software. It was the physical layer: a copper link operating past its rated reach.

Direct attach copper (DAC) cables are a passive or active copper interconnect that carries high-bandwidth signals over short runs without optical transceivers. The naive view treats any cable as interchangeable — just a wire that moves pixels to the headset. The useful view treats the interconnect as part of the motion-to-photon budget. DAC carries its own reach ceiling, its own signal-integrity limits, and — for active variants — retimer latency that competes with the same sub-20-millisecond budget your renderer is already fighting for.

What does working with a direct attach copper cable involve in practice?

A DAC cable is a fixed assembly: the connector housings are permanently terminated to a twinaxial copper cable, so you cannot mix and match modules the way you can with a transceiver cage. Passive DAC is exactly what it sounds like — copper conductors with matched impedance and shielding, and no active components in the path. The signal is driven by the transmitter at one end and recovered at the receiver at the other, with the cable contributing only attenuation and a small, fixed propagation delay.

That propagation delay is the reason DAC is attractive for latency-sensitive links. Signal travels through copper at roughly two-thirds the speed of light, which puts a two-metre passive run in the low-single-digit-nanosecond range for pure flight time. Add the SerDes and framing overhead on each end and a passive copper link still stays comfortably in the sub-microsecond range for the interconnect itself — small enough that, at the frame scale of XR, it is effectively free. This is a physical property of the medium, not a benchmark result: the delay is dominated by cable length and the transceiver’s own logic, both of which are known quantities.

The catch is attenuation. Copper loses signal energy with frequency and distance, and that loss climbs sharply as data rates rise. A cable that carries a comfortable eye pattern at one lane rate will close that eye at double the rate over the same length. This is why DAC reach shrinks as bandwidth grows — the two constraints are coupled, and you cannot treat “reach” and “bandwidth” as independent knobs.

What is the difference between passive and active DAC, and how does the retimer affect latency?

Passive DAC has nothing in the path. Active DAC adds electronics inside the connector housings — either an equalizer, which reshapes the received waveform to compensate for cable loss, or a retimer, which fully recovers the clock and data and re-transmits a clean signal. The distinction matters because it changes the latency story.

An equalizer is analog-domain conditioning. It extends reach by fighting attenuation, and it adds negligible delay because it never re-clocks the signal. A retimer is different: it recovers the bitstream, buffers it, and drives a fresh copy downstream. That recovery-and-retransmit cycle introduces a small but real fixed latency on top of the flight time — nanoseconds to low tens of nanoseconds depending on the implementation, plus the power the retimer chip draws.

For a datacenter link, retimer latency disappears into the noise. For a tethered XR link, it competes for the same budget the compositor is trying to protect. It is still small relative to a full frame, but the point is that active DAC is no longer “free” the way passive DAC is — you are trading a slice of budget and a slice of thermal headroom for extended reach. Whether that trade is worth it depends on how close you already are to the reach ceiling, a decision our end-to-end GPU audit frames explicitly rather than assuming the cable costs nothing.

What are the practical reach and bandwidth limits, and when do you switch to active optical?

Here is the decision surface for a tethered link. Treat the reach figures as the coupled reach-versus-rate property described above, not fixed guarantees — the exact numbers depend on the cable gauge, the specific SerDes, and the signalling standard.

Interconnect	Practical reach	Added link latency	Power / thermal cost	When it fits
Passive DAC	Short (a few metres, shrinking as rate rises)	Sub-microsecond, flight-time only	None in the cable	Desk-scale tether inside rated reach
Active DAC (equalizer)	Moderate extension	Sub-microsecond, near-passive	Low, analog conditioning	Reach slightly past passive limit
Active DAC (retimer)	Longer copper runs	Fixed retimer delay added	Retimer draws power at both ends	Copper reach you can’t get passively
Active optical (AOC)	Long (tens of metres)	Transceiver serialization delay	Optical transceiver power at each end	Room-scale or roaming tether

The switch to optical is forced, not chosen. Once a copper link is pushed past its practical reach or bandwidth, you are out of passive options and into either an active copper variant or an active optical cable, which trades copper’s reach limits for transceiver power and cost. The failure mode when you ignore the ceiling is not a clean cut-off — it is intermittent bit errors that the link layer retries, and those retries surface downstream as jitter and dropped frames.

How does interconnect choice factor into the motion-to-photon budget?

Motion-to-photon is the time from a head movement to the corresponding photons hitting the eye, and for tethered PCVR at 72–120 fps stereo the whole chain has to land inside a sub-20-millisecond envelope. That budget is spent by tracking, rendering, encoding (if the link is compressed), transport, decoding, and display scan-out. The interconnect is one line item, and its size depends entirely on whether the link is uncompressed or compressed.

An uncompressed DAC link that stays inside its rated reach contributes almost nothing — sub-microsecond transport plus the SerDes overhead. The problem starts when the physical layer can’t carry the raw bandwidth and something has to give. If reach forces you onto a compressed link, you have added an encode stage and a decode stage to the budget, and video compression is not free in either latency or quality. That is a structurally different cost than swapping cables, and it is why the interconnect decision belongs in the latency budget from the start rather than as an afterthought. The same principle applies to how a rendering pipeline manages its data movement across the host — we cover the memory side of that in how unified virtual memory shapes XR rendering budgets.

The observed pattern across tethered XR work is consistent: when a link is running near its reach ceiling, the symptom presents as a rendering or compositor problem long before anyone suspects the cable. (This is an observed pattern from XR interconnect debugging, not a benchmarked failure rate.) The GPU looks fine, the frame times look fine, and the reprojection is quietly doing more work than it should.

When does a link-layer bottleneck show up as dropped frames instead of a rendering problem?

This is the diagnostic that saves days. A physical-layer bottleneck and a compute bottleneck produce different signatures, and separating them early is the whole game.

• GPU utilisation and frame time both look healthy, but reprojection rate is elevated. The renderer is delivering frames on time; something after it is losing them. Suspect the link before the shader.
• Artifacts correlate with cable length or routing, not scene complexity. If a longer run or a tighter bend makes it worse and a heavier scene doesn’t, the medium is the constraint.
• Errors are intermittent and bursty, not steady. Marginal signal integrity produces occasional retries, not a constant frame-rate ceiling. A compute bottleneck is steady; a physical-layer one flickers.
• A shorter or lower-rate cable makes the problem vanish. The cleanest test — if dropping the link rate or shortening the run fixes it, you were past the reach ceiling.

None of these individually proves the interconnect is the culprit, but together they point at the physical layer rather than the frame pipeline. The failure class is a copper link operating near its reach or bandwidth ceiling, masked by reprojection until it breaks visibly. For the broader picture of how copper cabling behaves in dense compute environments, the same twinax constraints play out in DAC cabling inside GPU simulation clusters, where the reach-versus-rate trade shapes rack topology instead of headset tethers.

FAQ

What should you know about direct attach copper cable in practice?

A DAC cable is a fixed assembly of shielded twinaxial copper terminated permanently to its connectors, carrying high-bandwidth signals over short runs without optical transceivers. Passive DAC has no active components — just copper, so its only contributions are attenuation and a small fixed propagation delay. In practice that delay is negligible at frame scale, but attenuation limits how far and how fast the link can carry a clean signal.

What is the difference between passive and active DAC, and how does active DAC’s retimer affect latency?

Passive DAC has nothing in the signal path; active DAC adds electronics inside the connector — either an equalizer or a retimer. An equalizer reshapes the waveform to fight attenuation and adds negligible delay, while a retimer recovers and re-transmits the bitstream, adding a small fixed latency (nanoseconds to low tens of nanoseconds) plus power draw. For a tethered XR link that fixed retimer delay competes with the motion-to-photon budget, so active DAC is no longer “free” the way passive DAC is.

What are the practical reach and bandwidth limits of DAC, and when should you switch to active optical?

DAC reach and bandwidth are coupled: copper attenuation rises with frequency, so a cable that carries a clean signal at one rate closes the eye at double the rate over the same length. Passive DAC covers short desk-scale runs, active variants extend reach at some latency or power cost, and once you exceed practical copper reach you switch to active optical, which trades copper’s limits for transceiver power and cost. The switch is forced by physics, not preference.

How does interconnect choice factor into the motion-to-photon latency budget for tethered PCVR?

Motion-to-photon for tethered PCVR at 72–120 fps stereo must land inside a sub-20-millisecond envelope, spent across tracking, render, transport, and scan-out. An uncompressed DAC link inside its rated reach contributes almost nothing, but if reach forces a compressed link you add encode and decode stages that cost real latency and quality. That makes the interconnect a first-class line item in the budget rather than an afterthought.

What power and thermal cost does DAC carry compared to optical transceivers under a fixed headset envelope?

Passive DAC draws no power in the cable itself, which is its key advantage under a fixed headset thermal envelope. Active DAC’s retimer draws power at both ends, and optical transceivers draw more still to drive the laser and receiver. Under a constrained envelope those milliwatts and the heat they produce compete directly with the rest of the headset’s budget.

When does a link-layer bottleneck show up as dropped frames or reprojection artifacts rather than a rendering problem?

A physical-layer bottleneck typically shows healthy GPU utilisation and frame times while reprojection rate climbs, because the renderer delivers frames on time and something after it loses them. It correlates with cable length or routing rather than scene complexity, and errors are intermittent and bursty rather than a steady rate ceiling. The cleanest confirmation is that a shorter or lower-rate cable makes the problem vanish.

The interconnect is the one part of an XR frame pipeline that looks free until it isn’t. Keeping it honest — inside its rated reach, with the right passive-or-active choice for the run — is what stops a physical-layer limit from being quietly papered over as a software problem. When a copper link is running near its ceiling, an end-to-end GPU audit that accounts for the cable in the latency and power budget is what turns a week of chasing shaders into a five-minute cable swap.