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

[viaradio]

Boa noite Galera! POR FAVOR, estou com problema de interferência nos meus painéis que distribui para os clientes tenho uma mikrotik esta tudo Ok! tenho uma Rocket não esta legal mudei vários canais, passei aquele air View no expectro peguei canal com menos ruido mais de nada adianta, quando mudo de canal melhora um pouco, estava passando 4mb mudei canal agora esta passando 12mb, isso eu derrubando todos clientes e conectando somente 1 cliente para teste, para não dizer que é algum cliente prejudicando, estou sem opções, por favor,

Painel Base station 90º+rocket m5

Obs: Já tentei trocar os cabos fonte e painel e rocket fica tudo na mesma.

[rubem]

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:

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).

[Nielsen]

Melhore esses sinais.
Que banda vc entrega com estes sinais ?

[1929]

Rubem, só uma dúvida, quando por ex fixa o MCS4 no AP e no cliente fixa em MCS1 por exemplo, o AP vai transmitir num data rates mais alto mas a CPE está configurada para o MCS1 e daí ela não vai dar uma segurada para absorver este mcs4?
Nunca vi nos firmwares mas eu imagino que se fosse possível configurar TX e RX diferentes na station não teria melhor resultado ainda?

[viaradio]

Bom dia Rubem, vou aplicar estas mudancas esta madruga nos MCS e apos isso verificar os clientes com sinal ruim para abrir chamado, acredito que entendi bem esta parte, nos clientes a maioria usa nano loko m5 mais tem uma meia duzia de airgride e nanobridge, de alguns clientes que migraram, pois vendemos somente nano loko m5, sera que [e interessante migrar estes clientes para nano loco.

Nossos planos atuais sao de 1mb 2mb e 4mb, mais cada vez os clientes querem o maximo de velocidade, no minimo estamos vendendo e 2mb.

desde ja agradeco muiiiittoo por colaborar para me ajudar, o quanto antes volto com resultado, tomara que satisfatorio amigos.

[rubem]

Rubem, só uma dúvida, quando por ex fixa o MCS4 no AP e no cliente fixa em MCS1 por exemplo, o AP vai transmitir num data rates mais alto mas a CPE está configurada para o MCS1 e daí ela não vai dar uma segurada para absorver este mcs4?
Nunca vi nos firmwares mas eu imagino que se fosse possível configurar TX e RX diferentes na station não teria melhor resultado ainda?

Toda a transação ao redor do envio de um pacote torre>cliente é feito em MCS4 se setar assim.

Se o datarate é fixo há algo tipo um request-to-send em MCS4, o cliente manda um clear-to-send em MCS4, e há mais pre-estabelecimentos de comunicação feitos por ambos os lados em MCS4 afinal quem requisitou essa troca de dados foi a torre.

Se o datarate, potencia ou ack-timeout é automatico a maioria dos firmwares manda um tipo de packet-probe que ajuda na analise de qualidade pra definir se vai aumentar ou reduzir algo, são nanosegundos gastos com essas trocas.

Esse pacote hipotético é um pacote TCP/IP comum, ele saiu do linux no AP da torre e ele precisa um checksum (Ou algo do tipo), esse ckecksum que o linux da CPE precisa enviar já é outro pacote, ele será iniciado pelo linux da CPE, a wlan da CPE vai fazer automaticamente a transação, se ela está configurada pra MCS1 tudo ao redor desse mísero checksum ou simples "OK" pro pacote anterior será feito em MCS1 pelos 2 lados.

No fim das contas todo o download é feito em MCS4, e todo o upload é feito em MCS1. As respostas de pacotes que são resposta SO <> SO são feitas como se fosse download ou upload, elas é que tomam muito tempo de conexão, as respostas pra estabelecer comunicação não perdem quase nada de tempo, são poucos nanosegundos.
(Por isso nunca sugiro algo agressivo tipo -70dBm pra MCS15, em PTP isola até dá as vezes, mas em PTMP isso ia gerar muita perda de pacote nesse ato de responder cada conexão estabelecida)


Que teria muita vantagem em usar um datarate lindo tipo MCS15 nos 2 lados isso teria!
Tudo fixo em MCS15 seria perfeito, rede perfeita igual rede cabeada.
Mas olha o nível de sinal e de limpeza da zona de fresnel que ia precisar!

Em ambiente poluído o SNR necessário pode ser esse absurdo aqui:



Segundo o livro isso é pra ser analise do SNR em cada pacote, e abaixo uma aferição chamada "efetiva" de SNR levando em conta não o ruído geral no ambiente mas sim o que tem potencial pra atrapalhar o sinal depois do conversor analogico>digital (Que dizer, um transmissor FM a 100MHz, com harmonicas a 100, 200, 400, 800MHz, 1600 e 3200MHz, não deve incomodar, o ADC não vai converter isso).

O problema é: Você vê um ruído indicado em -96dBm, mas o PTP passa pouca banda. Você troca de canal, noutro canal onde também é exibido -96dBm de ruído, mas o PTP fica bom. Analisa bem, e o que tem no canal antigo? Um monte de SSID. Oras, mas SSID não é ruído, canal ocupado com outros sinais não é ruído, então apenas levar em conta o SNR não adianta, e ter um método supostamente "efetivo" ajuda menos ainda, SE usassem um método de SNR por pacote a gente veria ruído variando ora em -80, ora em -116dBm, talvez confundiria uns usuários, mas seria mais realista, perturbação não é um chiado de fundo, é o uso do canal com outros dados, esse uso varia mesmo, hora tem mais pacotes ou menos pacotes sendo trocados na vizinhança.

Ó uma suposta tomada em tempo-real do SNR:



Então como não dá pra confiar em SNR (Ou melhor, dá pra confiar, mas dá muuuuuuito trabalho, alterando datarate toda hora, exigiria muito processamento), nem em RSSI (Uma melhoria do SNR), os sistema de escolha de datarate nos chipsets não leva em conta isso, mas sim são sistemas baseados em perdas de pacotes.
São tipo auto rate fallback (Velho), adaptative auto rate fallback (Mais conservador nas tentativas de subir datarate), e um sistema de auto-rate baseado no receptor, onde o receptor informa AUMENTANDO/FUÇANDO no pacote original acrescentando dados sobre a qualidade da conexão anterior, e um algoritmo de adaptação de rate que é pra ser robusto, RRAA, que anda sendo muito usado.
Nesse algoritmo há o uso ou não de RTS/CTS (Conforme necessidade), há o uso de estimativa de perda futura (Já envia 2x antes mesmo do cliente avisar que não recebeu pacote, porque notou alteração em ruído, e... sabe que o ruído na torre pode ser de outra fonte com relação ao ruído no cliente!), e o melhor, ele usa apenas 1 frame pra fazer o packet probe a cada conexão, ele não manda um packet probe embutido ou a cada troca de dados. A princípio se suspeita que o algoritmo "Alternative" da UBNT seja esse.
(Enquanto o uso de AMPDU na MK diz que ela usa o sistema de auto-rate baseado no receptor, agregando dados no MPDU)

Esse algoritmos de tomadas de decisões são tudo software, o software diz o que vai pra camada mac e o hardware da wlan (phy) transmite e dá um feedback pro software informando tempo de respostas ou algo assim. O problema é que o software usa processamento pra pegar esse dado, analisar estimativa de perdas futuras e definir se vai ou não trocar o datarate. Quando o chipset está sobrecarregado ele fica lerdo nisso (Está compartilhando CPU com outros funções) e gera CCQ baixo e cia porque não está conseguindo analisar e trocar rates de forma rápida ou bem pensada (O software faz burrice porque o hardware fica lerdo).

Alias, tem mais uma hoje, como é sabido que muito hardware vagabundo é usado como AP em PtMP, e hardware vagabundo as vezes perde pacote porque a CPU está sobrecarregada, existe o modo de operação que CASO haja perda de pacote o próximo pacote só é enviado depois de um RTS respondido com um CTS. A intenção é: Se perdeu pacote é porque a CPU está lotada, pra não perder transmissão denovo vamos primeiro perguntar se podemos transmitir. Se esse pacote (Depois do RTS e CTS) for ok, aí os próximos pacotes são transmitidos sem RTS/CTS (Até que se perca algum denovo), o problema desse modo inteligente é: Ao invez de reduzir o datarate, o sistema insiste em datarate alto porque não sabe se a perda do pacote foi por sinal baixo ou por CPU hiperlotada, mas... sabemos que o ruído varia (SNR idem), algo comum é 1 pacote com RTS/CTS, 1 sem e perdido, 1 com RTS/CTS, 1 sem e perdido, e assim vai. Situação em que praticamente só há troca segura usando RTS/CTS. Como o pacote com RTS/CTS não é perdido nunca (Porque a contraparte da comunicação para a outras trocas de dados pra ouvir só 1 cliente) o software não experimenta baixar o datarate (Pra algum que tenha SNR melhor, e não precise RTS/CTS).

(Acho que você já deve ter testado um RTS threshold baixo, pra que quase todo pacote passe pelo processo de pedido e autorização, as vezes funciona e ajuda, mas as vezes só consome mais processamento e o resultado prático é zero (Onde não há colisão não há motivo pra implantar algo pra evitar colisão, por isso não uso colete-a-prova-de-balas nem antivirus, são proteções pra problemas que eu não tenho))

Pode parecer bobeira um algoritmo ser enganado por perda de dados, mas não podemos ver por esse lado, temos que ver a complexidade de produzir um algoritmo inteligente o suficiente pra saber diferenciar quando o pacote foi perdido por SNR baixo, quando foi por CPU lerda, quando foi por colisão, etc.
Antigamente em tempos de 802.11a o algoritmo era burro de fazer isso:


O BER é o bit error rate, 10 elevado a -4 é 4 zeros com um 10 depois, ou 0,00010, ou 0,0001%, ou 1 erro a cada 1000.
10^-5 seria um zero a mais, 1 erro a cada 10 mil.

Qual o problema disso pra chamar de algoritmo burro? O problema é que o erro JÁ OCORREU! O algoritmo não viu que o SNR era de só 10dBm? Não viu, ele esperou ter X erros pra depois perceber que era um rate ruim e então trocar.

Hoje temos algo muito melhor, que "prevê" erros.

E essa melhoria não depende do "querer fazer", mas sim do conseguir. Nunca mechi com programação porque não consigo esquematizar algoritmos (Ou falta paciência pra praticar), mas sei das dificuldades de um algoritmo que leve em conta um contador de frames perdidos, um analisador de qualidade de link (SNR, nível de sinal), um analisador de throughput necessário (E esse existe, muito ptp e ptmp cai pra 6M quando não tem tráfego, o problema disso é a demora pra "subir" o datarate quando aparecer tráfego), a coisa boba tipo "Se o índice de erros está baixo pode subir o datarate" não é suficiente, porque trafegando pacotes de 30 bytes (status de rede apenas) você tem uma taxa de ocupação do espectro, hora que passa pra pacotes de 1500 bytes (navegação/download) a ocupação aumenta, se usar um algoritmo bobo o datarate vai ficar variando.


Enfim, o problema não é ser automático, o problema é o tempo perdido na definição de QUAL rate, potencia ou ack usar. Em ambiente urbano o problema são as outras redes wifi, hora que outra rede está parada o canal fica mais limpo e você pode subir o datarate, mas hora que outra rede começar a trocar dados aos montes o seu PTMP teria que reduzir o datarate pra perder menos pacotes (Senão vai ter que ficar reenviando pacotes, aumenta o ping ou diminui o throughput se não diminuir o datarate), mas essa troca automática é lerda, e... essa mudança na ocupação dos canais ou o ruído não ocorre 3x ao dia, ela ocorre 3x por segundo e as vezes 3x por minuto, pro AP fazer uma troca rápida ele precisaria sair disparando packets probe pra todo lado, pra todos os clientes responderem e ele então definir a troca do datarate, mas isso consome muito processamento (Que um AP com 40 clientes não tem).

O resumo da coisa é estar preparado pra eventuais ruídos e ocupações alheias de canal. Um datarate baixo e fixo, com margem de sinal decente, e SNR decente, permite isso, ping constante (Sem jitter), com todos os clientes equalizados, sem variação de throughput conforme a hora do dia (Mais gente usando wifi de dia que de madrugada).

Os padrões 802.11 da IEEE não padronizam algoritmo desse tipo, cada fabricante usa um, as vezes pode ocorrer de 2 AP's tomarem a MESMA decisão e ficarem se acotovelando por canais, então nem a troca automática de canais me agrada, até porque um canal pode estar com ruído nos clientes, mas estar limpo na torre, quem manda é a torre então pode ter rede ruim por bobeira.

Sobre ack-time e SNR, também entra a questão da visada e zona de fresnel, nenhum algoritmo consegue ver qualidade da conexão física, eles olham nível de sinal, e numa zona de fresnel parcial a reflexão varia o tempo todo, varia 3x por segundo igual ruído ou SNR, um pacote curto (Uma rajada curta) vibra o elemento da antena por X picosegundos e para, mas um pacote longo (Grande) ressona ela por mais tempo de modo que altera em 1º pra baixo a emissão, porque antena multi-elemento é comum e se o sinal chegar levemente atrasado nos elemetos de cima a irradiação desse elemento cria uma quase contra-fase que empura o lóbulo de irradiação pra baixo, existe mais chance de pacote grande refletir com ganho maior, fora que pacote grande ficar em transmissão e recepção por um período de tempo maior, nesse tempo o ruído pode aumentar 10dBm "do nada" (E por ruído entenda ocupação do canal por outro AP, não entra no noise floor mas é sinal que atrapalha o desempenho da etapa de RF, é mais dado pro ADC converter).

Alias, tema que quero ler faz tempo é sobre as alterações na velocidade das ondas conforme o ambiente. Diz a física que RF só viaja na velocidade da luz no vácuo, e conforme o material há uma queda na velocidade. Falando em luz visível, sei que em diamante a velocidade é praticamente 1/3 da velocidade no vácuo (300 mil Km/s), sei que existe atenuação de RF por chuva, umidade, temperatura, mas preciso ler sobre a possivel diminuição da velocidade em sí, algum tipo de refração deve existir, mas se a luz visível chega a perder 60% da velocidade, já pensou se RF tem alterações tipo 1% na velocidade? 1% de diferença pode perfeitamente cria uma perda de pacote em wifi, porque os tempos precisam ser bem precisos pro ADC separar direito (Wifi sofre muito com efeito doppler, isso se sabe). Se uma nuvem de poeira passando atras da torre atrapalha os clientes pra aquele lado, mas não os pro outro lado, isso só geraria ainda mais processamento pra CPU desse AP numa omni, ia ter bit error rate diferente conforme o lado, e nenhum algoritmo tem como descobrir que tipo de antena está em uso, um equipto que faz beamforming sim, mas beamforming anda cada vez mais esquisito na prática, MIMO tipo 2x3 ou 2x6 parece mais fácil de implantar do que beamforming, parece que precisa muito mais processamento pro mesmo resultado (throughput). Um sistema de beamforming sim ia poder usar um datarate por cliente de forma inteligente, mas os equiptos que fazem isso andam "um pouco caros".

(E quem mais financia o mercado me parece que é o comprado de roteador de mesa midle-end, roteador de R$ 150 a 500, que atendem usuários de poucos dispositivos mas que querem muita banda, por isso tanto AP vem por default com canal de 40MHz (E vai pra MCS7 mesmo que conecte um celular com sinal -80dBm!))

Pra mim que a UBNT tem algoritmos diferentes nos Rocket e nos Picostation (Unifi não pude usar mecher quase nada), acho que estão no caminho certo, WISP precisa outro tipo de approach na seleção de rates, precisa modo de seleção 100% diferente de conexão com dispositivo mobile. Infelizmente parece que gastam muito com modos proprietários (TDMA) ao invez de fazer como Cisco ou Arruba e focar $$$ totalmente em algoritmos cada vez mais inteligentes pra essas seleções, porque elas ainda são bem burrinhas, é fácil ver CCQ de 95-98% em ptmp com tudo automático, com throughput médio tipo 10Mbps por cliente, sendo que fixando tudo em datarate baixo o CCQ fixa em 100%, o throughput médio fica nos mesmos 10Mbps, mas o jitter nos pings some, porque o algoritmo não vai pelo "rate necessário", mas sim pelo "maior rate possível, pra enganar os trouxas que só olham pra rates nominais".

[maisonmdsgreen]

Rubens so uma pergunta para PTP seria o mesmo caso o TX do ap download e o TX do Station Upload? No PTP recomenda usar no AP MCS alto e no Station Baixo? Ou os dois nivelados?

[rubem]

Pra PTP geralmente o equipto é igual nos 2 lados, dá pra usar mesmos datarates (Eu sempre uso).

Se fosse um PTP com equipto diferente (Rocket num lado, NS Loco no outro) talvez precise datarates diferentes pra ter CCQ em 100%.

[FabianoMartins2]

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:

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).

