• Jake zelezo na hl. router

jasně že to vim, jenom tě trochu opravim. Traffic shaping je možný pouze u dat která z routeru odcházeji. Ty můžeme regulovat protože víme kolik pustit a bufferovat nějakej čas. Ty která přichází nemůžeme a proto se používá IMQ který se použije jako virtuální iface do kterýho jsou směrovány příchozí data a pak jsou následně z IMQ jsou puštěna zpět do routeru jako by se nic nedělo ale na to IMQ rozhraní navěsíme shaping protože to z něj odchází do roueru (virtuálně). Vim že tohle nechtěly dát přímo do jádra a taky vim proč ale nevěděl jsem že tam místo toho daly už něco jinýho což je fajn. Mimo to, žádný IMQ neni třeba nasazovat protože stačí manglovat a shapovat na postroutingu každýho z ethernetů kde jsou čitelný všechny IP adresy ještě před natem. Sám to tak dělám na mikrotiku (zvyk z linuxu).

Technicky vzato se používaji IRQčka pouze při příchozích paketech a u odchozích už ne ale to nevim přesně.

Jak se vymezujou IRQčka na jádra? Tohle jsem nikdy nedělal.

No jestli potkáváš takový ISPíky jako já, tak bych tam přidal ještě jednu devítku.

Asi oprášim debiana a skusim si vanila kernel :-)

člověk uplně zapomíná jak je mikrotik nevýkonej, ach ta degenerace.

Dik za info ale spis me zajimaly zkusenosti vzhledem k MK ...

psal jsem cituji "Shapping je totiž na linuxu obecně možnej jen na (tuším) výstupní straně rozhraní." Nevím o co jsi tuhle definici rozšířil, ale určitě vím že si ji zobecnil. Traffic se totiž shapuje na egress třídě každého rozhraní, tedy na jeho výstupu, nikolik zákonitě na výstupu z routeru. Proto se používá berlička jako IFB nebo IMQ. I pro ingress třídu existují klasifikátory, ale je jich minimálně a neudržují se. Podívej se na nějaký "Kernel Packet Traveling Diagram" a uvidíš.

Data se navíc nikde nějak zásadně nebufferují. Shapping znamená pouze a jenom kontrolované zahazování paketů. Zdroj, který data odesílá nedostane potvrzení o jejich přijetí adresátem a sníží rychlost odesílání.

Technicky vzato se IRQ používají v jejich původní podobě při každé manipulaci s daty mimo CPU, takže i při odesílání. Tuto neduhu x86 systému odstraňují berličky jako např. DMA nebo právě MSI. Kdo zažil dobu DOSu a programování např. v assembleru ví o čem mluvím ;)

IRQ se přiřazují v /proc/irq/XX/smp_affinity. Podle binární masky se dá určit, který CPU má obsluhovat které přerušení. Při bootu kernelu je dobrý použít parametr isolcpus, kterým izoluješ z irq_balancingu ty jádra, která chceš použít pro síťové karty, případně jiná zařízení. Google je nejlepší rádce ;)

Netuším jaký ISPky potkáváš ty, ale pro mně to slovo znamená "poskytovatel služby". Takže bych očekával fundovanou osobu (fyzickou či právnickou), která se bude prát o svoje místo na trhu. Na neznalost se v obchodu nehraje.

Mám pocit, že ISP v týhle republice rychle zapomněli na to, z čeho vlastně vyrostli. S rozšířením Mikrotiku a příchodem levnejch "ready to deploy" rádií je každej rychle profesionálním "síťařem", kterej používá jen to, co se dá koupit v eshopu. Vlastní vývoj nebo alespoň nějaký pátrání jak řešit věci jinak, je ta tam. Kdepak jsou ty časy kdy člověk ladil konfiguraci kernelu a ovladačů pro první WiFi karty (např. XI-626) :) Ty co to podstoupili si z toho odnesli zkušenosti a know-how. Ale nejen pro ty ostatní je Mikrotik zaklínadlem na všechno. Nepouštějte se do mě, nic proti Mikrotiku nemám .... na střeše ... ;)

Sorry za offtopic

napsal jsem to s tim egress tak aby to pochopili i ostatní. Nečteš to jenom ty :-D

Buffer tam je, každá fronta má nějakej buffer viz fifo, sfq například.

No právě že lidi koupí, zapnout, lehce nastaví a jsou to ISPíci a nejlépe ti co fungujou na SQ. Tohle forum je jich plný tak čemu se divit.

