Výkon MK na x86

[tomcizech]

Kryštof mi dal brouka do hlavy v Luhačovicích ohledně sběrnic, IRQ apod. na Mikrotiku.

Zkusil jsem to tedy na svém PC ( osobním ). Konfigurace je následující:

Procesor: INTEL Core i7-2600K Quad-Core (Sandy Bridge) http://www.alza.cz/intel-core-i7-2600k- ... 201345.htm
Deska: GIGABYTE Z68X-UD3H-B3 http://www.alza.cz/gigabyte-z68x-ud3h-b3-d238181.htm
Síťové karty ( půjčil jsem si z rozestavěného serveru, zastrčené v PCIE x16 portech které vedou přímo na CPU ): 2x INTEL PRO/1000 PT Server Adapter, PCI-E x1, 1x 10/100/1000 GLAN, bulk http://www.alza.cz/sitova-karta-intel-p ... d65224.htm

Výsledky:

Při bandwidth testu ( TCP 100 spojení ) zvládají jejich limit, tj. 1000 Mbit/s full fuplex.
Zkusil jsem tedy jít do malých packetů, tj. 300 bajtů a dostal jsem se na 305K ( pouze forward z jedné síťovky na druhou )

Při kombinaci 60 000 spojení na portech 5000-65000, UDP, TCP a k tomu nat to vytáhlo 354 Mbit/s. Zkoušel jsem ještě přidat 1000 pravidel v queue simple a výkon spadl na 273 Mbit/s.

Update:

Zkusil jsem ty karty přendat do PCI-e které je přes DMI na jižním můstku a výsledky jsou úplně stejné, vždy to nerozdýchá CPU kvůli počtu IRQ takže nevím co Kryštof reší. Koukal jsem do specifikace chipsetu Z68 Express a DMI má propustnost 20 Gb/s.

Update 2:

Na základě požadavků testu na linuxu připravuji test na x64 kernelu s preemtion mode server, RPS, multiqueue, imq, power management na performace apod....

Update 3:

Tak jsem si hrál a udělal jsem nový kernel 2.6.38, nahrál nejnovější driver e1000e od intelu, nastavil CFLAGS_EXTRA=-DCONFIG_E1000E_SEPARATE_TX_HANDLER pro vytvoření front pro TX a RX zvlášť, InterruptThrottleRate nastavil na 3000 ( nastaví pevný počet interruptu za vteřinu takže 1 packet != interrupt, vytvoří latenci 0,33ms na kartě, default intelu je dynamický mezi 4000 až 20000 ) a dostal se sem:

Při bandwidth testu ( TCP 100 spojení ) zvládají jejich limit, tj. 1000 Mbit/s full fuplex.
Zkusil jsem tedy jít do malých packetů, tj. 300 bajtů a dostal jsem se na 313K tj. 940 Mbit/s pro lidi kteří říkají že to není moc bohužel nedokážu otestovat oběma směry protože mi to nedaj servery z kterých to testuju, při těchto 313K je cpu load 22%.

Při kombinaci 60 000 spojení na portech 5000-65000, UDP, TCP a k tomu nat to vytáhlo opět 940 Mbit/s. Vzhledem k tomu, že nevím jak se na linuxu dělají queue simple jako na MK jsem to musel udělat pomocí markování paktetů takže 1000 marků a 1000 tc pravidel 517 Mbit/s.

Myslím že Mikrotik by měl něco udělat s podporou x64, inovovat e1000e drivery a otevřít jejich možnosti nastavení. Další věc je že na MK šly při 2 kartách vytížit pouze 2 jádra, díky SEPARATE_TX_HANDLER, RPS a Multiqueue jsem zatížil všechny 4.

[net.work]

Promin - bude to trosku OT, ale kupuju ted PC v temer stejnem configu jako popisujes vyse - jak si spokojeny s tou zakladni deskou (rozmyslim se mezi ni a ASUSem).

Diky a nezlob se za OT

[dagus]

To je celkem smutný, na to kolik to železo stojí. Nemá někdo zkušenosti s podobným železem a linuxem? Kolik linux na podobným železe dá?

[hapi]

něco bych tu doma našel na čem to můžu testnout ale jakym softem se generoval pakety? Můžu testnout stejný železo jak na mikrotiku různých verzí, tak na linuxu s různými kernely. Jenom mi řekněte jakej soft na testování použít.

Mimochodem Kryštof je spíš teoretik a dokud si nerozpitvá mikrotika a normál linux, tak nezjistí že mikrotik skoro řekl bych lépe odlazen než většina distribučních kernelů bez kompilace vanila kernelu přímo na danou architekturu.

Rád pomůžu s testováním a s konečným rozseknutím smyslu mikrotika jako gateway a jeho haněním.

Na jakym OS jsi to testoval?

[tomcizech]

Test byl proveden na os RouterOS 5.4, bohužel už by mohl konečně vyjít i v 64bit verzi, přece jenom výkonnostní rozdíl je velký. Testováno přes iperf, servery mezi kterými tato data tekla jsou ještě o něco silnější, resp. jsou to Xeony v socketu 1366 na intel seskách a síťovky jsou dual port pcie x4.

[tomcizech]

Promin - bude to trosku OT, ale kupuju ted PC v temer stejnem configu jako popisujes vyse - jak si spokojeny s tou zakladni deskou (rozmyslim se mezi ni a ASUSem).

