Zamyšlení - Více hopů na 5GHz

[hapi]

ftipálku

pustil sis někdy tcp optimizer pro win7? jaký nastavení tam vidíš? debilní že?

[stepan.benes]

:-D ftipálku

pustil sis někdy tcp optimizer pro win7? jaký nastavení tam vidíš? debilní že?

To měření jelo dle kolegy z Winboxu. A jak tedy z Mikrotiku na Mikrotik tedy z routerboardu a tedy TCP/IP stacku Linuxu. Nebo se pletu ? A pokud ne, pak bych rád věděl jak s tím souvisí TCP optimizer pro Windows 7 ?

[stepan.benes]

Ta samá poznámka k NV2. Nanobridge používá Air Max protocol, NV2 je věc Mikrotiku.

[Walkeer]

a tim rusenim to byt vazne neni? zkus zmenit kanaly tak, aby sousendi spoje byly co nejdale od sebe, me tohle dost pomohlo

[Spreamer]

a tim rusenim to byt vazne neni? zkus zmenit kanaly tak, aby sousendi spoje byly co nejdale od sebe, me tohle dost pomohlo

Rušení opravdu ne, NV2 jede 5470 (šířka 40MHz upper), následně druhý hop postavený na nanobridge (5765MHz, 20MHz šířka). Zatížil jsem střídavě oba spoje a neovlivňují se. Raději detailně rozepíšu zapojení.

GateWay PC router Core2Duo -- 24p gigabit SWITCH -- RB433AH nv2 bridge strana1 -- RB433AH nv2 routing protistrana2 -- 24p gigabit switch -- nanobridge bridge -- nanobridge bridge -- RB433AH (problémový router).

Snad je zapojení lépe srozumitelné, samozřejmě jsem v prvním příspěvku uvedl pro ilustraci více hopů, ale u dalších hopů není evidentní takový pokles. NV2 jsem zkoušel přeladit i na jiný kanál, bez výsledku (nastavení: fixně MCS13, TDMA Peroid 2ms). Bandwidth test z PC na RB433AH strana2 mi dává i teď při plné zátěži přes 100 Mb/s, ale na problémový router RB433AH na konci dostanu maximálně 35-40 Mb/s a to i přesto, že ten spoj na nanobridge dává 60 Mb/s TCP. Je tedy prostor někde k optimalizaci? Samozřejmě jsem si vědom, že by prostistrana rb433ah s nv2 neměla mít na starost routing a mělo by tam být PC, ale i tak to nárazově procesor musí stíhat. Co říkáte?

[hapi]

:-D ftipálku

pustil sis někdy tcp optimizer pro win7? jaký nastavení tam vidíš? debilní že?

To měření jelo dle kolegy z Winboxu. A jak tedy z Mikrotiku na Mikrotik tedy z routerboardu a tedy TCP/IP stacku Linuxu. Nebo se pletu ? A pokud ne, pak bych rád věděl jak s tím souvisí TCP optimizer pro Windows 7 ?

jak? má omezenou variabilitu window size ne-li zakázanou. Btest na MKčku má podle mě na pevno nastavený okno 8kB takže čim je to latenčně dál, tim hůř to jde.

NV2 má na prvnim skoku kterej to všechny zničí. To samí pozoruji u nás na síti kdy se vytížené spoje vyměnili za dualy na NV2 a od tý doby je to takový všelijaký.

Taky se tu nabízí otázka jestli to prostě nedělají pomalí CPUčka v zařízkách po cestě. Jestli mají na to aby tahaly takový kvanta dat. Je možná na čase si říct že takovej mips 680MHz má na to aby uživil náročnýho klienta případně sektor pro klienty ale už ne na to aby tahal páteř pro 200 lidí. Asi budu muset vybavit alixe nějakými testery a umístit ho do sítě a provést test iperfem nebo fakt už nevim.

[mvh]

Airmax i NV2 je technologie TDMA a tam je zakopan pes.
Nema s tim nic spolecneho ani pocet klientu za spojem ani vykon CPU.
Proste to degraduje jednovlaknovy stream.
Dejte si dva nebo radsi tri NV2 spoje za sebou a zkousej to klidne Btestem na 1 spojeni a uvidis, muzes to zkouset i s RB nebo kompem s i5, win i linuch, dojdes k stejne tragickym vysledkum.

