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

[hapi]

tam jsem ho dal jako první takže ano, tam je.

Akuálně dám skrz první spoj cca 50Mbit, víc se nestíhá generovat a skrz oba přes 35Mbit. Včera to bylo cca 10Mbit při stejnym nastavení. Těch 35Mbit nejde víc nejspíš z důvodu toho že to nestíhá klient zpracovat/server generovat protože když se pustí test jenom na druhym spoji tak je tam stejná hodnota. Takhle je to supr trupr ale taky tam skoro nic neteče od ostatních userů protože nikdo neni doma takže se musí počkat na odpoledne až začnou lidi tahat a něco mi říká že to pak pujde do kopru doufám že se neobjeví levelův syndrom

aktuální stav:
první spoj (ptp): 130Mbit, NV2 2ms, max UDP speed 80Mbit, TCP 55Mbit (limited cpu)
druhej spoj (ptmp): 130Mbit (mixed a/n), NV2 2ms, max UDP speed 70Mbit, TCP 35Mbit (limited cpu)
celkem: max UDP speed 70Mbit, TCP 35Mbit (limited cpu)

[okoun]

jo jenže je problém že mám po cestě alexe a to je x86 a fix zatím nemám pro x86 nevím proč už dávno nevyšla 5.21! když opravili takovou závažnou chybu, jindy vydali verzi kvůli úplnému prdu do vzduchu

[net.work]

Na x86 funguje NV2? dyt na MT strankach pisou ze je to podporovane zatim jen u routerboardu? Jinac mam pocit ze ve 5.21 tech oprav bude hodne...

[hapi]

ofiko se k x86 nepřiznaly ale funguje nám to už od v5.2 nebo jaký. Prostě dlouho

ale lhal bych kdybych neřek že to neni bez problemu.

[Leeonek]

na x86 funguje NV2 normálně, mám hafo Alixů jako apčka

[zdenek.svarc]

Nepovažuju se za žádného odborníka na bezdrátové sítě, takže jediné co můžu použít je selský rozum. Původní tazatel nepíše, zda-li testy zkoušel na UDP nebo TCP. Možná to průběh diskuze nějak ozřejmil, ale od strany 2 do strany 5 je to taková skrumáž, že jsem ji pouze proletěl.

Tedy, pokud budu mít několik halfduplexních p2p nebo p2mp spojů nebo jejich kombinaci zřetězených za sebou na L2 (případně proloženo nějakou L3), pak předpokládám, že UDP propustnost bude vzhledem k principu halfduplexního média klesat sice progresivně, ale aritmeticky. Naopak při stejné konfiguraci, ale TCP provozu, mám důvod se domnívat, že vzhledem k potvrzování TCP bude propustnost s každým dalším spojem klesat exponencionálně.

Tedy, bez ohledu na případně vnořené TDMA, které může mít progresivní vliv na saturaci provozu, za hlavního viníka pokládám halfduplex.

[hapi]

tak, problém nejspíš nalezen ale není řešitelný.

Přišel jsem na to, že když CCQ na spoji není 100% při NV2, máte smůlu. Platí to jak na ptp tak na ptmp.

Dále jsem našel průser v tom že když je na stejném kanále někdo další se signálem třeba -85dB, máte smůlu. Ano, UDP jede 60-70Mbit ale TCP nedává ani 10Mbit.
Pokud tedy spojem nedáte na NV2 2x2 2ms rychlost přes 80Mbit v UDP, máte smůlu. TCP vám pojede mizerně.

A teď něco na konec... je jedno jaký má TDMA velikost, 1, 2 nebo 3ms... je to jedno, TCP to neovlivní nebo u mě neovlivnilo (TCP okno by mělo bejt furt dostatečný aby to vykrylo i přes několik spojů)

Aktuálně jedu skrz ptp --- ptmp --- ptmp všechny NV2 2ms a tcp dává kolísavě až 35Mbit což je cca limit generování btestu. To že to kolísá je buď narážení toku do jednotlivých TDMA a tedy potřeba buferovat a tím se zvýší dočasně latence a nebo prostě chvilkový zavrávorání wifin. (osobně si mysli že to za může ta wifina potažmo nutnost opakovat datový rámce na wifině a tim zvýšení latence)

[hapi]

Nepovažuju se za žádného odborníka na bezdrátové sítě, takže jediné co můžu použít je selský rozum. Původní tazatel nepíše, zda-li testy zkoušel na UDP nebo TCP. Možná to průběh diskuze nějak ozřejmil, ale od strany 2 do strany 5 je to taková skrumáž, že jsem ji pouze proletěl.

Tedy, pokud budu mít několik halfduplexních p2p nebo p2mp spojů nebo jejich kombinaci zřetězených za sebou na L2 (případně proloženo nějakou L3), pak předpokládám, že UDP propustnost bude vzhledem k principu halfduplexního média klesat sice progresivně, ale aritmeticky. Naopak při stejné konfiguraci, ale TCP provozu, mám důvod se domnívat, že vzhledem k potvrzování TCP bude propustnost s každým dalším spojem klesat exponencionálně.

