Today we'll dive into what seems like a straightforward topic — multicast monitoring. Despite its apparent simplicity, there are plenty of complexities lurking beneath the surface. The first of these? Controller characteristics.
In multicast, we're primarily interested in two metrics. The first is packet loss, which matters for both IPTV and DVB. The second is jitter, which is especially critical for DVB and low-latency systems. What we're really interested in is the accuracy of measuring these two parameters.
Timestamps
To measure jitter, each packet needs a timestamp. This can be done in two ways:
Software timestamping — timestamps are assigned by the driver in the Linux kernel. The problem: under heavy load, the kernel can't process packets evenly, causing timestamps to drift.
Hardware timestamping — timestamps are assigned by the network card itself, regardless of system load.
We ran a comparison: under moderate load, the difference in peak jitter measurement is 10-15%. Doesn't sound too bad? But when measuring minimum jitter, the difference reaches tens of thousands of percent!
So whenever possible, always use hardware implementation.
RSS Queues: Distributing Load the Right Way
Picture this: one CPU core at 100%, the rest sitting idle. Sound familiar? This is the classic scenario when receiving multicast without RSS (Receive Side Scaling) configured.
Here's how it works:
By default, the controller generates interrupts that are handled by a single CPU core. A modern 2-4 GHz core can easily handle 2-5 Gbps of traffic. But when you add stream analysis (which is exactly what a probe does), a single core isn't enough. When a core is loaded at 100%, you get packet loss in the network card's buffer because the processor can't keep up.
The solution: use a card that supports multiple RSS queues and ensure interrupt balancing is enabled in the system. This will distribute the load across multiple cores. NB: you don't need to enable all available queues. Use only as many queues as needed to prevent any single core from hitting 100%.
If your card doesn't support hardware RSS queues, use the software implementation RPS (Receive Packet Steering) in Linux.
In dual-socket servers, each CPU has its own memory and PCIe bus. If the network card is connected to one CPU but processing happens on another, you get cross-CPU memory access. This slows things down and increases jitter. RSS queues let you pin traffic processing to the same CPU the network card is physically connected to. This significantly optimizes performance.
So the main recommendations are simple: use RSS queues and hardware timestamping.
Top comments (0)