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)...