Tedy, bez ohledu na případně vnořené TDMA, které může mít progresivní vliv na saturaci provozu, za hlavního viníka pokládám halfduplex.

můj osobní názor je ten, že halfduplex za to nemůže ale může za to chybovost wifin. (i když svůj podíl na tom mám to jiste) Ačkoliv se neztratí ani jeden paket díky opakování poškozených rámců tak ovšem nevidíme to podstatný a tím je BER v reálném čase na radiu. Ano, máme CCQ ale to moc přesný není a nevidíme tam ty mikro opravy který donutěji TCPko něco dělat. Těžko to nějak změřit protože na ethernetech je vše v pořádku a přitom se wifina snaží třeba zopakovat každej 10 rámec na wifině a to se podepíše na TCPku.

Vlastně jedna možnost jak změřit chybovost wifiny je použít btest na UDP a sledovat lost packets ale to taky neni zrovna ok. Více méně když kolísá UDP test tak je něco špatně. UDP test by měl držet jak přibitej.

[hapi]

no vlastně máš čoveče pravdu. Nemožnost odeslat data v tu dobu co potřebuji a ještě čekat na TDMA bude mít jistě velký dopad na TCP. Teď je otázka jestli neni třeba začít používat QoS na NV2. Možná proto to tam implementovali aby určitej provoz (TCP) mělo přednost. Určitě to tak myšlený nebylo a mohlo by to mít svůj efekt.

úvaha: zkuste někdo pingat druhou stranu spoje 1500bajtovym paketem. Bejvá tam třeba 3ms ale většinou 6ms a neni ani vyjímkou 8 a víc že? to je úplně jiný kafe než malým paketem o velikosti 64bajtů kterej se do rámce vždy nějak vejde a odešle se při nebližší přiležitosti. Pokud to tedy udělá to samí s TCPkem no tak to potěž koště a problém je na světe. TCPko jako nejslabší z protokolů to prostě odnese.

Aktuálně se mi zvedá trafic na prvnim ptp spoji a začíná to mít vliv na tcp rychlost skrt tenhle samotnej spoj. Ráno to drželo krásně 55Mbit a teď kolísačka 30-50Mbit. kapacita spoje je přitom 2x větší a jsme sotva na polovině.

[ludvik]

Chybovost (už neopravená rádiem) může být původcem. Mám příklad, kdy chyboval gigový spoj (drátový, prostě chybka) a trošičku ztrácel. A jakékoliv TCP nepřekročilo cca 30Mbit. Což je proto, že retransmise z TCP stacku jdou pomaleji, zmenšuje se okno myslím. Sice v novějších jádrech linuxu jsem zahlédnul patch, který by to měl trochu řešit, ale z principu to tak bude vlastně vždy.
No a u UDP se to neřeší.

A vzhledem k tomu, že wifina bez chybovosti je teoretický nesmysl, tak bychom neměli takové spoje řetězit.

[Walkeer]

Chybovost (už neopravená rádiem) může být původcem. Mám příklad, kdy chyboval gigový spoj (drátový, prostě chybka) a trošičku ztrácel. A jakékoliv TCP nepřekročilo cca 30Mbit. Což je proto, že retransmise z TCP stacku jdou pomaleji, zmenšuje se okno myslím. Sice v novějších jádrech linuxu jsem zahlédnul patch, který by to měl trochu řešit, ale z principu to tak bude vlastně vždy.
No a u UDP se to neřeší.

A vzhledem k tomu, že wifina bez chybovosti je teoretický nesmysl, tak bychom neměli takové spoje řetězit.

Ano, tohoto chovani TCP vyuzva napr. shapovaci algoritmus RED, tedy random early drop, ktery nahodne zahazuje packety a odesilaci strana nasledkem PL snizi rate.

[hapi]

jistě, otázka je jestli se s tim dá něco dělat protože jinak je to pro wifiny konečná. Respektive jestli přechod na nstreme dual pomůže.

[ludvik]

U NV2 nefunguje hw-retries? Pokud ano - má to nějaký vliv? Obecně je můj názor, že s tím totiž nenaděláš jinak naprosto nic ... to se musí řešit na rádiové straně.

jistě, otázka je jestli se s tim dá něco dělat protože jinak je to pro wifiny konečná. Respektive jestli přechod na nstreme dual pomůže.

[honzam]

U NV2 nefunguje hw-retries? Pokud ano - má to nějaký vliv? Obecně je můj názor, že s tím totiž nenaděláš jinak naprosto nic ... to se musí řešit na rádiové straně.

jistě, otázka je jestli se s tim dá něco dělat protože jinak je to pro wifiny konečná. Respektive jestli přechod na nstreme dual pomůže.

Nefunguje, sice to jde měnit. Ale dle ofic fora to má vliv pouze u 802.11

[okoun]

stejnak se mi zdá vlákno o ničem, jelikož mě to normálně v praxi funguje, stahuji normálně soubory rychlostí kolem 2MB/s z win XP! a to že nějak tcp test na MK ukazuje 8Mb/s tak to je už vedlejší, vždy jsem se řídil UDP, pokud UDP nedrželo tak to bylo špatně nic víc....