[fox_m]

Всем привет.

 

Столкнулся с такой проблемой. Есть коммутатор Cisco3750, к которому подключены потребители мультикаста. В какой-то момент, на одном интерфейсе стали сыпаться ТВ каналы, а на самом интерфейсе появились output drops. Дропы растут не постоянно, а примерно раз 5-10 мин. QoS активирован, под мультик выделена своя очередь с увеличенным буфером. Собственно, через коммутатор идет только мультикаст другого трафика можно сказать что нет. Пробовал крутить буфера, и настройки шедулера интерфейса, но не помогло. Дропы в мультикастной очереди продолжались. Проблемный интерфейс принимает ~ 50-70 разных мультикаст групп. Удалось заметить, что если отключиться от одной из групп, то все приходит в норму. Судя по всему, проблемная группа генерит какой-то странный поток или что-то в этом роде. Битрейт при этом у нее совсем небольшой ~ 4-5 мбит/c. Как он умудряется забивать буфера на интерфейсе совершенно непонятно. Что самое интересное, на других C3750 тоже возникают проблемы, если подключиться к этой проблемной группе. Что за хрень такая?

[s.lobanov]

это проблема того, что та группа которую вы нашли имеет некачественный генератор (очень высокие бёрсты). снимите дамп tcpdump-ом (лучше в /dev/shm) и посмотрите степень неравномерности приходящих пакетов (wireshark-ом), потом предъявите эту картинку тому кто дает вам этот мультикаст на вход

[fox_m]

10 минут назад, s.lobanov сказал:

это проблема того, что та группа которую вы нашли имеет некачественный генератор (очень высокие бёрсты). снимите дамп tcpdump-ом (лучше в /dev/shm) и посмотрите степень неравномерности приходящих пакетов (wireshark-ом), потом предъявите эту картинку тому кто дает вам этот мультикаст на вход

Спасибо, попробую. А wireshark покажет эти burst'ы? 

[s.lobanov]

29 минут назад, fox_m сказал:

Спасибо, попробую. А wireshark покажет эти burst'ы? 

Да. Statistics->I/O graph, только надо поиграться с Interval (сделать его меньше чем 1 sec)

 

Также сравните проблемную группу с другими

 

Важно еще нормально снять дамп (лучше всего в /dev/shm). В идеале делать дамп на сетевой с hw timestamping, с соответствующим ядром и версией libpcap, но скорее всего и без этого будет всё видно

[fox_m]

 

Подскажите, Max BW - это грубо говоря максимальный битрейт? Если то, то получается, что он достигал 160 Мб/c? И что значит колонка Mux Burst (в документации написано, что вроде это максимальное кол-во пакетов в единицу времени)? Тут тоже значения значительно отличаются от нормальных потоков. 

[fox_m]

 

В общем, вот такая картина получается. Видимо эти burst'ы и есть причина дропов. Самое интересное, у нас есть специальный анализатор мультика (Bridgetech), так он показывает максимальный битрейт не более 5 Мбит/c. Вот и доверяй ему после этого.

[s.lobanov]

да, только я не помню за какой период усредняется в этом окне (скорее всего за 100мс, т.е. по факту за 10мс будет еще больше). у вас видно на картинке что всё плохо

 

у телевизионщиков параметр для мониторинга таких проблем называется IAT. если у вас есть IPTV-анализаторы, то там он будет очень высоким (плохим)

 

на bridgetech смотрите не bitrate, а не IAT

 

bitrate всегда усредняется в таких анализаторах, скорее всего анализатор считает среднее за секунду и там всё ок

 

откуда берете этот мкаст? сами генерируете? транспортируете через кучу промежуточных узлов?

[s.lobanov]

как W/A можете загнать эту группу в отдельную очередь пока не почините генератор или транспорт, чтобы её берсты не мешали нормальной работе остальных групп

[fox_m]

12 минут назад, s.lobanov сказал:

да, только я не помню за какой период усредняется в этом окне (скорее всего за 100мс, т.е. по факту за 10мс будет еще больше). у вас видно на картинке что всё плохо

 

у телевизионщиков параметр для мониторинга таких проблем называется IAT. если у вас есть IPTV-анализаторы, то там он будет очень высоким (плохим)

 

на bridgetech смотрите не bitrate, а не IAT

 

bitrate всегда усредняется в таких анализаторах, скорее всего анализатор считает среднее за секунду и там всё ок

 

откуда берете этот мкаст? сами генерируете? транспортируете через кучу промежуточных узлов?

Почему на IAT обращать внимание? IAT - это по сути ведь джиттер? Кстати, он на этом канале раз в 10 больше, чем у остальных. Поток берем от партнера (RTMP через Интернет) и прогоняем его через свой кодер, что бы мультикаст получить на выходе. 

[s.lobanov]

потому что jitter это и есть оценка того насколько некачественный поток с точки зрения birst'ов

 

>Поток берем от партнера (RTMP через Интернет) и прогоняем его через свой кодер, что бы мультикаст получить на выходе. 

 

тогда сделайте дамп на входном интерфейсе сервера, который занимается перекодировкой (или на зеркале если это не обычный linux-сервер). скорее всего из-за Интернета такие берсты. 

 

вообще, нормальные кодеры умеют нормализовывать jitter (это относительно типовая фича для всякого рода транскодеров)

[fox_m]

12 минут назад, s.lobanov сказал:

потому что jitter это и есть оценка того насколько некачественный поток с точки зрения birst'ов

 

>Поток берем от партнера (RTMP через Интернет) и прогоняем его через свой кодер, что бы мультикаст получить на выходе. 

 

тогда сделайте дамп на входном интерфейсе сервера, который занимается перекодировкой (или на зеркале если это не обычный linux-сервер). скорее всего из-за Интернета такие берсты. 

 

вообще, нормальные кодеры умеют нормализовывать jitter (это относительно типовая фича для всякого рода транскодеров)

Понятно. Спасибо!

[s.lobanov]

@fox_mсмогли сделать iat/jitter нормальным? какими средствами решили проблему?

[fox_m]

В общем пока на нашем кодере (elive) принудительно выставили CBR 4Мбит/c для выходной трубы. До этого он сам формировал трубу исходя из из битрейтов видео + аудио. IAT все равно остается высоким, но таких больших берстов пока не наблюдаем. Вообще есть подозрение, что проблема в кодере, поскольку с ним в последнее время что то происходить стало, и на некоторых потоках с него стали появляться CC error, хотя в исходных потоках все в порядке. В общем продолжаем наблюдать.