Enlace AC 80 mhz "Quase Perfeito" 580 metros, perdendo pacotes misteriosamente...

Bom dia amigos!
Estou com um problema que já bati muito cabeça, troquei canal, banda, largura, potencia e não resolve...
Meu sinal está em -45dbm, os pings estão em 0ms, banda real de 400mbps (teste entre pontos).
A distancia entre os pontos é de 580 metros.
Estou usando um par de Mikrotik SXT G-5HPacD, minha configuração ATUAL é:
Radio A: Bridge
Radio B: Station Bridge
Banda: 5GHz-only-AC
Largura do Canal: 20/40/80 eeCe
Frequência: 5540
Protocolo: 802.11
Segurança: WPA2 PSK / AES CCM (senha com 30 caracteres)
O restante está no default (resetei e configurei só esses parâmetros)


O que está ocorrendo...
Se eu deixar um radio pingando o outro, de tempo em tempo ele não recebe a resposta de 3 ou 4 pings...
Isso é constante, independente da banda, largura, canal ou potencia que eu configure (pelo menos em todas as configurações que eu já testei...)
O detalhe, é que a conexão entre eles não cai, em "Registration" eles continua lá sem "cair e voltar"...
Em Tx/Rx Drops, sempre ZERO!
Em Tx/Rx Errors, sempre ZERO!


Estou desconfiando de hardware...
O que acham??

Prints de ambos os rádios para melhor análise.

Citação:

---

Postado originalmente por sphreak

Prints de ambos os rádios para melhor análise.

---

Anexo 66044
Anexo 66043

Mais alguma?

Faltou o do radio da outra ponta.

Nessa print que foi postada a única coisa que posso perceber é que o SNR está excessivo. Um SNR de 59dB para um sinal de -45dBm daria um noise floor de -104dBm. Qual a interpretação pra esses valores? O Noise floor está em um bom patamar, o que significa que o sinal está em excesso.

Considere ir diminuindo a potência dos rádios, a fim de encolher esse SNR sem prejudicar a modulação do rádio. Mesmo porque essa SXT AC necessita de potência máxima de 22dBm e sinal mínimo de -70dBm para MCS alto. Vide: http://i.mt.lv/routerboard/files/sxt...1025161301.pdf

uma dica que talvez ajude ali em frequency mode: manual tx power,mude para superchanel,pode ajudar nesse enlace

Caramba, essa SXT dá tudo isso de tráfego agregado mesmo em 80mhz? 780mbps?

Citação:

---

Postado originalmente por fhayashi

Caramba, essa SXT dá tudo isso de tráfego agregado mesmo em 80mhz? 780mbps?

---

Não...segundo datasheet só até 540mbps

Vide: http://i.mt.lv/routerboard/files/sxt...1025161301.pdf

Citação:

---

Postado originalmente por thiagodp

Bom dia amigos!
Estou com um problema que já bati muito cabeça, troquei canal, banda, largura, potencia e não resolve...
Meu sinal está em -45dbm, os pings estão em 0ms, banda real de 400mbps (teste entre pontos).
A distancia entre os pontos é de 580 metros.
Estou usando um par de Mikrotik SXT G-5HPacD, minha configuração ATUAL é:
Radio A: Bridge
Radio B: Station Bridge
Banda: 5GHz-only-AC
Largura do Canal: 20/40/80 eeCe
Frequência: 5540
Protocolo: 802.11
Segurança: WPA2 PSK / AES CCM (senha com 30 caracteres)
O restante está no default (resetei e configurei só esses parâmetros)


O que está ocorrendo...
Se eu deixar um radio pingando o outro, de tempo em tempo ele não recebe a resposta de 3 ou 4 pings...
Isso é constante, independente da banda, largura, canal ou potencia que eu configure (pelo menos em todas as configurações que eu já testei...)
O detalhe, é que a conexão entre eles não cai, em "Registration" eles continua lá sem "cair e voltar"...
Em Tx/Rx Drops, sempre ZERO!
Em Tx/Rx Errors, sempre ZERO!


Estou desconfiando de hardware...
O que acham??

---

Você está passando 400M half nessa RB, é isso? Sei que foge um pouco do assunto do post, mas tem como fazer um teste de banda pra mostrar pra gente?

Em relação ao seu problema, também acho que pode ser sinal em excesso, recomendo diminuir a potência.

Enviado via Moto G (4) usando UnderLinux App

A banda dele é muito boa sim!
Ele possui porta Gigabit, então a transferência entre os pontos é superior ao Ethernet comum (10/100)...

Dependendo da configuração, o TX/RX Rate chega a 866.6Mbps...

Receive:
Anexo 66053

Send:
Anexo 66054

Both:
Anexo 66055

Apenas para mostrar o Tx Rate em 866.6Mbps:
Anexo 66056

O erro que estou tendo, é uma falha de ping...
Parece pouco mas incomoda pois, quando estou acessando um filme via DLNA no PONTO_B a partir do Ponto_A, ele cai, a TV desconecta, diz que o servidor está fora...
Anexo 66057

Print do sinal lado cliente?

Enviado via SM-J110L usando UnderLinux App

Citação:

---

Postado originalmente por gandhi