rubem, parabéns pela "aula", foi muito bem explicado. Uma pergunta: no caso de usar MCS, ACK Timeout manual e auto adjust to EIRP limit (automatic desmarcado), como fica a questão da potencia ? Exemplo, pelo datasheet do Nano Loco M5, MCS6 = 18dbm de potencia, o correto seria setar 18dbm de potencia independente da distancia, ou é melhor ajustar conforme a necessidade ?

Detalhe, usei MCS6 porque a minha rede é MISO, MIMO no transmissão e MIMO/SISO nos clientes. Tenho varios c/ airgrid.

Abraço.

[SuporteClinitec]

Tive um problema parecido com o seu, tinha um AP com os mesmos níveis de sinais do seu, porem latência alta, as conexões caindo direto, eu estava operando com canal limpo, porém o meu problema era um PTP que estava a 20 centímetros da minha basestation,e com trafego alto, ela estava em um canal bem distante do meu Ap, porem ele estava gerando auto interferência na minha torre justamente por esta muito próximo, só foi eu afastar ele e vualá, acabou as quedas, latência alta, tudo certo. então além de você verificar interferências externas, clientes com sinal baixo, tem que ver seus equipamentos na torres, se estão próximos de mais, eles tem que ter no minimo 1 metro de afastamento um do outro, da uma olhada nesta questão amigo.