To s těma IRQčkama si vyzkoušim. Je fakt že jsem linux jako hi-tech router neviděl už dlouho a i já jsem zběhnul k mikrotiku který láká winboxem s přehledem totálně o všem :-( sakra práce. Navnadil jsi mě na rozhraní pro linux router.

Každopádně na MK to nikomu nad 200Mbit a víc moc nejede a mám takovej pocit, že množství pravidel na tom moc nemění.

Není to buffer jako takový (který by cosi vyrovnával), ale fronta do který se pakety řadí a na jejím konci se algoritmus stará o jejich zahazování, pokud je třída saturovaná.

Linux dokáže hodně věcí a myslim si, že s trochou snahy z toho půjde vymáčknout i více než 1Gbit full-duplex. Při shapingu samozřejmě... Ve špičce jsem u nás měl 700Mbit a load necelých 70%.

Na MK nejede a myslím, že podle symptomů tak, jak je tady popisujete, je to nedostatkem přerušení. Ovlivňujete to právě množství paketů, který prochází routerem a generují přerušení. Rozhodně se to nevyřeší hardwarem, alespoň ne pokud MK nemá nějakou konkrétní konfiguraci nějak "zvýhodněnou".

buffer... fronta... jedno a to samí.

Každopádně jestli je to primárně závislí na IRQ, tak si člověk moc nepomůže když dá za sebou dva routery při tocích nad 300Mbit. Co zkusit v5? tam je podpora pro rozložení IRQček na jádra ale jestli to má nějakej efekt nevim. Brána mi na v5 jede ale stejně neprotahne ani o chlup víc než na v3.30 ale tady už asi fakt bude na hraně FSB. Někdo tu nedavno psal o vytížení při použití v5 kdy se mu snížilo zatížení CPU ale nepsal jestli to taky dosahne na větší propustnosti a nezačne to dělat kraviny jako mě.

Pak taky nesmim zapomenout na můj test duálního atomu kdy si při routingu bez pravidel dával skrz 1Gbit bez větších problemů ovšem test ftp je spíš o rychlosti s menšim počtem IRQ díky velkým paketům což zase kazí výsledek.

tazatel by asi měl pouvažovat o linuxovim routeru. Defakto stačí nahodit debiana a nainstalovat balíčky pro tc a upravit si scripty pro plnění dat.

Jasne linuxu se nebranime ale zajimaly me zkusenosti s MK. Budem ted muset vymenit HW tak kazdy nazor a zkusenost se pro rozhodovani hodi ... diky

o 2 měsíce později

Ahoj, resim ted novy centralni router(shaper a nat cca 300-400Mbit, 2000 PC) na LINUXU a premyslim, jaky poridit procesor. Nevim jestli vzit radeji 6 jadro s taktem 2,4GHz nebo 4 jadro s taktem 2,66GHz, ty maji 12MB cache, pripadne 4 jadro s taktem 3,2GHz ale jen s 8MB cache? Diky za radu.

cache nehraje az takovou roli jak se zda...vem spise rychlejsi s mene cache nebo to co bude lepsi pro tvoji kapsu :

PW

cache nehraje az takovou roli jak se zda...vem spise rychlejsi s mene cache nebo to co bude lepsi pro tvoji kapsu :

PW

spousta lidi tady na foru tvrdi presny opak ;) chtelo by to udelat nejayk poradny benchmark v realnem provozu ;)

ja osobne bych sel do sandy bridge (az pro to budou znackove desky), prave jsem si domu poridil quadcore i5-2500K a je to masakr. v desce s P67 se tomu da rict, aby vsechny jadra jely pri zatezi na max turbo frekvenci 3.7GHz, staci to jen dobre chladit. To ani neni OC, protoze ty jadra tu frekvenci umi, intel to omezuje jen kvuli TDP ;) takovy CPU uz asi neco odroutuje bych tipoval :) v idle ma ten procak cca 3-6W. Navic to je diky vysoke frekvenci a vysoke IPS vhodne i pro MK, ktery neumi poradne vyuzit vice jader.

to je zajímaví protože turbo u intelu přetaktovává pouze jedno jádro a ostatní podtaktovává aby se právě TDP vyrovnalo ale když zatížíš víc jáder tak by se frekvence měla držet na standartních hodnotách a nepřetaktovávat.

O sandy bridge se toho víc nakecá než aby to byl nějakej skok. Tak jak to bylo úžasný když to intel uvedl na trh tak teď se už o tom nemluví protože to neni zase tak úžasný. Už jenom to že tam nejde udělat tripple channel.