Myslím že jde o osobní preference ale Gigabyte a Asus jsou rozhodně obstojní konkurenti, já prostě už léta všude používám Gigabyte ve verzi Ultra Durable a jsem spokojen. Gigabyte je vetšinou trochu konzervativnější a nevymýšlí eye candy featury jako přetaktování přes bluetooth apod.

[hapi]

taky se víc přikláním ke gigabyte, mám k nim naprostou důvěru pokud jde o ultra durable verze který jsou dneska snad uplně všechny.

v iperfu jde změnit velikost paketu?

[tomcizech]

v iperfu jde změnit velikost paketu?

Lze u UDP, u TCP jsem to udělal malou prasárnou a to změnou MTU.

[hapi]

jo to jsem čekal.

Aktuálně jebu mikrotiky za nepodporu MSI-X který by vyřešilo zátěž routeru při směrování. Distribuční kernel v debianu to zvládá bez problemu a to tam je stejná verze jádra

Uvedu příklad. Debian dokáže forwardovat mezi ethernety 950Mbit s max zátěží 3% na každý ze dvou jader. Mikrotik na to potřebuje 50% z každýho jádra. Po dnešnim zkoumání to je jistě v MSI-X kdy mikrotik jede v legaci modu fasteoi tedy krutě vytěžující procesor IRQ dotazy.

[tomcizech]

jo to jsem čekal.

Aktuálně jebu mikrotiky za nepodporu MSI-X který by vyřešilo zátěž routeru při směrování. Distribuční kernel v debianu to zvládá bez problemu a to tam je stejná verze jádra

Uvedu příklad. Debian dokáže forwardovat mezi ethernety 950Mbit s max zátěží 3% na každý ze dvou jader. Mikrotik na to potřebuje 50% z každýho jádra. Po dnešnim zkoumání to je jistě v MSI-X kdy mikrotik jede v legaci modu fasteoi tedy krutě vytěžující procesor IRQ dotazy.

Nevím zda-li jsi četl update 3, nicméně MSI-X mám také aktivní resp. IntMode=2. Jediné mě štve je podpora traffic shapingu na linuxu, proč není něco jako queue simple, resp. ukažte mi kde to je, zkoušel jsem if-match přimo v TC ale chová se to divně a navíc lze to jen na incomming jedné karty a nebo naházat na všechny karty ale tím pádem pokud data která se vejdou do classifieru přitečou z 2 karet, tak mohou mít až dvojnásobný traffic . Jediná možnost pro mě známá je IMQ a markování .

[hapi]

update 3? co to je?

jo SQ v linuxu neni ale tak neni problem napsat mangle pravidlo a tc třídu ne? Jo ty to chceš na inputu hmmm... proč? vždycky jsem si vystačil pouze shapingem na outcommingu pokud tedy nepoužíváš obojí na jednou.
V dnešních kernelech je už tušim zabudovaná podpora pro incomming ale víc fak nevim.

No ale štve mě, že mikrotik na foru tvrdí jak msi-x neni třeba i když spousta lidí tam píše že to chtěji a oni pořád "do teď to nikdo nechtěl" a v duchu jedou dál jako že když do teď to nikdo nechtěl tak už nikdy to nebude.

Vyřešilo by to hodně výkonu třeba i na atomech, zacate a takových podobných pomalých pcčkách který by se pak mohly věnovat čistě jenom shapingu, filtru atd.. Takovej atom by pak lehce zvládnul gigo přenýst bez toho aniž by procesor vůbec přesahnul 10% zátěž a zbytek by byl volnej pro manipulaci s pakety. To přece chceme všichni. Jisně, byla by to domena předevšim PCček a na RBčka by to nejspíš vůbec nešlo použít.

[hapi]

tak mám výsledky testování

deska asus P5Q premium, procesor C2D E5200, dual channel 800MHz, 2x1GB.

Porovnání debian 6.0.1a s MKv5.2

test_mk_debian.png (15.35 KiB) Zobrazeno 3668 x

[hapi]

nevim či je to primárně způsobený a nechci tady kecat kraviny ale faktem je, že mikrotik padá na hubu pod zátěží IRQ. Nechci se tu dohadovat co je msi-x a čim dělá to že nevytěžuje procesor IRQčkama ale faktem je že linux s ethernety jede na msi-edge a je bez IRQ zátěže.

Pokud někdo ví jak se dostat do shellu linuxu pod mikrotikem, tak prosim PM.

[hafieror]

Já se zeptám blbě, ale má takovéto problémy s propustností i RB1100AH?

[hapi]

no tak předně RB1100AH nebo RB1100AHx2 neni x86. osobně tu architekuru moc neznám ale je to powerPC a ta bude stejně v háji jako na RB800 takže zátěž bude obrovská jako na mích testech takže taky k ničemu. Ani nevim jestli powerPC má něco jako msi-x takže tak či tak, je to hardware kterej bude neustále pod zátěží i když bude jenom forwardovat.

Jinak já jsem nedemonstroval problemy s propustností ale problem s vysokou zátěží CPU. Na propustnost do giga neni problem na mikrotiku jenomže na debianu to zvádne o řád pomalejší hardware a ještě s tim tokem něco může dělat, mikrotik už nemá dostatek výkonu v cpu na to aby s tim tokem něco ještě udělal což je typická chyba stroje na bráně která musí manglovat, natovat, qosovat atd... debian levou zadní, mikrotik za cenu větší zátěže cpu, s tim větší latence, větší spotřeba, větší teplota atd.... a ve finále nižší přenosovka.