Why spacing matters at all
An uncompressed 1080p59.94 video stream is roughly three gigabits per second of payload, carried as tens of thousands of packets per frame. Averaged over a frame, every sender in the diagram above sends the same number of bits. The difference is when those bits arrive, and that difference decides how much buffer every downstream device needs.
ST 2110-21 formalises this with a traffic shaping model and sender types. A narrow sender spreads packets as evenly as the format allows. A wide sender is permitted more variation. Receivers, in turn, declare how much variation they can absorb. A bursty sender that fits no profile can still look perfect on a tolerant receiver, and fail on a strict one.
The buffer model in plain terms
The specification describes compliance using a virtual receive buffer — a model of a receiver that drains packets at the nominal rate. If a sender delivers ahead of schedule, the modelled buffer fills; deliver too far ahead and it overflows. The measurement is therefore not "how fast did it send" but "how far ahead of the ideal schedule did it get, at its worst moment".
That has a practical consequence worth internalising: a single bad moment in a frame decides compliance. Averages are useless here, which is why a histogram of packet intervals tells you more than any single number a tool can print.
Software senders burst by nature. A general-purpose operating system wakes a process, gives it a slice of CPU, and it writes whatever is ready. Without hardware pacing or a kernel-bypass data path, output arrives in clumps aligned to the scheduler rather than to the video clock. This is the single most common reason a software ST 2110 sender fails a shaping check while producing a perfect picture.
What it looks like downstream
| Symptom | Likely cause |
|---|---|
| Receiver reports buffer overflow, no packet loss on the network | Sender delivering too far ahead of schedule — pacing, not bandwidth |
| Occasional torn or partial frames under load | Burst exceeding a switch queue, which discards the excess |
| Works on one receiver, fails on another at identical bitrate | Receiver buffer tolerances differ; the sender sits outside the stricter one |
| Problems appear only when a second stream starts | Two bursty senders colliding in the same queue |
Where the network takes the blame
Bursts and switch buffers interact badly. A leaf switch with shallow per-port buffers absorbs a smooth stream at ninety percent utilisation without trouble, and drops packets from a bursty stream at half that load. Engineers then reach for more bandwidth, which does not help, because the problem is instantaneous queue depth rather than average throughput.
Before adding capacity, it is worth establishing whether the sender is narrow, wide or neither. If packets arrive in clumps at the first hop, no amount of downstream bandwidth will make the clumps disappear.
Practical checks
- Capture the stream as close to the sender as possible — every hop smooths or worsens what you are trying to measure.
- Plot packet intervals as a histogram. A narrow sender shows a tight cluster; a bursty one shows a long tail and a spike at zero.
- Compare the worst-case deviation over many frames, not the mean over one.
- Check whether the sender exposes a pacing setting at all. Many software senders offer none, which is itself the answer.
- Repeat the measurement with a second stream running, since pacing problems are often only visible under contention.
If you need a reference to compare against, a generator whose own pacing you trust is the most direct way to tell a sender problem from a receiver problem: transmit a known-good stream into the same receiver and see whether the symptom follows the sender or stays with the receiver.