Сегодня мы разберем, казалось бы, простую тему — мониторинг мультикаста. Несмотря на кажущуюся простоту, здесь тоже хватает сложностей. И первая из них — особенности контроллера.
В мультикасте нас в первую очередь интересуют две метрики. Первая — потери пакетов. Это важно и для 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-очереди и аппаратное проставление таймингов.