Že je to chyba mikrotiku platí jen pro ten btest.
Jinak obecně, když zkoušíte to jedno TCP spojení (btestem) mezi vícero RBčky za sebou, tak testujte i pomocí UDP. Pokud v UDP vám to dá co čekáte (např neruší se ty dvě rádiové linky zřetězené za sebou atd), tak linky jako takové jsou v pořádku. Pokud následně TCP jde hodně dolů, tak prvně předpokládám koukáte, zda to nestojí na přetíženém CPU a pak jde už o to, že se neumí TCP btest s danou linkou vyrovnat.
UDP test davá víc proto, že nezávisí na odezvě spoje. A UDP test zatěžuje o tolik míň koncové strany proto, že btest při UDP využívá fligny, že se nepočítají při odesílání a následně při příjmu UDP checksumy (kontrolují se jen IP záhlaví checksum). To UDP umožňuje a kdysi to Sun prosadil kvůli zvýšneí výkonosti pro NFS (spoléhá se na pošetření přes CRC na L2 vrstvě, pokud to L2 neumí, nemá se vypnutí UDP checksumu pouřžívat). U TCP to vypnput nelze a ten CPU v RB odejde na tom sečítání nulových čísel (ano, jsou tam šmejd CPU a chcecksum offloading do hardware síťovky stále nikde). Pokuzd se RB CPU fláká, tak kontrola, zda používáte po cestě contrack, pokud není nutný, tak vypnout (contrack pro TCP spojení je o fous náročnější než pro UDP), taktéž firewall, není-li nutný, tak vypnout. Pak forward paketu přes router po cestě je nezávislý na tom, zda je to TCP nebo UDP...
Pak už je to bohužel na tom, jak se daná konvové aplikace vyrovnají s profilem daníé trasy. Ovlivní to hlavně odezva linky časová, potom stabilita té odezvy (pokud hodně při zátěži lítá TCP ACK odezva, tak to na max nevytížíte) a nakonec chybovost. Bohužel řetězení half duplex linek za sebou je smrt pro TCP obecně a je jedno, jakou technologii používáte. Samozřejmě nv2 s oknem víc ms způsobuje, že jedno spojení to celé neucpe na max, pokud apliakce/OS neumí řídit TCP spojení na max.
Jediné řešení je snažit se minimalizovat odezvy linek a držet je pokud možno na konstantní hodnotě pod zátěží a s minimální chybovostí....
Ta myšlenka, zkusit to TCP spojení tunelovvat třeba v L2TP nemá smysl, pro ty routující routery uprostřed je to na stejno (není-li hodně debilní stavový firewall v cestě), doba průchodu bude stejná. Pokud má smysl, tak leda MPLS v režimu IP akcelerátor, které na RB433AH urychlí průchod paketu routerm o cca 100 us (proti holému IP routingu), ale pokud ta tím bude několik linek na bázi NV2 s několik ms oknem čekání na shluk dat, tak si na celkovém času moc nepomůžu...
Padla otázka, zda IPv6 je na tom stejně? Dokonce IPv6 by na tom mohlo být lépe než IPv4, protože po IPv6 routeru se chce ještě méně, než po IPv4 (zrušem chechsum záhlaví), ale opět se bavíme o zlomcích us v routovacím procesu proti milisekundám na NV2 vrstvě.
Jinak hodnoty zcela v normě. Mám tu třeba linku, kde je 17 GHz uplink, brána RB1100AHx2, nano bridge, RB493AH router, sextanxt-sextand bridge linka (nyní nstream), RB435G router baráku, za tím RB433UAH nebo RB800 koncový home router.
V UDP to dá up/down 48/48 Mbps (řezaný limit linky) mezi RB1100AHx2 a RB800 i RB433. V TCP to dá 22/12 pro RB433UAH nebo 22/22 pro RB800. Pokud za to připojím WinXP a pustím btest tak UDP cca 30/30 Mbps, a TCP 20/10 Mbps. Když nabootuji Win7, tak UDP 46/46 Mbps a TCP 25/15 Mbps. Pokud měřím proti speedtest.net, tak XPčka dají 22/15 Mbps a Win7 33/20 Mbps. Ano Win7 má trošku lepší IP stack.