uma dica que talvez ajude ali em frequency mode: manual tx power,mude para superchanel,pode ajudar nesse enlace

---

Você sugere mudar para superchannel para sair da faixa normal de operação e escapar de interferências no canal? Mas olhe que já foi comentado que o Noise está num patamar excelente...
Qual seria o outro benefício de mudar para superchannel?

Citação:

---

Postado originalmente por sphreak

Print do sinal lado cliente?

Enviado via SM-J110L usando UnderLinux App

---

Os testes de banda foram todos feitos pelo lado cliente...
Já com outras configurações, alterei pra não conectar nos data rates básicos (6 a 54)...
O sinal está nos prints dos testes

Talvez possa ter alguma linha de energia proximo a sua torre, algo que possa gerar interferencia, vi relatos dos nossos amigos sobre problemas assim

Passei a perceber isso a aproximadamente 1 ano, quando, a antena externa de TV VHF, foi elevada (na mesma vara), porém ainda tem uns 3 metros entre a as antenas (SXT e TV). Não sei se tem relação ou não...

Passou a noite toda e perdeu 41 respostas dos pings:
Anexo 66058

Citação:

---

Postado originalmente por ab5x2

Você realmente precisa dessa banda toda aí? Cara, soltar 80MHz num ambiente urbano é matar todo mundo.

Aqui sofremos com esses "garotinhos" que soltam 80MHz com potência máxima e arrebentam com o espectro 5GHz.

---

Certeza que não. Senão o ping não estaria tão baixo, rrs

Mas.......

supondo que irá manter os 80mhz, eu abaixaria uns 5 ou 6dbs na potência de transmissão dos seus rádios.

Não sei os MK, mas nos cálculos de enlace da Ubnt, se escolher o Enhanced modelling, ele já te dá o sinal que em teoria satura o rádio. A queda de banda é brutal.

Citação:

---

Postado originalmente por ab5x2

Você realmente precisa dessa banda toda aí? Cara, soltar 80MHz num ambiente urbano é matar todo mundo.

Aqui sofremos com esses "garotinhos" que soltam 80MHz com potência máxima e arrebentam com o espectro 5GHz.

---

Realmente preciso da banda toda...
Entre os pontos A e B, há durante o dia várias transferências de arquivos, as vezes de até 30 giga...
Não é omnidirecional, é um ponto a ponto direcional (20º cada antena)...
Estou usando a faixa 5490 a 5730, abaixo da faixa 5735 a 5835, que é a mais usada...
A potência está em "default", justamente pra ele controlar a potencia.

Citação:

---

Postado originalmente por thiagodp

Realmente preciso da banda toda...
Entre os pontos A e B, há durante o dia várias transferências de arquivos, as vezes de até 30 giga...
Não é omnidirecional, é um ponto a ponto direcional (20º cada antena)...
Estou usando a faixa 5490 a 5730, abaixo da faixa 5735 a 5835, que é a mais usada...
A potência está em "default", justamente pra ele controlar a potencia.

---

Quanto as prints amigo... por enquanto só foi print meio inutil... Teste de velocidade pouco ajuda! Sinal e info de recepção dos dois lados entende? Info de SNR dos dois lados. Configs dos dois lados.... Noise dos dois lados...

Quanto a 80mhz... se necessita de tudo isso de banda investe em Airfiber ou radio digital ao invés de matar o espectro. Por não ser omnidirecional não significa que o sinal se limite ao enlace... Em potência máxima ele ultrapassa a linha dos radios. Então tenha em mente que esse teu enlace polui pelo menos 25km antes de desvanecer. Teu radio é de 1300mW com um EIRP de 47dBm... E a abertura é de 90°. Um enlace assim espalha sinal em pelo menos 600Km2... Em 80mhz e muita poluição
Por isso é sempre bom efetuar a regulagem correta da potência em somente a necessária.

Boa sorte!


Enviado via SM-J110L usando UnderLinux App

Citação:

---

Postado originalmente por sphreak

Quanto as prints amigo... por enquanto só foi print meio inutil... Teste de velocidade pouco ajuda! Sinal e info de recepção dos dois lados entende? Info de SNR dos dois lados. Configs dos dois lados.... Noise dos dois lados...

---

Nos prints que passei dos testes, não limitei a tela (print) somente ao teste, neles tem as informações do sinal do ponto B.
https://under-linux.org/showthread.p...849#post802849

O ponto A, foi um dos primeiros posts (o meu segundo), após você pedir os prints.
https://under-linux.org/showthread.p...784#post802784

Reduzir a potência não resolveu?

Citação:

---

Postado originalmente por fhayashi

Reduzir a potência não resolveu?

---

Não.
Reduzi a banda e a potencia e nada...
Mas vou fazer testes melhores, com potencia mais baixa, novamente neste final de semana.

Citação:

---

Postado originalmente por sphreak

Quanto as prints amigo... por enquanto só foi print meio inutil... Teste de velocidade pouco ajuda! Sinal e info de recepção dos dois lados entende? Info de SNR dos dois lados. Configs dos dois lados.... Noise dos dois lados...

