Interferência Ruido lentidão 5.8Ghz sem oque fazer Por favor os especialistas ai de Plantão

[FabianoMartins2]

@rubem, testei de madrugada MCS4 no AP e variei um pouco nos clientes, cheguei a usar MCS2, depois MCS5 no AP e MCS3 nos clientes, mas em ambos os casos teve cliente que tive que acessa-lo por SSH e voltar a configuração anterior pois o CCQ ficou muito baixo e nem chegava a abrir pelo browser, só por SSH.

Daí voltei tudo no automático novamente. Acho que esgotou as opções no AP, acho que vou partir p/ a antena do cliente, tipo colocar mais alta ou até troca-lá, pra ver se melhora o CCQ.

Valeu pela ajuda, abraço.

[AlexTrevisol]

o que seria uma porcentagem aceitavel de ccq no cliente e no AP ?

[rubem]

Depende do que espera da rede, se quer rede perfeita só se satisfaça com 95% de CCQ pra cima, é possível ter isso (Sem equipto caro, depende talvez mais de visada dos clientes e área com pouca poluição do que do preço do equipto).

CCQ de 90% se for datarate tipo 20x maior que a banda vendida (20M nominal, pra cada 1Mbps nos planos) não permitirá atender muito cliente (40 num Rocket, digamos) sem que uns fiquem com internet ruim, depende da lotação do Acess Point.

Com 98-100% de CCQ você coloca 40 clientes de 1-5Mbps num Rocket tranquilo (Usando MIMO, claro. Com SISO não acho funcional vender mais que 3Mbps pra mais de 15 simultaneos).
Com 80% de CCQ se tiver 30 clientes nesse mesmo Rocket já vai ter cliente reclamando, CCQ baixo significa pacote perdido que precisou ser reenviado, reenviar pacote velho é atrasar o envio de pacote novo de nova conexão/navegação, atrasa toda a troca de dados.

[raumaster]

Pra não criar outro tópico e aproveitar seu grande conhecimento, Rubem, queria perguntar uma coisa.

Os protocolos TDMA proprietários funcionam bem quando o canal é limpo, só pra aquele AP já que o mesmo considera como ruído qualquer outra transmissão no mesmo canal, mesmo que a outra transmissão venha de um AP identico, mas com TDMA desativado. Sabemos que no protocolo 802.11 todos APs que se "enxergam" trabalham em "parceria" para melhor utilização do meio de transmissão, utilizando o protocolo CSMA. Se ele identifica outro AP ou mesmo cliente de outro AP, ele espera sua vez para transmitir, já no TDMA não, transmite e recebe em cima de qualquer transmissão de outro AP, mesmo que esse vizinho utilize também um protocolo TDMA. Correto? É cada um por si, passando por cima um do outro e no final eu já percebi que isso gera um resultado ruim no data rate, ao menos quando em automático, pior ainda em 2.4Ghz. Por outro lado se temos CPEs num mesmo AP e que não se "enxergam", vem o problema do nó oculto. Pergunto, o que é pior? Concorrer "deslealmente" pelo meio de transmissão ou nós ocultos? Eu creio que a resposta pra isso são micro células, tentando manter maioria dos clientes se "enxergando" e mantendo o protocolo nativo, 802.11. O que vc pensa disso?

Obrigado!

[rubem]

Não tenho muita experiência com TDMA, só em PTP's mesmo.

Sobre essa parte de CSMA esperar, isso não funciona bem, porque se o AP 1 manda um clear-to-send pro Cliente1, ele fica esperando esse cliente responder, esse cliente pode enviar algo ou não. Se ele enviar uma rajada grande de dados o canal vai estar em uso igual, o AP 2 viu uma oportunidade, transmitiu, mas... quando ele transmitiu um monte de clientes do AP1 transmitiram também, encheu o espectro do mesmo jeito. Uma coisa é um AP controlar o trafego com seus clientes, mas não pode fazer o mesmo com os clientes de outros AP's.
(E não tem como um AP saber o que o outro troca, se é sinc ou dado legítimos, tá tudo encriptado mesmo que não tenha senha na rede)).

Em uso indoor você tem sinal alto de um AP, mas os da vizinhança tem sinal baixo, o AP interno tem controle total no ambiente, se ele manda um clear-to-send o cliente responde, se ele não manda isso o cliente é que manda um request-to-send, o AP organiza a bagunça porque ele é o mestre dessa rede.

