Multicast has to reach you first
ST 2110 streams are multicast, and multicast is delivered only to hosts that ask. The machine sends an IGMP join for the group; the switch, if it is snooping, then forwards that group to that port. Three things go wrong repeatedly:
- No querier on the VLAN. Snooping switches need a querier to keep memberships alive. Without one, streams start and then stop a minute later, which looks like an intermittent fault and is not.
- Joins sent on the wrong interface. A machine with several adapters may join on the one with the default route rather than the media network. The join goes nowhere useful and nothing arrives.
- Firewall dropping inbound UDP. On Windows this is the single most common cause of "the stream just does not appear" — the join succeeded, packets arrived, and the host discarded them.
The NIC decides more than the CPU
For a receiver, the network adapter determines two things that software cannot fix afterwards: whether timestamps come from hardware, and how much work the host does per packet.
Hardware timestamping matters because PTP accuracy measured in software includes the operating system's scheduling noise. If the adapter can stamp arrival in hardware, offsets become trustworthy; if not, you are measuring Windows as much as the network.
Packet rate matters because uncompressed video arrives as a very large number of small packets. At around 3 Gb/s a 1080p stream is roughly a quarter of a million packets per second; 4K multiplies that. Each one traversing the full kernel path costs interrupts and copies, and at some point the machine spends more time moving packets than looking at pictures.
This is where the money usually goes. Competing software analysers commonly require a specific vendor's SmartNIC, or an NVIDIA ConnectX with a separate Rivermax licence, before they will receive anything at all. Being able to start on the adapter already in the machine — and add DPDK on a commodity Intel X550 when 4K demands it — removes a purchase and a dependency from the experiment.
When kernel bypass is worth it
DPDK takes the adapter away from the operating system and lets the application poll it directly, as in the lower path of the diagram. The gain is real: no per-packet interrupts, no copy through the socket buffer, and far more predictable behaviour under load. The costs are equally real:
- The port is bound to the DPDK driver and no longer available for ordinary networking, so a second interface is needed for management.
- Driver installation is an administrative operation, and on Windows may involve test-signed drivers and a reboot.
- Debugging is different — familiar operating system tools no longer see the traffic, because the traffic no longer passes through the operating system.
A reasonable rule: start on the standard path at 1080p. Move to bypass when the packet rate, not the picture, is what the machine is struggling with.
Host settings that matter
| Setting | Why |
|---|---|
| Receive buffer size | Default socket buffers are sized for ordinary traffic; a burst at video rates overruns them in milliseconds |
| Interrupt moderation and RSS | Spreading a single high-rate flow across queues, or coalescing interrupts, changes both throughput and jitter |
| Power management | C-states and adapter power saving introduce latency spikes that look exactly like network jitter |
| Jumbo frames | ST 2110 video typically uses standard-sized packets; a mismatched MTU along the path causes silent loss |
| Firewall rules | Inbound UDP for the media ports must be allowed explicitly, per network profile |
A bring-up order that saves time
- Put the media interface on the right subnet and confirm the machine is not routing media traffic through another adapter.
- Allow inbound UDP on the media ports before testing anything else.
- Check PTP lock, with hardware timestamps if the adapter supports them, before looking at any stream.
- Join one stream and confirm packets arrive and keep arriving past the first minute, which is where IGMP problems appear.
- Read the adapter's own drop counters alongside stream statistics — a receiver that reports loss while the NIC reports drops is a host problem, not a network one.
- Only then add a second stream, which is when buffering and pacing problems tend to surface.