Quanto a 80mhz... se necessita de tudo isso de banda investe em Airfiber ou radio digital ao invés de matar o espectro. Por não ser omnidirecional não significa que o sinal se limite ao enlace... Em potência máxima ele ultrapassa a linha dos radios. Então tenha em mente que esse teu enlace polui pelo menos 25km antes de desvanecer. Teu radio é de 1300mW com um EIRP de 47dBm... E a abertura é de 90°. Um enlace assim espalha sinal em pelo menos 600Km2... Em 80mhz e muita poluição
Por isso é sempre bom efetuar a regulagem correta da potência em somente a necessária.

Boa sorte!


Enviado via SM-J110L usando UnderLinux App

---

Fora que acho depositar muita coisa sobre um equipamento tão básico. Se sempre tem essas transferências grandes, deve ter alguma missão crítica nesse enlace. Eu mudaria já para fibra.

Qualquer interferência nas redondezas vai te matar. Essas SXT, devem ter uma abertura de quase 45 graus.
@sphreak, se não me engano, a AirFiber, apesar de mais robusta que as Airmax, também é um devorador de espectro, não?

Se precisa de tanta banda assim em um espaço tão curto, seria melhor usar uma fibra. Mais confiável e dependendo de onde tiver de passar esse cabo, sai mais barato. Sem contar que você teria muita folga para expansão. Por exemplo, se for um terreno único de empresa.

Concordo com o amigo acima, nessa distância, compensa colocar uma fibra, vai sair um custo relativo baixo de projeto e instalação. Caso a empresa não possua SCM não vai conseguir fazer o projeto, ai tem que ir de rádio mesmo. E para essa banda toda em 5Ghz é um problema dificil de resolver, eu iria confiar em um AF24 pra essa banda e sem ter problemas com interferência, bem alinhado, pode ter certeza que consegue uns 750MB full...

Só uma coisa, o sinal pelos prints NÃO é -45dBm, mas sim -49dBm.

O RX do chain0 num print, e do chain1 no outro, estão com -49dBm, esse é o valor que importa, tanto faz o valor no campo signal strenght, o que importa é o sinal de cada chain.

E -49dBm não é suficiente pra MCS9 em AC não, e menos ainda em 80MHz!
Quanto mais largo o canal mais sinal precisa, -49dBm talvez seria suficiente pra 30 ou 40MHz, ou MCS7 em 80MHz, mas MCS9 em 80MHz precisa sinal melhor que -45dBm (Em todos os chains, todo RX deve ter menos que -45, ou seja, -44, -43, -42, etc).

O problema é que o rádio não deve nem ter mais que 22dBm de potência a MCS9, e se pegar a queda de sinal de 102dBm em 580m, 22dBm+16dBi = 38dBm EIRP, menos 103dBm de perda dá -65dBm no ar a 580m, como a outra antena tem 16dBi de ganho, -65 + 16 = -49dBm. Ou seja, na potência máxima isso nem tem como chegar em -45dBm em AC.

Não confundam o setup, aqui informa -45dBm mas é em HT20-0, ou seja, com 20MHz, em MCS0, tem -45dBm de sinal:
https://under-linux.org/attachment.p...8&d=1485340551

Aqui em modo A (De Antiquado e ridículo de velho) a 54Mbps já cai pra -47dBm na aba signal:
https://under-linux.org/attachment.p...3&d=1485270408

O real sinal em AC a 80MHz seria HT80-8 ou HT80-9 (MCS8 ou MCS9 a 80MHz), esse sinal provavelmente será -49dBm ou pior, que é sinal insuficiente pra CCQ de 100%.

Fixa em MCS7 digamos, e testa, porque não tem como ter sinal suficiente pra CCQ de 100% em MCS9 nessa distância, parece perto mas AC exige sinal muito bom pra ter o máximo throughput, e -49dBm é suficiente apenas pra MCS7 (Do padrão N ainda) ter a máxima banda.

