Возможно ли в linux системными насторйками ограничить пиковую скорость передачи UDP (per-socket)?

Question

[Zolg]

Возможно ли в linux'е (ядро 4.19.56) настройками ядра/iptables ограничить скорость отправки udp-пакетов на per-socket основе ? Т.е. чтобы любой отдельно взятый udp socket не мог отправлять пакеты чаще чем раз в n микросекунд, но при этом общая пропускная способность (для всех сокетов) не ограничивалась ? Пакеты, не укладывающиеся в лимит должны не отбрасываться, а буферизироваться.
Ограничение пропускной способности не в пакетах, а в килобайтах так же устроит, но период расчета среднего должен быть коротким (миллисекунды).

Не очень кратенькая предыстория, к прочтению необязательная:

spoiler

Есть железка (Netup Streamer), рассылающая IP multicast video. Фактически это [почти] обычный x86 Linux сервер под Debian Stretch. Подключена к сети по 1Gbps линку.
После обновления прошивки стримера стали наблюдаться проблемы у клиентов:
IPTV-приемники, подключенные к сети по 1Gbps линкам стали безумно сыпать картинку. При этом подключенные по 100Mbps работают нормально. Нет, ничего не перепутано: 100Mbps - полет нормальный, 1Gbps - картинка рассыпается.
При принудительном переводе порта коммутатора в 100Mbps проблема исчезает.
При уменьшении количества транслируемых в сеть каналов (вплоть до одного) проблема усугубляется, т.е. картинка на приемниках 'рвется' сильнее.
Техподдержка кивала на нашу сеть, кабеля, IGMP snooping, просила выключить и снова включить и другими способами изображала дерево.
C кабелями, сетью в целом и IGMP snooping в частности все в порядке: трафик на клиентский порт приходит ровно тот, что нужно. Более того, снятые ноутбуками со встроенной сетевой картой дампы трафика с 100Mbps и 1Gbps портов полностью совпали. Да и VLC на этих ноутах и там и там показывал идеальную картинку. А вот на ноуте с USB сетевой картинка рвалась и обнаружились потери пакетов.

Немного мозгового штурма и была найдена причина: стример принимает тв-сигнал (со спутника), что-то там демуксит-ремуксит, и отправляет UDP- мультикастом в сеть. Битрейт каждого потока ~10Mbps.
НО из-за того, что он 'что-то там ремуксит' эти 10Mbps - не непрерывный поток, а пачки пакетов на полной гигабитной скорости, перемежающиеся ~20 миллисекундными паузами (50 кадров в секунду, потому что). Т.е. каждый кадр выплевывается стримером в сеть так быстро, как он может. Далее просто: опорный кадр может быть достаточно большим, и USB сетевая (а в STB сетевые как правило висят на USB шине) принимая IPTV поток на 1Gbps интерфейсе просто не успевает засунуть все в шину USB и некоторые пакеты из наиболее крупных пачек теряются. Как вы понимаете 'наиболее крупные пачки' это key frames. При работе порта в 100Mbps режиме коммутатор буферизирует пакеты и трафик принимается нормально.

ps: flow control на портах клиентского коммутатора - не решение проблемы.

Comments

[ru6ak]

А написать производителю железки, откатить прошивку нельзя ?

[Zolg]

ru6ak, видите ли, нынешнее обновление прошивки - долгожданный результат запроса к производителю для решения другой проблемы (которая зажатием порта на 100Mbps не костылится).
В добавок самому производителю на данную проблему пофиг, т.к. его родные STB (китайский OEM ессно) довольно хилые и 100Mbps only. Так что он даже не видит что 'что-то не так' ибо в 99.999% случаев буферизация свитча проблему маскирует, а 0.001% можно и на косяк сети или исходного сигнала списать.

[hint000]

Предложу костыль. Раз на 100 Mbps нормально, то подключайте тормозного клиента кабелем, который не позволит соединиться на 1000 Mbps, т.е. у которого обжаты только две пары - оранжевая (1, 2) и зелёная (3, 6).

[Zolg]

hint000, это проще в настройках порта свитча делать (и, естественно, сделано)
но это именно костыль, т.к.
во-первых проблема не решается, а (достаточно неплохо) маскируется. burst'ы остаются и на 100Mbps, только гоораздо реже приводят к нежелательным последствиям
во-вторых приставки, имеющие 1Gbps интерфейс помимо вывода IPTV потока еще и другие задачи выполняют, для которых гигабит полезен.

[Валентин]

