Bezdrátové propojení dvou budov - dva spoje

zigi

Díky za upozornění, takže můžu spoje nastavit takto:

- první: 5500MHz a 20/40MHz HT Below

- druhý: 5680MHz a 20/40MHz HT Above

a podle článku http://www.internetprovsechny.cz/pasmo- ... andu-v-cr/ bych tam měl ještě nastavit automatické přelaďování?

5470-5725 MHz (zkráceně 5.4 GHz): použití uvnitř i vně budov, maximální vyzářený výkon 1 W EIRP (30 dBi). I zde ale platí podmínka o vybavenosti automatickou regulací výkonu se stejnými pravidly, tj. není-li regulace zapnuta, je max. vyzářený výkon 0.5W (27 dBi) a podmínka o automatickém přelaďování.

hapi

na to kašly

zigi

card rate

Takže nastavím Antenna Gain na 15 (dle anteny) a Tx Power Mode na "card rates" a budu to postupně regulovat pomoci hodnoty Tx Power_

hapi

ne. prostě přepneš frequency mode zpátky na manual tx power a pak budeš používat pouze card rates a tx power. Antenna gain už tě zajímat nebude.

zigi

30 metrů od sebe a ty si tam nepřetahnul optickej převěs kterej bude 20m nad zemí? Vůbec bych se toho nebál. I blbýho UTPčka ve vzduchu bych se nebál.

Při propojování dvou budov UTP kabelem nevzniknout tam nějaké proudové smyčky? Není lepší to nějak galvanicky oddělit, třeba právě tím optickým kabelem?

hapi

dá se to řešit stíněným kabelem a stíněnymy konektory ale optika je samozřejmně vhodnější protože je to defakto dielektrikum nedy izolant sám o sobě + ten fakt, že třeba takovej typickej převěsovej optickej kabel samsung drop má se všim všudy 3mm v průměru včetně nostných prvků v sobě pro bezproblémové překlenutí i přes 100 metrové dálky + se daji lehce koupit na to kotva takže instalace bezproblémová.

zigi

1. změnil jsem nastavení kanálů

- první: 5500MHz a 20/40MHz HT Below

- druhý: 5680MHz a 20/40MHz HT Above

2. nastavil hw retries na 15

3. snížil tx power na 1dBm - síla signálu šla dolů na cca -53dBm

- během btestu byly rychlosti víceméně stabilní +-7Mbps vůči průměru a ztrátovost u UDP testu se stále pohybuje kolem 1100-1400

hapi

fajn, to už je lepší. Co přenos skrz celou tu trasu až skrz switche?

zigi

Spoje a jejich propustnost po úpravách budu testovat dneska. Ale co ta ztrátovost u UDP btestu?

zigi

Další postřehy - testy byly prováděny mezi notebookem s windows a PC s linuxem (SFTP a SAMBA server) bez jakýchkoliv mezilehlých switchů : NTB -- WDS Station --< NV2 >-- WDS AP -- PC

- úpravy provedené v konfiguraci spoje:

distance = 1km (původě "dynamic")

hw-protection-mode = "none" (původně "rts cts")

tdma-period-size = 1ms (původně 2ms)

nv2-cell-radius = 10km (původně 30km)

- u UDP BTestu se Tx/Rx rate pohyboval okolo 110/110Mbps a Tx/Rx CCQ se pohybovalo od 94 do 100%

- u TCP BTestu (TCP connection count = 1) se Tx/Rx rate pohyboval okolo 30/30Mbps

- při kopírování z PC na NTB pomocí WinSCP (SFTP) jsem dosahoval v průměru rychlosti 8800 KiB/s a Tx/Rx CCQ se pohybovalo od 94 do 100%

- při kopírování z PC na NTB pomocí TotalComanderu (SAMBA) jsem dosahoval v průměru rychlosti 2400 KiB/s - i po výkonostních úpravách SAMBY jsem z toho nebyl schopen vymáčknout více

- při současném kopírování z PC na NTB pomocí WinSCP (SFTP) a TotalComanderu (SAMBA) byl celkový součet rychlostí kolem 9700 KiB/s, což je super, ale kopírování ze SAMBY (1200 KiB/s) šlo dolů na úkor SFTP (8500 KiB/s) a Tx/Rx CCQ se pohybovalo od 94 do 100%