Deve passar altas bandas as vezes porque agrega muitos cabeçalhos de pacotes e transmite tudo em rajadas enormes, mas o problema é bem esse, ou o jitter fica alto (Ping de 0 a 4ms, que significa uma rede muito ruim variando 400% nos tempos) ou dá essas falhas periódicas quando o rádio tenta subir de data rate (Já que você setou pra ir até MCS9, ele vai tentar, ele sobe pra MCS9, espera dar 3 perdas consecutivas de pacotes (E todo chipset faz isso, só desce data rate depois de 3 perdas consecutivas, se tiver 2 perdas e 1 ok ele não desce) e só então baixa o data rate usado. Pelo tamanho da agregação talvez isso se manifeste em 2 a 5 pings, mas geralmente isso significa 3 ou 4 pacotes perdidos antes de diminuir o data rate e re-sincronizar.

Citação:

---

Postado originalmente por thiagodp

Realmente preciso da banda toda...
Entre os pontos A e B, há durante o dia várias transferências de arquivos, as vezes de até 30 giga...
Não é omnidirecional, é um ponto a ponto direcional (20º cada antena)...
Estou usando a faixa 5490 a 5730, abaixo da faixa 5735 a 5835, que é a mais usada...
A potência está em "default", justamente pra ele controlar a potencia.

---

Quem disse que default controla a potência? Ele altera a potência pra máxima quando o data rate permite, e um pouco menor em data rates mais altos. As SXT não possuem controle algum de potência propriamente dito.

@rubem,

agora me confundiu mais hahahaha. Vamos lá. No spec dessa SXT 5AC

https://routerboard.com/RBSXTG-5HPacD

Lá tem a sensibilidade de -72 para MCS9, imaginava que isso era o dbm combinado, mas não sendo, com o mínimo para cada chain de -72 para rodar em AC, o -49db não seria mais que suficiente para estabilizar? Isso desconsiderando alguém entrando no canal, claro.

Tentando editar a tempo. Acho que entendi, esses -49 que mostra no Mikrotik é a potência máxima no modo backup, certo?

Aproveitando aqui, já que estamos falando da potência teórica de transmissão/sensibilidade.

Supondo que um rádio renda 27dbm transmitindo em um canal de 10mhz. Se eu dobrar a largura do canal, eu passo a transmitir o dobro e então a potência do rádio passa a ser divida nesse novo espectro? Cairia uns 3dbs para transmitir em 20mhz?

Me corrigindo a tempo, o sinal recebido no outro lado cai uns 3db porque a potência de transmissão seria a mesma mas mais distribuída no espectro.

Prints atuais, sem perda de banda.
Ainda tem as "quedas", apesar de não mostrar nestes prints abaixo.

Lado A:
Anexo 66082

Lado B:
Anexo 66083

Olá meu caro,

Vamos lá sem mágicas e mistérios,

Frequência 5.8, SXT, Banda 200MB Full, Processamento 79%, potência de sinal 49dbm, nível de sinal -54.

Começaria dizendo que:

esquece você não conseguirá desempenho de rádio digital em 5.8, vai haver sempre perda de pacote, uma simples oscilação elétrica vai fazer o seu equipamento dar perda de pacote.
200MB full verifica que o processamento está mostrando dar 79%, já começará a ter perda de desempenho do equipamento por estar com processamento alto. Digo alto porque par SXT esse processamento já está acima do recomendável.
Potência de sinal 49dbm.
http://www.juliano.com.br/artigos/te...s/image002.gif
Logo,
49 = 10 + 10 + 10 + 10 + 3 + 3 + 3
http://www.juliano.com.br/artigos/te...s/image004.jpg


Tem idéia do quanto que está emitindo de RF para um simples enlace de 500 Metros?
Utilize o gráfico acima e faça as contas, acho que essa potência vai alguns KM X mais do que você está querendo.

Agora vamos tratar banda AC.
AC usa modulação com 256 pontos na quadratura, 256QAM, exige definição melhor de sinal pra ser legível, e exige TANTO a mais (10dBm a mais) porque N na maior modulação usa só 64 pontos, 64QAM.

Portanto o sinal -49 acredito estar fora do recomendado.
De nada vai adiantar colocar um alto falante de 20" colocar um amplificador na bunda e querer escutar do outro lado a 10 metros de distância um o som puro.

Amigo nem com reza, macumba, magia ou que quer que seja vai passar link com baixa latência e qualidade em 5.8 ainda mais com produtos baratos, sem contar que vai fud... o espectro, vai ter que meter a mão no bolso e colocar fibra ou enlace digital.

Voltando pra questão da sensibilidade do rádio, versus o sinal presente, é questão de MARGEM, assim como o SNR.

O SNR é uma margem entre sinal e ruído (Relação Sinal-Ruído). Se tem um motor rondando a 60dB, você só entenderá alguém falando se o som da voz dessa pessoa chegar no seu ouvido lá pelos 70dB. Humanos precisam um SNR tipo 10dB pra conseguir entender a maioria das palavras.

Notar: A maioria das palavras. Pra entender tudo precisar margem tipo 15 a 20dB.

Wifi passa pela mesma situação, precisa um SNR mínimo pra maioria dos bits do pacotes ser legível. Pra 100% dos bits serem legíveis precisa coisa altíssima tipo 30dBm pra MCS15:
https://under-linux.org/attachment.p...4&d=1461116122

AC em MCS8 e MCS9 precisam SNR ainda maior, se não me engano bate 35dBm de SNR em MCS9.

Assim como na comunicação verbal podemos não entender algumas palavras, com SNR baixo uma comunicação entre 2 rádios vai perder parte de cada pacote. Essa parte vai ser retransmitida, porque existe uma checagem de integridade em wifi, a parte que recebe analisa os dados e gera um checksum (Um código que é a soma de uns bits que recebeu), devolve esse checksum, e se ele não bater com o checksum que o rádio transmissor calculou, ele entende que parte do pacote foi perdido e envia de novo. Esse reenvio faz um ping de 1ms pular pra 2ms, e se ele pular pra 4ms então ter re-retransmissão de algumas partes (Perdeu partes até do reenvio).

Ter um CCQ de 100% significa que todo o pacote enviado chega completo, no máximo com uns 13 a 25% perda que foi reenviada.

A outra margem que conta tanto quanto SNR é a margem entre o sinal e a sensibilidade, é o SOM, System Online Margin.

A sensibilidade de -72dBm é o mínimo pro rádio entender alguma coisa. Assim como nosso ouvido escuta som tão baixo tipo 20dB. Mas... escutar que TEM UM SOM é diferente de conseguir entender um Recifense falando rápido. -72dBm é o sinal mínimo pro rádio entender pelo menos algumas partes do pacote, entender que tem alguém falando. Mas pra entender o pacote todo precisa margem tipo 20dBm (Acima da sensibilidade. Digamos -52dBm de sinal onde a sensibilidade no datasheet é de -72dBm). Pra humanos mesma coisa, pra entender um Recifense que fala rápido o som precisa estar lá pelos 45 a 50dB, por mais que se estiver em 20dB a gente consegue entender vagamente que tem alguém falando algo que lembra vagamente um humano falando (E dá pra descobrir o idioma mais pelas pausas e entonações do que por ouvir de fato as pronúncias).

Essa margem entre sensibilidade e sinal, o SOM, é bom que seja a maior possível. O calculo gera tabelas tipo essa de um engenheiro da UBNT:
https://community.ubnt.com/t5/Wirele...hment-id=17483

Essa tabela leva em conta -86dBm, que é a sensibilidade em A ou G a 18Mbps. Se a margem entre sinal e sensibilidade for de só 8dBm (Seria sinal de -60dBm pra sensibilidade de -72dBm) vai ter 10% de perda. E perder 10% do pacote compromete um pacote de 1500 bytes completamente, o checksum nunca sairá certo, 10% de perda num texto significa tirar 10% das letras num página, compromete COMPLETAMENTE a legibilidade!

Wifi dá conta de lidar mais ou menos só com perdas tipo abaixo de 1%, essas perdas geram pouco reenvio de bits, então 18dBm de margem (Entre sinal e sensibilidade) é o mínimo pra ter algum pingo de qualidade.

Se a sensibilidade é de -72dBm, o mínimo de sinal seria então 18dBm maior que isso, ou seja, -72+18 = -54dBm. Isso é o mínimo. E com mínimo não existe CCQ de 100% nem a pau! Pra ter CCQ máximo precisa aumentar a margem ainda mais, eu não trabalho com menos de 20dBm de margem nunca, assim garanto CCQ de 96-99% e throughput estável.

Peguei uns prints e marquei aqui o sinal REAL nesse caso, que não é melhor que -54dBm o tempo todo. Aqui o melhor sinal:

Anexo 66128
Tem que se basear pelo menos sinal presente. Nesse caso é -49dBm. Como é uma margem suficiente, o sistema RouterOS está usando de fato AC, está usando MCS9.

Vide http://www.mcsindex.com pra ver o que 866Mbps a 80MHz é, ele é AC de fato, MCS9 (Na coluna azul, na direita, tem o MCS em AC).

E aqui o menor sinal nos prints, são 8dBm a menos de sinal:
Anexo 66129

Esse sinal de -57dBm não é suficiente pra AC, por isso o RouterOS NÃO ESTÁ USANDO AC! Veja em www.mcsindex.com que 650Mbps vem a ser uma modulação de N, é MCS15 a 80MHz (MCS7 em dualchain vem a ser 100% a mesma coisa que MCS15 em N). Naturalmente baixando o data rate, o throughput real (O pass throughput é o presumido pelo número de cabeçalhos, ele leva em conta o percentual legível dos pacotes, ele não confere com o throughput real porque os dados do usuário ficam DENTRO de um pacote wifi que adiciona cabeçalhos e sincronizações diversas. Mal comparando: o throughput real é sua encomenda dentro de uma caixa dos Correios, a caixa dos Correios dentro de um caminhão é o pass throughput, e o caminhão inteiro é o data rate))