Em outdoor com múltiplos AP's não tem como gerenciar isso, devido ao angulo das antenas o AP2 pode estar numa posição que não receba o sinal do AP1, mas que recebe em cheio o sinal de uns clientes do AP1, você nunca sabe quando o cliente (De outro AP) vai começar a transmitir muita coisa, num PTP é previsível que sempre terá dados, mas em cliente de internet varia demais, pode ter meia hora de uso massivo, e 23,5 horas de praticamente idle, só troca de dados de sincronia. Esperar o cliente enviar os dados de sincronia é tranquilo, mas quando ele está usando o canal trocando um pacote depois do outro não funciona, nunca tem espaço, e o cliente responde ao AP dele, se o AP disse que está livre pra receber então o cliente vai transmitir, independente de ter outro AP por perto também transmitindo, até onde eu saiba a espera é feita quando não há tráfego e quando o sinal de outros AP's no canal é bem alto.

Sobre TDMA tratar tudo como ruído, aí fico na dúvida, porque o chipset faz alguns processos por instrução primária dele, coisas inalteráveis via software, o que TDMA faz é modificar um time-out pra sincronia, e forçar o cliente a esperar liberação (Com CSMA o padrão é esperar só se for pacote muito grande, mas sinc e cia eles não esperam), ou seja, o aparelho ainda tem capacidade pra entender o que um aparelho CDMA está enviando, ele deve jogar no ADC, fazer o batimento com portadora e etc, pra depois descartar. Isso é desperdício de processamento, mas... isso é circuito burro do chipset, não tem como alterar isso via software (Teria que fechar a porta do ADC, um switch na saída já faz isso, atenua quando o amplificador transmite, se estou falando eu ouço mal e roteador faz exatamente o mesmo, há muito reenvio de pacotes em CSMA por conta desse instante, o cliente 1 manda pacote de sinc e cia quando o AP está transmitindo pro cliente 2, mas o AP não vai entender o pacote todo e vai ignorar (Mas uma parte deve chegar, e ocupar ADC e cia), o cliente 1 vai ter que enviar de novo.

Na prática em PTMP você tem sucesso nuns locais e fracassos em outros usando TDMA, ou configurando pra um RTS e CTS de pacotes bem pequenos, porque uns chipsets ou softwares respondem de formas diferentes na parte de sincronia (Dados adjacentes aos dados legítimos do usuário, camadas mac e cia, layer2 e 3 especialmente, fora pacotes feitos especialmente pra ver se o AP ou cliente ainda está ligado, provar datarate pra saber se muda ou não (Se tem pacote legítimo ele pode colocar algo numa camada pra isso, se não ele tem que fazer pacote só pra isso). Também entra na estória as diferenças de posicionamento, como cada chipset trata os sinais que chegam por reflexo (Mesmo pra descartar precisa analisar primeiro, isso toma processamento).

Enfim, tem mesmo motivo pra uns serem felizes com TDMA e outros não, ou pra ser feliz forçando CTS/RTS ou não. Vai variar conforme chipsets, antenas, posicionamentos, sinais da vizinhança.

(Em PTP com radome realmente é difícil TDMA não melhorar alguma coisa)

[dioney29]

Ruído em -91dBm não é o fim do mundo.

O que eu acho o fim do mundo é sinal baixo tipo -76dBm usando datarate alto tipo MCS12.

Acho insuficiente tanto pelo SNR, como pela margem entre sinal e sensibilidade.

Se o SNR decente pra MCS12 em 5GHz é 26dBm:
Anexo 59418
Então teriamos -91 + 26 = -65dBm como sinal mínimo. Poderia padronizar como meta -55 a -65dBm

Se a margem de sinal adequada é de 20dBm, e a sensibilidade de MCS12 nos Rocket é de uns -85dBm (-84 a -86, não lembro bem, olhar no datasheet se precisar), -85 + 20 = -65dBm. Wow, caiu denovo em -65dBm como sinal mínimo pra ter rede adequada.

Sobre o datarate, você marcou MCS12 como TX maximo, mas com a caixa "automatic" marcada o radio ainda troca dados com datarates menos, tem uns TX Rates em MCS11 no status (52M é rate de MCS11).

E nos clientes a coisa tá feia, tem RX Rate de 19,5M, que é MCS2, você tem Airgrid aí? Só assim pra justificar ter um datarate de single polarization. Outros estão em 26M, 39M, 52M, ou até 78M. Se tem upload baixo tipo 1 a 2Mbps, porque usar nos clientes um TX rate tão alto tipo 52 ou 78M? O problema desses datarate como vimos acima é que exige sinais muito altos, tipo -65dBm a -55dBm.

Testa o seguinte: Configura a torre 1 vez na vida e não meche mais, usa somente MCS12 (Desmarca o "automatic" senão vai usar de MCS0 a MCS12). Configura uma potencia tipo 20dBm mas desmarca a caixa "auto adjust to EIRP limit" senão o radio sempre vai levar a potencia até o limite EIRP (Em 5,7 a 5,8GHz é 36dBm EIRP, como você não informou o ganho da antena ele está entendendo que tem ao menos um dipolo simples de 3dBi, ele está usando a maxima potencia que o datarate permite).
E também marque um ack-timeout fixo, de acordo com último cliente. Se o cliente mais distante está a 4,5Km, marque o ack-timeot de uns 5Km, cerca de 10% acima do real.

Já nos clientes você usa cada um com uma config., e altera conforme a zona de fresnel muda (Arvores crescem, construções aparecem na frente).
Nos clientes use MCS9 como Max TX Rate (Desmarcando a caixa automatic), com MCS9 você poderá chegar na torre com sinal -70dBm (Torre > Cliente = -65dBm, Cliente > Torre > -70dBm). Como ack-timeout seleciona uma distancia 10 a 20% maior que o real (Desmarque a caixa automatic senão não adianta ajustar nada). Se a zona de fresnel está ruim use 20%. Se a zona de fresnel está 200% limpa pode usar o ack-timeout correto/exato e MCS10.
E ajuste a potencia no cliente de modo que o sinal dele chegando na torre fique entre -60 e -70dBm, o ajuste de potencia serve pra isso (Mas lembra, "auto adjust to EIRP limit" impede seleção manual de potencia).

Se não dá pra se livrar do ruído, conviva com ele, e o jeito de fazer isso é com datarates baixos cliente > Torre, com ack-timeout maior que o real, e melhorando a zona de fresnel entre torre e cliente, como tem tanto sinal em -75dBm imagino que tenha esse problema, CPE's baixas demais (E zona de fresnel parcial derruba sinal).

Se o Rocket está a 20dBm, e tem setorial de 16dBi, tem 36dBm EIRP (Limite legal de 5,8gHz, tá bom assim), em 1Km o sinal cai 108dBm, 36 - 108 = -72dBm no ar, se tem a 1Km um cliente com Nanostation Loco M5 com antena de 13dBi, são 13dBm a mais de sinal (Ganho aumenta sinal), -72 + 13 = -59dBm, sinal pra lá de suficiente. Já se o NS Loco M5 transmitir em 23dBm, que é a potencia maxima em MCS9 nele, somando a antena de 13dBi isso dá 36dBm EIRP, vai chegar -72dBm no ar a 1Km, e a setorial de 16dBi vai passar isso de -72 pra -56dBm, que é sinal muito alto. Pra reduzir pra -60dBm você precisa baixar 4dBm na potencia do NS Loco M5, ou seja, baixar de 23 pra 19dBm no rádio.

E assim você ajusta cada cliente pra quem ele compartilhe o mesmo tempo do Rocket, sem ninguém gritando (Sem sinal absurdo tipo -50 e outro a -75dBm), cada cliente com config. diferente afinal cada cliente está numa distancia diferente (E pode ter zona de fresnel com percentual diferente livre de obstaculos. Essa queda de sinal de 108dBm em 1Km que citei é com a zona de fresnel totalmente limpa, linha de visada 3m acima de qualquer obstaculo, já se for apenas 1m acima dos obstaculos isso dá zona de fresnel apenas 60% limpa, o sinal cai 10dBm a mais, o sinal cairia de -59 pra -69dBm, que é sinal insuficiente pra conexão DE QUALIDADE usando MCS12. Convenhamos que 2m de tubo de aço a mais na hora da instalação não são nada no custo de um provedor, custa R$ 15 a mais mas se o cliente paga R$ 50 por mes esse custo não é nada, zona de fresnel limpa é bem possível, e ela faz muuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuita diferença na qualidade da rede (Especialmente nos níveis de sinal).

Eu resumiria todo seu problema a sinais baixos, não a ruído (Até porque ruído comum é -96dBm, se aplicar SNR de 26dBm isso significaria sinal de -70dBm pra MCS12, mas você tem cliente com -75dBm se sinal, insuficiente de qualquer forma).

fico encantado com o conhecimento que esse cara tem!queria eu ter 15% do conhecimento seu rubem!mesmo trabalhando com radio transmissão a anos,sempre aprendo um pouco com seus comentarios!muito obrigado por compartilhar conosco seu conhecimento!