Standartni problem s propustnosti - VYRESENO zapnutim flowcontrol

[Majklik]

Se to nějak zvrhlo. Pokud chci hodnotit výkon, tak musím řešit za jak dlouho se dostane paket z jednoho interface na druhý. Hádat se, že routing a bridge v routerbordech jsou na tom už skoro stejně je hezké, ale pokud to porovnám s HW switchem, tak to pořád MK dostane na frak. Sice pomáhá fast forward, ale ne na vše. Pokud se rozhodnutí o switchování odehraje vždy během jednoho cyklu v ASICu a jede to ven, tak to je jiná doba, než když to přehrabuje klasický CPU nad RAMkama, kde ta doba je navíc dosti proměnná. Pokud bych naasadil routery, co mají HW routování, tak mezi HW swichem a HW routem řešícím routing v HW v hradlovích polích, tak výkon bude obdobný také.
Takže ano, síť switchovaná na HW bud mít lepší propustnost, dokud ji nezačnu někde ucpávat, pak záleží na její chytrosti a co mi nabídne za možnosti, jak to řešit, když jedu na 100% přenosovky. Pokud mám poloblbé switche, kde začne ztrátovat na malých bafrech nebo při mohutném zapnutí flow contol mi to dělat vlny blokujících rámců rekurzivně, tak začne ten Mikrotik získávat navrch, protože dokážu se v nich s použití věších front a shapingu lépe vyrovnat, ale dokud ta switchovná síť pojede pod stropem s nějakou rezervou, tak na tom bude lépe HW switch.

[okoun]

hele já se s váma hádat nebudu si všude routujte když chcete

[hapi]

obecně je prostě daleko náročnější průchod provozu routerem, kde se musí rozhodovat jakou cestu půjde než bridgem, to bylo vždycky, proto existuje například MPLS, aby to co nejvíce akcelerovalo provoz.
tady bych řekl že papír snese všechno a hlavně na klasickém btestu to vůbec není znát, začne to být znát hlavně v reálném provozu.
s nástupem fast pathu se to dost vyrovnalo použití mpls ten routing...

odkdy MPLS akceleruje na rbčkách provoz? jo, bylo ftipný když se to objevilo v MKčku tak se začli ukazovat takový hezký nepravdy. MPLS? akcelerace na routerboardech? přece víš že to je blbost. "Akcelerační" to je u hw switche kde prostě switch s MPLS dokáže "směrovat" pakety jako router s rychlostí switche. To je ta "akcelerace". To že sis přidal vrstvu do mikrotiku si mu rozhodně nepomohl k akceleraci. Ten paket musí stále projít nějakou cestou v os. A opět, k "akceleraci" došlo pouze z toho důvodu, že na to "neplatí" iptables což dneska luxusně řeší fast path a to ještě mnohem efektivněji resp. ve smyslu snížení latence skrz router a ne zrovna málo. To je akcelerace.

Chápu MPLS u switchovaný sítě. Nechápu ale MPLS u wifi sítě z důvodu akcelerace obzvlášť když si takový lidé potom stěžují na propustnosti

Majklik to tady hezky řek. Plně s nim souhlasim. Některý hw switche dokážou zvětšit buffery jako mikrotik na portech a pak se to dá doladit přes fronty který dokáže konfigurovat ale ceny jsou někde jinde. Proto se spíš klonim k bridge na mikrotiku protože tam je cena desetinová ale zase záleží co tam vůbec teče ale když to svírá nějaký 10GHz spoje tak to povětšinou bohatě stačí.

[okoun]

nesmysl do toho zatahovat wifi, nemá to žádnej důvod...
tady se to popsalo snad úplně dostatečně viewtopic.php?f=5&t=7048 takže komentáře už nejsou třeba

[hapi]

jistě, v době kdy fast path na mk nebyl. Navíc si nejsem vědom že by si měl 90% zákazníků na kabelech

[Majklik]

Hele, tohle téma výkon jednoho TCP spojení na tomto fóru je jak kvadratura kruhu. Definitivní řešení bude, až se místo TCP bude používat něco, co zvládá LFN nebo na i4wifi bude k dispozici kabeláž, kde místo předpotopního skla uprostřed bude Boseho-Einsteinův kondenzát (a za doboru cenu).

Add MPLS: Okoune, máš na mysli v tom starém diskusním vlákně moji větu: "ROS neumí spousty mnohem jendodušších věcí (...), natož vylomeniny v MPLS. A navíc, dokud to celé hrotí v CPU, tak tu bude pořád výkonostní limit, co proteče mezi porty.... Nu, mámo muziky, málo peněz.." ?

Hapi: Já doufám, že dneska nikdo není takový masochista, aby na ROSu provozoval holé MPLS pouze v režimu prostého IP akcelerátoru. Jednak to ztrailo výrazný smysl s příchodem fast forwardu, jak zmiňuješ. Stále je MPLS IP akcelerace o fous rychlejší, než fast-forward nativního IP, ale nemá smysl ta komplikace jen kvůli tomu. Ale spíše je problém, že to podporuje jen IPv4 (a rozhodně nevypadá, že by Mikrotik měl chuť doplňovat IPv6 MPLS a LDP).
Takže kdo honí MPLS, tak asi primárně kvůli nečemu dalšímu. Okoun tím tlačí PPPoE přes routovanou síť pomocí VPLS tunelů.

Ve ztahu k původnímu dotazu je MPLS také jedna z možností jak to řešit, ale ne pouhou MPLS IP akcelerací, nýbrž použitím traffic engineering (MPLS TE). Je to jedna z cest, jak řešit ucpávání trasy. V tomto případě si pomocí RSVP protokolu k hlavní bráně dostane informace o aktuálních tocích dál a jaké je nejužší hrdlo v cestě a pokud daný TE tunel použiju s limitací, tak rovnou od hlavní brány budu daným směrem posílat jen tolik, aby se to cestou nikde nemělo potřebu hromadit a řešit pak to, co řešíl tazatel na tom přechodu gigo na 170 Mbps rádio (a fakticky znovu v menším bude řešit i o kus dál v síti za tou RB850Gx2, kde na tom switchi SWH-2126G bude řešit přechod giga na stovku, respektive asi max těch 170 Mbps ořezaných od 1S10 na 100 Mbps). Toto TE řešení se tak snaží o to, abych shaping a bafrování paketů dělal jen na jednom místě na začátku sítě a ne X-krát po cestě, čímž je naděje, že celková kapacita trasy (myšleno kolik bajtů dat je právě v přepravě mezi konci) klesne, což má dopad na rychlejší TCP také (potřebuji co nejkratší odezvu konců mezi sebou, bafrovaných dat po celé cestě ideálně do 1/2 velikosti TCP okna a žádné ztráty). U tohoto řešení, vedle složitější konfigurace, je podstatné to, zda mám přenosovou síť schopnou protlačit delší MTU kolem 1530 (pokud se kombinuje MPLS/TE/VPLS), aby se to tunelovalo bez fragmentace, protože jinak přínos tím zase pozabíjím (optimisticky přehlédněme, že v tom má zase ROS nějaké specifika a nedodělky k dokonalosti)...

[3com]

Nějaká zkušenost z praxe, která volba Flow control na MK je lepší? 1. Auto nebo 2. On ?