Jo a mimochodem, to přetaktování a podtaktování může na routerech dělat paseku a ne malou. Tyhle procesory jsou pro desktop kde halt procesoru na 1ms při změně frekvence člověk nepozná ale u routeru je to fatální problem. Tak jako je dobrý tyhle funkce u C2D zakazovat, tady to je taky třeba zakázat. To je jako že u klasických xeonů tyhle funkce jsou standartně vypnutý a věději proč. Vytváří to totiž lagy z důvodu čekání na ustálení napájecího napětí při přetaktování a stabilizování oscilátorů a to může trvat i několik stovek tisíc instrukčích cyklů. Nejrychlejší přetaktování v řádově desítek cyklů má via na svých procesorech. Na normálních je to strašně dlouhý.

Nechci nějak hanit sandy bridge protože jeho hlavní přínos spočívá jinde a to předevšim v silný grafice na chipu. Faktem je že rozdíl mezi prvními c2d a nehalemi je zanedbatelnej i když keci intelu volaly po ukrutných změnách a to samí je i mezi nehalemem a sandy bridge i když je chválihodné jejich brutálně nízké TDP i když jak překlad napovídá tak jde o typickou hodnotu a ne maximální. Nicméně Nehalem v tripple channelu bych volil asi spíš.

to je zajímaví protože turbo u intelu přetaktovává pouze jedno jádro a ostatní podtaktovává aby se právě TDP vyrovnalo ale když zatížíš víc jáder tak by se frekvence měla držet na standartních hodnotách a nepřetaktovávat.
Ano, takto se chova defaultne. Na P67 chipsetu (je urcen pro OC) se mu da zvysit max povolene TDP a take nastavit, jaky max nasobic ma pouzivat pro zatizena jadra podle toho, kolik jich je prave zatizenych. Napr. ja mam nastaveno, ze vsechny jadra mohou jet pri plnem vytizeni vsech jader na sve max frekvenci, coz je 2500k 3,7GHz (mam MSI P64A-C43). Mam k tomu freezera 7, ktery to uplne vpohode uchladi. Otazka je, zda podobne featury budou dostupne i na serverovych deskach, tipuji ze SM to tam mit nebude, coz bude jiste skoda.

O sandy bridge se toho víc nakecá než aby to byl nějakej skok. Tak jak to bylo úžasný když to intel uvedl na trh tak teď se už o tom nemluví protože to neni zase tak úžasný. Už jenom to že tam nejde udělat tripple channel.

Prumerne zrychleni je cca 20% na stejnefrekvenci, navic se prodavaji frevence o dost vyssi a to vse za skoro stejnou cenu, takze me to jako pecka prijde. Trippe channel prijde brzy.

Jo a mimochodem, to přetaktování a podtaktování může na routerech dělat paseku a ne malou. Tyhle procesory jsou pro desktop kde halt procesoru na 1ms při změně frekvence člověk nepozná ale u routeru je to fatální problem.

Ano, napr. v mem BIOSu muzu zakazat jednotlive C-states podle libosti. V routeru bych ty vyssi urcite zakazal.

Tak jako je dobrý tyhle funkce u C2D zakazovat, tady to je taky třeba zakázat. To je jako že u klasických xeonů tyhle funkce jsou standartně vypnutý a věději proč. Vytváří to totiž lagy z důvodu čekání na ustálení napájecího napětí při přetaktování a stabilizování oscilátorů a to může trvat i několik stovek tisíc instrukčích cyklů. Nejrychlejší přetaktování v řádově desítek cyklů má via na svých procesorech. Na normálních je to strašně dlouhý..

Pokud se bavime o tom turbu, tak bych se dost divil, ze zmena frekvence trva stovky tisic cyklu. Zkusim to pohledat, pripada mi to jako hrozne moc. Samozrejme na vytizenem routeru se to da uplne vypnout.

Nechci nějak hanit sandy bridge protože jeho hlavní přínos spočívá jinde a to předevšim v silný grafice na chipu. Faktem je že rozdíl mezi prvními c2d a nehalemi je zanedbatelnej i když keci intelu volaly po ukrutných změnách a to samí je i mezi nehalemem a sandy bridge i když je chválihodné jejich brutálně nízké TDP i když jak překlad napovídá tak jde o typickou hodnotu a ne maximální. Nicméně Nehalem v tripple channelu bych volil asi spíš.

Tak s tim muzu jen tezko souhlasit.

1) silnou grafiku to rozhodne nema, spise se intel pokousi dohnat skutecne slusne integrovane grafiky, co dava AMD (ATi) do svych chipsetu a moc se mu to porad nedari. Do kanclu je ta grafika ok, ale na hry to vazne neni.

