Je možné omezit maximální přenosovou rychlost UDP (na zásuvku) v Linuxu pomocí systémových nastavení? — Habr Otázky a odpovědi
Je možné v Linuxu (kernel 4.19.56) omezit rychlost odesílání paketů udp na základě jednotlivých soketů pomocí nastavení jádra/iptables? Tito. aby žádný jednotlivý udp socket nemohl posílat pakety častěji než jednou za n mikrosekund, ale zároveň nebyla omezena celková propustnost (pro všechny sockety)? Pakety, které se nevejdou do limitu, by neměly být zahozeny, ale uloženy do vyrovnávací paměti.
Omezení šířky pásma nikoli v paketech, ale v kilobajtech bude také fungovat, ale průměrná doba výpočtu by měla být krátká (milisekundy).
Nepříliš stručný příběh na pozadí, není povinná četba:
Existuje kus hardwaru (Netup Streamer), který odesílá IP multicast video. Ve skutečnosti je to [téměř] běžný x86 linuxový server, na kterém běží Debian Stretch. Připojení k síti přes 1Gbps link.
Po aktualizaci firmwaru streameru začali klienti mít problémy:
IPTV přijímače připojené k síti pomocí 1Gbps spojení začaly produkovat šílený obraz. Přitom ty připojené rychlostí 100 Mbps normálně fungují. Ne, nic se neplete: 100 Mbps – vše v pořádku, 1 Gbps – obraz se rozpadá.
Vynucení portu přepínače na 100 Mbps problém zmizí.
na pokles počet kanálů vysílaných v síti (až jeden) problém se prohlubuje, tzn. obraz na přijímačích je více ‘roztrhaný’.
Technická podpora ukázala na naši síť, kabely, IGMP snooping, požádala o vypnutí a opětovné zapnutí a jinými způsoby předstírala, že je strom.
S kabely, sítí obecně a IGMP snoopingem je vše v pořádku: provoz přicházející na klientský port je přesně to, co je potřeba. Navíc foceno s notebooky s vestavěnou síťovou kartou výpadky provozu z portů 100Mbps a 1Gbps zcela sladěné. A VLC na těchto noteboocích ukázal perfektní obraz v obou případech. A tady na notebooku se sítí USB obraz byl roztrhaný a byly zjištěny ztráty paketů.
Trochu brainstormingu a důvod se našel: streamer přijímá TV signál (ze satelitu), něco je demuxováno-remuxováno a posílá to přes UDP multicast do sítě. Datový tok každého streamu je ~10 Mbps.
ALE protože to „něco remixuje“, těchto 10 Mbps není nepřetržitý stream, ale dávky paketů plnou gigabitovou rychlostí, proložené ~20 milisekundovými pauzami (50 snímků za sekundu, protože). Tito. Každý snímek je streamerem vyplivnut do sítě tak rychle, jak jen může. Pak je to jednoduché: referenční rámec může být poměrně velký a síť USB (a v STB ty síťové obvykle visí na sběrnici USB) přijímající stream IPTV na rozhraní 1 Gb/s prostě nestihne dát vše do sběrnice USB a některé pakety z největších dávek se ztratí. Jak jste pochopili, „největší balíčky“ jsou klíčové snímky. Když port pracuje v režimu 100 Mb/s, přepínač ukládá pakety do vyrovnávací paměti a provoz je přijímán normálně.
ps: řízení toku na portech klientského přepínače není řešením problému.
- Otázka byla položena před více než třemi lety
- Zobrazení 650
7 komentáře
Přihlásit se k odběru 3
Náročné 7 komentáře
Je možné napsat na výrobce hardwaru a vrátit firmware?
Zolg @Zolg Autor otázky
ru6ak, vidíš, aktuální aktualizace firmwaru je dlouho očekávaným výsledkem požadavku výrobce na vyřešení dalšího problému (který nelze vyřešit upnutím portu na 100Mbps).
Navíc se o tento problém nestará ani samotný výrobce, protože. jeho nativní STB (samozřejmě čínský OEM) je dost slabý a jen 100Mbps. Takže ani nevidí, že „něco není v pořádku“, protože v 99.999 % případů problém maskuje vyrovnávací paměť přepínače a 0.001 % lze připsat problému se sítí nebo zdrojovým signálem.
Nabízím berličku. Pokud je 100 Mbps normální, tak pomalého klienta připojte kabelem, který neumožní připojení rychlostí 1000 Mbps, tzn. který má krimpované pouze dva páry – oranžový (1, 2) a zelený (3, 6).
Zolg @Zolg Autor otázky
hint000, je to jednodušší to udělat v nastavení portu přepínače (a samozřejmě je to hotovo)
ale to je jen berlička, protože
Za prvé, problém není vyřešen, ale (celkem dobře) maskován. shluky zůstávají na 100 Mbps, ale je mnohem méně pravděpodobné, že způsobí nežádoucí následky
Za druhé, set-top boxy s 1Gbps rozhraním kromě výstupu IPTV streamů plní i další úkoly, pro které je gigabit užitečný.
Valentin @vvpoloskin Kurátor značky Počítačové sítě
Jaká je MTU a skutečná velikost přenášených paketů? Možná tam jede jeden tlustý balík a kvůli tomu všechno umírá?
Valentin @vvpoloskin Kurátor značky Počítačové sítě
Zde jsou dvě možnosti pro rozvoj vašeho výzkumu:
1) nějaký střední proxy nebo převodník s vlastními parametry
2) plánovač typu qdisc/tc a plánování není nutné, můžete snížit mtu a dát zpoždění při přenosu paketů
Zolg @Zolg Autor otázky
Miláček,
mtu na rozhraních streameru 1500
velikost odesílaných UDP paketů je obecně 1344 (20+8+1316)
takže ne, o mtu to bohužel není
Řešení otázky 1
Zolg @Zolg Autor otázky
Pokus, omyl a kouření many vedly k řešení.
Objeví se potřebná funkce rychlost paketů, implementované ve spravedlivé frontě dopravní policista
Charakteristické je, že značná část vygooglovaných materiálů na dané téma se týkala IPTV vysílání.
# tc qdisc show dev eth0
qdisc pfifo_fast 0: kořenový refcnt 2 pásma 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 a hostitel 235.1.6.4
.
00:00:00.022090 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000024 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000022 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000011 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000014 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000022 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000014 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000013 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000021 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000014 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000015 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000038 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000020 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000044 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000042 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000012 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000005 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000015 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000026 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000005 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000005 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000016 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000020 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000007 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000020 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000032 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000007 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000022 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000005 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000014 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.022102 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
oříznut na pakety odpovídající začátku snímku h.264
Po:
# tc qdisc add dev eth0 root fq pacing maxrate 25Mbit
# tcpdump –time-stamp-precision=micro -ttt –dont-verify-checksums udp a hostitel 235.1.6.4
.
00:00:00.016850 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000023 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000524 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000929 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000011 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000964 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000013 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000941 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000960 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000961 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000007 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000977 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000011 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000941 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.001008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000013 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000910 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000954 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000956 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000961 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000962 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.009238 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000036 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000492 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000012 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000976 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000942 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000957 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000008 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000958 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000007 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000004 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000963 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000010 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000957 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.000009 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
00:00:00.016154 IP iptv-server.57842 > 235.1.6.4.1234: UDP, délka 1316
oříznut na pakety odpovídající začátku snímku h.264, hustý balík zbývajících paketů snímku je nyní rozmazán v průběhu času.
funguje perfektně. nebylo zaznamenáno žádné zvýšení zátěže streameru (celkový odchozí tok 250+Mbps).
parametr maxrate se nevztahuje na frontu jako celek, ale na každé vlákno zvlášť (ve skutečnosti nastavuje výchozí hodnotu soketu SO_MAX_PACING_RATE)