Poslední příspěvky1
Sítě / Re:Funkční 10GbE řešení pro TrueNAS Scale
« Poslední příspěvek od František Ryšánek kdy Dnes v 08:13:36 »Hele nepadla tady jedna zásadní věc: vidíte na počítadlech vadně přijatých paketů (err) na síťovkách číslo vyšší než 0 ?
Pokud ano, hledejte problém na fyzické vrstvě (transceivery, vlákna, kompatibilita transceiverů proti síťovkám).
Pokud je tam nula, tak máte fyzickou vrstvu nejspíš v pořádku.
Tady někdo popisuje podobný problém a udává velmi podobné hodnoty jako Vy - a pak si všiml, že má 10Gb síťovku linknutou na PCI-e jenom šířkou x1 :-)
lspci -s 03:00.0 -vv | grep LnkSta:
LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
Ve vašem případě by nejspíš lspci navíc přidalo kyselý dovětek "downgraded" = že se zařízení dohodlo pod svoje možnosti.
Číslo zařízení jsem zadal natvrdo, abych dostal hodnotu jenom pro své konkrétní zařízení. Jedná se vlastně o pozici na sběrnici, najdete ji ve výpisu lspci bez parametrů.
Testoval bych předně linux proti linuxu. Oddělíte tak windowsové špecifiká od skutečných HW problémů.
Pak mě napadá, zakázat procesoru hlubší C-states. V linuxu na AMD nejspíš processor.max_cstate=1 (nebo i =0, třeba jenom na chvilku). Jinak pro to bývá položka v BIOS SETUPu, ta platí i pro Linux (i pro Windows). Výsledek ukáže tuším turbostat z balíku linux-cpupower (Debian/Ubuntu). A možná bych neváhal vyzkoušet pcie_aspm=off.
Man iperf3 zmiňuje pár dalších zajímavých věcí.
Například, že -P (paralelní streamy) ve skutečnosti jede na jediném CPU jádře, protože iperf3 je jednovláknový :-( takže víc jader tím nevytížíte.
Dále bych zmínil -Z (zero copy), což by mohlo trochu omezit režii.
Pak jsem si všiml -w/--window -- tady si nejsem jist, zda se uplatní také u UDP. Jinak na TCP by si iPerf měl správnou velikost okna ustálit sám...
Dále manuál zmiňuje možnost, nastavit afinitu k CPU jádru parametrem -A. Mohlo by se hodit, nechat běžet iPerf na jádře, které obsluhuje interrupty od síťovky - viz "cat /proc/interrupts" . Ačkoli je pravda, že hardware síťovek a ovladače se snaží provádět "interrupt amalgamation" (moderation) aby se stroj neudávil jenom obsluhou IRQ. Tohle se děje zhruba od gigabitu výš, na 10Gb hardwaru zcela určitě. Tuším se toho týká keyword NAPI, což je nějaký generický framework linuxového kernelu pro tyhle kejkle - využívají ho drivery síťovek, konkrétně drivery od Intelu ho tuším zmiňují při bootu v dmesg (osobně jsem to pozoroval u gigových síťovek, 10Gb mi tolik rukama neprochází). Jinak se historicky vyskytlo také API zvané netpoll, což je ale asi trochu jiné zvířátko, je třeba ho v aplikacích používat explicitně a iperf3 ho zjevně neumí. Kdoví, zda je to vůbec ještě aktuální - zda to někdy opustilo stádium out-of-tree patche.
Našel jsem takový lehce povrchní starší článek od RedHatu, jak ladili průchodnost (pakety za sekundu) zřejmě na téže síťovce, co máte Vy. Není tam moc zaklínadel v příkazovém řádku, ale jako rozcestník = seznam dalších tipů by to mohlo být použitelné.
Pokud ano, hledejte problém na fyzické vrstvě (transceivery, vlákna, kompatibilita transceiverů proti síťovkám).
Pokud je tam nula, tak máte fyzickou vrstvu nejspíš v pořádku.
Tady někdo popisuje podobný problém a udává velmi podobné hodnoty jako Vy - a pak si všiml, že má 10Gb síťovku linknutou na PCI-e jenom šířkou x1 :-)
lspci -s 03:00.0 -vv | grep LnkSta:
LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
Ve vašem případě by nejspíš lspci navíc přidalo kyselý dovětek "downgraded" = že se zařízení dohodlo pod svoje možnosti.
Číslo zařízení jsem zadal natvrdo, abych dostal hodnotu jenom pro své konkrétní zařízení. Jedná se vlastně o pozici na sběrnici, najdete ji ve výpisu lspci bez parametrů.
Testoval bych předně linux proti linuxu. Oddělíte tak windowsové špecifiká od skutečných HW problémů.
Pak mě napadá, zakázat procesoru hlubší C-states. V linuxu na AMD nejspíš processor.max_cstate=1 (nebo i =0, třeba jenom na chvilku). Jinak pro to bývá položka v BIOS SETUPu, ta platí i pro Linux (i pro Windows). Výsledek ukáže tuším turbostat z balíku linux-cpupower (Debian/Ubuntu). A možná bych neváhal vyzkoušet pcie_aspm=off.
Man iperf3 zmiňuje pár dalších zajímavých věcí.
Například, že -P (paralelní streamy) ve skutečnosti jede na jediném CPU jádře, protože iperf3 je jednovláknový :-( takže víc jader tím nevytížíte.
Dále bych zmínil -Z (zero copy), což by mohlo trochu omezit režii.
Pak jsem si všiml -w/--window -- tady si nejsem jist, zda se uplatní také u UDP. Jinak na TCP by si iPerf měl správnou velikost okna ustálit sám...
Dále manuál zmiňuje možnost, nastavit afinitu k CPU jádru parametrem -A. Mohlo by se hodit, nechat běžet iPerf na jádře, které obsluhuje interrupty od síťovky - viz "cat /proc/interrupts" . Ačkoli je pravda, že hardware síťovek a ovladače se snaží provádět "interrupt amalgamation" (moderation) aby se stroj neudávil jenom obsluhou IRQ. Tohle se děje zhruba od gigabitu výš, na 10Gb hardwaru zcela určitě. Tuším se toho týká keyword NAPI, což je nějaký generický framework linuxového kernelu pro tyhle kejkle - využívají ho drivery síťovek, konkrétně drivery od Intelu ho tuším zmiňují při bootu v dmesg (osobně jsem to pozoroval u gigových síťovek, 10Gb mi tolik rukama neprochází). Jinak se historicky vyskytlo také API zvané netpoll, což je ale asi trochu jiné zvířátko, je třeba ho v aplikacích používat explicitně a iperf3 ho zjevně neumí. Kdoví, zda je to vůbec ještě aktuální - zda to někdy opustilo stádium out-of-tree patche.
Našel jsem takový lehce povrchní starší článek od RedHatu, jak ladili průchodnost (pakety za sekundu) zřejmě na téže síťovce, co máte Vy. Není tam moc zaklínadel v příkazovém řádku, ale jako rozcestník = seznam dalších tipů by to mohlo být použitelné.
