fox_m Опубликовано 19 октября, 2020 · Жалоба Всем привет. Столкнулся с такой проблемой. Есть коммутатор Cisco3750, к которому подключены потребители мультикаста. В какой-то момент, на одном интерфейсе стали сыпаться ТВ каналы, а на самом интерфейсе появились output drops. Дропы растут не постоянно, а примерно раз 5-10 мин. QoS активирован, под мультик выделена своя очередь с увеличенным буфером. Собственно, через коммутатор идет только мультикаст другого трафика можно сказать что нет. Пробовал крутить буфера, и настройки шедулера интерфейса, но не помогло. Дропы в мультикастной очереди продолжались. Проблемный интерфейс принимает ~ 50-70 разных мультикаст групп. Удалось заметить, что если отключиться от одной из групп, то все приходит в норму. Судя по всему, проблемная группа генерит какой-то странный поток или что-то в этом роде. Битрейт при этом у нее совсем небольшой ~ 4-5 мбит/c. Как он умудряется забивать буфера на интерфейсе совершенно непонятно. Что самое интересное, на других C3750 тоже возникают проблемы, если подключиться к этой проблемной группе. Что за хрень такая? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 октября, 2020 · Жалоба это проблема того, что та группа которую вы нашли имеет некачественный генератор (очень высокие бёрсты). снимите дамп tcpdump-ом (лучше в /dev/shm) и посмотрите степень неравномерности приходящих пакетов (wireshark-ом), потом предъявите эту картинку тому кто дает вам этот мультикаст на вход Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 19 октября, 2020 · Жалоба 10 минут назад, s.lobanov сказал: это проблема того, что та группа которую вы нашли имеет некачественный генератор (очень высокие бёрсты). снимите дамп tcpdump-ом (лучше в /dev/shm) и посмотрите степень неравномерности приходящих пакетов (wireshark-ом), потом предъявите эту картинку тому кто дает вам этот мультикаст на вход Спасибо, попробую. А wireshark покажет эти burst'ы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 октября, 2020 · Жалоба 29 минут назад, fox_m сказал: Спасибо, попробую. А wireshark покажет эти burst'ы? Да. Statistics->I/O graph, только надо поиграться с Interval (сделать его меньше чем 1 sec) Также сравните проблемную группу с другими Важно еще нормально снять дамп (лучше всего в /dev/shm). В идеале делать дамп на сетевой с hw timestamping, с соответствующим ядром и версией libpcap, но скорее всего и без этого будет всё видно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 19 октября, 2020 · Жалоба Подскажите, Max BW - это грубо говоря максимальный битрейт? Если то, то получается, что он достигал 160 Мб/c? И что значит колонка Mux Burst (в документации написано, что вроде это максимальное кол-во пакетов в единицу времени)? Тут тоже значения значительно отличаются от нормальных потоков. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 19 октября, 2020 · Жалоба В общем, вот такая картина получается. Видимо эти burst'ы и есть причина дропов. Самое интересное, у нас есть специальный анализатор мультика (Bridgetech), так он показывает максимальный битрейт не более 5 Мбит/c. Вот и доверяй ему после этого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 октября, 2020 · Жалоба да, только я не помню за какой период усредняется в этом окне (скорее всего за 100мс, т.е. по факту за 10мс будет еще больше). у вас видно на картинке что всё плохо у телевизионщиков параметр для мониторинга таких проблем называется IAT. если у вас есть IPTV-анализаторы, то там он будет очень высоким (плохим) на bridgetech смотрите не bitrate, а не IAT bitrate всегда усредняется в таких анализаторах, скорее всего анализатор считает среднее за секунду и там всё ок откуда берете этот мкаст? сами генерируете? транспортируете через кучу промежуточных узлов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 октября, 2020 · Жалоба как W/A можете загнать эту группу в отдельную очередь пока не почините генератор или транспорт, чтобы её берсты не мешали нормальной работе остальных групп Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 19 октября, 2020 · Жалоба 12 минут назад, s.lobanov сказал: да, только я не помню за какой период усредняется в этом окне (скорее всего за 100мс, т.е. по факту за 10мс будет еще больше). у вас видно на картинке что всё плохо у телевизионщиков параметр для мониторинга таких проблем называется IAT. если у вас есть IPTV-анализаторы, то там он будет очень высоким (плохим) на bridgetech смотрите не bitrate, а не IAT bitrate всегда усредняется в таких анализаторах, скорее всего анализатор считает среднее за секунду и там всё ок откуда берете этот мкаст? сами генерируете? транспортируете через кучу промежуточных узлов? Почему на IAT обращать внимание? IAT - это по сути ведь джиттер? Кстати, он на этом канале раз в 10 больше, чем у остальных. Поток берем от партнера (RTMP через Интернет) и прогоняем его через свой кодер, что бы мультикаст получить на выходе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 октября, 2020 · Жалоба потому что jitter это и есть оценка того насколько некачественный поток с точки зрения birst'ов >Поток берем от партнера (RTMP через Интернет) и прогоняем его через свой кодер, что бы мультикаст получить на выходе. тогда сделайте дамп на входном интерфейсе сервера, который занимается перекодировкой (или на зеркале если это не обычный linux-сервер). скорее всего из-за Интернета такие берсты. вообще, нормальные кодеры умеют нормализовывать jitter (это относительно типовая фича для всякого рода транскодеров) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 19 октября, 2020 · Жалоба 12 минут назад, s.lobanov сказал: потому что jitter это и есть оценка того насколько некачественный поток с точки зрения birst'ов >Поток берем от партнера (RTMP через Интернет) и прогоняем его через свой кодер, что бы мультикаст получить на выходе. тогда сделайте дамп на входном интерфейсе сервера, который занимается перекодировкой (или на зеркале если это не обычный linux-сервер). скорее всего из-за Интернета такие берсты. вообще, нормальные кодеры умеют нормализовывать jitter (это относительно типовая фича для всякого рода транскодеров) Понятно. Спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 октября, 2020 · Жалоба @fox_mсмогли сделать iat/jitter нормальным? какими средствами решили проблему? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 24 октября, 2020 · Жалоба В общем пока на нашем кодере (elive) принудительно выставили CBR 4Мбит/c для выходной трубы. До этого он сам формировал трубу исходя из из битрейтов видео + аудио. IAT все равно остается высоким, но таких больших берстов пока не наблюдаем. Вообще есть подозрение, что проблема в кодере, поскольку с ним в последнее время что то происходить стало, и на некоторых потоках с него стали появляться CC error, хотя в исходных потоках все в порядке. В общем продолжаем наблюдать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...