А какой MTU и реальный размер у передаваемых пакетов? Может там идёт один жирный пакет и из-за этого все умирает?

[Валентин]

Ну и на обозрение два варианта развития ваших изысканий:
1) какая-нибудь промежуточная прокси или конвертер со своими параметрами
2) шедулер типа qdisc/tc, причём шедулить необязательно, можно уменьшить mtu и дать задержку при передаче пакетов

[Zolg]

Валентин,
mtu на интерфейсах стримера 1500
размер отправляемых UDP-пакетов вообще 1344 (20+8+1316)
так что, нет, дело не в mtu, увы

Answer 1

[Zolg]

Пробы, ошибки и курение манов привели к решению.
Необходимая фича завется packet pacing, реализована в fair queue traffic policer'е
Что характерно - ощутимая часть нагугленых по теме материалов касалась именно вещания iptv

до:

# tc qdisc show dev eth0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
#tcpdump --time-stamp-precision=micro -ttt --dont-verify-checksums udp and host 235.1.6.4

spoiler

...
00:00:00.022090 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000024 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000022 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000011 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000014 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000022 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000014 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000013 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000021 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000014 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000015 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000038 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000020 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000044 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000042 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000012 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000005 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000015 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000026 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000005 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000005 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000016 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000020 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000007 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000020 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000032 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000007 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000022 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000005 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000014 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.022102 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316

обрезано по пакетам, соответствующим началу кадра h.264

После:
# tc qdisc add dev eth0 root fq pacing maxrate 25Mbit
# tcpdump --time-stamp-precision=micro -ttt --dont-verify-checksums udp and host 235.1.6.4

spoiler

...
00:00:00.016850 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000023 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000524 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000929 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000011 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000964 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000013 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000941 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000960 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000961 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000007 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000977 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000011 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000941 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.001008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000013 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000910 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000954 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000956 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000961 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000962 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.009238 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000036 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000492 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000012 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000976 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000942 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000957 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000958 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000007 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000963 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000957 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316
00:00:00.016154 IP iptv-server.57842 > 235.1.6.4.1234: UDP, length 1316

обрезано по пакетам, соответствующим началу кадра h.264, плотная пачка остальных пакетов кадра теперь размазывается по времени.

работает идеально. какого-либо увеличения нагрузки на стример (суммарный исходящий поток 250+Mbps) не зафиксировано.
параметр maxrate относится не к очереди в целом, а к каждому потоку в отдельности (фактически - задает значение опции сокета SO_MAX_PACING_RATE по умолчанию)

Answer 2

[iddqda]

А вот на ноуте с USB сетевой картинка рвалась и обнаружились потери пакетов.

т.е. потери пакетов обнаружились не на сервере, не на коммутаторах, а уже на конечном устройстве.
Ну и решайте проблему с конечным устройством тогда. Сервера и сети не должны решать проблемы индейцев.

стандарт 1000Base-T это вообще говоря не про скорость, а про принцип кодирования и передачи информации по физической среде (4 медные пары). т.е. это больше про совместимость по уровням сигналов.
Да, используя эту среду теоретически можно передать и получить (одновременно) поток фреймов в 1000Мбит/с.
Но если у ноута тормозной чипсет и он может передать максимум 150Мбит/с, то все равно в характеристиках его сетевухи будет 10/100/1000. Ведь 150 больше 100, а промежуточных от 100 до 1000 форматов нет.
Когда идет TCP поток, то flow control встроен в протокол и там проблем не возникает
с UDP все хуже. тут flow control обычно выносится дальше на уровень приложения.
В случае мальтикаста вроде таких механизмов из коробки нет. Можно только подписаться на канал с худшим качеством.
Кстати, ваш IGMP снупинг действительно может не работать или быть неправильно настроен. Или вы правда вливаете в ноут больше 10 потоков по 10 метров?

Comments

[Zolg]

Или вы правда вливаете в ноут больше 10 потоков по 10 метров?

Естественно нет. в клиентский порт приходит ОДИН поток в 10Mbps. Другого трафика на порту НЕТ.
Но эти 10Mbps являются 10Mbps только при усреднении на боле-менее длинных интервалах (>20ms). При более коротких интервалах это burst'ы в [почти]1000Mbps, длящиеся сотню-другую микросекунд, перемежающиеся паузами в ~20 миллисекунд. И, как вы совершенно справедливо заметили, клиентское железо с обработкой этих burst'ов не справляется, несмотря на то, что в среднем поток небольшой.

