Is it possible to limit the peak UDP transfer rate (per-socket) in linux with system settings?

Question

linux

Is it possible in linux (kernel 4.19.56) to limit the speed of sending udp packets on a per-socket basis with kernel / iptables settings? Those. so that any single udp socket cannot send packets more than once every n microseconds, but the total throughput (for all sockets) is not limited ? Packets that do not fit into the limit should not be discarded, but buffered.
Limiting the bandwidth not in packets, but in kilobytes will also suit, but the period for calculating the average should be short (milliseconds).
Not a very short background, optional reading:

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 на портах клиентского коммутатора - не решение проблемы.

Answer 1

Trial, error and mana smoking led to a solution.
The necessary feature is called packet pacing , implemented in fair queue traffic policer 'e
What is characteristic - a tangible part of the materials googled on the topic concerned iptv broadcasting
to:
# 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

truncated on packets matching start of h.264 frame
After:
# 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

truncated by the packets corresponding to the beginning of the h.264 frame, the dense burst of the rest of the frame packets is now smeared in time.
works perfect. no increase in the load on the streamer (total outgoing stream 250+Mbps) was recorded.
the maxrate parameter does not refer to the queue as a whole, but to each thread individually (in fact, it sets the value of the SO_MAX_PACING_RATE socket option by default)

Answer 2

But on a laptop with a USB network picture was torn and packet loss was detected.

those. packet loss was detected not on the server, not on the switches, but already on the end device.
Well, solve the problem with the end device then. Servers and networks should not solve Indian problems.
the 1000Base-T standard is generally speaking not about speed, but about the principle of encoding and transmitting information over a physical medium (4 copper pairs). those. it's more about signal level compatibility.
Yes, using this medium it is theoretically possible to transmit and receive (simultaneously) a frame stream of 1000Mbps.
But if the laptop has a brake chipset and it can transmit a maximum of 150Mbps, then it will still have 10/100/1000 in the characteristics of its network card. After all, 150 is more than 100, and there are no intermediate formats from 100 to 1000.
When there is a TCP stream, then flow control is built into the protocol and there are no problems
with UDP, it gets worse. here flow control is usually taken out further to the application level.
In the case of a malticast, there are no such mechanisms out of the box. You can only subscribe to the channel with the worst quality.
By the way, your IGMP snooping may indeed not work or be configured incorrectly. Or do you really pour more than 10 streams of 10 meters into the laptop?

Answer 3

Set up shaper for IPTV traffic.

Answer 4

I would try to solve the problem by setting up traffic shaping inside the same debian towards each individual client (for example, if the stream is 10Mbps, limit it to 15Mbps) using, for example, https://lartc.org/howto/lartc.qdisc.html (beginning of documentation) If but right inside there is no such possibility, then put something between the network with consumers with a piece of iron that will shape the traffic.