jediny co na to ma vliv je TDMA period size, ale je to k nicemu protoze kdyz to snizis ze 2ms na 1 ms tak ziskas par Mb na jednom spojeni na ukor desitek Mb na maximalce vice vlaken, aneb vic skoku s NV2 oceni pouze torrentari

[Daxxim]

Je možná na čase si říct že takovej mips 680MHz má na to aby uživil náročnýho klienta případně sektor pro klienty ale už ne na to aby tahal páteř pro 200 lidí.

Řekl bych, že těch 680MHz na páteři (pro wifi), bohatě stačí, otázkou je jak dlouho...

[Spreamer]

:-D ftipálku

pustil sis někdy tcp optimizer pro win7? jaký nastavení tam vidíš? debilní že?

To měření jelo dle kolegy z Winboxu. A jak tedy z Mikrotiku na Mikrotik tedy z routerboardu a tedy TCP/IP stacku Linuxu. Nebo se pletu ? A pokud ne, pak bych rád věděl jak s tím souvisí TCP optimizer pro Windows 7 ?

jak? má omezenou variabilitu window size ne-li zakázanou. Btest na MKčku má podle mě na pevno nastavený okno 8kB takže čim je to latenčně dál, tim hůř to jde.

NV2 má na prvnim skoku kterej to všechny zničí. To samí pozoruji u nás na síti kdy se vytížené spoje vyměnili za dualy na NV2 a od tý doby je to takový všelijaký.

Taky se tu nabízí otázka jestli to prostě nedělají pomalí CPUčka v zařízkách po cestě. Jestli mají na to aby tahaly takový kvanta dat. Je možná na čase si říct že takovej mips 680MHz má na to aby uživil náročnýho klienta případně sektor pro klienty ale už ne na to aby tahal páteř pro 200 lidí. Asi budu muset vybavit alixe nějakými testery a umístit ho do sítě a provést test iperfem nebo fakt už nevim.

Takže jsme našli slabinu NV2 a Airmaxu, nicméně i ty RBčka tomu napomáhají, protože z dané lokality z optiky máme jeden hop na Alcomě přímo do města (tam je rb493ah), odkud je již jeden hop na náš kancl (nanobridge) a taky pozozuji pokles při btestu. Na RB protlačím z kanclu 70 Mb/s, ale na hraniční PC router jen do 40-50 Mb/s. Takže řešení je starší nstreme protokol? Nemám ale otestováno na Nkových kartách
Nebo prostě střílet trasy třeba na 11Km, aby bylo co neméně hopů, i když to bude mimo limit? Co pán Beneš na to, máte nějaký tip?

[sub_zero]

viewtopic.php?f=4&t=7008&hilit=optimalizace+tcp pro Stepana a jeho averzik moznosti chybnyho IP stacku ve win

[stepan.benes]

https://ispforum.cz/viewtopic.php?f=4&t=7008&hilit=optimalizace+tcp pro Stepana a jeho averzik moznosti chybnyho IP stacku ve win

Jeden o koze a druhej o voze. Já jsem se ptal jak souvisí výkon TCP/IP stacku Win s zde uvedeným, na čemž se tady otáčel Hapi. Na to jsem odpověd od Hapiho nedostal, jen další "moudra". Mimochodem správná odpověď, tedy aspoň pokud testování proběhlo tak je výše popsáno, je nijak. Windows se nikde v celým řetězu nevyskytla a proto nevím, proč tu vůbec někdo začal řešit TCP/IP stack Windows. Žádnou averzi k možnosti chyb v TCP/IP stacku Windows nemám (jen jsem napsal, že vychází z kódu OpenBSD), jen nevím proč se to tu vůbec řeší.
Možná bychom tu mohli řešit obecné problémy TCP/IP stacku, RTT vs. WinSize vs. propusnost, nebo implementaci v Linuxu (Mikrotiku), který byl na testy použit, metodiku měření (která je rozhodně špatně), atd., ale držme se věcí, které se uvedeným tématem souvisí. To bychom se tu rovnou mohli začít hádat, zda je lepší Subaru Impeza STI nebo Mitsubishi Lancer Evo. Kapišto ?