- při kopírování z NTB na PC pomocí WinSCP (SFTP) jsem dosahoval v průměru rychlosti 1500 KiB/s - což je taky málo

- Tx/Rx bit rate občas klesl z 300Mbps na 270Mbps, ale víceméně se během pár vteřin vrátil na max hodnotu

- žádné dropy či errory na záložce traffic

- asi po hodině testování se začly dít divné věci - Tx/Rx CCQ začlo lítat od 60 k 95%

DOTAZ1: jak zvýšit rychlost uploadu/downloadu ze samba serveru?

DOTAZ2: kde se dá najít info k A-MPDU, tedy přesněji, čemu odpovídají jednotlivé priority?

disk

A co nepoužít nv2, ale jen nstreme (např. best fit a f.limit 3999)? Mám to tak všude a nevím o tom. Zatím se mi nikde nv2 neosvědčilo, ani na A, ani na N. Ale to asi bude spíše rukama.

Pusť si na linuxu iperf a testuj to proti nb. Má to i win verzi. SFTP a Samba na testování není. To radši obyč. FTP.

zigi

Další postřehy - testy byly prováděny mezi notebookem s windows a PC s linuxem (SFTP a SAMBA server) bez jakýchkoliv mezilehlých switchů : NTB -- WDS Station --< Nstreme >-- WDS AP -- PC

- SAMBA a SFTP jsou pro testy použity zdůvodu nejčastěji používaných protokolů v naší síti (tedy po HTTP(S) a mail protokolech)

- úpravy provedené v konfiguraci spoje:

wireless protocol = "nstreme"

Enable Nstreme

Enable Polling

Disable CSMA

Framer Policy = "best fit"

Framer Limit = 3200

hw-protection-mode = "none" s "rts cts" cca o 200 KiB/s pomalejsi (SAMBA)

- u UDP BTestu se Tx/Rx rate pohyboval okolo 80/80Mbps a Tx/Rx CCQ se pohybovalo kolem 95/70%

- u TCP BTestu (TCP connection count = 1) se Tx/Rx rate pohyboval okolo 35/35Mbps a Tx/Rx CCQ se pohybovalo kolem 92/92%

- při kopírování z PC na NTB pomocí WinSCP (SFTP) jsem dosahoval v průměru rychlosti 10300 KiB/s a Tx/Rx CCQ se pohybovalo kolem 90%

- při kopírování z PC na NTB pomocí TotalComanderu (SAMBA) jsem dosahoval v průměru rychlosti 4300 KiB/s - občas i až 4600 KiB/s, ae víc ani ťuk

- při současném kopírování z PC na NTB pomocí WinSCP (SFTP) a TotalComanderu (SAMBA) byl celkový součet rychlostí kolem 11100 KiB/s, což je výborný, ale kopírování ze SAMBY (1500 KiB/s) šlo dolů na úkor SFTP (9600 KiB/s) a Tx/Rx CCQ se pohybovalo od 94 do 100%

- při kopírování z NTB na PC pomocí WinSCP (SFTP) jsem dosahoval v průměru rychlosti 2900 KiB/s - což je hoďně málo oproti opačnému směru kopírování - a Tx/Rx CCQ se pohybovalo kolem od 80 do 95%

- při kopírování z NTB na PC pomocí TotalComanderu (SAMBA) jsem dosahoval v průměru rychlosti 4100 KiB/s - což je dobrý výsledek oproti předchozím testům a konfiguracím

- Tx/Rx bit rate nabýval různých hodnot od 100 do 270 Mbps, ale snad nikdy nepřekročil 300 Mbps a přechody na větší hodny bit ratu byly dost pomalé

- žádné dropy či errory na záložce traffic

DOTAZ3: čím to může být, že SAMBA nedosahuje aspoň 75% přenosové rychlosti při kopírování pomocí SFTP?

DOTAZ4: jak to, že dojde k útlumu kopírování přes SAMBU na úkor SFTP - nějaký implicitní QoS, či je SAMBA protokol tak špatný a náchylný na obasazenost přenosového pásma? Počítač na druhé straně by to neměl nijak omezovat, snad jen plánovač OS.