[rubem]

rubem, parabéns pela "aula", foi muito bem explicado. Uma pergunta: no caso de usar MCS, ACK Timeout manual e auto adjust to EIRP limit (automatic desmarcado), como fica a questão da potencia ? Exemplo, pelo datasheet do Nano Loco M5, MCS6 = 18dbm de potencia, o correto seria setar 18dbm de potencia independente da distancia, ou é melhor ajustar conforme a necessidade ?

Detalhe, usei MCS6 porque a minha rede é MISO, MIMO no transmissão e MIMO/SISO nos clientes. Tenho varios c/ airgrid.

Abraço.

Quando você marca o "auto adjust to EIRP limit" o software eleva a potencia até o limite legal. Conforme o país selecionado ele varia, mas no mundo civilizado é algo tipo uns 20dBm EIRP de 5,1 a 5,3GHz, 27dBm EIRP de 5,4 a 5,7GHz, e 36dBm EIRP de 5,7 a 5,8GHz.

Onde você pode informar qualquer valor de antena você pode tapear essa medida, afinal a legislação fala em valor EIRP, e valor EIRP soma potencia de radio com ganho de antena. Muito noob seta 0dBi pra tentar tapear e vendo números diferentes acha que isso não funciona. Mas um sistema operacional pobre e simplório como o AirOS é mais inteligente que os noobs, o SO sabe que todo equipto UBNT tem um dipolo de emissão com 2 ou 3dBi de ganho, então mesmo que coloque 0dBi em equipto com antena interna ele sabe que isso é impossível e usa um mínimo de 3dBi (Se o limite legal for 20dBm EIRP ele vai então usar potencia de emissão no radio de 17dBm, afinal 17 + 3 = 20).