Se conseguir fazer o sinal (Nivele sempre pelo menor. Esquece a média resumida na aba registration, use o que consta na aba signal dando duplo clique sobre a conexão) ficar em -49dBm o tempo todo, aí sim vai usar AC, mas talvez só em 40MHz.

Aí entra outra coisa: O datasheet dá dados a 20MHz de largura. A sensibilidade diminui uns 3dBm cada vez que você dobra de canal. Ou seja, se a 20MHz é -72dBm em MCS9, a 40MHz será 3dBm mais alta, ou seja, -69dBm, e ao dobrar pra 80MHz sobe pra -66dBm de sensibilidade.

O SNR mínimo pra sequer conseguir conectar (Mas ter ping só de 32 bytes, com os demais pacotes sendo perdidos) é essa tabela, notem que entre 20 e 40MHz muda 3dBm, de 40 pra 80dBm idem:
https://static1.squarespace.com/stat...1418680339628/

Ou aqui a tabela completa:
https://pbs.twimg.com/media/ByjIAKPCMAAOGD-.png

37dB de SNR é a margem pra MCS9 a 80MHz, mas isso é o mínimo.

Segundo os prints o ruído está até abaixo de -100dBm, então o SNR pra MCS9 tá ótimo. O que está longe de bom é a relação entre sinal e sensibilidade (SOM), que pra dar margem de 18dBm, levando em conta sensibilidade real a -66dBm a 80MHz (Pra -72dBm a 20MHz), seria -66 + 18 = -48dBm.