2)rozdil mezi nehalemem a C2D je veliky, koukni se na benchmarky, rozdil je vic nez 20% a to je hodne. Navic v jednovalknovych aplikacich je diky turbu jeste vetsi, nekde dokonce vic nez 50%. Muzu te ujistit, ze spotreba sandybridge je vynikajici, jedna se o procesory s jednim z nejvyssim pomerem vykonu na Watt. Tripple channel pomuze v pametove narocnych operacich, to je jasne, ale nejake mega rozdil to nebude.

koukni napr. na toto: http://www.tomshardware.com/charts/desk ... ,2407.html

a toto: http://www.tomshardware.com/charts/desk ... ,2435.html

tu grafiku jsem myslel právě že dohnaly konkurenci v rámci integrovaných grafik. Jine ani náhodou.

tu grafiku jsem myslel právě že dohnaly konkurenci v rámci integrovaných grafik. Jine ani náhodou.

hele tak mas pravdu :) sem ais koukal na nejakej spatnej test, z integrovanych GPU je to asi vazne nej. to je hezke, ale me se spis libi ta spotreb, vykon a cena.

http://www.gearslutz.com/board/music-co ... rking.html

podle postu c. 7 trva prepinani mezy P-states (ne C) jen par cyklu, takze bych ocekaval, ze zmena nasobice bude jeste rychlejsi. Takze to na routeru zrejme problem nebude.

Ahoj, resim ted novy centralni router(shaper a nat cca 300-400Mbit, 2000 PC) na LINUXU a premyslim, jaky poridit procesor. Nevim jestli vzit radeji 6 jadro s taktem 2,4GHz nebo 4 jadro s taktem 2,66GHz, ty maji 12MB cache, pripadne 4 jadro s taktem 3,2GHz ale jen s 8MB cache? Diky za radu.

co ti na tom pobezi za sw ? ros nebo linuch ?

Ahoj, resim ted novy centralni router(shaper a nat cca 300-400Mbit, 2000 PC) na LINUXU a premyslim, jaky poridit procesor. Nevim jestli vzit radeji 6 jadro s taktem 2,4GHz nebo 4 jadro s taktem 2,66GHz, ty maji 12MB cache, pripadne 4 jadro s taktem 3,2GHz ale jen s 8MB cache? Diky za radu.

co ti na tom pobezi za sw ? ros nebo linuch ?

Debian, nejsem blazen, bych si zabil hlavni branu rosem. :)

Koupil jsem nakonec INTEL Quad-Core Xeon E5640 2.66GHZ/12MB/ LGA1366. Zas to nejakej ten rok vydrzi a kdyby bylo nejhur, tak mu vedle do patice poridim bratricka. :)

jenom pozor na to že dva duálcore neni to samí jako jeden quadcore. Předně dvě patice maji každá svojí ramku a přenosy mezi ramkama jdou po pomalí zběrnici skrz desku atd..

Jesli to byla reakce na me, tak ja tam mam quadcore.

myslel jsem to jako obecné srovnání dvou patic vs. jednu patici i když dohromady daji stejnej počet jader.

o 6 dní později

jenom pozor na to že dva duálcore neni to samí jako jeden quadcore. Předně dvě patice maji každá svojí ramku a přenosy mezi ramkama jdou po pomalí zběrnici skrz desku atd..

Ta sbernice QPI (hypertransport 3.1 je rychlejsi, umi az 25GBps FD), kterou jsou ty XEONy propojene, je -+ stejne rychla, jako pametovy subsystem jednoho CPU.

Dva sockety maji vyhodu v tom, ze se jedna o NUMA (nehalem a novejsi architektury), ktera ma pripade NUMA-aware OS az N-krat rychlejsi pametovy subsystem, nez jednosocketove reseni, N je pocet socketu. Proste kazdy socket ma vlastni RAM a kdyz ma vsechna potrebana dava v ni, nemusi se o ni delit s dalsimy jadry/sockety, coz se deje v pripade jedno socketovych reseni. Myslim, ze moderni linuxove SMP kernely by v pripade routovani tohoto mely byt shopne dosahnout.

Jeste poznamka: ten XEON E5640 ma rovnez Turbo (2,93) a kdyby to melo zpusobovat jakekoli problemy v souterech/serverech, myslim, ze to tam intel nedaval. ostatne AMD to ma take. Rozhodne bych to nevypinal.

📡 Telekomunikace.cz