DATAZ5: jde nějak vytunit bit rate, aby tolik nelýtal dolu a nahoru - co záložka "Data rates" a zakliknout tam jen pouze pár nejvyších rychlostí?

DOTAZ6: jaké zabezpečení používá Nstreme - klasický security profile?

hapi

samba je na houby. Neni vůbec agresivní, je háklivá na latence. Nicméně stále využíváš pouze jeden spoj ne? Druhej tomu nijak nepomáhá.

disk

Zaškrtnout disable CSMA, framer limit na 3999, btest ti nic neřekne, když provoz nestíhá vygenerovat, zkus jiný kanál, jaké jsou pingy při testech (-s 1472), se sambou nic neuděláš - vlastnost protokolu.

Pošli to aspoň jako demo.

zigi

nstreme a iperf + vliv TCP window size:

C:\Downloads>iperf.exe -c 192.168.1.111 -m -w 524288 -t 20

------------------------------------------------------------

Client connecting to 192.168.1.111, TCP port 5001

TCP window size: 512 KByte

------------------------------------------------------------

[1912] local 192.168.1.203 port 1523 connected with 192.168.1.111 port 5001

[ ID] Interval Transfer Bandwidth

[1912] 0.0-20.3 sec 221 MBytes 91.2 Mbits/sec

[1912] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)

C:\Downloads>iperf.exe -c 192.168.1.111 -m -w 262144 -t 20

------------------------------------------------------------

Client connecting to 192.168.1.111, TCP port 5001

TCP window size: 256 KByte

------------------------------------------------------------

[1912] local 192.168.1.203 port 1530 connected with 192.168.1.111 port 5001

[ ID] Interval Transfer Bandwidth

[1912] 0.0-20.3 sec 224 MBytes 92.5 Mbits/sec

[1912] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)

C:\Downloads>iperf.exe -c 192.168.1.111 -m -w 131072 -t 20

------------------------------------------------------------

Client connecting to 192.168.1.111, TCP port 5001

TCP window size: 128 KByte

------------------------------------------------------------

[1912] local 192.168.1.203 port 1535 connected with 192.168.1.111 port 5001

[ ID] Interval Transfer Bandwidth

[1912] 0.0-20.3 sec 225 MBytes 93.3 Mbits/sec

[1912] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)

C:\Downloads>iperf.exe -c 192.168.1.111 -m -w 65536 -t 20

------------------------------------------------------------

Client connecting to 192.168.1.111, TCP port 5001

TCP window size: 64.0 KByte

------------------------------------------------------------

[1912] local 192.168.1.203 port 1536 connected with 192.168.1.111 port 5001

[ ID] Interval Transfer Bandwidth

[1912] 0.0-20.0 sec 223 MBytes 93.5 Mbits/sec

[1912] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)

C:\Downloads>iperf.exe -c 192.168.1.111 -m -w 32768 -t 20

------------------------------------------------------------

Client connecting to 192.168.1.111, TCP port 5001

TCP window size: 32.0 KByte

------------------------------------------------------------

[1912] local 192.168.1.203 port 1537 connected with 192.168.1.111 port 5001

[ ID] Interval Transfer Bandwidth

[1912] 0.0-20.0 sec 215 MBytes 90.3 Mbits/sec

[1912] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)

C:\Downloads>iperf.exe -c 192.168.1.111 -m -t 20

------------------------------------------------------------

Client connecting to 192.168.1.111, TCP port 5001

TCP window size: 8.00 KByte (default)

------------------------------------------------------------

[1912] local 192.168.1.203 port 1531 connected with 192.168.1.111 port 5001

[ ID] Interval Transfer Bandwidth

[1912] 0.0-20.0 sec 115 MBytes 48.0 Mbits/sec

[1912] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)

zigi

Zaškrtnout disable CSMA, framer limit na 3999, btest ti nic neřekne, když provoz nestíhá vygenerovat, zkus jiný kanál, jaké jsou pingy při testech (-s 1472), se sambou nic neuděláš - vlastnost protokolu.

Pošli to aspoň jako demo.

