2110 at the Edge, MXL at the Core

MXL is having a moment. It’s all over the trade-show floor, the LinkedIn hot takes, and the conference Q&A, usually a sentence away from someone declaring it the thing that finally kills SMPTE-2110, or warning that you’d better pick a side before the future leaves without you. We’ve watched the chatter pile up, so let’s clear one thing up. It’s not 2110 or MXL. They solve different problems in different places, and a real facility runs both.

SMPTE-2110 is an edge protocol. It’s how a camera, an encoder, an SDI gateway, or a partner’s switcher puts essence on the network and how it leaves again on the way to air. It’s PTP-locked, runs RTP over IP, and is already spoken by the entire installed base of professional gear. That interop is the whole point. You don’t get to choose your camera vendor’s transport.

MXL is a core protocol. Once essence is inside the building, wrapping every hop between functions in RTP is pure waste. MXL is the Media eXchange Layer, the open data plane of the EBU’s Dynamic Media Facility. It moves media between containerized functions with zero copies on a node and over RDMA between nodes. The DMF blueprint draws the line exactly here: 2110 at the boundary, MXL in the middle. Two halves of one ecosystem, not two answers to one question.

Two protocols, two jobs

#

The clean way to think about it is to ask where the essence is when it moves.

You can’t replace 2110 at the edge, because you don’t control what a camera emits. And you shouldn’t use it in the core, because the moment essence is in the building you do control the transport, and packetizing every internal hop is bandwidth and CPU you’ll never get back. DMF draws that line. So do we.

MXL on a single node

#

On one node, MXL is almost boring. That’s the highest compliment you can pay a data plane.

Flows and grains are ring buffers in shared memory. A grain is one typed, timed media unit: a video frame, a window of audio, a chunk of data. The model is reader/writer, not sender/receiver. A function that produces video opens a writer; every downstream function opens a reader on the same ring and sees the grains with no packetization and no copy. Fan-out is free: a compositor’s output can feed an encoder, a preview, and an AI analyzer at once, all reading the same buffer, no extra connections.

And there’s no daemon in the middle. No proxy process brokering essence between containers, nothing extra to crash or restart at 2 a.m. The grains and the functions reading them are the whole system.

On hardware like the DGX Spark it gets better still, because the CPU and GPU share one physical memory pool. A 2110 packet the NIC lands is already in memory the GPU reads directly. The format conversion, the encoder, and every MXL reader all work the same address space. The grain never moves.

Across nodes: MXL Fabrics over RDMA

#

The honest constraint, up front: on one node MXL is shared-memory only, and shared memory stops at the edge of the machine. Physics doesn’t negotiate.

So to span nodes, something has to carry grains from one node’s domain into another’s. That’s the DMF project’s MXL Fabrics layer, and it’s what jeket runs cross-node. A bridge reads grains from the local domain on one side and writes them into the local domain on the other over RDMA: the NIC moves the data straight into the next node’s memory, with the CPU mostly out of the loop. The media functions on either end never know it happened. They’re still just reading and writing a local ring.

Where there’s no RDMA hardware, the same fabric falls back to ordinary networking and keeps running, on-prem or in the cloud. Choosing the path is the platform’s job, not yours: jeket profiles each node and provisions the bridge accordingly. Your media function never finds out which transport carried its grains.

And it’s the same wire. On the ConnectX-7, one network port carries both the 2110 traffic and the cross-node RDMA at once, so a single node is an edge endpoint and a core node at the same time. You don’t dedicate hardware to each role, and the node’s second 200 GbE port is free for red/blue redundancy.

What we measured

#

We measured the fabric cross-node between two production DGX Sparks, over a ConnectX-7 200 GbE link, driving a real 1080p uncompressed (V210) flow through the live Fabrics bridges.

• It clears the bar: ≥10 Gbps, zero loss. A six-minute soak sustained 11.92 Gbps with zero transport loss. Every grain the bridge sent on one node arrived on the other. That’s the bar we hold the bridge to, met on real hardware moving real media.
• It barely touches the CPU. Moving that ~12 Gbps cost the bridge 0.073 of a single core, roughly six thousandths of a core per gigabit. That’s the whole argument for RDMA in one number: the NIC moves the data, and the cores you’d otherwise burn on networking stay free for media.
• There’s headroom. A single flow sustained ~20 Gbps and burst to ~24 before the bridge’s per-flow drain became the limit, not the 200 GbE link. You scale past one flow by adding flows and links, and a 200 GbE port has room to spare for edge and core traffic at once.
• It’s genuinely RDMA. The NIC’s own byte counters tracked the grains we sent, to within the ~6% of RDMA header overhead. That’s proof the data really went over RDMA, not a silent fallback to ordinary networking.
• Under a millisecond, end to end. The cluster’s PTP clock is genlocked to the grandmaster within a few nanoseconds, which lets us time delivery precisely: a whole uncompressed 1080p frame crosses from one node to the other in 0.67 ms at the median, 1.0 ms at the 99th percentile, one way. A 60 fps frame is 16.7 ms, so the hop costs a small slice of a single frame. And it’s conservative, measured moving whole frames while the production bridge ships sub-frame slices and pipelines lower.

Three numbers from one fabric on real hardware: ~12 Gbps, 0.07 of a core, sub-millisecond.

Bring your own MXL node

#

This is what makes it an ecosystem instead of a stack.

The contract for a media function on jeket is small. jeket hands your container the MXL flow IDs and domain to use, and your code opens a writer to produce grains and a reader to consume them. That’s the whole data-plane surface. MXL is vendor-neutral by construction: Apache-licensed, governed under the Linux Foundation with the EBU and NABA, grain-first so there’s no per-vendor format conversion. If your node speaks MXL, it speaks to every other node on the plant.

So a partner, or a customer’s own engineers, can package a media function we’ve never imagined: a custom grader, a sports-analytics overlay, a generative-AI compositor, a volumetric renderer. They build a container that reads grains and writes grains. They never write a line of RDMA code, never register with NMOS by hand, never care whether they landed on a ConnectX-7 or a stock cloud VM. They hand jeket the image; it runs as a node in the air chain, and the platform schedules it, picks its transport, bridges it across the cluster, registers it, and fails it over.

Everything underneath is our problem: the RDMA plumbing, the provider selection, the NMOS discovery and connection management, the scheduling, the failover. Not yours.

The ecosystem, not the appliance

#

The industry spent two decades buying appliances: a box for framesync, a box for conversion, a box for encode, each speaking its own dialect, each a vendor relationship and a point of failure. 2110 cracked the edge open by putting essence on commodity IP. DMF and MXL crack the core open by putting the in-house data plane on an open, zero-copy, RDMA-capable standard nobody owns.

jeket’s job is to run both halves as one system: 2110 at the edge where interop is law, MXL at the core where copies are waste, the fabric stitching nodes into a cluster, and a control plane that lets anyone bring a node without learning any of it. That’s not a side to pick in a 2110-versus-MXL debate. It’s a facility to run.

Throughput, loss, and CPU are measured on the live production Fabrics bridges over a single ConnectX-7 200 GbE RoCEv2 link between two DGX Spark nodes, with the verbs path confirmed against the NIC’s own counters. Latency is one-way, for a whole 1080p frame over the same verbs fabric, timed against a PTP clock genlocked to the grandmaster within a few nanoseconds; it’s a conservative figure, since the production bridge ships sub-frame slices and pipelines lower.