Как сетевой контроллер влияет на точность мониторинга мультикаста

В мультикасте нас в первую очередь интересуют две метрики. Первая — потери пакетов. Это важно и для IPTV, и для DVB. Вторая — джиттер, который особенно важен для DVB и систем с минимальными задержками. Именно достоверность измерения этих двух параметров нас и интересует.

Временные метки

Для измерения джиттера на каждый пакет нужно поставить временную метку. Это можно сделать двумя способами:

• Программная реализация — метки ставит драйвер в ядре Linux. Проблема: при высокой нагрузке ядро не успевает обрабатывать пакеты равномерно, временные метки «плывут».
• Аппаратная реализация — метки ставит сама сетевая карта, независимо от нагрузки на систему.

Мы проводили сравнение: при умеренной нагрузке разница в измерении пикового джиттера составляет 10-15%. Звучит не страшно? Но если измерять минимальный джиттер, разница достигает десятков тысяч процентов!

Поэтому по возможности всегда используйте аппаратную реализацию.

RSS-очереди: распределяем нагрузку правильно

Представьте: одно процессорное ядро на 100%, остальные простаивают. Знакомая картина? Это классика при приёме мультикаста без настройки RSS (Receive Side Scaling).

Как это работает:

По умолчанию контроллер генерирует прерывания, которые обрабатываются одним CPU-ядром. Современное ядро на 2-4 ГГц легко обработает 2-5 Гбит/с трафика. Но когда вы добавляете анализ потока (а зонд именно это и делает), одного ядра становится мало. Если одно ядро загружено на 100%, появляются потери пакетов в буфере сетевой карты, потому что процессор не успевает их обрабатывать.

Решение: используйте карту с поддержкой нескольких RSS-очередей и убедитесь, что в системе работает балансировка прерываний. Это позволит распределить нагрузку между несколькими ядрами. Важно: не нужно включать все доступные очереди. Используйте столько очередей, сколько нужно, чтобы ни одно ядро не было загружено на 100%.

Если ваша карта не поддерживает аппаратные RSS-очереди, используйте программную реализацию RPS (Receive Packet Steering) в Linux.

В серверах с двумя физическими процессорами каждый CPU имеет свою память и PCIe-шину. Если сетевая карта подключена к одному CPU, а обработка идёт на другом — возникают кросс-процессорные обращения к памяти. Это замедляет работу и увеличивает джиттер. RSS-очереди позволяют «прибить» обработку трафика к тому же CPU, к которому физически подключена сетевая карта. Это серьёзно оптимизирует производительность.

Таким образом, основные рекомендации просты: использовать RSS-очереди и аппаратное проставление таймингов.