Fórum Root.cz
Hlavní témata => Software => Téma založeno: JmJ 25. 08. 2015, 10:46:03
-
Zdravim,
mam hodne slabe prumyslove PC, na kterem mi bezi starsi debian s na miru zkompilovanym kernelem. Pokud zacnu po siti na toto zarizeni posilat velke mnozstvi paketu, pak operacni system presune veskery vykon CPU na reseni softwarovych irq, coz vede k temer uplne smrti jinych dulezitych procesu.
Snazim se zjistit, zda ma toto nejake reseni, ktere nevyzaduje instalaci iptables (ci jineho sw) nebo prekompilovani kernelu. Instalace dodatecnych balicku je ale mensi zlo, nez novy kernel. Driver na sitovku by mel umet NAPI, ktere by snad nejak melo umoznovat, aby by pri velke zatezi se preslo z preruseni na polling ci tak neco, ale nemam to nijak overene. Obslouzit vsechny prichozi pakety neni nutnost, mrtva sit je akceptovatelny stav. Tedy dalsi moznosti je, nejak nastavit limit, kdy prichozi IRQ ze sitovky proste hodit po psovi. Pripadne nejak urcit prioritu zpracovavani softwarovych irq. Ovsem nemuzu obecne "zpomalit/omezit" softwarove IRQ, protoze k PC je pripojeno i dost jinych periferii, ktere musi reagovat co nejrychleji.
Zatim zkoumam co a jak, takze budu vdecny za nejake nasmerovani atd.
-
Co nastavit rate-limiting na switchi?
-
Co nastavit rate-limiting na switchi?
Nemozno. Zarizeni samo musi umet se s tim vyporadat.
-
Prave jsem zjistil, ze interrupt coalescing neumi driver pro mou sitovku zrejme nastavit.
ethtool -c eth0
Coalesce parameters for eth0:
Cannot get device coalesce settings: Operation not supported
Sitovka:
00:08.0 Ethernet controller: RDC Semiconductor, Inc. R6040 MAC Controller
Kernel driver in use: r6040
-
Co nastavit rate-limiting na switchi?
Nemozno. Zarizeni samo musi umet se s tim vyporadat.
Z trabanta formuli neudelate aniz by jste zacali zahazovat neco pred dodatecny SW. Takze na tom budete uplne stejne, akorat misto prace switche to bude prace toho PC. Upgrade PC v ramci toho kernelu neni mozne ? disky, ram, a specialne cpu ?
-
Můžeš zkusit snížit RX buffery na síťovce (ethtool -g eth0). Je to dost hack, ale mohl bys docílit toho co chceš, pakety začne zahazovat už síťovka a nedostanou se vůbec do kernelu.
-
Co presne znamena "Pokud zacnu po siti na toto zarizeni posilat velke mnozstvi paketu"? Predpokladam, ze tam poloucha nejaka aplikace. Neslo by pridusit sitovy provoz te aplikaci? Treba pres trickle, eventuelne trickled?
-
Koupit Mikrotik nebo jinou schopnou krabici a dát to mezi PC a switch.
-
Co presne znamena "Pokud zacnu po siti na toto zarizeni posilat velke mnozstvi paketu"? Predpokladam, ze tam poloucha nejaka aplikace. Neslo by pridusit sitovy provoz te aplikaci? Treba pres trickle, eventuelne trickled?
Zadna aplikace polsouchat nemusi. Konkretne to zahltim napr. UDP pakety o delce cca 100 bytu, kdyz je posilam z normalniho PC, ktere tvrdi, ze jich odesle pres 200 000 za sekundu.
-
Co nastavit rate-limiting na switchi?
Nemozno. Zarizeni samo musi umet se s tim vyporadat.
Z trabanta formuli neudelate aniz by jste zacali zahazovat neco pred dodatecny SW. Takze na tom budete uplne stejne, akorat misto prace switche to bude prace toho PC. Upgrade PC v ramci toho kernelu neni mozne ? disky, ram, a specialne cpu ?
Upgrade nemozny. Je to "system on chip".
-
Můžeš zkusit snížit RX buffery na síťovce (ethtool -g eth0). Je to dost hack, ale mohl bys docílit toho co chceš, pakety začne zahazovat už síťovka a nedostanou se vůbec do kernelu.
Bohuzel ani tohle mi neni prano, Operation not supported.
Kazdopadne zkusim zjistit, jestli se ethtool v kombinaci s driverem sitovky neda nejak rozchodit.
-
Konkretne to zahltim napr. UDP pakety o delce cca 100 bytu, kdyz je posilam z normalniho PC, ktere tvrdi, ze jich odesle pres 200 000 za sekundu.
A tech 200000 paketu za vterinu byste tam z toho PC posilal z jakeho duvodu? Abyste vyzkousel, ze to lze zaDoSovat? Tak budto mate duveryhodnou sit, tak tam ty pakety neposilejte. Nebo vase sit je cochcarna, kam si kdekdo prinese vlastni stroj a bavi se tim, ze vam posila UDP pakety, kam se mu zachce. Takze si nainstalujte iptables, ty vam stroj moc nezatizi a pokud UDP na tom stroji nepotrebujete, tak ho muzete take rovnou kompletne ustrihnout. Jinak, viz k, 12:03:51 - Mikrotik.
-
Konkretne to zahltim napr. UDP pakety o delce cca 100 bytu, kdyz je posilam z normalniho PC, ktere tvrdi, ze jich odesle pres 200 000 za sekundu.
A tech 200000 paketu za vterinu byste tam z toho PC posilal z jakeho duvodu? Abyste vyzkousel, ze to lze zaDoSovat? Tak budto mate duveryhodnou sit, tak tam ty pakety neposilejte. Nebo vase sit je cochcarna, kam si kdekdo prinese vlastni stroj a bavi se tim, ze vam posila UDP pakety, kam se mu zachce. Takze si nainstalujte iptables, ty vam stroj moc nezatizi a pokud UDP na tom stroji nepotrebujete, tak ho muzete take rovnou kompletne ustrihnout. Jinak, viz k, 12:03:51 - Mikrotik.
A je to tu. Proste zarizeni musi takovemu naporu odolat. Tak to je a hotovo. Sit u toho muze umrit, ale jine procesy nesmi. Tvrzenim, ze k tomu vlastne vubec nesmi dojit, tu vec nevyresim. IpTables jsou resenim, jenze take bohuzel znamenaji rekompilaci kernelu.
-
Proste zarizeni musi takovemu naporu odolat.
A) Napsat vlastní driver k síťovce a pokusit se emulovat interrupt coalescing.
B) Vykuchat vnitřnosti z Mikrotiku a vrazit je dovnitř zařízení.
-
A je to tu. Proste zarizeni musi takovemu naporu odolat. Tak to je a hotovo. Sit u toho muze umrit, ale jine procesy nesmi. Tvrzenim, ze k tomu vlastne vubec nesmi dojit, tu vec nevyresim. IpTables jsou resenim, jenze take bohuzel znamenaji rekompilaci kernelu.
pokud to uz ted umira na premiru soft IRQ, tak je velka sance ze rozebehnutim iptables se to jeste zhorsi (v soft IRQ CPU stravi jeste vice casu diky pravidlum v iptables). Nevim kam ty UDP packety miri - jestli na neotevreny port (pak by dropnuti packetu mohlo usetrit cykly CPU diky negenerovani ICMP unreachable packetu) nebo na port obsluhovany nejakou aplikaci (pak by asi byla aplikace videt v zatizeni CPU)
IMHO to zarizeni nema HW vybavu na to aby takovy napor vydrzelo. Chce to vykonnejsi CPU (Ghz + vice jader) a lepsi sitovku.
-
Ak by nieco rozhodovalo o tom, ktory paket je mozne oblsluzit a ktory nie, je potrebne mat na LAN karte specializovany NET procesor. Ak tam nieje, tak o tuto obsluhu sa stara ovladac a ten vykonava vsetko na nejakom CPU. Ak je mrtva siet akceptovatelny stav, tak moze byt vyhovujuce dat kartu DOWN na nejaky cas v zavislosti na pocte paketov za sekundu.
-
Co takhle "upgradovat" zařízení tím, že k němu přidáte router s rate limitingem, pro jistotu to slepte izolepou a máte "upgradované" zařízení které se s tím samo umí vypořádat.
-
A je to tu. Proste zarizeni musi takovemu naporu odolat. Tak to je a hotovo. Sit u toho muze umrit, ale jine procesy nesmi. Tvrzenim, ze k tomu vlastne vubec nesmi dojit, tu vec nevyresim. IpTables jsou resenim, jenze take bohuzel znamenaji rekompilaci kernelu.
Ehm, chci aby to melo kridla, litalo to, ale nechci aby to bylo letadlo ...
Iptables resenim nejsou, iptables je SW filtr, a nezpracovava to nic jinyho nez prave CPU - kazdej jeden paket. Jestli ten stroj neustoji ty pakety na vstupu, kde nic neposloucha, iptables jen zvednou zatizeni jeste vic = zmensi se pocet paketu, ktery to sejmou. JEDINA cesta je omezit ten provoz jinde. Tzn jak bylo receno, mezi to zarizeni a sit dat neco, co to omezit zvladne. Jestli to stim mikrotikem (nebo cikoli jinym) pak strcis co cerny krabice a budes trvrdit, ze to je jedna vec, je uz pak vedlejsi.
A jelikoz 52B x 200k = 10MB/s = 100Mbit sit na 100%. Tohle bude mit problem zvladnout kazda podobna krabka.
-
A jelikoz 52B x 200k = 10MB/s = 100Mbit sit na 100%. Tohle bude mit problem zvladnout kazda podobna krabka.
Mozna by slo nekde vystrachat dva stare huby, co maji jeste BNC konektor. Zapojit to tomu do cesty, dat tam 3m tenkeho Ethernetu a ma to omezene na 1 Mbit, coz by mozna uz stacilo.
-
Panove, vase navrhy jsou slechetne a nejsou jiste nerealne, ale zatim je velka snada to resit tak jak jsem psal. Tedy bez pridavneho zarizeni. Takze by to chtelo napady udrzet v ramci zadani :-)
-
nevim, jestli by slo zmenit prioritu (nice, trickle) "sitoveho procesu"? Pripadne QoS nastaveni kernelu, cgroups.
-
Panove, vase navrhy jsou slechetne a nejsou jiste nerealne, ale zatim je velka snada to resit tak jak jsem psal. Tedy bez pridavneho zarizeni. Takze by to chtelo napady udrzet v ramci zadani :-)
OK, prepni sitovku na 10Mbit. Kazda by to mela umet.
-
Si tam připájej jinou síťovku. Naemuluj tu původní a měj v ní vlastní systém. To už je reálné, ne? To musíš během pár měsíců stihnout a pak už si budeš jen užívat luxusního zařízení.
-
Možná jsem to v diskuzi přehlédl, ale co je to za zařízení (model, výrobce) ?
-
Panove, vase navrhy jsou slechetne a nejsou jiste nerealne, ale zatim je velka snada to resit tak jak jsem psal. Tedy bez pridavneho zarizeni. Takze by to chtelo napady udrzet v ramci zadani :-)
Jak uz tady nekdo radil. Vrtal jsem se v par zarizenich a delal i embedded vyvoj. Vsude se nastavovalo fixne 10Mbit kdyz byl realny problem ze ty levne krabky a pseudositovky by nezvladaly.
Dulezite je nastavit autonegotiate-10MB. A ne jako pometla-lidi s CCNP co nastavi 10 rezim bez autonegotiate a divi se ze jim to blbne kdyz na druhe strane maji autonegotiation.
-
200k pps zabije daleko silnejsi stroje, nez je nejaka zvejkacka prilepena na plosnaku (sry).
Jedina sance bud tomu predradit filtr, nebo pouzit neco, co ma vic jader - sitovka vetsinou zabije jenom jedno.
-
Panove, vase navrhy jsou slechetne a nejsou jiste nerealne, ale zatim je velka snada to resit tak jak jsem psal. Tedy bez pridavneho zarizeni. Takze by to chtelo napady udrzet v ramci zadani :-)
OK, prepni sitovku na 10Mbit. Kazda by to mela umet.
Neuviedol si blizsie informacie. Tak sa necuduj. Z toho co som si precital mam zatial dojem ze sa snazis "pumpovat slavu do prasata" ako by povedal Svejk.
-
Panove, vase navrhy jsou slechetne a nejsou jiste nerealne, ale zatim je velka snada to resit tak jak jsem psal. Tedy bez pridavneho zarizeni. Takze by to chtelo napady udrzet v ramci zadani :-)
OK, prepni sitovku na 10Mbit. Kazda by to mela umet.
Neuviedol si blizsie informacie. Tak sa necuduj. Z toho co som si precital mam zatial dojem ze sa snazis "pumpovat slavu do prasata" ako by povedal Svejk.
:-) ano, to se snazim a jsem si toho vedom. Presto si zatim stale myslim, ze ten problem ma reseni. Jak jiz bylo zmineno, nevadi, kdyz se rozpadne sit. Takze jde o to, v miste mezi hw irq a soft irq vyhodnotit, ze tech hw irq (tedy nejspis "paketu") prichazi moc a proste je zahodit. Tato uprava samozrejme znamena nove jadro, ale to se uz proste neda nic delat.
Nasel jsem si patricne misto v net/core/dev.c a je zajimave, ze presne v miste, kde bych to chtel resit je snad od jadra 3.11 nejaky "flow control" (v jadre 3.9 to tam neni). Opet prosim neomlacovat mi o hlavu, ze samozrejme mam mit nejvyssi jadro atd. Berte to tak, ze u tohoto zarizeni takove veci nejsou jednoduche. Tech zarizeni je totiz "po svete" zrejme par stovek a maji velmi specificky ucel, ktery na ne klade urcite pozadavky, ktere musi byt dodrzeny. Proto proste zkousim pumpovat slavu do prasete, jak pravil jednorocni dobrovolnik Marek :-) Omluvam se, ze nejsem konkretni, ale jednak to nepovazuju za uplne nutne a druhak to neni moc vhodne.
Pokud se mi to podari vyresit primo na tom zarizeni, tak samozrejme bude nahoru sdeleno silne doporuceni, na spravnou konfiguraci site, ktera by cele situaci mela predejit.
Vcera jsem byl na cestach, dnes se v tom zkusim povrtat.
-
Jeste jsem zapomenul k dokresleni situace - po hw strance je to procesor na urovni nejakeho pentia ale na 600 Mhz. Tedy opravdu je to dost pomala zvykacka priplacla na boardu, nebo jak to tu nekdo nazval ;-)
-
:-) ano, to se snazim a jsem si toho vedom. Presto si zatim stale myslim, ze ten problem ma reseni. Jak jiz bylo zmineno, nevadi, kdyz se rozpadne sit. Takze jde o to, v miste mezi hw irq a soft irq vyhodnotit, ze tech hw irq (tedy nejspis "paketu") prichazi moc a proste je zahodit. Tato uprava samozrejme znamena nove jadro, ale to se uz proste neda nic delat.
Pátráte na špatném místě, jakmile vznikne 200k hardwarových přerušení za sekundu tak už máte zahrobenou mašinu z principu obsluhy přerušení a v software už je na řešení pozdě. Musíte nějak hardware domluvit aby to snížil na max 1k, třeba periodickým zakazováním a povolováním přerušení na NIC, nebo přejít na pooling.
-
:-) ano, to se snazim a jsem si toho vedom. Presto si zatim stale myslim, ze ten problem ma reseni. Jak jiz bylo zmineno, nevadi, kdyz se rozpadne sit. Takze jde o to, v miste mezi hw irq a soft irq vyhodnotit, ze tech hw irq (tedy nejspis "paketu") prichazi moc a proste je zahodit. Tato uprava samozrejme znamena nove jadro, ale to se uz proste neda nic delat.
Pátráte na špatném místě, jakmile vznikne 200k hardwarových přerušení za sekundu tak už máte zahrobenou mašinu z principu obsluhy přerušení a v software už je na řešení pozdě. Musíte nějak hardware domluvit aby to snížil na max 1k, třeba periodickým zakazováním a povolováním přerušení na NIC, nebo přejít na pooling.
Ok. Jestli se nepletu, tak pri obsluze hw preruseni je aktualne obsluhovane preruseni zakazano, tusim se tomu rika maskovani preruseni? V jadre je to udelano tak ze, se v obsluze preruseni jen "presunou dat" do fronty pro soft irq, a hw irq se odmaskuje, tedy povoli. Podle programu top je procesor vytizen zpracovani soft irq. Nevim, jestli se do toho pocita uz presun dat z hw irq do fronty soft irq nebo ne. Pokud by se tam nepocitalo, pak by to mohlo znamenat, ze me zahazovani muze pomoct. Kazdopadne zkusim ze srandy nechat hw irq zamaskovane par mikrosekund pri jeho kazdem zpracovani a uvidim, co to udela ;-).
Chapu, ze ten muj pristup nezni moc profi, ale s podobnyma vecma sem si hral naposled na 8bit atarku :-(
-
coalesce? muzu se zeptat jak to funguje? pripadne nejaky cteni doporucit
diky
-
coalesce? muzu se zeptat jak to funguje? pripadne nejaky cteni doporucit
https://en.wikipedia.org/wiki/Interrupt_coalescing
-
Ak nebudes uspesny tak existuje este jedno super jednoduche riesenie, ktore sa volakedy pouzivalo ak bol niekto moc paranoik. Staci dat na ten spravny twisted par feritovu perlu. To obmedzi priepustnost siete na nejaku minimalnu hranicu. Zrejme bude treba nastavit 10Mbps.
-
JEDINA cesta je omezit ten provoz jinde.
Vždyť se o pár příspěvků před tebou píše i o jiných cestách. Například omezení těch interruptů.
Tazatel: obávám se, že bez rekompilace kernelu (nebo alespoň modulu) to prostě nepůjde. Teoreticky bys to mohl zkusit detekovat v userspace a v případě moc velké zátěže síťovku/přerušení zakázat, ale asi to nebude moc spolehlivé.
A jelikoz 52B x 200k = 10MB/s = 100Mbit sit na 100%. Tohle bude mit problem zvladnout kazda podobna krabka.
Mně teda gigabitový proud paketů odrovná Core i3-2350M s AR8151.
a druhak to neni moc vhodne
Nestyď se, já také dělám počítačem řízené sex-toys.
-
JEDINA cesta je omezit ten provoz jinde.
Vždyť se o pár příspěvků před tebou píše i o jiných cestách. Například omezení těch interruptů.
Jasne ... kolik asi tak kousku HW neco takovyho umi ...
Ale znam zcela 100% spolehlivou a zcela 100% realizovatelnou cestu, sak pise ze mu na funkcni siti nezalezi, tak proc ji zapojuje?
-
Jasne ... kolik asi tak kousku HW neco takovyho umi ...
99 % HW s irq podporuje povolit/zakázat generování irq. Po větších úpravách v ovladači tak počet irq za sekundu snížit jde nepochybně. Situace není že to nemá řešení, ale že řešení bude pracné.
-
OK, prepni sitovku na 10Mbit. Kazda by to mela umet.
Proč to nechce udělat?
Mně to přijde jako řešení, proč to řešení není?
Co mi uniká?
-
Já tomu nerozumím, osobně bych shodil rychlost na 10Mbit, což je tak akorát, aby to tu krabičku nezabilo.
To by byl první krok.
Ve druhém kroku bych monitoroval počet volaných IRQ za vteřinu a pokud by jich bylo víc než X, shodil bych síťovku.
V Proc je tuším dost údajů, abych to mohl shodit i primitivním skriptem volaným co pár vteřin.
A kdybych chtěl dělat něco fakt hustodémonsky krutopřísného, tak prostě pošlu command přímo switchi, aby mi toho posílal míň.
Minimálně všechny trochu slušný Cisco a lepší HP to umí.
-
Já tomu nerozumím, osobně bych shodil rychlost na 10Mbit, což je tak akorát, aby to tu krabičku nezabilo.
To by byl první krok.
Ve druhém kroku bych monitoroval počet volaných IRQ za vteřinu a pokud by jich bylo víc než X, shodil bych síťovku.
V Proc je tuším dost údajů, abych to mohl shodit i primitivním skriptem volaným co pár vteřin.
A kdybych chtěl dělat něco fakt hustodémonsky krutopřísného, tak prostě pošlu command přímo switchi, aby mi toho posílal míň.
Minimálně všechny trochu slušný Cisco a lepší HP to umí.
Pane cisco odborniku. Uz vite co vam provede zapnuti flow-control na ethernetu s protokoly vyssich vrstev?To je zakladni chyba kterou dela vetsina unpraktiku. Ciste nahodou takovy "malo pouzivany" TCP ktery skoro nikdo nezna a jez ma vlastni flow control ze. Nebo pokud mas i jine protokoly jez maji jeste dodelavane vlastni rizeni toku. Etherneti Flow-control muze pomoci, ale musim opravdu velmi presne dobre vedet jak je to se signalizaci na vyssi vrstvy a ktera strana bude akceptovat PAUSE framy.
Takze misto vyreseni problemu jsme tomu chudakovi pridelali dalsi problem treba se skakajicim TCPkem, ztratou mraku UDP paketu a na 20ti dalsich prispevcich budete resit tuneni a treba kterou implementaci TCP pouzit.
Cesta do pekla je dlazdena dobrymi umysly - Ethernet Flow control. Pokud nemam veci pro ethernet flow control dotunene tak nechavam vypnute. Nektere drivery to navic nemaji ani vhodne implementovano takze to je dalsi promenna.
-
Tak se to nakonec podarilo (snad ;-) ).
Ad reseni s 10 Mbity - funguje, procesor to v pohode stiha. Byl tu jisty pozadavek na to, ze by se to tak ale resit nemuselo. Samozrejme je to velice jednoduche a spolehlive reseni, takze bude take pouzito.
Ad upravy kernelu/ovladace - dev.c je spatne misto, to uz je vrstva nad ovladacem. Pomohla uprava ovladace, kde nebylo potreba delat nic moc sloziteho. Zjednodusene - staci monitorovat pakety za sekundu a kdyz je jich moc, tak na nejakou dobu zablokovat IRQ. Tedy presne to reseni, ktere zde nekdo uvadel.
Reseni trochu detailneji (mozna nepouziju uplne spravnou terminologii):
Ze sitovky prijde irq, to vyvola handler v ovladaci, ktery zamaskuje preruseni a informuje pres NAPI rozhrani vrstvu nad ovldacem o tom, ze si ma ze sitovky pollingem nacist pakety. To zavola metodu pro polling z driveru sitovky. V teto metode spocitam, kolik cca paketu prislo v poslednim merenem casovem useku. Pokud je to pod limit, pak po nacteni vsech dat ze sitovky se ihned povoli irq. Pokud je to nad limit, pak se irq nepovoli, ale jen se nastavi priznak, ze se tak ma pozdeji stat. Do driveru jsem pridal timer, ktery tika kazdych 100 ms (zkusmo zvolena hodnota) a ktery v pripade, ze je nastaven priznak povoleni irq, toto irq povoli. Povoleni irq je tak v pripade zahlceni nahodne zpozdeno o 0 - 100 ms.
Pro praci s timerem sem pouzit funkce setup_timer, mod_timer, del_timer, ktere jsem nasel jako vhodne pro pouziti v kernelu. Nema s nimi nekdo nejakou negativni zkusenost?
Nic sloziteho ani prevratneho.
V prvnim updatu sw pro tajmene zarizeni bude moznost zapnout 10 Mbit a pozdejsi vetsi update zrejme zahrne jadro s upravenym ovladacem.
Dekuji za rady a napady :-)