[hapi]

tak za prvé, Evo je lepší impreza je spíš jako americká kára, na rovince jede dobře ale zatáčky jim moc nejdou... aby taky ne s těmi jejich prehistorickými konstrukcemi podvozků.

ale k tématu.

Router nebo jakýkoliv prvek v cestě nerozhoduje o TCP stavu. O TCP rozhoduje zdroj a cíl který reflektují to co se s datovym přenosem děje po cestě. Dále je také nutné do hry přidat samotný aplikace takže když aplikace na jeden požadavek pustí max 8kB tak prostě tcp window size tuto hodnotu navýšit nemůže. No a v neposlední řadě je další problém v nastavení tcp stacku v samotnym OS. Takže když mám omezený tcp window jako maji winxp na pevnou hodnotu, můžu se stavět na hlavu a prostě víc nedá ani kdybych se rozkrájel. Tam je jediná možnost využít víc spojení na jednou což ve většině případech v reálnym stahování nejde.

Údajně seznam.cz má omezený tcp window v OS protože při jejich zátěži o vyřizování požadavků by jim nestačila ramka na tcp window a tak jednoduše omezili jeho velikost a maji zaručený zabrání paměti při určitym počtu spojení. Kdyby jim tam vlítlo pár lidí co maji variabilní tcp window size tak by mohly klidně 3x víc obsadit paměť což je určitě nežádoucí pro web servery.

Takže když vemu btest kterej nejspíš staticky nastavuje tcp window size na 8kB, tak prostě za několika nv2 spojema vychcípe a musí se použít víc spojení což ale neni ok. Ovšem, to souvisí i s tzv. odesílacími okny na NV2. Ví někdo jak NV2 funguje? ono se toho moc neví ale posílají se bloky dat a co se stane když jedno tcp window rosekne třeba na 3-4 bloky? že by narostla latence řádově 3-4x? aha? malej ping do 1500 bajtů to nejspíš nerosekne ale tcp window dejme tomu o velikosti 16kB což je 11 paketů při MTU 1500 to může docela dost pokazit.

Víte, já sem se tohodle hodně obával s příchodem Nka. Už první testy ukazovaly že Nko jako takový se využije na max jenom při velkym počtu spojení protože Nko má 8kB bloky který posílá. Jo občas to sedne a jede ale většinou ne. Ano, mělo by to zkracovat komunikační okna když nejsou potřeba ale určitě to nebude dělat zázračně dobře aby to neubralo na celkový rychlosti. Proto taky nstreme na 40MHz docela kulhá protože má max 4kB bloky a při tý rychlosti tu wifinu už nedokáže tak rychle přepínat. Jistě kvůli tomu vymysleli NV2 kde se ty 4kB bloky (o jaká náhoda že jsou opět 4kB jako u nstreme) řadí do jednoho velkýho bloku za sebou což ale tcpku nepomůže.

[Cheprer]

Jsem si jist ze to neni problem ciste nv2... protoze resim na velkem poctu spoju teneto problem.
I sam us sebe pozoruji problem ze IGW-ROCKET..70MBit FDX..- switch- ..NB25 60MBit HDX.. - na konci RB.. na LAN nenamerim vice jak 30MBit HDX i pri nulovem provozu.

Na prvnim hopu nestiha 100MBit ether... a jednostrane to i TCP neni problem jednosmerne vytizit do maxima ten eth na vystupu.... ke switchi prez ten spoj. A mezi nanobgidgema mezi mkj udelam speed testky od ubnt i bandw. test od MK a 60MBit HDX bez problemu. Ale u koncovich klientu je to v kasi.... i ti na ethernetu jsou tak na 30MBit a to je strop.

[hapi]

skuz schválně přepnout na obyč Nko a já bych se vsadil že to potom pojede jedna báseň. TDMA je totiž svině. Asi by se neměly používat seriově za sebou po cestě.

[mvh]

S vama je fakt sranda, od zacatku to tady melduju v cem je problem a ze nelze bezproblemove retezit tdma spoje za sebou, ale furt se tady resi uplne jiny veci, nacez hapi po X prispevkach napise to samy co ja ale mozna pouzivam spatnou barvu pisma a moje prispevky jsou neviditelne