A GPU video-analytics cluster lives or dies on the fabric that feeds it. When capture nodes, storage, and inference GPUs sit in the same rack, the interconnect between them is not a checkbox — it is a real line item in both the capital budget and the rack power envelope. The common reflex is to default to optical transceivers everywhere because fibre feels like the “serious” choice, or to accept whatever the switch vendor bundles. That reflex quietly overpays. Here is the claim worth internalising before you spec a single cable: for the short, fixed-length links inside a rack, direct attach copper (DAC) cables deliver equivalent bandwidth at a fraction of optical cost and markedly lower power per port — and optics only earns its premium where copper physically cannot reach. Matching the cable medium to the actual physical topology of your analytics fabric is what keeps interconnect cost and power in line with the workload. Defaulting to one medium everywhere fails in one of two directions: you either burn money on optics for links a copper cable would have served, or you push copper past its reliable reach and start chasing intermittent link errors. What matters most about DACs networking in practice? A DAC is a single assembly: two transceiver-shaped connectors (SFP+, SFP28, QSFP+, QSFP28, and so on) permanently terminated onto a length of twinaxial copper cable. You plug one end into a switch port and the other into a NIC or a second switch. There is no separate transceiver to buy, no fibre to clean, no optical alignment. The cable is the link. That integration is the whole point. Because the electrical signalling stays in copper end-to-end, a DAC skips the electrical-to-optical-to-electrical conversion that a fibre link performs at each transceiver. Skipping that conversion is what gives DACs their two headline advantages inside a rack: lower insertion latency and lower power draw per port. In practice, the switch and NIC treat a DAC exactly like any other pluggable — the same cage, the same EEPROM identity, the same interface counters. Operationally it behaves like a transceiver; physically it is a wire. The naive mental model is that copper is the “old, slow” medium and fibre is the “modern, fast” one. That is not how the physical layer works at rack scale. Copper is not slower — it is shorter-reach. Within the distances that separate machines in the same rack or adjacent racks, copper carries the same 25G, 100G, or 400G lanes the optics do. The trade you are making is reach, not throughput. What is the difference between a DAC cable and an optical transceiver link? An optical link is three separately purchased parts: a transceiver at each end plus a fibre patch cable between them. A DAC is one part that replaces all three. That single structural difference cascades into everything else — cost, power, latency, reach, and how you troubleshoot a bad link. The cost gap is the most visible. A DAC assembly typically costs a fraction of a comparable transceiver-plus-fibre-plus-transceiver optical link for the same short run (observed-pattern — the ratio varies by data rate and vendor, but the direction is consistent across the deployments we have specced). The power gap matters more than teams expect: an optical transceiver runs active laser optics and burns a couple of watts per end, while a passive DAC draws effectively nothing beyond the host SerDes. Multiply a couple of watts per port across a dense GPU cluster with hundreds of links and the difference becomes a real slice of the rack power and cooling budget. DAC versus optical: a decision matrix for the analytics fabric Factor Direct attach copper (DAC) Optical transceiver + fibre Typical reach ~1–3 m passive; ~5–7 m active (data-rate dependent) Tens of metres (SR) to kilometres (LR) Relative cost per short link Low — one integrated assembly High — two transceivers plus fibre Power per port Effectively negligible (passive) ~1–3.5 W per transceiver, per published optics specs Insertion latency Lowest — no O/E/O conversion Slightly higher — conversion at each end Best fit Intra-rack: NIC-to-ToR, ToR-to-ToR Inter-rack, cross-row, spine uplinks Failure mode to watch Marginal signal if run too long Dirty/damaged fibre, transceiver failure Flexibility Fixed length; buy per run Fibre length independent of transceiver The reach column is the whole argument. Copper stays reliable over the short, fixed distances that dominate an intra-rack fabric; fibre earns its cost and power premium precisely where copper stops being dependable. This is the same medium-matching logic that governs whether the physical layer feeds your GPUs fast enough to hit their per-stream deadlines — a concern we treat in more depth alongside the [GPU latency framing that determines whether analytics stages meet their deadlines](GPU engineering). Where do DACs make sense in a GPU video-analytics fabric, and where do you need optics instead? Think about the physical shape of a real deployment. Cameras or ingest servers land video into capture nodes. Those feed storage and a bank of GPU nodes running decode, object detection on the decode path, and object tracking across frames. In most builds, the heavy east-west traffic — capture-to-storage, storage-to-GPU, GPU-to-GPU — happens between machines in the same rack, connected through a top-of-rack switch a metre or two away. Those links are exactly where DACs win. A NIC-to-ToR uplink or a ToR-to-ToR cross-connect over a couple of metres is the canonical DAC use case: lowest latency, lowest power, lowest cost, and copper is comfortably inside its reach. Reaching for optics on those runs is pure overspend. Optics earns its place the moment a link leaves the rack. Spine uplinks, cross-row aggregation, a storage tier in a different cabinet, or a capture head-end sitting metres away across a machine room — those distances are where copper becomes marginal and optical transceivers become the correct, if pricier, tool. The discipline is to profile the topology first and let each link’s physical distance pick its medium, rather than deciding the medium fleet-wide and forcing every link to conform. This is the same profiling logic our parent framing applies one layer up. Just as we profile which analytics functions actually justify GPU economics before committing to accelerated hardware, the fabric layer rewards profiling which links justify optical over copper before committing to a wiring standard. Both are refusals to default. What are the reach, bandwidth, and power trade-offs at 10/25/40/100GbE and beyond? Reach and data rate are coupled: as the per-lane signalling rate climbs, the distance copper can carry it cleanly shrinks. At 10GbE (SFP+), passive DACs comfortably reach a few metres. At 25GbE (SFP28) and 100GbE (QSFP28), passive reach tightens toward the 1–3 m range, which is still the sweet spot for intra-rack wiring. Push to 400GbE and beyond and the reliable passive-copper window narrows further, which is why active DACs and active optical cables enter the conversation for the longer intra-rack runs. Bandwidth itself is not the differentiator — a DAC and an optical link at the same standard carry the same lane rate. What differs is how far each can carry it and at what power. Treat the published reach figures from your cable and switch vendors as the authority here; they vary by gauge, by active-versus-passive design, and by the host SerDes driving the link. The safe planning posture is to size copper for the short runs it is rated for and never assume a data sheet’s maximum reach is a comfortable operating point. What are passive versus active DACs, and when does the distinction matter? A passive DAC is a plain twinaxial wire with connectors — no electronics, no power draw, relying entirely on the host ports’ SerDes to drive and equalise the signal. An active DAC adds small signal-conditioning electronics (equalisation, sometimes redriver or retimer circuitry) inside the connectors to compensate for loss over longer copper, extending usable reach at the cost of a small amount of power. The distinction matters when your intra-rack runs bump against the passive reach limit. For the short NIC-to-ToR links that dominate most analytics racks, passive is the right default — cheapest, coolest, simplest. When you need to span a taller rack, reach a machine two cabinets over, or run at a data rate where passive copper is marginal, an active DAC buys you the extra metres before you have to jump to optics. Reserve active DACs for that in-between band; below it use passive, above it use fibre. How does interconnect choice affect GPU utilisation and per-stream latency? Interconnect is not neutral to how well the GPUs run. A video-analytics GPU that stalls waiting for the next batch of frames because the fabric can’t feed it is an expensive idle asset — and starved GPU nodes are a direct contributor to the GPU underutilisation pattern that shows up in accelerated pipelines. Fabric medium is genuinely part of the utilisation story, not a separate networking concern. Latency matters most where the pipeline has a per-stream deadline. In live or near-live analytics, each stream must complete decode, detection, and tracking within a frame budget. A DAC’s slightly lower insertion latency is marginal on any single link, but it is one of the free wins available when you are fighting for headroom against a tight deadline — and choosing it costs nothing extra. The larger point is that the interconnect is a physical-layer input to the same latency accounting that governs whether analytics stages hit their deadlines; you cannot reason about per-stream latency while treating the fabric as invisible. FAQ How does DACs networking work? A DAC is a single cable assembly with transceiver-shaped connectors permanently terminated onto twinaxial copper, plugged directly into switch or NIC ports. Because the signal stays electrical end-to-end, it skips the optical conversion a fibre link performs at each transceiver, which is what gives DACs lower insertion latency and lower power per port. Operationally the switch treats it like any other pluggable; physically it is just a wire. What is the difference between a DAC cable and an optical transceiver link? An optical link is three separately bought parts — a transceiver at each end plus a fibre between them — while a DAC replaces all three with one integrated assembly. That structural difference makes DACs cheaper per short link and lower-power (a passive DAC draws effectively nothing versus a couple of watts per optical transceiver). The trade-off is reach: copper stays reliable only over the short distances inside a rack. Where do DACs make sense in a GPU video-analytics fabric, and where do you need optics instead? DACs win on the short, intra-rack links that dominate most builds — NIC-to-ToR and ToR-to-ToR runs of a metre or two between capture, storage, and GPU nodes. Optics earns its cost-and-power premium the moment a link leaves the rack: spine uplinks, cross-row aggregation, or a storage tier in another cabinet. Profile the topology first and let each link’s physical distance pick its medium rather than standardising fleet-wide. What are the reach, bandwidth, and power trade-offs of DAC cables at 10/25/40/100GbE and beyond? Reach and data rate are coupled: passive copper reaches a few metres at 10GbE but tightens toward 1–3 m at 25/100GbE and narrows further at 400GbE. Bandwidth itself is not the differentiator — a DAC and an optical link at the same standard carry the same lane rate — but power is, since passive DACs draw effectively nothing versus watts per optical port. Treat vendor-published reach figures as the authority and avoid running copper at its rated maximum. How does interconnect choice affect GPU utilisation and per-stream latency in a video-analytics pipeline? A GPU that stalls waiting for frames because the fabric cannot feed it is idle capital, so a starved interconnect feeds directly into the GPU underutilisation pattern. Latency matters most where each stream has a frame-budget deadline across decode, detection, and tracking; a DAC’s slightly lower insertion latency is a free win when fighting for headroom. The interconnect is a physical-layer input to per-stream latency accounting, not a separate concern. What are passive versus active DACs, and when does the distinction matter? A passive DAC is plain twinax with connectors and no electronics, relying on the host SerDes to drive the signal; an active DAC adds signal-conditioning circuitry to extend reach at a small power cost. Passive is the right default for the short NIC-to-ToR links that dominate most racks. Active DACs fill the in-between band — longer intra-rack runs or marginal data rates — before you have to switch to fibre. Where the fabric decision actually gets made The mistake is treating the interconnect as a downstream detail once the GPUs are chosen. It is a topology decision that should be made with the same profiling rigour you apply to the compute. If you are auditing a video-analytics pipeline for cost and performance, the audit does not end at the GPU — it should extend to the fabric and name, link by link, where a DAC is sufficient and where optical reach or bandwidth is actually required. That is the difference between a fabric sized to the workload and one that either overpays for optics on intra-rack hops or quietly fails on copper stretched past its reach. Which links in your cluster have you actually measured the distance on — and which are running the medium someone defaulted to?