Ou seja, pra ficar fixo em MCS9 precisa -48dBm ou mais, mas precisa isso o TEMPO TODO, em todos os chains, seja sendo A>B ou sentido B>A (Rx e Tx nos 2 lados). Uma variação de 1 ou 2dBm é normal até em link perfeito então teria que fazer o sinal ficar em -46dBm em dias de chuva (Que deve implicar provavelmente -42dBm em dias de sol).

Tudo isso pra explicar porque o datasheet fala em -72dBm mas não tem mínimas condições de um link de 500m com esse equipamento ficar com CCQ de 100% em MCS9 a 80MHz.

Esse sinal ora em -49dBm e ora a -57dBm me diz que a zona de Fresnel disso não está ok, mas nem adianta muito tentar cortar árvores fora pra melhorar isso, precisa antena de ganho maior pra fazer o sinal médio ficar sempre acima de -46dBm nessa distância.

Eu gosto de fazer o cálculo de free space loss aqui: http://mayo.nuvisions.net/ubnt_link/ O SXT tem sensibilidades similares aos Rocket M5 (Os chipsets Qualcomm/Atheros são muito similares), fica assim o exemplo, que vale pro SXT 16dBi também:
Anexo 66130
O que isso diz: Usando MCS15 de N (Não é AC), em largura de 20MHz, tem 25dB de margem entre sensibilidade e sinal.
Passando pra 40MHz lembra que a sensibilidade cai 3dBm, então a margem cairia pra 22dB.
Passando pra 80MHz lembra que a sensibilidade cai mais 3dBm, então a margem cairia pra 19dB, fica meio que por um triz.

(Lembra que o sinal varia fácil 2dBm conforme chuva, poeira, calor, enfim, teria momentos de margem de 17dB, que acho pouco)

Isso em MCS15 em N! AC vai exigir mais 3dBm pra MCS8 a 80MHz (Ou seja, a margem cairia pra 16dB). E pra MCS9 mais 2 ou 3dBm, ou seja, margem caindo pra 13dB.

O jeito de ter sinal mais alto seria rádio com mais potência (Vide no datasheet a potência de cada modulação. Não adianta configurar no software uns 30dBm, se a potência no hardware é de 21dBm nalguma modulação, essa será a potência, e não os 30dBm no software). Ou então usar antena de ganho maior. PowerBeam de 19dBi acho que nem compensa (Aumentaria o sinal em 6dBm, são 3dBi de cada antena), provavelmente teria que partir pra 22dBi em antena, com rádio a 22dBm.

