problém s rychlostí na Wifi

[okoun]

Mám problém s rychlostí na spojení: hlavní brána do alix -> alix (nv2 300Mb) do MK switche do RB411 -> RB411 (nv2 150Mb) do RB600 -> RB433 (nv2 150Mb) do RB433 -> SXT (nstreme 54Mb) do Rb600 do SXT -> SXT (802.11n 130Mb) do RB433 tedy celkem 5 wifi skoků

Přes těchto pět skoků nemohu protáhnout do internetu více jak 28Mb jedním směrem a i při BTtestu je rychlost při TCP 1 connection velmi malá cca 15Mb, UDP jde 40Mb (omezuje spoj s nstreamem).
Když si cestu zvětším dalším wifiskokem, tak rychlost opět klesne, není někde něco špatně nastaveno?

[Tomáš Nesrsta]

nastaveno spatne nic neni. Cim vice skoku za sebou tim nizsi rychlost na konci. To je proste danej fakt.

[okoun]

No rychlost, když tam dám více connectionů tak to jede 40Mb také, mě jde o to jedno na 1 spojení. Na VDSLku to prostě krásně na jedno spojení protáhne.

[Polk]

Řekl bych, že špatně nic, prostě vlastnost NV2, kterých tam máš po cestě více. (také mě to štve)

[zzam]

Předpokládám, že jsi zkoušel bandwidth test na všechny jednotlivý zařízení, aby jsi zjistil, jestli třeba není někde slabé místo a neteče tam míň ? Kdyby náhodou ne, tak si postupně dej Btest na všechna zařízení. I přes 5 přeskoků by jsi měl vyždímat víc. Možná si zkus přeměřit trasu "SXT (nstreme 54Mb) do Rb600 do SXT ", protože jestli v této části slinkováný zařízení na 54Mbit, tak v reálu víc jak 30Mbit z toho nevyždímeš. Možná tady bude slabé místo.

[okoun]

tam problém není ale všimnul jsem si zvláštní věci a to že mezi ethernetama hlavní brány a alixe mám cca 7Mb zpomalení na TCP při jednom connection.

[hapi]

je logický že při více spojení to vytahne víc. Btest neumí menit window size takže se musí nadopovat více spojeními. Dál, to neni vlastnost NV2 ale například nefunkční změna window size na těch zařízeních který mězi sebou komunikujou. Takže hlavní roly hraje window size a čim dříve to někdo pochopí, tim dříve se mu bude žít lépe. Například windows 7 nemaji absolutně žádnej problem i v defaultu měnit svolje window size k lepšímu. Tady hraje i významnou roly zdroj dat a to jestli je ochoten window size změnit také protože jestli se jedná o hodně vytěžovaný server, tak vám prostě window size nezvedne protože by musel vyhradit víc paměti. Dál nato má vliv i ztrátovost celí trasy. Čim větší ztrátovost, tim mení window size a tim menší rychlost.

V neposlední řadě tohle platí jenom pro TCP a pokud UDP protahne celou trasu stabilně a bez problemu, dál bych se o to nestaral a počkal na reálný vytížení.

[trandak]

Tak tuhle tabulku už taky znám a jakpak pracuju na zkrácení trasy. Pokud to dnes dobře dopadne tak nejvzdálenější mk v síti stáhnu z 12 na 8, myslím skoků v traceroutu

[hapi]

hele to je fuk, přijdu s notebookem na konec sítě kde to máme 20ms k nám na server a do netu ještě dál a všechno šlape jak má. jasně, něco jinýho je, když se snažíš protahnout 100Mbit jednim spojení a něco jinýho je kdžy 20Mbit. Těch 20Mbit windows 7 vytahnout určo ale těch 100Mbit s tou latencí už potřebujou upravu pomocí softu co šahne do registrů. S tim má velký zkušenosti sub_zero a má tu i vlákno o tom.

viewtopic.php?f=4&t=7008

[okoun]

takže jedině spoje překopat do profipojidel, jinač to nepůjde, je škoda nevyužít, že duplexní spoje přenesou 80Mb, ale nikdy ne na jedno spojení...

[hapi]

no to je ten ftip. Ty nemůžeš ovlivnit latenci na netu. To že si svojí síť uděláš super neznamená vůbec nic. Ty musíš dobře optimalizovat koncový počítače. Skuz si iperf skrz svojíi síť s nastavenym window size na třeba 1 mega a ono to bude fungovat. Já bych to nijak dál neřešil. Nový OSka pojedou v pohodě. Linux desktopy taky.