Díky za reakce, ale nejsem v MK tak zběhlý, takže nevím co znamená "demo". Jinak obsazenost kanálů a použité frekvence jsou k nalezení v mých předchozích příspěvcích.

Latence se u normálního pingu 64B pohybujou při nezatíženém spoji kolem 1ms a při plném vytížení se vyšplhají na max. 10ms - tedy při použití nstreme.

disk

Ano, ale to máš jen v jednom spojení. Takže spoj jak vidíš by měl být v pořádku. Pingy v průběhu testu?

Pošleš veřejku a nějakým portem to přesměruješ na ty mk a vytvoříš uživatele demo jen s omezenými právy (jen pro čtení).

zigi

samba je na houby. Neni vůbec agresivní, je háklivá na latence. Nicméně stále využíváš pouze jeden spoj ne? Druhej tomu nijak nepomáhá.

U Samby jsem se snažil pořešit TCP window size a jiné socket parametry, ale jen s malým úspěchem. Stále provádím testy bez switchů (tedy i bez LACP) a pouze po jednom spoji. Jinak díky moc za přínosné komentáře a cené rady.

zigi

to disk:

PC iperf server - NTB iperf client

ping -l 1472 cca 10ms

C:\Downloads>iperf.exe -c 192.168.1.111 -m -w 65536 -d -t 60

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 64.0 KByte

------------------------------------------------------------

Client connecting to 192.168.1.111, TCP port 5001

TCP window size: 64.0 KByte

------------------------------------------------------------

[1840] local 192.168.1.203 port 1587 connected with 192.168.1.111 port 5001

[1812] local 192.168.1.203 port 5001 connected with 192.168.1.111 port 56553

[ ID] Interval Transfer Bandwidth

[1812] 0.0-60.0 sec 370 MBytes 51.7 Mbits/sec

[1812] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)

[1812] Read lengths occurring in more than 5% of reads:

[1812] 496 bytes read 38382 times (43.2%)

[1812] 8192 bytes read 39171 times (44%)

[1840] 0.0-60.0 sec 370 MBytes 51.7 Mbits/sec

[1840] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)

zigi

PC iperf client - NTB iperf server

iperf -c 192.168.1.203 -m -w 65536 -t 20

------------------------------------------------------------

Client connecting to 192.168.1.203, TCP port 5001

TCP window size: 128 KByte (WARNING: requested 64.0 KByte)

------------------------------------------------------------

[ 3] local 192.168.1.111 port 56074 connected with 192.168.1.203 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-20.0 sec 222 MBytes 93.1 Mbits/sec

[ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet)

obousměrný test - propustnost šla o 50% dolů o proti stejnému testu, kdy bylo PC iperf server - NTB iperf client

iperf -c 192.168.1.203 -m -w 65536 -d -t 20

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 128 KByte (WARNING: requested 64.0 KByte)

------------------------------------------------------------

Client connecting to 192.168.1.203, TCP port 5001

TCP window size: 128 KByte (WARNING: requested 64.0 KByte)

------------------------------------------------------------

[ 5] local 192.168.1.111 port 56077 connected with 192.168.1.203 port 5001

[ 4] local 192.168.1.111 port 5001 connected with 192.168.1.203 port 1608

[ ID] Interval Transfer Bandwidth

[ 5] 0.0-20.0 sec 59.2 MBytes 24.8 Mbits/sec

[ 5] MSS size 1448 bytes (MTU 1500 bytes, ethernet)

[ 4] 0.0-20.0 sec 57.9 MBytes 24.3 Mbits/sec

[ 4] MSS size 1460 bytes (MTU 1500 bytes, ethernet)

a nejhůře dopadl UDP test

iperf -c 192.168.1.203 -u -t 20

------------------------------------------------------------

Client connecting to 192.168.1.203, UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 112 KByte (default)

------------------------------------------------------------

[ 3] local 192.168.1.111 port 45017 connected with 192.168.1.203 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-20.0 sec 2.50 MBytes 1.05 Mbits/sec

[ 3] Sent 1785 datagrams

[ 3] Server Report:

[ 3] 0.0-20.0 sec 2.50 MBytes 1.05 Mbits/sec 6.538 ms 0/ 1785 (0%)

« Předchozí stránka Další stránka »