(No caso do Rocket AC e de umas RB's AC, cuida que eles tem só coisa tipo 19dBm nos datarates mais altos, pra esse caso precisa compensar isso com ainda mais antena, se a potência cai 3dBm é só colocar antena 3dBi maior, o que importa é a potência EIRP (dBm do rádio + dBi da antena) na hora de calcular)

Mas ainda assim tem o problema da chuva e do calor: CCQ com chuva é complicado ficar bom mesmo com sinal suficiente. E o calor e a umidade criam uma barreira de vapor até 2m do solo ou paredes, é situação onde a primeira zona de Fresnel limpa não é suficiente, as vezes precisa 200% da zona de Fresnel limpos se a intenção é CCQ de 100% o tempo todo (Com chuva, ou com calor gerando evaporação. Lembrem que cada metro quadrado de solo úmido pode evaporar 4 ou 5 litros de água por dia, essa evaporação fica majoritariamente concentrada em 4 ou 5 horas, é muito vapor no ar, wifi é microondas que é afetado por particulas pequenas tipo vapor ou poeira, afeta pouco mas já impede de ter CCQ de 100%).

Estudar é isso ai...

Um comentário que não deixa dúvidas sobre o que se esperar de resultados...

Acho que agora ficou claro que não tem mágica nem reza braba para resolver. É só saber o que se pode esperar. Não tem canal, superchannel ou outras benzeduras.. Pura matemática e física...

A chave esta na configuração do basic rate e mcs, o radio verifica o ruido e sinal, percebe q está ótimo, sobe automaticamente sua modulaçao para maximo troughput, neste momento recebe interferências, perde pacote, baixa a modulacao! Isso e comum, amanhã darei um print do meu caso resolvido e vc resolve ai[emoji106]


Sent from my iPhone using UnderLinux

Rubem, amanhã vou ler tudo com calma... mas sobre a diferença entre os sinais dos prints, é por que estão com potências diferentes...

Marcelo, fico no aguardo das configurações que você falou...

Enviado via XT1580 usando UnderLinux App

Ah sim, pacote perdido é sinal que vai pra contagem de ruído mesmo.

Se o CCQ não está em 100% (Ou 97-99%) tem que diminuir o data rate até ficar nesse valor (Esquece throughput por enquanto. O começo é ver quanto precisa baixar o data rate).

Aumentar ack-timeout num valor uns 10 ou 20% acima acima do real também ajuda a não perder tanto pacote (Mas onde já tem CCQ de 100% não tem perda de pacotes).

Se respeitar a margem de link de 20dBm como mínimo acima da sensibilidade do data rate (Se a sensibilidade do data rate em uso é -75dBm pelo datasheet (E o datasheet usa valores pra 20MHz), então o sinal mínimo pra aquele data rate deve ser -55dBm, e tem que olhar nos 2 chains, não no que o software exibe como média), só com outro problema mais grave pra ter perda de pacotes, mas essa questão do ruído absurdamente alto aparece até em modo cliente/station sem nem estar conectado em nada, digo, lá no meio da roça a 50km da civilização onde nem pega rádio FM (Que dirá celular, tv, ou qualquer SSID wifi) tem CPE em torre que dá isso, liga em modo station e escaneia, aparece lá bonitão -88 ou -90dBm de ruído. É só mudar a instalação (Centímetros mais longe, as vezes) que isso some. Pra mim o que mais tem é CPE grudada em cantoneira de torre, é só botar espaçador de 40cm que resolve, o "ruído" some.

Mas ruído que só aparece quando conecta e tem tráfego, aí é sinal de pacotes sendo perdidos, um ping -l 1450 ia mostrar o real tamanho da má qualidade da rede, ping de 32 bytes a 2ms e ping de 1450 bytes a 20ms é resultado de uma rede lixo, se um pacote leva 2ms, ele é retransmitido em 4ms, re-retransmitido em 6ms, re-re-retransmitido em 8ms, e por aí vai, precisa ter muita perda de pacotes pra um ping ficar tão ruim (Acima de 4 ou 5ms em distância curta tipo 1km). Teste de throughput feito pela CPE é meio inútil já que gera pacote no chipset, não passa pela parte ethernet, o teste precisa ser feito ethernet a ethernet (Algo na ethernet de uma CPE até algo na ethernet da outra) porque essa etapa também come processamento e aumenta consumo elétrico (Que aumenta ripple), mas o ping a 1450 bytes é um bom termômetro, em rede perfeita pode dar 4ms porque uma parte do pacote sendo perdida não é um problemão, o problemão é quando é uma parte grande do pacote, e o reenvio também é perdido. Se perde tanta parte da rajada de dados, a margem de sinal deve estar baixa, a legibilidade fixa baixa e as partes que não saem legíveis entram na conta de ruído, apesar de não serem.

O cabo de rede pode ocasionar essa "queda" ?
Lembrando que em registration, não cai, permanece conectado, porém um lado para de comunicar com o outro por uns segundos... Geralmente 4 pings pedidos e volta a comunicação.
São aproximadamente 30 metros de cabo, CAT6 GigaLan Furukawa (Vermelho), cabo sem blindagem, conector CAT6 sem blindagem.
Fonte original Mikrotik, injetor POE Gigabit Original Mikrotik.

Ping de rádio pra rádio mesmo? Digo, cliente pingando no AP?

Se perder até ping de rádio pra rádio (Do cliente pro AP e vice-versa), aí é problema na etapa de RF mesmo, o cabo de rede não tem como afetar a etapa de RF (Afetaria só o ping que passa pelo cabo). A não ser que tenha WLAN e LAN ethernet numa mesma bridge, aí a coisa muda, coisa tipo DLNA sei que pesa horrores (Comparado a rodar conteúdo hospedado no outro lado da rede) mas não sei que tipo de loops na rede pode criar, quando tem brige e switch no meio na história.

Limitando data rate (Ou largura de canal, que acaba limitando data rate) também tem o problema? Daria pra falar em falta de capacidade do hardware se ocorresse só com data rate ou throughput grande, ou na potência máxima (O chipset é feito pra digamos 19dBm a 20MHz. Pra operar ok a 40MHz devia cair pra 17 ou 18dBm, e em 80MHz talvez pra 15 ou 16dBm. Caso o firmware não o faça, o chipset ou os amplificadores aquecem muito, e talvez o RouterOS permita isso porque em bancada o chipset aquece menos (Sem sol na carcaça), é um componente que muda muito a distorção quando a temperatura dele muda só 10°C, e um dissipador de calor sobre o amplificador poderia fácil mudar mais de 15°C! Vai que o RouterOS não limita isso porque nos aparelhos mais caros tem dissipador de calor.

Citação:

---

Postado originalmente por rubem

Ping de rádio pra rádio mesmo? Digo, cliente pingando no AP?

Se perder até ping de rádio pra rádio (Do cliente pro AP e vice-versa), aí é problema na etapa de RF mesmo, o cabo de rede não tem como afetar a etapa de RF (Afetaria só o ping que passa pelo cabo). A não ser que tenha WLAN e LAN ethernet numa mesma bridge, aí a coisa muda, coisa tipo DLNA sei que pesa horrores (Comparado a rodar conteúdo hospedado no outro lado da rede) mas não sei que tipo de loops na rede pode criar, quando tem brige e switch no meio na história.

Limitando data rate (Ou largura de canal, que acaba limitando data rate) também tem o problema? Daria pra falar em falta de capacidade do hardware se ocorresse só com data rate ou throughput grande, ou na potência máxima (O chipset é feito pra digamos 19dBm a 20MHz. Pra operar ok a 40MHz devia cair pra 17 ou 18dBm, e em 80MHz talvez pra 15 ou 16dBm. Caso o firmware não o faça, o chipset ou os amplificadores aquecem muito, e talvez o RouterOS permita isso porque em bancada o chipset aquece menos (Sem sol na carcaça), é um componente que muda muito a distorção quando a temperatura dele muda só 10°C, e um dissipador de calor sobre o amplificador poderia fácil mudar mais de 15°C! Vai que o RouterOS não limita isso porque nos aparelhos mais caros tem dissipador de calor.

---

A perda é somente de rádio pra rádio mesmo...
Mesmo quando eu coloco em 20MHz e com potencia baixa, tenho as perdas de pacote.
Achava que poderia ser hardware, mas deixei os 2 em bancada, configurado como indoor, deixei "TORANDO" aproximadamente 250Mb/250Mb RX/TX (500Mb) sem perda de pacotes.
Antes eu não perdia, estou associando a uma troca do cabo de rede que fiz, era menor e coloquei um maior, não tenho certeza se foi ai que começou a dar problema...

Um motivo meio relacionado ao cabo seria um cabo longo com mais perdas (Mas via cabo você reenvia tudo mais rápido, o ping aumenta de 0,3ms pra 0,9ms e ninguém nota, mas teve perda, exigiu reprocessamento pro reenvio) que faz a CPU ficar meio ocupada com ethernet.

Seria caso de ping por esse cabo, mas seria bom evitar Windows, que só diz o ping tipo "<1ms", seria bom algo que desse o ping mais preciso, testa num roteador digamos
ping -t 192.168.1.20 -l 1450

E veja se dá 0,3 a 0,8ms. Aí parte pro outro com cabo longo. Se der valor muito maior, tipo 4ms, realmente tem algo errado nele.

Ping de 4ms com pacote grande até é aceitável, mas ele indica muita perda de partes das rajadas de dados enviadas, precisa reenviar cada parte. Se coincidir perda no cabo com perda via wifi, gera 2 ou 3 perdas seguidas de modo que o software dá timeout na conexão (DLNA faz muito tipo voip, aplica um delay intencional e fixo de acordo com o ping, atrasa a voz sempre, pro caso de alguns pacotes atrasarem, afinal a voz precisa tráfego constante pra sair legível, não é como texto que dá pra criar um bufferzinho ou exibir num ritmo inconstante. Hora que dá uma perda dessa de vários reenvios esse delayzinho não é suficiente, ele esvazia o pouoc buffer que tinha e derruba a conexão por falta de mais dados chegando, coisa que outras conexões não fazem)

Citação:

---

Postado originalmente por rubem

Um motivo meio relacionado ao cabo seria um cabo longo com mais perdas (Mas via cabo você reenvia tudo mais rápido, o ping aumenta de 0,3ms pra 0,9ms e ninguém nota, mas teve perda, exigiu reprocessamento pro reenvio) que faz a CPU ficar meio ocupada com ethernet.

Seria caso de ping por esse cabo, mas seria bom evitar Windows, que só diz o ping tipo "<1ms", seria bom algo que desse o ping mais preciso, testa num roteador digamos
ping -t 192.168.1.20 -l 1450

E veja se dá 0,3 a 0,8ms. Aí parte pro outro com cabo longo. Se der valor muito maior, tipo 4ms, realmente tem algo errado nele.

Ping de 4ms com pacote grande até é aceitável, mas ele indica muita perda de partes das rajadas de dados enviadas, precisa reenviar cada parte. Se coincidir perda no cabo com perda via wifi, gera 2 ou 3 perdas seguidas de modo que o software dá timeout na conexão (DLNA faz muito tipo voip, aplica um delay intencional e fixo de acordo com o ping, atrasa a voz sempre, pro caso de alguns pacotes atrasarem, afinal a voz precisa tráfego constante pra sair legível, não é como texto que dá pra criar um bufferzinho ou exibir num ritmo inconstante. Hora que dá uma perda dessa de vários reenvios esse delayzinho não é suficiente, ele esvazia o pouoc buffer que tinha e derruba a conexão por falta de mais dados chegando, coisa que outras conexões não fazem)

---

A perda é do "SXT A" para o "SXT B", no enlace.
Se eu estiver no lado A pingando o SXT A via cabo, não há perdas;
Se eu estiver no lado B pingando o SXT B via cabo, não há perdas;
Se eu estiver no lado A pingando o SXT B via cabo, há perdas;
Se eu estiver no lado B pingando o SXT A via cabo, há perdas;

Sim, entendi essa parte, falei pra comparar o ping via cabo em detalhes, com pacote grande (-l 1450) pra ver se ele não varia, indicando que ele é reenviado (Não perde o pacote, mas perde a primeira tentativa de envio. Reenvio é perda, reenvio gasta tempo, tempo que se reflete no ping, ping não pode aumentar 100% (De 1 pra 2ms) assim de graça, ou tem baixo poder de processamento envolvido, ou tem perdas de partes dos pacotes (Que são reenviadas, por isso perder não perde, mas aumenta muito (Percentualmente) o tempo de resposta no pacote grande).

Digo isso porque se o chipset (Que nos SXT AC é unificado, tudo no mesmo CI) estiver gastando mais processamento com ethernet, vai sobrar menos pra gastar com a etapa de RF. Ethernet gigabit pesa, por isso rádios digitais não tem ethernet direto no chipset principal (Que geralmente é mais poderoso que muito notebook), ele tem um chipset ethernet só pra isso, como se fosse uma placa-mãe com placa de rede offboard ao invés da rede onboard no chipset da placa-mãe).