Ну и решайте проблему с конечным устройством тогда. Сервера и сети не должны решать проблемы индейцев.

О, да, конечно, вместо того, чтобы нормализовать поток на сервере, давайте решим проблему с клиентами (читай - заменим на новые, более дорогие).

[maniac_by]

Поддерживаю камрада выше ( iddqda ). У вас на оконечном устройстве чипсет/дешифровщик не справляется с нагрузкой (ибо железо либо дешевое, либо старое). Сервер не решеает проблему отдельных устройств, он не для этого создан. У вас проблема в конкретном ноутбуке (устройстве, карте, чипе и т.д) - решайте проблему с ним. Если он не может прожевать на интервеле 1000Мбит/с, то ему хоть оптику впихните - это не поможет.

[iddqda]

ну так задайте этим клиентам 100М на порту и проблема решена
А вообще, с архитектурной точки зрения, не стоит без острой необходимости пытаться решать проблему между клиентом и сервером (точнее сервисом) в каких то промежуточных узлах

правильней будет открыть кейс у разработчика

[Zolg]

Вы не понимаете о чем я пишу.
ТВ-канал, приходящий со спутника, представляет собой цифровой сигнал в 10Mbps, причем эти 10Mbps это именно один бит каждую 0,1 микросекунду (это не совсем так, со спутника приходит мультиплекс из нескольких каналов, но для первого приближения и понимания порядка величин вполне подходит).
STB-коробка (а проблемы именно с STB коробками, а не 'конкретным ноутбуком'. И коробок этих на объекте несколько сотен) прекрасно с этой задачей справлялась.
Но как только стример стал слать не 'один бит каждую 0,1 микросекунду' а сначала 200000 бит за 100 микросекунд (100 бит в 0,1 микросекунды), а затем 19800 микросекунд молчать приставки наелись.

И т.к. задача приставки не столько молотить сетевой трафик, сколько показывать TV-поток, а исходный TV-поток творчески обрабатывается сервером до непринимаемого состояния, то проблема в общем-то не совсем в приставке.

[Zolg]

ну так задайте этим клиентам 100М на порту и проблема решена

Боже, как же мы без тостера до такого гениального решения не додумались. Одна проблема - железки помимо тв еще и собственный контент показывать умеют и для его прогрузки типагигабит был вполне кстати.

в каких то промежуточных узлах

с чего вы взяли про промежуточные узлы ? к стримеру есть рут-доступ, на нем обычный дебиан.

правильней будет открыть кейс у разработчика

и до этого мы без тостера додуматься никак не смогли. но прошлый опыт общения с ними показывает, что время ожидания решения и его качество мягко говоря желают лучшего.

[iddqda]

в системе клиент-сервер ваш дебиан находится посередине как и ОС на клиенте. т.е. являются промежуточными узлами. И там и там вы теоретически можете повлиять на работоспособность сервиса.
Наверное можно написать какой-то кольцевой буфер для нормализации потоков, но, возможно, проще будет не строить велосипеды, а починить то что работало.
могу предложить откатить версию софта на сервере, но вы, наверное, тоже уже догадались до этого гениального решения без тостера

Answer 3

[res2001]

Настройте шейпер для IPTV трафика.

Answer 4

[Владимир]

Я бы попробывал решить проблему через настройку трафик шейпинга внутри тогоже дебиана в сторону каждого отдельного клиента (например если поток 10МБит - ограничить до 15Мбит) при помощи например https://lartc.org/howto/lartc.qdisc.html (начало документации) Если же прям внутри нет такой возможности то между сетью с потребителями железкой поставить чтото что будет шейпить трафик.

Comments

[Zolg]

В том, что нужно, мы уже более-менее разобрались: нужен pacing для UDP трафика. Вопрос 'как' ?
если б мы могли сами перекомпилировать стримящий софт, то по идее достаточно было бы включить fq на интерфейсе и при открытии сокета в опциях указывать so_max_pacing_rate.
Но на открытие сокета мы, увы, повлиять не можем.
Есть ли вариант установить systemwide умолчания для sockopt вновь открываемых сокетов ?

[Валентин]

Zolg, это не будет работать для udp. Трафик свыше будет дропаться. И ответ на ваш вопрос - без патча нет.

[Zolg]

не будет работать для udp

как оказалось - будет. и очень хорошо.
и so_max_pacing_rate по умолчанию установить таки можно. вернее не совсем опцию сокета, а умолчание при ее отсутствии.
подробней отписался отдельным коментом, чтобы пометить как решение