Desmarcando o "auto adjust to EIRP limit", ainda existe regulamentação, na aba advanced se não me engano. Se o software tem ganho de antena fixo em digamos 13dBi (E você não pode alterar isso), você pode selecionar 24dBm de potencia mas se usar 5,4GHz o firmware não é burro e respeitará o limite legal de 27dBm EIRP, ou seja, 27 - 13 = 14dBm, é nessa potencia que vai ficar (Setando 18, 20 ou 24dBm no radio).

O espectro está uma lixo e os fabricantes sabem que isso é culpa dos noobs que resolvem fuçar nisso sem ler antes, então a maioria dos firmwares respeita os limites legais sem ficar exibindo ou limitando tudo, noob é fácil de enganar se ele ACHAR que está com potencia alta (Porque ele não sabe como verificar isso, infelizmente com os malditos sons automotivos dá pra verificar e os idiotas tem as porcarias mais barulhentas, mas com RF os leigos não verificam nada (Legislação e limites legais) e fodem o espectro então o jeito de minimizar isso é não transparecer no firmware que há um limite sendo excedido (O que não ia adiantar nada, afinal leigo é egoísta, quer o espectro todo pra ele e quer é a potencia mais alta do mundo pra compensar a incompetência nas instalações).

Quando a ack-timeout e datarate (MCS), isso não tem relação com potencia.
Quanto maior o MCS menor a potencia que o radio CONSEGUE usar, isso é outra estória, não tem relação com limite legal. No caso dos NS Loco (E de todo equipto UBNT) há um amplificador de saída, esse amplificador assim como o chipset tem limitações de desempenho quando usa potencia alta, então o software limita a potencia e isso não tem como tapear (SE precisa mais potencia compre outra CPE, NS Loco é o mais barato porque tem limitações).

Se você setar MCS6 e 5,8GHz, onde o limite legal é 36dBm EIRP, o radio vai ficar no máximo que consegue em MCS6 que é 18dBm, afinal juntando com os 13dBi da antena você tem 18 + 13 = 31dBm EIRP.
Se baixar pra MCS4 a potencia subirá pro máximo que o radio consegue, 21dBm, aí terá 21 + 13 = 34dBm EIRP

Mas se usar 5,6GHz ele vai respeitar o limite legal de 27dBm EIRP, a antena não muda de ganho nunca, tem 13dBi, então 27 - 13 = 14dBm, como TODOS os datarates tem potencia maior que isso, independente do datarate, independente de ser 20 ou 40MHz, independente do que você selecione como potencia acima disso, ele vai operar com o radio a 14dBm.

Digo que AirOS é um sistema com setup pra senhorinha analfabeta porque não permite por exemplo selecionar 1 datarate pra polarização simples (Pra se comunicar com os Airgrid, digamos), e 1 datarate pra polarização dupla pra se comunicar com NS Loco, NS, SXT, NanoBeam, PowerBeam, PowerBridge, etc.

RouterOS permite, você marca MCS4 e MCS12 e pronto, quem tem DP se comunicará com MCS12, e quem tem pol. simples se comunicará com MCS4 (Ou quem tem DP mas está com sinal ruim demais por instalação porca ou porque apareceu algo na frente).
MCS4 e MCS12 são a mesma coisa, a mesma modulação, mas um tem só 1 chain, e o outro tem 2 chains em uso. 2 MCS4 formam um MCS12, simples assim.

(Em UBNT você tem que marca o Max TX Rate em MCS12, deixar a caixa automatic marcada, e aí sim DP e pol. simples conectam, o problema é que os equiptos de pol. simples costumam ser burros de usar MCS7 (O maior datarate, que exige sinal maior senão a conexão vira um lixo) mesmo que tenham sinal ridículo de ruim tipo -70dBm)

[FabianoMartins2]

@rubem, entendi, valeu pela explicação. Até aqui falamos de antenas que podemos tratar como "antenas clientes", e se falarmos do Rocket M5 por exemplo, ele não tem antena! Nesse caso se deixar desmarcado o "auto adjust to EIRP limit", realmente não haverá nenhum outro controle ou ainda assim pode ter limitações ?

Exemplo básico é a Base Station 5G20-90 + Rocket M5. Essa base tem 20dbi de ganho e se usar canal acima de 5,7GHz e dessa vez deixar marcado a opção "auto adjust to EIRP limit", assim pode chegar numa soma de 36dbm, usando até 16dbm de potencia, correto ?

Abraço.

[rubem]

No caso do Rocket, de de algumas versões do Airos em Airgrid e nanostation, você informa qualquer valor de antena.

Se você informar que a antena é de 20dBi (Sendo ela desse ganho ou não, o que importa é o que você disse pro firmware), e o firmware sabe o que limite legal em 5735MHz é de 36dBm EIRP, ele vai limitar a potencia do radio a 16dBm se você marcar digamos 25dBm de potencia. Se você marcar 15dBm de potencia ele vai subir pra 16dBm igual porque a função faz o "ajuste PARA/ATÉ o limite EIRP". Essa função não limita abaixo disso, ela sobe a potencia também.

Já se for em 5700MHz, onde o limite legal é 27dBm EIRP, o radio vai operar a 7dBm.

Já se a antena for de 20dBi, mas você informar que tem uma de 10dBi, ele vai colocar o radio pra trabalhar a 26 e 17dBm respectivamente (Pra ficar a 36 e 27dBm EIRP).

Na prática o valor da antena informado vai de 3 a 40dBi, se marcar 0dBi ele sabe que qualquer dipolinho de nada dá pelo menos 2,4dBi então ele usa 3dBi como o mínimo na conta. Não tem como ser zero porque antena comercial não tem 0dBi de ganho.

Se você deixar em branco o campo antena, o radio vai entender que tem uma antena mínima de 3dBi, e vai mandar potencia limitada a 24dBm (5,4 a 5,7GHz), e no máximo 30dBm de 5,7 a 5,8GHz.

(Nenhum radio vai a 33dBm porque há tanto na resolução brasileiro ( http://www.anatel.gov.br/legislacao/...-resolucao-506 ) como na maior parte do mundo o limite de potencia de radio de 1W (30dBm), mas o limite EIRP pode ser 36dBm (De 5,7 a 5,8GHz))

Uma coisa é a antena real instalada, outra é o ganho que você DIZ pro firmware que a antena tem. O firmware acredita em você, e baseia o limite EIRP no que você disse que a antena tem.

TALVEZ algum firmware seja inteligente a ponto de perceber falcatrua quando se comunicar com CPE cliente de ganho conhecido. A CPE Ns Loco M5 tem ganho fixo (Não tem como plugar antena externa), se o sinal dela chegar em digamos -60dBm, e o ack-timeout dialogado foi de uns 25us, tá na cara que a antena no Rocket não tem 3dBi de ganho (Se você deixou em 0) mas sim uns 15dBi, o calculo por distancia é matematica simples, um firmware poderia fazer isso se quisesse (Num PTP talvez. Mas em PTMP teria muita conexão pra pouco processadores gerenciar).

O firmware respeita o limite legal conforme o país que você preencher, e conforme o ganho de antena que você preencher. Ele não consegue descobrir se está no país certo ou se a antena tem o ganho informado, o firmware acredita em você.

Muita gente muda país pra tentar usar outros canais, mas por bobeira/anaçfabetismo não lêem a legislação desses países, e trabalham com potencia baixa igual. A maioria dos países do mundo tem limite parecido, 20 / 27 e 36dBm EIRP em 5,1-5,3 / 5,4-5,7 e 5,7-5,8GHz, o brasil é grande mas tem algumas coisas do tamanho de ervilhas no mundo onde com 1W se atravessa o país todo, há consenso meio que mundial sobre os limites.

(No caso de 5,4 a 5,7GHz, há comunicação marítima nessa faixa, navios de grande porte dependem disso então eles tem prioridade e você precisa usar DFS nessa faixa, sistema de radar internacional e sistema marítimos são muitos mais importante que vender internet pro povão acessar o facebook em casa, então tem que limitar potencia e usar DFS. 5,1 a 5,3GHz é limitado em potencia e uso outdoor porque pega em cheio a primeira harmonica (Dobro! Uma oitava é o dobro da frequencia) de rede "4G" LTE de 2600MHz em uso no brasil. LTE alcança mais usuário e em distancia maior então que se dane quem usa 5,1 a 5,3GHz, que fiquem com potencia baixa e em ambiente indoor, LTE é mais importante. Esses são os motivos pra 5,1 5,7GHz terem potencia limitada e necessidades tipo DFS ou a proibição de uso outdoor pra 5,1-5,3GHz)

[FabianoMartins2]

@rubem, Ok! novamente tudo muito bem explicado, fácil de entender. Só p/ finalizar, eu já uso a um bom tempo Modulação MCS manual e Act Timeout também manual, mas tenho setores c/ tudo automático, mas tudo automático só em torre c/ sinal excelente e CCQ proximo a 100%. Falando dos setores c/ tudo manual (inclusive o "auto adjust to EIRP limit"), fico meio perdido c/ relação a potencia, porque já testei de todo jeito e me parece que alterando a potencia não muda em nada c/ relação aos clientes. Digo isso porque tenho casos de clientes a uma distancia de 2.4km, sinal de -61, tudo setado manual e mesmo assim o CCQ não firma, sempre fica entre 80% e 90%.

Tenho alguma ideia ou já passou por casos assim ?

Abraço.

[rubem]

Hum, quando tem sinal suficiente pro datarate escolhido (-61 é suficiente pra MCS4 ou MCS12 tranquilo, ou pra 36M em 802.11a) e o CCQ não sobe, dá pra desconfiar de ruído ou zona de fresnel criando problemas.

A primeira zona de fresnel (Ou 100% da zona de fresnel) de 5,6GHz em 2,4Km é de 5,7 metros, ter a linha de visada uns 3m acima dos obstaculos já tá bom demais.
Mas reflexo também ocorre na 2ª zona de fresnel, que passa de 5,7 pra 11,4m, ou na 3ª zona de fresnel a uns 22m, e por por aí vai.

Acho que nesses casos é bom mecher na antena do cliente, apontar 1 ou 2º pra cima, ver se o cabo não está enrolado em rede elétrica ou algo do tipo, ver se não tem uma calha de zinco enorme tipo 2m bem numa area na frente onde reflitiria sinal em cheio, bobeiras assim que geralmente não criam problema.

E tem o risco de naquele determinado cliente um canal ter ruído, um miniPTP "passando" pela vizinhança dele talvez, se mudando de canal esse cliente continuou ruim (Por isso cito anotar os clientes ruins, uma anotação de meses de sinal ruim pode mostrar que ciclano ao menos 1x por semana tem sinal ruim) então não deve ser esse o problema.

E se tem outro anteneiro, desconfia do entendimento de zona de fresnel dele, eu tive anteneiro com 6 anos de "experiência" que a cada poucos meses soltava um "Não tem nada na frente, só um galho de coqueiro e uns fios de um poste", foram 6 anos explicando que fio de alta tensão de 20mm fira um bolo com onda AC ao redor que na prática vira um obstaculo de 30 a 60cm, e que folha de arvore quando tem umidade atenua o mesmo que parede. Mas... na cabeça dele se era "pequeno" então não devia atrapalhar.

[FabianoMartins2]

@rubem veja os dois anexos, tirei de um único cliente, veja a diferença na Distancia e o CCQ.

[rubem]

Tá, saquei agora um detalhe bobo: Você está olhando o CCQ no cliente. Não precisa se preocupar com ele.

O que tem que cuidar muito é o CCQ no AP, o CCQ de RX desse cliente está como 98%, que tá bom.

Nunca procurei os detalhes mas é normal o CCQ no AP ficar algo tipo 95%, mas no setup do cliente aparecer 70 ou 80%. Pro AP isso não é uma conexão ruim, e seu foco deve ser no desempenho do AP porque ele se comunica com 40 clientes, se o AP tiver desempenho ruim todos os 40 terão conexão ruim.

A CPE do cliente só se comunica com 1 contraparte, ela pode sofrer, ela pode se esforçar e repetir pacote. Quem não pode ficar repetindo pacote é o AP porque repetir pacote perdido é gastar tempo que podia estar sendo gasto com conexão de outro cliente.

Você precisa muita banda? Ví que está em MCS7, de 65M. Se trafegar ao todo menos de uns 15Mbps teste o max tx rate em MCS4, nem que seja por uma madrugada (É mudar e salvar, todo mundo cai mas volta em segundos). Ele é uma modulação 16QAM que aceita melhor sinais nem tão altoa tipos -66dBm, acho que tem grandes da maioria dos CCQ's irem pra 98-99% se usar MCS12.

(Eu vejo pelo seguinte lado: MCS7 (65M) tem sensibilidade de uns 76dBm, se colocar uma margem de 20dBm o sinal recomendavel seria -56dBm. Esse cliente recebe hoje -66dBm, que é a margem minima pra manter conexão, provavelmente por isso o Airmax capacity está abaixo do mínimo (50%, no quadrinho vermelho). Mais fácil que fazer o sinal subir 10dBm é baixar pra um datarate que se dá bem com -66dBm, tipo MCS4 (Talvez MCS5, mas MCS5 é modulação 64AQAM, é muito mais ponto que 16QAM do MCS4, há uma diferença de 3 a 5dBm na sensibilidade entre MCS4 e MCS5 porque eles não muito diferentes mesmo, onde MCS5 funciona bem geralmente MCS7 também, então acho que só valeria a pena testar MCS4 logo de uma vez)

[FabianoMartins2]

Tá, saquei agora um detalhe bobo: Você está olhando o CCQ no cliente. Não precisa se preocupar com ele.

O que tem que cuidar muito é o CCQ no AP, o CCQ de RX desse cliente está como 98%, que tá bom.

Nunca procurei os detalhes mas é normal o CCQ no AP ficar algo tipo 95%, mas no setup do cliente aparecer 70 ou 80%. Pro AP isso não é uma conexão ruim, e seu foco deve ser no desempenho do AP porque ele se comunica com 40 clientes, se o AP tiver desempenho ruim todos os 40 terão conexão ruim.

A CPE do cliente só se comunica com 1 contraparte, ela pode sofrer, ela pode se esforçar e repetir pacote. Quem não pode ficar repetindo pacote é o AP porque repetir pacote perdido é gastar tempo que podia estar sendo gasto com conexão de outro cliente.

Você precisa muita banda? Ví que está em MCS7, de 65M. Se trafegar ao todo menos de uns 15Mbps teste o max tx rate em MCS4, nem que seja por uma madrugada (É mudar e salvar, todo mundo cai mas volta em segundos). Ele é uma modulação 16QAM que aceita melhor sinais nem tão altoa tipos -66dBm, acho que tem grandes da maioria dos CCQ's irem pra 98-99% se usar MCS12.

(Eu vejo pelo seguinte lado: MCS7 (65M) tem sensibilidade de uns 76dBm, se colocar uma margem de 20dBm o sinal recomendavel seria -56dBm. Esse cliente recebe hoje -66dBm, que é a margem minima pra manter conexão, provavelmente por isso o Airmax capacity está abaixo do mínimo (50%, no quadrinho vermelho). Mais fácil que fazer o sinal subir 10dBm é baixar pra um datarate que se dá bem com -66dBm, tipo MCS4 (Talvez MCS5, mas MCS5 é modulação 64AQAM, é muito mais ponto que 16QAM do MCS4, há uma diferença de 3 a 5dBm na sensibilidade entre MCS4 e MCS5 porque eles não muito diferentes mesmo, onde MCS5 funciona bem geralmente MCS7 também, então acho que só valeria a pena testar MCS4 logo de uma vez)

Poisé @rubem, esse setor está todo setado no automático agora. Tanto modulação quanto o ACK TimeOut. Se eu mudar p/ MCS manual (MCS4 pra testar), somente no AP já vai servir como teste, ou terei que alterar nos clientes também ?

Abraço.

[rubem]

Se vai mudar só um lado, é melhor mudar todos os clientes (Pra MCS2 digamos) do que mudar só da torre.

Mas mudar só o da torre pra MCS4 não é difícil testar, muda, todos caem e voltam em poucos segundos.

Ack timeout fixo não é urgente, nem é tão necessário, é mais pra quem quer otimizar todo o possível, mas colocar em cada cliente um max tx rate baixo (Sugiro MCS2) acho bem urgente.

[FabianoMartins2]

Se vai mudar só um lado, é melhor mudar todos os clientes (Pra MCS2 digamos) do que mudar só da torre.

Mas mudar só o da torre pra MCS4 não é difícil testar, muda, todos caem e voltam em poucos segundos.

Ack timeout fixo não é urgente, nem é tão necessário, é mais pra quem quer otimizar todo o possível, mas colocar em cada cliente um max tx rate baixo (Sugiro MCS2) acho bem urgente.

Ok @rubem, vou testar essa madrugada e te falo o resultado, abraço e obrigado pela força.