#  > Telecomunicações >  > Redes >  >  Ajuste de MCS do MikroTik RouterOS

## rick

Olá Pessoal gostaria de saber se alguém sabe como eu acerto o mcs do mikrotik para que ele mantenha o CCQ mais proximo de -100% mantendo o radio com o sinal dentro do envelope determinado pelo radio???

----------


## mkre0

MCS 0

----------


## rick

mas... desculpe minha ignorancia rsrs. mas o que é precosi mara habilitar esta função?

----------


## mkre0

normalmente no radio do cliente.  :Hmmmm2:

----------


## emilidani

Entendo que se esta usando 802.11n , ele vai se ajustar automaticamente para obter o maior CCQ. Se trabalhar com a menor banda oferecida (alguns permitem 5mHz) com certeza estará na melhor condição para obter maior CCQ possivel. Será que estou equivocado?

----------


## brunobelas

se os 2 forem mikrotik tem sim

----------


## emilidani

Mais qual o motivo de sair ajustando o MSC para obter melhor CCQ se o equipamento faz isso automaticamente da forma mais conveniente?

----------


## rubem

O problema não é cair em MCS0 se deixar no modo auto, se cair no MCS0 é porque o sinal está ruim. O problema é subir pra MCS5 ou 6 mas o troughput ficar ridículo. 

Isso não ocorre só em modo N, você consegue conexão a 54M em G com sinal -65, mas vai ter troughput digamos 2Mbps, se baixar pra 18M no datarate a sensibilidade melhora, o nº de bits por simbolo diminui e tem menos perdas nas sub-portadoras, e o troughput sobe de 2 pra 12Mbps (Baixando o datarate, mudança que altera potencia e sensibilidade).

Se vai trafegar 2Mbps, pra quem usar MCS7? Esse MCS vai usar sempre todos os bits do simbolo, com muitos bits por simbolo a sensibilidade do hardware cai muuuuuuito (Vide ficha técnica dos aparelhos, a sensibilidade em MCS5 a 7 é péssima comparada em MCS0 ou 1), e o hardware e o software tem que processar todos os bits do simbolo pra "obter" os míseros 2Mbps. Porque não usar MCS0 nesse caso? Vai ter sensibilidade ótima, vai ter potencia maior, vai ter tempo de processamento menor, portanto as perdas de pacotes serão menores.

Eu testei MCS3 na torre, e nos clientes livre de MCS0 a 3, mas hoje penso em fixar nos cliente em MCS0. Porque? Porque em MCS0 cabe perfeitamente o upload do cliente e as respostas dos pacotes. MCS baixo no cliente tem vantagem? Tem, cria menos processamento pra torre. Tem desvantagem? Não permite upload alto, tipo não mais que 4Mbps. Quem aí vende conexão com mais de 4M de upload?

Você pode ter datarate diferente na torre e no cliente, quanto menor o datarate menor o trafego MAXIMO, mas também será menor o processamento, e em torre quando você quer muitos clientes num painel você tem que optar por modulações que exijam menos processamento. Usar por exemplo modo G pra PTP de 15M (Em 48-54M) é bobeira em hardware de hoje porque o processamento nesse modo é grande comparado a modo N em MCS3, que terá até mais que 15Mbps de troughput com tempos de respostas e perdas menores.

Largura de canal tem efeito menor ou similar a usar menos bits por simbolo, é mais interessante usar canal padrão (20MHz) com poucos bits por chip (MCS0 ou 1) do que usar gambiarra/despadronização tipo canal de 10MHz que terão muitos bits por simbolo igual, só terão menos sub-portadoras. Se há perda de subportadoras, independente de ter 20 ou 50 subportadoras, você perderá muito mais dados com 6 bits por símbolo (MCS7) do que com 1 bit por símbolo (MCS0). Onde o sinal não está bom você VAI perder subportadora, perder pacote grande piora mais o troughput do que perder pacote pequeno.

Mas o grande fator é:
MCS7 = Potencia baixa, sensibilidade ruim, varios clientes simultaneos usam mais processamento
MCS0 = Potencia alta, sensibilidade ótima, varios clientes simultaneos usam pouco processamento

Essa diferença *altera alcance* (Derivado da potencia e sensibilidade dos hardwares domesticos, e da sensibilidade em hardware de torre) e *altera nº maximo de clientes por painel* (MCS baixo exige menos processamento da etapa de RF, portanto permite mais clientes ou permite mais qualidade de conexão).

----------


## klabundee

A um bom tempo já implementamos MCS fixo no cliente e na torre, além de fixar sinal mínimo de -69 na torre.

Não posso reclamar.

----------


## gabrielest

> Mas o grande fator é:
> MCS7 = Potencia baixa, sensibilidade ruim, varios clientes simultaneos usam mais processamento
> MCS0 = Potencia alta, sensibilidade ótima, varios clientes simultaneos usam pouco processamento


O que me confunde um pouco no MK é que quando vc usa o NV2 em 40mhz (estou usando ele num PTP com duas SXT lite 5) vc tem vários MCS vão do 0 ao 23, ai fico meio perdido...

----------


## mkre0

Se eu tenho 25 clientes fixados MCS0 (6,5 Mbps) e meu upload liberado é de 2 Megas, se 3 clientes utilizarem todo seu upload eles ocupariam quase que 100% do rádio (0,3 segundos cada) ??? Como fica os outros 22 clientes iram ter uma navegação decente???

----------


## mkre0

Aqui eu uso MCS10 (81 Mbps) em cliente empresarial :|

----------


## rubem

> O que me confunde um pouco no MK é que quando vc usa o NV2 em 40mhz (estou usando ele num PTP com duas SXT lite 5) vc tem vários MCS vão do 0 ao 23, ai fico meio perdido...


Os esquemas MCS mudam o tipo de modulação, e nº de bits por simbolo.
MCS0 a 7 é o basico, canal de 20 ou de 40MHz, 1 a 6 bits por chip, com 4 tipos de quadratura de modulação.
MCS8 a 15 é o mesmo nº de bits por simbolo que MCS0 a 7, mesmas modulações, mas usa MIMO, seja 2x1 ou 2X2
MCS16 a 23 usa o mesmo nº de bits por símbolo que MCS0 a 7, mesmas modulações, mas usa 3 conexões (TriTro?), 3x1, 3x2 ou 3x3.

A sensibilidade do MCS16 será igual ou muito proxima ao MCS8 e MCS0. O nº de bits por símbolo e o tipo de modulação (Tipo de quadratura escolhida) muda se repetindo a cada 7 esquemas, só aumenta o troughput porque aumenta o numero de canais (chains) fazendo multiplas conexões. Ou seja, MCS8 é um MCS0 x2, MCS16 é um MCS0 x3, e por aí vai.

Veja que o nº do esquema não quer dizer troughput, MCS16 tem 20 ou 40M de datarate (Afinal é só 1 bit por chip, mesmo que seja 3x1), enquanto MCS15 tem 130 ou 270M, mesmo que seja 2x2 o que faz a diferença é a modulação usada e o que mais muda na modulação que é nº de bits por chip.

É só olhar sempre a tabela:
http://mcsindex.com/
(O tempo de trafego de pacotes uteis de 400 ou 800nS muda POUCO a coisa, o que mais influencia é a largura do canal e a modulação. Aumentar largura de canal não é solução eficiente, porque polui o espectro, exige muito mais processamento em caso de PtMP, e não permite muitos AP's proximos porque simplesmente não tem canal disponível no mundo, então o negócio é evoluir os tipos de modulação)

O padrão 802.11AC tem modos com modulação em 256QAM, graças a ele a numeração dos MCS fica zoneada, não confundir MCS de 802.11AC com o MCS padrão. Ignore AC por enquanto.




> Se eu tenho 25 clientes fixados MCS0 (6,5 Mbps) e meu upload liberado é de 2 Megas, se 3 clientes utilizarem todo seu upload eles ocupariam quase que 100% do rádio (0,3 segundos cada) ??? Como fica os outros 22 clientes iram ter uma navegação decente???


Por isso você não pode vender conexão com upload de 2M e fixar na torre MCS0. Se tem media de 20 clientes consumindo, com trafego tipo 6-7M, melhor fixar em MCS1.

Veja que MCS0 no cliente e MCS4 na torre é tranquilo, a codificação de um não obriga a do outro. Veja pelo seguinte lado: Torre em MCS4, vai mandar 4 bits por simbolo, e serão 16 simbolos porque são 16 fases de simbolo, isso popula mais o canal:
http://electronicdesign.com/site-fil...0956-fig-5.jpg
Mas você tem um throughput maior pra dividir entre os clientes, digamos 32-35Mbps.
MCS0 no cliente vai fazer CHEGAR na torre, ou melhor, no radio da torre, um monte de conexões com apenas 1 bit por símbolo, e apenas 2 simbolos, em 2 fases:
1ª figura, a de cima: http://electronicdesign.com/site-fil...0956-fig-4.jpg 
São menos dados pra processar, então o processamento consumirá menos hardware, haverá menos perdas também no processamento mas o principal: São só 2 fases, ou nível alto ou nível baixo (0 ou 1, apenas 1 bit), a chance disso distorcer a ponto de perder muitos pacotes é pequena, o SNR necessario pra MCS0 é uns 5dB menor que o SNR necessario em MCS4, e o melhor, por estar ocupando pouco tempo de processamento a etapa de RF terá mesmo a maior sensibilidade possível, ou seja, poderia ter SNR menor que funcionaria, mas com certeza terá SNR maior!

Em modo N esquece esse negocio de "6,5M dividido por X clientes", não é bem por aí em qualquer modulação. Como o beamforming "pergunta" por qualidade de conexão ele gasta banda grande em MCS4 pra isso, ele "para" as comunicações por muito tempo útil, por isso em PtMP você não consegue grandes coisas com MIMO e canal de 40MHz, o tempo gasto sem trafegar pacote útil é grande (Quanto mais clientes, mais tempo), diferente de um PTP, em que datarate mais alto é mais eficiente afinal so tem 1 contraparte pra trocar dados.
O throughput em MCS0 vai ficar nuns 5Mbps, a estratégia de usar esse datarate baixo é impedir que 1 cliente tenha todo a banda de upload só pra ele, MCS baixo tende a equalizar as conexões, não que 1 cliente ruim derrube demais a qualidade dos demais apenas no upload, não tem como, mas o cliente ruim não deixa de poder usar uma parcela significativa do upload. SE fosse um MCS alto nos clientes, tipo MCS4, tem grandes chances dos clientes de melhor sinal ficarem com toda a banda de upload e não sobrar nada pra quem tem o sinal um pouco pior (Qualquer 5dB a mais de SNR, ou qualquer 20uS a mais no ack time, etc). Ou seja, clientes com MCS alto são tratados de forma desigual pela torre, a torre transmitindo a MCS4 atinge todos igualmente, troca pacotes igualmente da sua parte, mas tendo respostas mais lentas ela vai alocando cada vez menos banda pra quem responde lentamente, cria uma diferença abissal de troughput quando a diferença no sinal nem é tão grande. Usar MCS baixo no cliente freia esse comportamento, SE chegar no ponto em que o consumo de upload está alto é hora de colocar mais paineis, mas enquanto ele estiver dentro do suporte do modo (5-6Mbps pra MCS0, 11-12Mbps em MCS1, etc) você não vai ter desequalizações grandes.

Vejam que falo do consumo REAL e continuo de todo o upload por parte do cliente. Quem só tem consumo variável (Navegação) pode usar modo auto, mcs alto, pode usar mimo misturado com siso, que tudo vai funcionar, mas falo de ter a disposição da maioria dos clientes todo a banda contratada de forma contínua e com o mínimo de variação conforme outros clientes consomem a mais ou a menos (Caracteristica do modo N não é derrubar as conexões boas pelas ruins, mas sim tirar um pouco das boas pra garantir pras ruins, muito mais por conta do modo AUTO cair no MCS0, que tem uma modulação propícia pra alcance e estabilidade, do que por caracteristica de processamento (Software).

SE tem sinal suficiente, não há problema em usar MCS alto no cliente, mas SE não tem upload grande não há motivo pra exigir instalação melhor (Com mais sinal), SE MCS0 ou 1 com seus 5-10Mbps de throughput REAL por painel servem, recomendo que a usem, isso vai permitir mais clientes e clientes de sinal pior sem grande degradação das grandes bandas.
(É que instalação excelente em area urbana não é simples, 200% zona de fresnel afetada por reflexo não falta, alta tensão sempre está na altura dos telhados, mas o pior: Hardware barato pro cliente tem sinal pior, anteninha de 8 a 12dBi, com transmissão a 20-22dBm, enquanto na torre é normal ter 22-24dBm com antena de 17 a 21dB, ou seja, é uma conexão nativamente desigual, em alcance mais longo você sempre terá sinal cliente>torre muito pior que torre>cliente, e isso não é problema, o problema é com multiplas conexões, pra não haver atendimento desigual e um cliente ruim derrubar demais a qualidade geral você tem que equalizar os sinais cliente>torre, se equalizar eles com MCS0 em -70dB você podera simplesmente baixar a potencia nos clientes proximos, e manter os clientes distantes com hardware normal, digamos a 22dBm em 1500m com um NS Loco, enquanto o cliente proximo com NS Loco opera a apenas 16dBm, simples, equaliza o atendimento e equaliza o custo pros clientes (Que nunca estão distribuidos todos na mesma distancia, com os mesmos obstaculos, sempre varia).

MCS alto não é problema, o problema é sinal variando, em ambiente urbano uma hora tem -60, de noite sobe pra -66, um dia choque e dá -70, outro dia aparece -60 denovo... modo auto exige que o hardware prove os modos ou espere 3 perdas de pacotes até reduzir o modo, onde o sinal varia isso cria uma grande redução de troughput. Em PTP de longa distancia (Quilometros) você PODE ter sinal -70 e contar com míseros 18dB de SNR pra ter throughput alto, tipo 50Mpbs. Mas em ambiente urbano quem tem sinal -70 raramente está distante, o motivo do sinal baixo geralmente é obstrução física do sinal, é facil ter -70 em 300m com zona de fresnel muito obstruída, esse tipo de obstrução proxima causa muita perda de pacote de apenas algumas sub-portadoras, se a sub-portadora trafegar mais dados (Mais bits por símbolo) tem mais chance de ela ter distorção e um simbolo distorcido exigir retransmissão do pacote todo, o fator que distorceu um conjunto de 4 bits dum simbolo dos 64 existentes (MCS6 ou 7) dificilmente iria distorcer o símbolo de 1 bit do MCS0. Seria perfeito ter MCS0 também na torre, mas aí teria muito pouco trhoughput pra dividir entre os clientes, recomendo usar o MCS mais baixo que atenda a banda necessaria (Se for menos de 4Mbps pode até usar modo B :-) pra aproveitar essas perdas reduzidas, mas a torre envia pacotes pra muito aparelho, o aparelho do cliente só recebe sinal da torre, ele geralmente está em espera, com sensibilidade alta, e pode pegar um sinal ruim da torre. A torre ouve muito aparelho, ela não estará sempre esperando na maior sensibilidade possível o cliente, por isso se o cliente mandar sinal mais legível (MCS0 e seu bit por simbolo, com 2 simbolos apenas) tem muuuuuito menos chance de a torre não entender o sinal (Sinal chega na antena, vai pro mixer que mistura oscilação local de sub-banda, vai pro LPF, aí é convertido em digital (Pacote digital é uma coisa, mas antena recebe e envia pelos cabos sinal bruto, tensão pura, o mixer mistura tudo como se analógico fosse), pra DEPOIS o processamento separar o que é útil (Cliente devido enviou) de inútil (Ruído, cliente mandou pacote na hora errada (Ignorou RTS e CTS), esse processamento é que é afetado por 4 bits distorcidos num dos 64 símbolos do MCS4, se a torre tiver 20 clientes transmitindo em MCS4 ela terá umas 6x mais dados pra processar que se eles transmitirem em MCS0. Mas SE há sinal suficiente pra não ter essas perdas, e o painel não está cheio, pode usar MCS alto, só não vai poder colocar tanto cliente de sinal um pouco pior (5 ou 6dB a menos, 20uS a menos no ack), ou seja, vai ter que caprichar muito mais nas instalações, e negar atendimento a muito mais clientes em que instalação meia-boca é impossível.

----------


## brunobelas

vlw professor @*rubem*
então é mas viável fixar o mcs no cliente, e no caso de um cascateamento?
supondo
torre>stx>5 cliente conectados por switch, cada cliente com 4mbs, como ficaria o MCS?

----------


## gabrielest

Rubens,
Parabéns, novamente mais uma aula, devo dizer-te que foi muito útil e ajudou e preencher algumas lacunas que eu tinha, mas deixa eu resumir pra ver se entendi bem:

Pelo que entendi são 8 tipos de MCS para cada tipo de operção:

- Siso: do 0 ao 7:
- Mimo 2x2 ou 2x1: do 8 ao 15;
- Mimo 3x3, 3x2 ou 3x1: do 16 ao 23.

1- Em linha geral dentro, de cada tipo de operação, quanto mais alto o MCS maior o troughput em banda correto?

2 - Um caso atipico, mas que acredito que tenha gente que usa assim veja, o MK permite que eu tenha um MIMO na transmissão (torre) e um siso na recepção (cliente). Se, por exemplo eu estiver fazendo uma transmissão numa SXT5 Lv4 em MCS 16 em 20Mhz me dá um troughtput de 21mb, o cliente pode usar uma groove (por exemplo) com MCS0 em 20Mhz correto?

3 - Uma coisa que não consegui entender foi como fica com o NV2??

4 - Outra pergunta, a única variável que influencia no ajuste do MCS é a quantidade de banda que se quer usar?? acredito que não, parece-me que a qualidade do sinal (que deriva da visada limpa e zona de freznell ok) também influencia né?

----------


## rubem

Em caso de cascateamento a última etapa de RF, seja em bridge ou em roteamento, é o que conta, ela que é responsavel pela maior deterioração da qualidade da conexão.
(Bridge ou roteamento, o que atrapalha é sinal ruim pro modo escolhido, desde que o gargalo não seja o resto da rede (Exemplo: PtMP de 20M, PTP de 2M, obvio que o PTP vai ser o gargalo, mas isso é raro)



E o pensamento com MCS é esse mesmo, 1x1 de 0 a 7, 2x2 ou 2x1 de 8 a 15 e etc Em geral quanto maior o MCS mais a banda DESDE QUE com o mesmo numero de chains. MCS8 vai ser MENOS que MCS7, porque tem modulação diferente e nº de chains diferente, então nem sempre MCS maior terá banda maior.

Conexão 2x1 (2T na torre, 1R no cliente) é tranquila pra PtMP, o processamento pro RX da torre não é grande, se tiver 2T em 2 polaridades diferentes não há muito lucro porque a antena do cliente (1R, 1 receptor, em 1 polaridade) vai receber o sinal na polaridade nativa 30dB mais alto que na polaridade errada, e não há HOJE muitas opções de setoriais 2T de mesma polaridade, o que há muito é H+V, mas se a antena do cliente estiver apenas em H ou apenas em V não há lucro nenhum nisso, vai ser um 1,01x1, e não um 2x1 (Porque será um 1x1 mais 0,1x1, ou seja, a antena na polarização errada te dará 10% da qualidade de conexão). Cuidado com 2x1, a polarização das 3 antenas (2 de transmissão, 1 de recepção) precisa ser a mesma pra OTIMIZAR a coisa.

NV2 e airMAX, taí coisa que só sei o basico do basico, são modulações diferentes então tem POTENCIAL* pra ter desempenho 100% diferente.
(*POTENCIAL = O Rubem não sabe bem o tipo de modulação usada, sei que NV2 é TMDA, mas IMAGINO que tenha outra diferenças fundamentais, nunca me preocupei porque não quero e não vou me acorrentar a apenas 1 fabricante, os padrão IEEE (802.11N, por exemplo) independem de fabricante)

MCS faz variar a banda utilizavel por conta da modulação, mas a população/povoamento dos canais e/ou portadoras altera o alcance e a estabilidade, aí é que está o que defendo: MCS mais baixo tende a ter alcance e estabilidade maiores, se não vai passar banda grande num PtMP não tem motivo pra escolher datarate maior, já que datarate maior significa em linhas gerais menos alcance e menos estabilidade.

----------


## gabrielest

Ok,
Obrigado, mas quanto a questão sobre o MCS com operações diferentes ficou-me um pouco vago veja:
- se eu tiver 2 sxt eu tenho que trabalhar com os mcs dos modos 2x2 e 3x3, ou seja, do 8 ao 23 (dependendo do que eu queira fazer com o datarate);
- se eu tiver uma sxt e uma groove (ou um aparelho siso), a sxt eu seto no MCS que eu quiser do 8 ao 23 mas o groove só vou poder setar do 0 ao 7 pq ele é ciso correto??
- Me explica melhor a questão da interação do MIMO 3x1 com o siso 1x1?

----------


## emilidani

Segundo a explanação o MCS que é fixado no AP pode ser diferente do Cliente? Entendo que o modo MCS fixado no AP será a que CADA cliente vai utilizar para se comunicar. Entao , independentemente do MCS que é fixado no Cliente, quem manda e o MCS do cliente, fixado no AP.

----------


## rubem

Quando você configura um roteador para usar MCS8, ele vai usar 2 streams de 6,5M pra transmitir, se a contraparte da conexão vai usar 1, 2 ou 3 streams pra transmitir de volta isso só influenciará no troughput final, não na conexão "basica" entre eles.

Ou seja, você define aqui nesse roteador como ele irá transmitir (1 canal, 2 canais, etc), se a contraparte da conexão vai transmitir do mesmo jeito, ou se vai usar outro data-rate, isso você não configura aqui, tem que ir lá na contraparte configurar isso.

SXT só tem 2T2R, certo? (Se tem um 3T3R tô por fora) Se ele for o AP da conexão você pode configurar no MCS8 que ele irá mandar sempre 2 streams de dados pra começar a negociação, se o outro SXT estiver com 1 antena desligada/removida, a comunicação será 2X1. Se nesse 2º SXT você selecionar MCS0, mesmo ele tendo 2 antenas ele irá usar os switches da saída de RF pra fazer diversidade, serão 2 antenas num único chain. Isso é o que a maioria dos hardwares com antena de "dupla polaridade" tem feito, eles não tem MIMO mas tem 2 antenas em polaridades diferentes, com um switch que define qual polaridade irá usar ou se usará as 2, a cada pacote praticamente.

Num SXT em MCS8, se ele se comunicar APENAS com uma CPE de antena de polarização única, é bem possível que esse SXT deixe de usar 2 chains depois de algumas perdas de pacotes enviados na polarização que a CPE não capta direito (São geralmente 25-30dB a menos na polarização "errada"), num PTP essas perdas de pacotes contam muito, mas é questão de segundos ou minutos até as partes do PTP verem que polarização e chain tem respostas mais rapidas ou menos perdas, o software não é burro, ele faz esse tipo de escolha (Por isso digo que liberar a capacidade de processamento é importante).

Num PtMP algumas estações responderão melhor na pol. H, outras na V, mas o importante é: Você tem 2 chains trocando dados, a parte de mixer e encoder/decoder é importante na etapa de RF (Então quanto mais etapas de RF, melhor), se tiver muito pacote de níveis diferentes (De muitos clientes) tem distorção no ADC (Analog to digital converter) ou no decoder. Por isso usar hardware com 1 chain mas com antena de dupla polarização é importante, a maioria das CPE's tem isso hoje, porque isso melhora muuuuuito a conexão pro lado da torre (Que tem 1 etapa de RF em cada polarização).

MCS8 só vai se comunicar direito com CPE's com antena de dupla polarização com switch, se a CPE tiver antena de polarização única a torre vai se comunicar com essa CPE em MCS0, não em MCS8, não por limitação do 802.11N, mas porque a antena de polarização "errada" nunca terá resposta, CPE V não captará sinal H com intensidade suficiente pra responder, todos os pacotes na H serão perdidos e a torre vai perceber isso e passar a ignorar a possibilidade de uso dessa polarização (O software é inteligente). Em PtMP não é bom ter essa mistura de H aqui, V alí, isso exige mais processamento da torre, mas usando CPE V+H não há problema, a torre escolherá a polarização que melhor lhe atende sem gastar tanto processamento, mas usará as 2 polarizações pra transmitir, ou seja, dividirá os dados por 2 encoders, por 2 mixes, porque serão 2 etapas de RF (E por receber nas 2 polarizações a CPE vai mandar ora por uma e ora por outra conforme a torre responder, porque atenuação de sinal varia conforme inclusive polarização (Algo atenua a V mas não a H, e vice-versa).

----------


## gabrielest

Blz Rubens,
Novamente obrigado

----------


## naldo864

Hummm deixa eu ver se entendi então no caso dos UBNT usar airgrid e nanoloco em clientes e usar rocket na torre e uma combinação ruim visto que forca o processamento no radio da torre.
O ideal era deixar tudo 2*2 ou seja rocket com nanosloco.
Se quiser ter um bom arranjo como já uso nanoloco e airgrid nos clientes e baixar o MCs na torre também !.

Falei alguma bobagem ou e isso mesmo ?

----------


## rubem

NS Loco com sua polarização dupla em teoria "pesaria" menos no processamento, já que sempre vai se adaptar pra polarização de melhor sinal na transmissão, mas... é uma anteninha tão ridícula de 13dBi, com 20dB de isolamento entre polarização, que faz pouca diferença comparado a um airGrid de polarização simples, que tem 22dBm de isolamento entre polarização, mas tem antena de ganho muito maior (Ou seja, num mesmo cliente ele vai receber o sinal V ok, mas o H vai estar uns 22dBm abaixo, e os 10dBi a mais de ganho dum airGrid M5 23 comparado com NS Loco 13dBi, darão algo acima dos 22dBm na polarização errada).

Tanto NSLoco como airGrid não são uma maravilha no 2x1, o NS Loco seria menos pior desde que proximo da torre (O que é meio impossível no mundo real) e com sinal bom em ambas as polarizações (O que também não é tão comum). Se tiver CCQ excelente em ambas as polarizações, NS Loco vai ser perfeito. Com CCQ meia boca, tanto faz, o gargalo deixa de ser o processamento da torre.

Mas como todo mundo mistura NS, NS Loco, airGrid, nanoBridge, usar 2x1 economizaria processamento na conexão com NS, NsLoco e nanobridge, e gastaria um pouco a mais nos airGrid, acho que ainda é lucro.


Mas veja que estamos falando de perda de processamento significativa com 30 clientes conectados e navegando, quem tem 10 conectados num Rocket, com conexão tipo 1-5Mbps, não tem diferença preocupante.

Com 30 simultaneos, se metade por airGrid, ao escolher MCS10, de 40M, essas conexões vão a longo prazo se adaptando pra fazer apenas 1x1, na prática elas vão se limitar a 20M, A outra metade, com NS, NSLoco e NanoBridge vai conseguir usar 2x1 mesmo, vai poder chegar nos quase 40M do datarate. SE esses airGrid precisam somados mais que 20M, é bom passar pra MCS11 ou 12, tem que escolher o datarate 2x que atenda as CPE's single-polarization com a banda que elas precisam (MCS10 equivale a MCS2, MCS11 a MCS3, etc).

----------


## rubem

Alias, usar coisa como NS na torre também tem essa vantagem de se adaptar a polarização de melhor sinal, mas desde que esteja usando NS/NSLoco/nanoBridge/SXT ou CPE de dupla polarização nos clientes. Pra grandes bandas essa feature é fantástica, mas pra banda pequena e sinal "ruim" (O normal de se ver em 802.11B, CCQ de 80-90%) isso consome mais processamento que devia, pra banda pequena de qualquer forma serve, mas pra banda grande TEM QUE ter CCQ perfeito em todos os clientes, pra não haver gasto de processamento exagerado pra uns e isso derrubar o throughput pros outros.

(Ah sim, Rocket M em antena de dupla polarização, se configurado pra MCS0-7, também faz autoadaptação de polaridade. Mas se tiver apenas airGrid isso é um tiro no pé, ela vai gastar processamento com sinal na horizontal, sendo que ninguém responderá nessa polarização. São pacotes probatórios, são poucos por conexão, mas em 30 conectados a soma consome processamento que derruba trhoughput)

----------


## naldo864

Um pergunta pertinente e se fossem apenas 10 clientes digamos todos airgrid com rocket na torre .
Mas 10 clientes consumindo 10 MB sem parar ao mesmo tempo a AP rocket iria abrir o bico ?

----------


## rubem

Seriam 100MB, teria que ser MCS6 ou 7 com canal de 40MHz. Aguentar aguenta, isso não é problema.

O problema é: _"Vou usar MCS12, que tem datarate de 162M, deve dar"_. Não vai dar, porque uma da polarizações vai ser inútil (Exceto talvez se o sinal for muuuuuito bom, tipo 50dBm de SNR), com apenas 1 polarização funcional o MCS12 vai ser um MCS4, de 80M. Precisaria então MCS13 ou 14, mas se vai ter apenas airGrid não vale a pena pagar por multipla polarização se não vai usar, não tem lucro em usar isso se não tiver algo similar nos clientes, tem é um leve prejuízo de processamento (V+H > H).

Já SE você usar airGrid conectado numa torre com 2 ou 3 setoriais V afastadas o suficiente, fazendo 2x1 ou 3x1 na mesma polarização, tanto a teoria como alguns experimentos mostram que você tem MAIS banda do que num sistema V+H de antenas proximas (No mesmo refletor). Aí que entram os Wavion e outros sistemas multi-omni que prometem banda alta, autoadaptative é excelente, permite througput excelente, mas as antenas precisam ficar distantes ou precisam baixa potencia, e com baixa potencia automaticamente o alcance diminui. Imagino que 2 setoriais V a 2m uma da outra já fariam um belo trafego a mais pros airGrid que V+H juntos (NS, BaseStation) rumo a NS Loco e cia, metade pela distancia entre irradiantes e metade pelo ganho maior dos airGrid.

----------


## gabrielest

bela discussão esse post...muito bacana...da prazer de ler....

----------


## gabrielest

Graças e esse post e outros fechei um PTP com 2 SXTLite5 em 1.8km, assim;

- Nstream
-5300mhz
Sinal: -50/-50
Potencia: 22dbm (elas chegam a 27)
Teste de banda fechando 90mb full (isso pq setei no Nstream) em NV2 + NStream passo 120full no teste de banda.

Shou mesmo

----------


## naldo864

O que eu aprendi já estou testando o ruben e show sussesso.

----------


## rubem

Mas é bom vocês lerem por conta propria outros conteúdos sobre o assunto, porque tem pouco conteúdo sobre isso.
Quando um padrão é lançado o pessoal do marketing usando tanto o "Até 150M" ou "Até 3,2Gbps" que acaba tendo pouca informação técnica, divulgam um resumão sobre as novidades no maior datarate do padrão mas esquecem de falar sobre modulações intermediarias, sobre subportadoras em canais mais estreitos ou mais largos que o padrão, sobre comportamento das modulação fazendo mimo com polarização dupla...

Muito do conteúdo encontrável é sobre roteadorzinho domestico Linksys com 2 ou 3 antenas na vertical, com um notebook qualquer conectado, ignoram o fato de notebook ter 2 ou 3 antenas em polarizações diferentes, ignoram a recomendação que as vezes a propria linksys (Só pra seguir o exemplo) dá de colocar uma ou 2 das antenas a 45°, falam sobre beamforming e autoadaptação mas com apenas 1 micro conectado (Quem compra roteador Linksys de R$ 500 e usa apenas 1 dispositivo móvel nele?).

Enfim... tem muito conteúdo academico sobre isso, tem que ler 10 pdf's academicos pra extrair 2 ou 3 informações práticas. E as vezes se baseiam em featura específica de algum chipset que a gente (Ou o proprio autor) generaliza pro protocolo todo.
(Mas talvez se comprar os textos da IEEE facilite... no cadastro gratis não tem nada útil)

----------


## Jhonvalter

> Mas é bom vocês lerem por conta propria outros conteúdos sobre o assunto, porque tem pouco conteúdo sobre isso.
> Quando um padrão é lançado o pessoal do marketing usando tanto o "Até 150M" ou "Até 3,2Gbps" que acaba tendo pouca informação técnica, divulgam um resumão sobre as novidades no maior datarate do padrão mas esquecem de falar sobre modulações intermediarias, sobre subportadoras em canais mais estreitos ou mais largos que o padrão, sobre comportamento das modulação fazendo mimo com polarização dupla...
> 
> Muito do conteúdo encontrável é sobre roteadorzinho domestico Linksys com 2 ou 3 antenas na vertical, com um notebook qualquer conectado, ignoram o fato de notebook ter 2 ou 3 antenas em polarizações diferentes, ignoram a recomendação que as vezes a propria linksys (Só pra seguir o exemplo) dá de colocar uma ou 2 das antenas a 45°, falam sobre beamforming e autoadaptação mas com apenas 1 micro conectado (Quem compra roteador Linksys de R$ 500 e usa apenas 1 dispositivo móvel nele?).
> 
> Enfim... tem muito conteúdo academico sobre isso, tem que ler 10 pdf's academicos pra extrair 2 ou 3 informações práticas. E as vezes se baseiam em featura específica de algum chipset que a gente (Ou o proprio autor) generaliza pro protocolo todo.
> (Mas talvez se comprar os textos da IEEE facilite... no cadastro gratis não tem nada útil)


 Nobre amigo, boa tarde!
Tendo sua experiência no assunto e lembrando que sou novato na área, gostaria se possível que você pudessem fazer um análise nessa tela em anexo e se possível me orientar.

Obrigado.

----------


## rubem

> Nobre amigo, boa tarde!
> Tendo sua experiência no assunto e lembrando que sou novato na área, gostaria se possível que você pudessem fazer um análise nessa tela em anexo e se possível me orientar.
> 
> Obrigado.


Dá uma olha em baixo, no nível de sinal e no datarate dos 2 aparelhos conectados.
Sinal -77 e ruído a -92 são ridículos 15dB de SNR, devia ter 25!

O outro tem sinal -71, são 21dB de SNR, EM TEORIA seria suficiente pra um MCS14 sem problemas. E... está mesmo em MCS14. Mas... na prática use SNR 20 ou 21 apenas em MCS0 a 3, 8 a 11 9. Acima disso é bom ter uns 25dB de SNR pra ter estabilidade (CCQ tipo 99% em MCS14. Afinal não adianta ter CCQ 85% em MCS14, vai perder pacote legítivo, o datarate teórico será maior que 99,9% de CCQ em MCS12, mas CCQ menor significa menos perdas de pacotes, o throughput você vê de cara pelo CCQ, não pelo datarate).

Pra mim você tem o classico problema do modo AUTO com sinal variando conforme o cliente, o airMAX está com capacidade péssima porque o sinal está ruim, e o throughput real deve estar ruim porque no modo auto e com 2 "clientes" o datarate variando faz muito "teste" de datarates e pacotes (Procura sempre o melhor datarate possível).

Enfim, com esse SNR acho que só terá estabilidade se fixar em MCS9 ou 10. Se quiser mais banda nos 2, vai ter que melhorar o sinal desse "UBNT", pra uns -71. Enfim, tem que equalizar os sinais, e com SNR pelo menos nos 20-22dBm.

Alias, -71 não é um sinal ruim, seu ruído é que está meio alto pro meu gosto. Se for Querencia - MT devia ser -104, se for Primavera do Leste - MT imagino que uns -97, se tem esse -92 não tem outro radio muito proximo? Ou o sinal não passa sobre rede de alta tensão? (10m pra cima de rede de 2,3KV ou mais é um problemão) Acho meio estranho esse ruído todo no interior de MT. Mas enfim, se o ruído está alto mesmo, o jeito é melhorar o sinal pra ter SNR maior, ou fixar num MCS menor pra ter sensibilidade maior.

EU só usaria airmax com SNR tipo 25dBm, e só o manteria ativo se a capacidade dele no setup fosse maior que 60%. Porque ví muuuuita perda de pacotes com sinais piores que isso, 22dB se SNR dá pra 60-70Mbps de throughput com MCS12 (400nS pelo que lembro), mas ao ativar airMAX a capacidade ficava sempre nos 50%, e o throughput baixava 10-15Mbps.

Se tiver 30dBm de SNR é claro que airMax vai fazer a banda aumentar muito, mas TODOS tem que ter esse SNR.

Equalização. -71 e -77 num provedor não é problema, vender pacote de 1 a 5M de internet com modo auto e esses sinal está ok, mas se é PTP tem que fixar o MCS pra ter estabilidade, e fazer das tripas coração pra ter SNR acima de 25dBm.
(Cuida que se baixar o MCS o SNR automaticamente sobe em metade dos casos, tipo: MCS14: 15dBm de SNR. MCS10: 21dBm de SNR. Wow... etapa de RF em MCS menor tem uns dBm a mais de potencia, e uns dBm a mais de sensibilidade.

----------


## Jhonvalter

> Dá uma olha em baixo, no nível de sinal e no datarate dos 2 aparelhos conectados.
> Sinal -77 e ruído a -92 são ridículos 15dB de SNR, devia ter 25!
> 
> O outro tem sinal -71, são 21dB de SNR, EM TEORIA seria suficiente pra um MCS14 sem problemas. E... está mesmo em MCS14. Mas... na prática use SNR 20 ou 21 apenas em MCS0 a 3, 8 a 11 9. Acima disso é bom ter uns 25dB de SNR pra ter estabilidade (CCQ tipo 99% em MCS14. Afinal não adianta ter CCQ 85% em MCS14, vai perder pacote legítivo, o datarate teórico será maior que 99,9% de CCQ em MCS12, mas CCQ menor significa menos perdas de pacotes, o throughput você vê de cara pelo CCQ, não pelo datarate).
> 
> Pra mim você tem o classico problema do modo AUTO com sinal variando conforme o cliente, o airMAX está com capacidade péssima porque o sinal está ruim, e o throughput real deve estar ruim porque no modo auto e com 2 "clientes" o datarate variando faz muito "teste" de datarates e pacotes (Procura sempre o melhor datarate possível).
> 
> Enfim, com esse SNR acho que só terá estabilidade se fixar em MCS9 ou 10. Se quiser mais banda nos 2, vai ter que melhorar o sinal desse "UBNT", pra uns -71. Enfim, tem que equalizar os sinais, e com SNR pelo menos nos 20-22dBm.
> 
> ...


Obrigado meu amigo Rubem pelas preciosas informações. Esse equipamento é uma base station que no momento ta com 3 clientes pendurados. Essa região não é mato grosso e sim RS, acredito que seja algo como refração pra ta tando ruido assim em um desses clientes já que essa é uma região de muito telhado de zinco. Vou ver o que posso fazer. Abração.

----------


## rubem

Pelo pouco que tentei brigar com telhados de zinco / aluminio, eles não "produzem" um nível de ruído maior, só fazem o CCQ diminuir muuuuuito.

Quem afeta muito o nível de ruído, e passa desapercebido, é rede de alta tensão. HOJE considero ideal ter 200% da zona de fresnel livre de linha de alta tensão, porque já sofri com linha de 13KV a pouco mais de 100% da zona e o desempenho era péssimo por mais que mechesse.
(Veja o detalhe: Não é rede longe da antena, mas sim longe da zona de fresnel! Não dá pra evitar esse obstaculo as vezes, mas é bom pelo menos saber o que está atrapalhando. Se tem rede AT na zona de fresnel: A culpa é dela, não da sua configuração ou do equipamento. Dá pra minimizar o problema, mas nunca soube como resolver efetivamente (Sem ser fibra ou FSO))

----------


## Jhonvalter

Olha eu novamente meu amigo Rubem. Veja essa tela, mu TX fica oscilando entre 52 e 117. Em que isso pode prejudicar meu enlace? Grato.

----------


## rubem

O que está oscilando é o data rate, não necessariamente o throughput passante está variando.

Data rate muda quase toda hora quando você usa o modo AUTO, eu sempre defendo que isso gasta processamento a toa, e perde pacotes a toa (Pra descar um mcs tem que ter um certo nº de perdas de pacotes), por isso insisto no uso de MCS fixo, escolhe um data rate suficiente e fixa nele. Um data rate "suficiente" e não "o maior data rate possível" porque em datarates menores GERALMENTE tem respostas mais rapidas. Digo, você pode ter 80Mbps de throughput em MCS12 mas com ping variando de 10 a 40mS, acho isso péssimo, baixando pra MCS11 o throughput cai pra 45Mbps mas a tem ping de 1-2mS. Ping é referencia? Mais ou menos, lembra de dar ping ou fazer teste de velocidade com pacotes pequenos e grandes, a maior parte dos seus cliente vai trafegar pacotes grandes (1450 a 1472 bytes) então ter resposta grandes justo neles (Tipo 40mS) dá uma sensação de ruim de navegação.

No seu caso pelo visto está com tempo de guarda de 400ns, afinal tem 52 e 117M de datarate (MCS10 e 14 se não me engano) isso indica 400nS de GI. Se quer aumentar o throughput e tem sinal (Tem mais de 30dB de SNR) o jeito que não piora nada é aumentar o GI pra 800nS.

Mas não ligue pra datarate variando, isso indica que o sinal não está completamente estável, mas com noise floor tão alto tipo -91 deve ter muito equipamento 5GHz por perto (Não necessariamente no mesmo canal). Testa canal mais alto, lá pelo 5750MHz pra cima, pra ver se a antena não tem ganho melhor, ou VSWR melhor, nessa frequencia mais alta (As vezes tem diferença de 2dB no ganho ao subir ou descer 60MHz).

Se não quer variação nenhuma é só fixar a velocidade, desativa o auto, mas veja que a transmissão no modo auto está sendo feita em MCS10, que é o datarate de 52M, ou seja, é o modo que os aparelhos "definiriam" via testes ser o de maior velocidade conseguível, então pra ter estabilidade talvez você precise fixar no MCS abaixo (MCS9) e aumentar o GI pra 800nS (Não lembro o local exato no setup de AirOS, não tenho nenhum agora pra olhar e ver o nome exato, tempo de guarda, guard interval, gi, qualquer coisa com opção 400 e 800nS é isso, talvez 0,4 / 0,8mS)). Enfim, o sinal dessa estação do print pra outra não está ótimo, por isso no modo auto fica em 52M (MCS9 ou 10, não lembro), talvez esteja bom pro throughput que você precisa, mas o sinal da outra estação rumo a essa do print está muuuuito melhor, por isso está em MCS14 de 117M. Talvez uma antena seja diferente da outra, e trocando canal (Mudando 100MHz ou mais) chegue num canal onde ambas as antenas tem ganho similar e ficam com datarate mais parecido no RX e TX.

----------


## evandrojso

Parabéns pelo tópico, tenho o PTP RB 912 modulando em MCS 12, normalmente passa 85Mbps, mas derrepente cai para 50Mbps.
Segue print para avaliar. Qual seria melhor solução para passar 100mbps, consigo isso só manipulando MCS?

----------


## rubem

Esse HT-40 2S SGI indica que está usando short guard interval, ou seja, já está no limite do MCS12.

Pra mais banda passante vai precisar passar pra MCS13, mas seria bom mudar pra intervalo de guard longo ("HT Guard intervall" em long na aba HT), porque parece que não tem zona de fresnel tão limpa (Senão o CCQ seria maior com esse nível de sinal).

MCS-13 GI longo é o datarate de 216Mbps. DEVIA dar mais de 100Mbps se a zona de fresnel estiver ok.

Ou a distancia é grande? Se for, melhor pensar em antena maior.
Antena de maior ganho não afeta a potencia de emissão, obdecendo o limite EIRP de 36dBm dá pra ir longe. Mas antena grande melhora o nível do sinal RECEBIDO, uma antena de 14dBi recebe um sinal digamos a -74, já uma antena de 28dBi nesse mesmo local vai receber esse sinal em -50 mais ou menos. -74 é suficiente pra um MCS10 talvez. -50 é suficiente até pra MCS15. Diferença enorme na banda passante.

Nessa mesma aba HT tem o HT AMPDU, marcando os 7 você DEVIA ter mais throughput pois vai haver mais agregação de frames, mas isso gera um pequeno delay a mais, então seria bom testar ack-timeout fixo e maior que o real, acho que uns 30 a 40% maior que o correto, pra dar tempo de "desagregar" os frames agregados no outro lado.

(E aqui é o único ponto em que o setup da UBNT me agrada mais que MK, na aba advanced você marca agregação de até 32 frames, e seleciona tamanho, o default acho que é 50KB, mas pode ir (Se não me engano) até 65535 (E 32 vezes 1500 bytes (Limite no MTU) dá só 48KB, então o default de 50KB tá ótimo). Num PTP distante onde perder 4ms não é problema desde que o throughput sejá bom e o jitter seja zero isso é ótimo. Não é a toa que tanta gente elogiava Rocket M5 em PTP, uma configuraçãozinha boba tipo a agregação de frames faz muita diferença no throughput)


Alias, falando em agregação, se tem MK nos 2 lados teste NV2, ele agrega com mais versatilidade, o throughput costuma ser maior com o mesmo sinal.
(Já se realmente tiver a zona de fresnel meio suja ele pode piorar a coisa, afinal frame agregado significa as vezes metade de uma conexão aqui e metade alí, se metade é perdida ele tem que armazenas mais conteúdo em cache até que o pacote perdido seja reenviado, aí ao invez de demorar 4ms ele demora 12ms (Chega ilegível em 4ms, volta o aviso de ilegibilidade em 8ms, é enviado denovo em 12ms), conforme a qualidade do link pode piorar muito mais que um simples ping ruim. Mas tem que testar)

----------


## JonasMT

Tem algo errado ai, com msc 12 consigo algo proximo de 110mb. Se estiver usando nstreme mude para nv2

----------


## evandrojso

Caro Rubem obrigados pela respostas.
1 - A Zona de fresnel esta limpa

2 - A distância é 38km
3 - São duas RB912 e Antenas Xwave 5831DPR
Então as configurações ficou MCS fixo no AP e Defalt na estação, estou usando NV2 com TDMA Period Size: auto Cell Radius: 38KM, frequency=5425, ampdu-priorities=0,1,2,3,4,5,6,7,band=5ghz-onlyn
ht-basic-mcs=mcs-10,mcs-11,mcs-12 \ ht-supported-mcs=mcs-10,mcs-11,mcs-12.

A pergunta é seguinte tem alguma configuração para fazer no MK para que diminuísse o throughput do RX visto que nesse enlace não usamos velocidades full duplex para que passasse somente uns 30% de Upload e que não degradasse o enlace, ou isso não ajudaria em nada.


Está passando quase 100Mbps no horário de pico, mas como da para ver gráfico nessas crista enlace continua instável, esta passando 80Mbps e derrepente cai para 50Mbps, leva um tempo volta normal.

----------


## JonasMT

deixe marcado apenas mc12 e teste, ja conferiu em outro canal? 

Ja vi muita gente relatando que acima de 70mb ela começa a abrir as perna. Voce poderia testar um apc 5m pessoal costuma comentar que só nao passa mais de 100mb por causa da porta /100

----------


## rubem

E quanto a isso de ter RX menor, é só marcar HT MCS menor no outro lado.

O lado A pode transmitir com MCS12, e o lado B com MCS10, sem problemas. Vai ter no lado A TX/RX de 78M/39M no ponto A, e 39M/78M no ponto B.

Nas RB's recentes a Mikrotik não divulga mais a sensibilidade de CADA datarate, só de MCS0 e MCS7 (Que dá na mesma que MCS8 e MCS15), mas pelos numeros nessas 2 sensibilidades a gente tem idéia do resto. Em MCS12 a sensibilidade com canal de 20MHz deve ser cerca de -86dBm, então o sinal pra ter CCQ no máximo devia ser -66dBm até uns 10Km, e em 38Km eu diria que precisa 30dBm acima da sensibilidade, ou seja, -56dBm de sinal pra ter CCQ no máximo.

O último print mostra sinal em -62 ou -63, isso é sinal suficiente pra MCS10 nessa distancia (Se a intenção é CCQ maximo).

Quanto maior a distancia maior a margem de sinal entre sensibilidade e o sinal de RX, 38Km exige uns 30dBm de margem, isso é sinal pra caramba.
(Em 3Km pode ter só 12 ou 13dBm de margem que terá CCQ em 100%, em 10Km pula pra uns 20dBm de margem, e partir dos 25Km precisa 30dBm de margem, porque a perda por poeira e agua em distancia grande é maior, tem o "thermal fadding")

ACHO que com RB912 e antena de 31dB mandar sinal suficiente pra MCS12 vai ter que colocar a potencia em 24dBm, que é o máximo se não me engano. Com essa potencia deverá ter sinal em -55 no outro lado, suficiente com folga pra 100% de CCQ em MCS12.
(E o outro lado transmitindo em MCS10, com potencia também bem alta, tipo 22dBm)

(Baseio minha conta na perda de 140dB de sinal em 40Km. Radio a 24dBm + antena de 31dBi = 55dBm EIRP, 55 menos 140dBm de perda dá -85, com 31dBi de ganho da antena dá -85 + 31 = -54dBm de sinal chegando no outro radio. Com relação a sensibilidade de uns -86 isso dá 32dB de margem, excelente pros faddings no caminho tipo poeira, chuva, nuvens)

----------


## evandrojso

Consegui resolver o problema desse enlace, estava usando inicialmente antenas de 31dBi +RB912, dai optamos em trocar radio para ganhar mais nos sinal, trocamos para RB922 sinal foi para -55dBm mas na resolveu só ficava estável no MCS11 que passava em torno de 65Mbps, resolvemos trocar antena 34dBi da Ubiquiti+RB912, sinal caiu pra -43dBm com isso esta passando uns 130Mbps.

----------


## pedrohafe

Caro @*rubem*, aproveitando da sua boa vontade, me tire uma dúvida, nas minhas torres tenho 4 painéis com RB912, os clientes dos painéis são em sua maioria SXT mas tenho algumas Nano Loco e AirGrids, nenhum cliente tem plano acima de 5Mb de download e 1.5Mb de upload. Eu deveria deixar o MCS automático nas RBs e configurar MCS fixo nos clientes? Se eu configurar MCS4 numa RB por exemplo, eu não conseguiria fornecer mais do que 40Mb de link para os clientes conectados nessa RB?

----------


## rubem

Mas você está usando polarização simples?
MCS4 é datarate de polarização simples, é o 16QAM de maior datarate, em 20MHz ele tem 39M nominal, na prática dá pra uns 20Mbps.

Aí entra a vantagem de dupla-polarização, quando coloca 2 chains fazendo MIMO, o mesmo 16QAM equivalente a MCS4 é o MCS12, cujo datarate em 20MHz é de 78M, que dá 40Mbps ao todo.

O problema de misturar polarização dupla com simples é desperdiçar capacidade do radio, o AP tem capacidade pra X troca de dados por segundo, se tiver uma duzia de clientes com Airgrid em pol. simples e MCS4 você vai gastar com eles o mesmo tempo que gastaria com uma duzia de clientes com pol. dupla (SXT, NS, NB, etc), mas em pol. dupla usando datarate maior passaria mais tráfego em menos tempo. E AP eficiente é o que tem duzias de clientes conectados.

O MCS automatico é lindo quando funciona, o problema é que o software é burro de OPTAR por datarates grandes quando NÃO HÁ sinal suficiente. Por exemplo, o cliente recebe sinal -70dBm da torre, o softwarte é burro o suficiente pra trocar dados usando MCS15, cuja sensibilidade é -78dBm, e portanto há entre sensibilidade e sinal uma margem de ridículos 8dBm. Em ambiente muito limpo essa margem até é suficiente pra banda grande, mas... se olhar o CCQ não verá ele grande. CCQ longe de 100% indica perdas de pacotes, indica que o radio está mandando digamos 10 pacotes em MCS15, e está tendo que repetir 2 porque o AP não entendeu, isso gera CCQ tipo 90%, mas o pior, esse reenvio de 2 pacotes tomou tempo que poderia estar sendo gasto com outros clientes (Aí é a situação que 1 cliente com CCQ ruim atrapalha toda a rede).

Quando todos os clientes tem mais de 100% da zona de fresnel limpa, ou quando usam uma banda muuuuuuito menor que os datarates (512Kbps com MCS15, por exemplo), aí o modo automatico opera bem, pra um datarate nominado como 135M (MCS15 em 20M) pode ter 90% de perdas que ele ainda vai conseguir levar 512Kbps sem problemas. O problema seria: O AP suportaria 40 clientes com 98-99% de CCQ, transferindo pra cada pelo menos 1Mbps. Já com CCQ de 80-90% ele mal suporta 30, e vai transferir pra cada menos de 500Kbps.

O problema do modo automático é que ele não aumenta só o datarate do cliente próximo que está com sinal -60dBm (18dBm de margem com relação a sensibilidade de -78 em MCS15), o problema é que ele COSTUMA aumentar o datarate de quem está longe, ou de quem tem sinal baixo por culpa de zona de fresnel parcial.

Bom mesmo seria um firmware onde você pudesse definir datarare por cliente, ou por nível de sinal, aí sim teriamos rendimento excelente.

Curioso que você encontra muita gente recomendando 20dBm de margem, exemplo:
https://community.ubnt.com/t5/Wirele.../464429#M35664

Em material oficial da UBNT também já ví a RECOMENDAÇÃO de 20dBm de margem. Mas... a desgraça do modo automático seleciona o datarate levando em consideração uma margem de apenas 6dBm! Nunca consegui 100% de CCQ nem com 10dBm de margem, pra mim que o mínimo é 12dBm, mas a meta é mais de 20dBm (E o modo automatico ignora isso)

Se não for olhar pelo lado da margem sensibilidade x sinal, olhe pelo SNR.
Ruído em -96dBm? Então se usar MCS15 e tiver sinal de -66dBm (12dBm de margem com relação a sensibilidade do MCS15 de -78dBm) terá CCQ de 100%?
Duvido muito. Por isso:

Segundo isso precisaria 32dB de SNR pra MCS15. E... -96 + 32 = -64dBm

Já em MCS12 segundo isso precisaria apenas 26dB de SNR. Se o ruído é -96dBm então o sinal mínimo pra MCS12 seria -70dBm.
Testa aí, um mini-PTP em modo automatico, ruído -96dBm, e ajusta a potencia de modo a ter sinal digamos -70dBm, veja se o software vai ser inteligente pra ir pra MCS12. Sempre que fiz isso ele foi burro de ir pra MCS15, e ter não só apenas 8dBm de margem, como apenas 26dB de SNR (Que segundo duzias de tabelas é insuficiente pra MCS15).

Mas tem que ver que SNR e margem falam apenas em PERCENTUAL de erro, não existe erro zero em wifi (Só via cabo existe), com RF sempre terá reflexo, vswr e etc. Mas com SNR baixo é fácil ver o percentual previsto de erros:

Veja que com 20dB de SNR em MCS12 a perda não é zero, é 0,00001%, ou 1 pacote perdido a cada 100 mil. O problema é que um pacote de 1500 bytes pode ser quebrado em várias transmissões via wifi, 1 erro a cada 100 mil pode gerar na verdade o reenvio de 1 pacote completo a cada 1 mil, e num AP com 50 clientes tendo essa parte isso pode ser 1 perda a cada 20 transações, isso dá uma perda de capacidade geral teórica de 5%! (Cai de 40Mbps pra 38Mbps).

Esse tipo de pequena diferença é fácil ver em PTP, você meche 1 fio de cabelo no angulo da antena e ela cai de 40 pra 38Mbps de média, em PtMP ninguém costuma dar bola porque o trafego real depende do que os clientes estão fazendo, mas falando em *otimizar a capacidade* a recomendação é trabalhar com margem mínima de 20dBm (Sinal -66dBm se usar MCS12 em UBNT ou MK), SNR mínimo de 32dBm (Se o ruído estiver em -90dBm tem que trabalhar com sinal acima de -58dBm), e trabalhar com zona de fresnel acima de 100% (E acima de 200% se tiver no caminho algo altamente reflexivo tipo telhado metalico ou agua), assim terá CCQ proximo a 100% (98, 99 ou 100%) e poderá enfiar 40 clientes trafegando muito num Rocket.

Isso é OTIMIZAÇÃO, não quer dizer que coisa pior não funcione. Mas se for pelo "funcionar funciona" o negócio é economizar ao máximo e botar um Greatek 700mW em 802.11b como AP, numa omni 15dBi, e antenas de grade com adaptador USB no cliente... funcionar funciona :-)
(Mas está longe de ser uma estrutura de qualidade, ou otimizada)

----------


## pedrohafe

Utilizo polarização dupla nas RBs, estou postando os prints da configuração das RBs via winbox.

----------


## rubem

Você está usando isso outdoor? Se sim, muda pra faixa que PODE ser utilizada pra ambiente outdoor, que é ACIMA de 5350MHz.

Seção X daqui:
http://www.anatel.gov.br/legislacao/...-resolucao-506
5150 a 5350MHz é APENAS pra uso indoor.

Por isso o espectro está uma zona no brasil, ninguém respeita regulamentação.

Se usar MIMO, use apenas os datarates de MIMO, isto é, MCS8 a MCS15.

E o uso de largura de canal auto em 20/40MHz, é pra passar mais banda? Mas lembra que 40MHz exige mais sinal, não só tem sensibilidade uns 2-3dBm menor como exige SNR uns 2-3dBm maior. A tabela de SNR que enviei é das poucas que agrupa 20 e 40MHz na mesma necessidade de SNR (Pois ela usa a conta de bits por hertz, que só funciona em laboratório), mas outras dão valores diferentes, exemplo:

Essa tabela tem SNR mais conservador porque aparentemente leva em conta uma taxa de erros maior tipo 99% (E a outra algo tipo 99,99%), o Bit Error Rate. Fora que se for ver tabelas oficiais de sensibilidade uns datasheets citam coisa tipo "-85dBm (10% error)", ou seja, se aplicar a margem sobre essa sensibilidade exata terá 10% de perdas "apenas" (E isso é considerado aceitavel no maldito mundo do marketing), 1 de cada 10 pings perdido, isso é uma rede lixo... mas pra fins de marketing tá tudo certo.

----------


## emilidani

> Consegui resolver o problema desse enlace, estava usando inicialmente antenas de 31dBi +RB912, dai optamos em trocar radio para ganhar mais nos sinal, trocamos para RB922 sinal foi para -55dBm mas na resolveu só ficava estável no MCS11 que passava em torno de 65Mbps, resolvemos trocar antena 34dBi da Ubiquiti+RB912, sinal caiu pra -43dBm com isso esta passando uns 130Mbps.



perfeito, é bem simples so se trata de niveis de sinal!!!

----------


## rubem

> Consegui resolver o problema desse enlace, estava usando inicialmente antenas de 31dBi +RB912, dai optamos em trocar radio para ganhar mais nos sinal, trocamos para RB922 sinal foi para -55dBm mas na resolveu só ficava estável no MCS11 que passava em torno de 65Mbps, resolvemos trocar antena 34dBi da Ubiquiti+RB912, sinal caiu pra -43dBm com isso esta passando uns 130Mbps.





> perfeito, é bem simples so se trata de niveis de sinal!!!


Mas tem alguma outra questão nesse caso, apontamento de antena provavelmente.

Porque trocando de 31 pra 34dBi são 3dBi de diferença no ganho, 3dBm por lado, 6dBm ao todo, e -55 + 6 daria -49dBm.
Se subiu pra -43dBm é porque OU as antenas de 31dBi estavam mal alinhadas, OU tinha problema de fábrica nelas (E eu não confio é no acabamento das Algcom, solda feia tipo a que eu faço, e folha de alumínio na ponteira, não me inspiram confiança).

O ganho de uma antena em bom estado tem tudo a ver com nível de sinal, trocar antena de 33 por 34dBi só deve mudar 1dBm no nível de sinal, se trocar nos 2 lados dum PTP só deve mudar 2dBm, se mudar algo além (Ou diminuir) então tem algo variando além do ganho da antena, tipo apontamento, conector, cabo, ou antena de angulo mais aberto pegando reflexo do chão (Multipath diz a teoria que não tem poder pra derrubar sinal, teria que chegar muuuuuita onda em contrafase pra criar isso, devia derrubar o throughput mas não o sinal).

----------


## Jhonvalter

Rubens meu amigo dá uma olhada nessas imagens e veja que problema nos persegue. Durante o dia o ping para esse lado do enlace e 3, 5, 6 e por ai... agora depois das 20 horas fica desde jeito, porém já trocamos canal fizemos de tudo um pouco e nada de exito. Rocket m5 com disco de 25db. Tava pensando em testar um esse enlace de 3.5 km por um par de antena da intelbras APC 5M-18.Anexo 60356Anexo 60357Anexo 60359

----------


## geovane.torres

> O problema não é cair em MCS0 se deixar no modo auto, se cair no MCS0 é porque o sinal está ruim. O problema é subir pra MCS5 ou 6 mas o troughput ficar ridículo. 
> 
> Isso não ocorre só em modo N, você consegue conexão a 54M em G com sinal -65, mas vai ter troughput digamos 2Mbps, se baixar pra 18M no datarate a sensibilidade melhora, o nº de bits por simbolo diminui e tem menos perdas nas sub-portadoras, e o troughput sobe de 2 pra 12Mbps (Baixando o datarate, mudança que altera potencia e sensibilidade).
> 
> Se vai trafegar 2Mbps, pra quem usar MCS7? Esse MCS vai usar sempre todos os bits do simbolo, com muitos bits por simbolo a sensibilidade do hardware cai muuuuuuito (Vide ficha técnica dos aparelhos, a sensibilidade em MCS5 a 7 é péssima comparada em MCS0 ou 1), e o hardware e o software tem que processar todos os bits do simbolo pra "obter" os míseros 2Mbps. Porque não usar MCS0 nesse caso? Vai ter sensibilidade ótima, vai ter potencia maior, vai ter tempo de processamento menor, portanto as perdas de pacotes serão menores.
> 
> Eu testei MCS3 na torre, e nos clientes livre de MCS0 a 3, mas hoje penso em fixar nos cliente em MCS0. Porque? Porque em MCS0 cabe perfeitamente o upload do cliente e as respostas dos pacotes. MCS baixo no cliente tem vantagem? Tem, cria menos processamento pra torre. Tem desvantagem? Não permite upload alto, tipo não mais que 4Mbps. Quem aí vende conexão com mais de 4M de upload?
> 
> Você pode ter datarate diferente na torre e no cliente, quanto menor o datarate menor o trafego MAXIMO, mas também será menor o processamento, e em torre quando você quer muitos clientes num painel você tem que optar por modulações que exijam menos processamento. Usar por exemplo modo G pra PTP de 15M (Em 48-54M) é bobeira em hardware de hoje porque o processamento nesse modo é grande comparado a modo N em MCS3, que terá até mais que 15Mbps de troughput com tempos de respostas e perdas menores.
> ...


Boa noite a todos !

Rubem por gentileza, teria como vc analisar as configurações e me dizer o que está de errado ? segue os prints do rocket m5 e da nano loco m5 de cliente.
Minha rede hj é de 30 clientes 
link adsl 25 megas gvt
Rb 493-ah para autenticar os clientes ppoe
rocket m5 conectada a uma omni ubiquit 13 dbi 5.8 ghz
nos clientes tenho 5 airgrid m5 e 25 nano loco m5

obrigado


sucesso a todos

segue abaixo configuração do equipamento de cliente

----------


## rubem

@*geovane.torres* , se já resolveu o problema ignora o comentário.

Pra mim que seu problema está aqui:
https://under-linux.org/attachment.p...9&d=1437690029

Veja que o ruído (NOISE) dos clientes chegando está em -86dBm, e tem cliente com sinal ruim tipo -76dBm.

Isso é uma margem entre ruído e sinal de apenas 10dBm, SNR de 10dBm é insustentável até pra PTP, que dirá quando tem duzias de conexões.

Teria que ver a origem desse ruído em -86dBm, ele está meio alto. E se não tiver como reduzir isso, terá que aumentar o sinal dos clientes, colocar todos com sinal ao menos -65dBm (Isso será mais de 20dBm de SNR, não é perfeito mas é usável).

Como aumentar sinal de cliente? Aumentando o ganho de antena ou a potência de transmissão deles, no setup se com 18dBm de potencia o sinal é -76dBm, ao aumenta pra 22dBm o sinal aumentará 4dBm, ou seja, vai passar de -76 pra -72dBm, ainda não é suficiente, então tem que ver pessoalmente se esse cliente tem visada e zona de fresnel boa, porque em 1Km um NS Loco devia chegar com sinal mais alto que -72dBm SE tivesse visada total (Ou zona de fresnel quase totalmente desobstruída).

Um PTP até fica usável quando tem sinal baixo e ruído, mas quando tem 20 pessoas conectadas o sinal baixo e ruído começam a incomodar, pela imagem parece que é o caso, "o que fazer" depende da origem do ruído ou sinal baixo, mas um ruído desse com sinais tão baixos realmente não tem como dar uma rede boa, é trabalhoso melhorar sinal de cliente em cliente, mas... o sinal deles está ruim.

----------


## NielsonPadilha

Meus planos aqui são de 1 a 5mb de down e de 640kbps de up no máximo. Setei na torre (APC-5M-90+) MCS12 em 20 Mhz usando somente N e nos clientes até 1,5 km to usando WOM 5000 Mimo(Usando firmware 5.0 BETA 4.2, porém ainda não usei o ipoll) com MCS8 em 20mhz somente N, a potência desse cliente a 1km está a 15dbm, os demais estão de 7 a 9 dbm, e acima de 1,5km até 3km estamos usando o APC-5m-18+. Nessa torre tenho 2 Setoriais A e B.

Meu pior cliente ta a quase 1km e com fresnel não tão limpo (Devido a altura de algumas árvores, porém não da pra ver corretamente a visada devido a dificuldade do local ser alta e a dificuldade de colocar a escada de 2 lances. A instalação fixamos um suporte na parede e colocamos um mastro de 3m onde o wom 5000 mimo está no topo apontando para direção de nossa torre) As vezes o SNR caí rapidamente para 16 mais logo volta para acima dos 20.

Oque realmente incomoda é os picos que da onde o sinal fica ruim. Vejam:

http://prntscr.com/8558hr
http://prntscr.com/8558nn
http://prntscr.com/8558s0
http://prntscr.com/85580t

To esperando a intelbras arrumar o ipoll para ver oque melhora.


==========
UPdate: Atualizei os clientes para MCS9. Não sei se é impressão minha, mais achei o mcs9 mais fluido para conexão. (Testando uma conexão de 2 mb)

Abraços

----------


## erlindo

boa noite entrei agora para saber sobre MCS, muito bom o que vcs estão falando, queria uma ajuda...

na torre eu uso rb912 e nos clientes sxt, nao consigo deixar o ccq ali em 100% em todos clientes visados, deixei a potencia no máximo das sxt, baixei a potencia das sxt, e nao fica bom qual a conf. certa para isso.. Ajudaaaaa...  :Big Grin:

----------


## rubem

Eu diria que você tem 4 clientes com sinal bem ruim:


É bem fácil 2 ou 3 clientes ruins detonarem com a capacidade de processamento da RB.

Mas você está usando 40MHz de largura. Precisa disso tudo mesmo? Se é cidade grande deve ter poluição aos montes, e se tem poluição demais o jeito de ter qualidade é com canal mais estreito, e não mais largo. Teste 20MHz mesmo.

Marque uns datarates básicos, não apenas os suportados. 
E... porque marcou datarates de polarização simples? (MCS0 a 7 são pol. simples, se misturar Airgrid com Nanostation não vai caber 38 simultaneos nunca, use apenas dupla-pol. se quiser otimizar célula) Testa marcar apenas pol. dupla, e nos clientes marque só 2 ou 3, tipo MCS10 e 11 talvez, afinal o upload deles provavelmente será mínimo (E pode ver que o CCQ deles pra torre é bem pior que da torre rumo aos clientes, o RX na torre é o TX dos clientes).

----------


## erlindo

blz vou fazer um teste aki e posto ai depois obrigado..

----------


## jeffao

Rubem,

Eu fiz essa alteracao TX - MCS 10 na torre e TX - MCS 8 no cliente, não deu certo ele conecta com o menor, tanto no TX/RX, tem algum detalhe que preciso fazer para ele fazer o modulação correta?

----------


## rubem

> Rubem,
> 
> Eu fiz essa alteracao TX - MCS 10 na torre e TX - MCS 8 no cliente, não deu certo ele conecta com o menor, tanto no TX/RX, tem algum detalhe que preciso fazer para ele fazer o modulação correta?


Qual equipamento?
Se for MK ou UBNT é estranho, o normal é permitir datarates diferentes.

Se olhar só no AP, as vezes aparece o TX e RX no mesmo datarate, mas olhando no setup do cliente o TX dele é diferente do exibido no AP. Nessa hora eu ignoro isso e me preocupo só com os sinais chegando no AP (Olhe os sinais no AP, não no cliente).

Não sei se é bug de versão isso de exibir datarate diferente no AP e cliente, mas o normal em MK ou UBNT é permitir qualquer RX com qualquer TX, tipo:
https://under-linux.org/attachment.p...1&d=1441761135

----------


## emilidani

Interessante,,, nao sabia que pode conectar asimetrico, pensava que sempre conecta no menor MCS setado em ambos radios.

----------


## jeffao

Bom dia,

AP: Mikrotik
HT Supported MSC: 8,9,10
HT Basic MCS: 8
Data Rates: 6mbps
---------------------------
Cliente
NanoLoco M5
Datarate: mcs8

obs: no NANOLOCO M5 ele conecta de boa e data rates fica certo, RX-MCS10/TX-MCS8
----------------------------
Cliente
SXT Lite5
HT Supported MCS: MCS8
HT Basic MCS: MCS8
Datarates: 6mbps
obs: SXT Lite5 somente conecta com o MCS8, tanto o TX-MCS8/RX-MCS8, faz teste de banda so passa 13mb, tanto o AP e a Estacao estão na mesma versao 6.28.
Se marcar apenas MCS10 no ap e MCS8 no cliente, o sxt não conecta.

----------


## rtfl

Rubem aqui estou usando MSC 1 na torre e MCS 0 cliente, sera que esta correto?

----------


## rtfl

> Rubem aqui estou usando MSC 1 na torre e MCS 0 cliente, sera que esta correto?


clientes estão distantes a 500 mts no maximo. SNR variando de 13 a 21 25

----------


## rubem

> Bom dia,
> 
> AP: Mikrotik
> HT Supported MSC: 8,9,10
> HT Basic MCS: 8
> Data Rates: 6mbps
> ---------------------------
> Cliente
> NanoLoco M5
> ...


Não sei se resolve seu problema, mas no AP marque o basic também MCS9 e 10. Ele é uma tabela que permite multiplas seleções e não só 1 porque ele trata o datarate "básico" como datarate pra trocar de dados de sincronia como beacons, preambulos e etc. Enquanto o "supported rates" é pros pacotes do usuário, dados de unicast mesmo.

Enfim, recomendo marcar em básico tudo o que marcar em suportado.

Mas isso de não conectar com um num datarate diferente do outro pra mim é novidade, já fiz mini-PTP com SXT Lite5 (Mas provavelmente na versão 5.x, eu nunca atualizo) em coisa tipo MCS10 e 12, ou 9 e 12, sem esse problema.





> clientes estão distantes a 500 mts no maximo. SNR variando de 13 a 21 25


Esse SNR está assustador hein! Se tem sinal digamos -60dBm (Em 500m com visada é normal ter mais que isso), um SNR de 13dBm significa ruído em -73dBm, que é uma gritaria enorme no ouvido do radio, coitado dele.

MCS0 e MCS1 são datarates de polarização única, você tem SXT, Wom ou algo assim? Porque se for NS ou equiptos de dupla-polarização você devia estar usando MCS8 e 9, que são os mesmos modos mas em dupla-polarização.

Mas veja esse ruído aí, se não é culpa de antenas próximas demais, ou fonte chaveada atras dos radio, um ruído alto seria -85dBm, e se for esse o ruído tem que fazer o SNR ficar acima dos 20dBm mesmo, ou seja, com sinal -65dBm pra cima (Em 500m com visada isso é fácil, mas tem que ter visada senão você se obriga a aumentar potência, aí só gera ruído em canais e AP's vizinhos, aí seus vizinhos aumentam a potência, e a bola de neve gerada inutiliza o espectro).

Onde tem muito ruído e não tem o que fazer, o melhor é justamente usar dupla-polarização, ao invez de MCS2 (SISO) use MCS9 (MIMO) que passaria teoricamente a mesma banda, mas na prática tem CCQ maior (Uma das polarizações terá ruído menor, é o normal) e o throughput não é o mesmo na prática.

----------


## rtfl

> Não sei se resolve seu problema, mas no AP marque o basic também MCS9 e 10. Ele é uma tabela que permite multiplas seleções e não só 1 porque ele trata o datarate "básico" como datarate pra trocar de dados de sincronia como beacons, preambulos e etc. Enquanto o "supported rates" é pros pacotes do usuário, dados de unicast mesmo.
> 
> Enfim, recomendo marcar em básico tudo o que marcar em suportado.
> 
> Mas isso de não conectar com um num datarate diferente do outro pra mim é novidade, já fiz mini-PTP com SXT Lite5 (Mas provavelmente na versão 5.x, eu nunca atualizo) em coisa tipo MCS10 e 12, ou 9 e 12, sem esse problema.
> 
> 
> 
> 
> ...


eh aqui toh usando no ap WOM5000 SISO POL VERT, potencia do radio 7 dbm, ack no menor possível 300 mtrs.

----------


## rtfl

> Não sei se resolve seu problema, mas no AP marque o basic também MCS9 e 10. Ele é uma tabela que permite multiplas seleções e não só 1 porque ele trata o datarate "básico" como datarate pra trocar de dados de sincronia como beacons, preambulos e etc. Enquanto o "supported rates" é pros pacotes do usuário, dados de unicast mesmo.
> 
> Enfim, recomendo marcar em básico tudo o que marcar em suportado.
> 
> Mas isso de não conectar com um num datarate diferente do outro pra mim é novidade, já fiz mini-PTP com SXT Lite5 (Mas provavelmente na versão 5.x, eu nunca atualizo) em coisa tipo MCS10 e 12, ou 9 e 12, sem esse problema.
> 
> 
> 
> 
> ...


fonte lah em cima tem uma caixa hermética de energia com amplificador UHF/VHF proeletronic... o logico as antenas UHF/VHF.

----------


## jeffao

Boa tarde Rubem

Sr, nao deu certo, continua mesma coisa.
No AP se eu colocar MCS8, 9, 10, na estação colocar MCS8, ele não conecta. Agora se eu colocar no AP MCS8, e na estação colocar MCS8, 9, 10, ele conecta so que com MCS8,

----------


## rubem

> eh aqui toh usando no ap WOM5000 SISO POL VERT, potencia do radio 7 dbm, ack no menor possível 300 mtrs.


O ACK-timeout abaixo do ideal geralmente causa mais perda de pacotes. Bom seria usar ack acima do ideal.

Mas a WOM tem uma exibição estranha de ruído, não confio nesse dado nela. Aí não sei dizer se isso seria um ambiente com muito ruído mesmo (Harmônicas de UHF e VHF) ou se é só exibição de ruído que não é real, não sou de usar WOM.





> Boa tarde Rubem
> 
> Sr, nao deu certo, continua mesma coisa.
> No AP se eu colocar MCS8, 9, 10, na estação colocar MCS8, ele não conecta. Agora se eu colocar no AP MCS8, e na estação colocar MCS8, 9, 10, ele conecta so que com MCS8,


Hum, aí já foge da minha experiência, ainda não ví um caso desse de um em MCS10 e outro em MCS8 não conectar, nem imagino que outra config. poderia criar essa incompatibilidade.
(As vezes não conecta se marcar datarate, tipo 1M ou 6M, ou 54M, mesmo em modo somente N nuns casos a aba Datarates (Que só DEVIA fazer efeito em A/N ou A-only) impede ou permite conexão.

O pouco que diria pra testar (Além de mexer na aba Datarates) é marca preambulo longo, e talvez habilitar WDS dinamico.

----------


## rtfl

Nossa Rubem valeu msm... obrigado.  :Smile:

----------


## telmetrics

Olá Rick!

Ajustar manualmente o MCS é uma das melhores opções a fazer em casos onde o enlace apresente instabilidade ou problemas de performance claras.

Para definir o MCS ideal na prática para seu enlace operar basta desmarcar a opção automatica ao lado do MCS na guia Wireless no seu UBNT e selecionar o MCS desejado. Assim o seu MCS ficará fixo e não irá se alterar.

Para escolher o MCS mais adequado para seu enlace de modo fácil e prático, sem fazer cálculos, basta em rádios 2x2 selecionar o maior MCS possível, no caso MCS15 e ir baixando até chegar em MCS8. E a cada mudança fazer um teste de banda e ir anotando. No fim veja qual resultado deu mais largura de banda sem perda de pacotes. Esse será o MCS mais adequado a situação atual do seu enlace.

Caso tenha alguma dúvida fico a disposição

Rafael Themístocles
[Consultor em Redes e Telecomunicações/NGN Network Project Engineer]
http://www.telmetrics.com.br
E-mail: [email protected]
Skype: rafaelthemistocles




> Olá Pessoal gostaria de saber se alguém sabe como eu acerto o mcs do mikrotik para que ele mantenha o CCQ mais proximo de -100% mantendo o radio com o sinal dentro do envelope determinado pelo radio???

----------


## jeffao

Bom dia Rubem

Qual a versão do Mikrotik que vc usa que funciona as configurações dos MCS?
Vou fazer um downgrade, para testar

----------


## rtfl

> Olá Rick!
> 
> Ajustar manualmente o MCS é uma das melhores opções a fazer em casos onde o enlace apresente instabilidade ou problemas de performance claras.
> 
> Para definir o MCS ideal na prática para seu enlace operar basta desmarcar a opção automatica ao lado do MCS na guia Wireless no seu UBNT e selecionar o MCS desejado. Assim o seu MCS ficará fixo e não irá se alterar.
> 
> Para escolher o MCS mais adequado para seu enlace de modo fácil e prático, sem fazer cálculos, basta em rádios 2x2 selecionar o maior MCS possível, no caso MCS15 e ir baixando até chegar em MCS8. E a cada mudança fazer um teste de banda e ir anotando. No fim veja qual resultado deu mais largura de banda sem perda de pacotes. Esse será o MCS mais adequado a situação atual do seu enlace.
> 
> Caso tenha alguma dúvida fico a disposição
> ...


se for SISO ai eh do MCS 8 para baixo?

----------


## berghetti

> se for SISO ai eh do MCS 8 para baixo?


1x1 (SISO) os MCS são de 0 á 7;
2x2 (MIMO) = 8 á 15;
3x3 = 16 á 23;
4x4 = 24 á 31

ai está a tabela com as modulações de cada MCS
http://mcsindex.com/

----------


## telmetrics

Exato rtfl! Se for um único Chain 1x1 use a mesma técnica só que de MCS8 pra baixo.

No Mikrotik, pra deixar o MCS fixo é só vc marcar a opção advanced no menu wireless e na guia MCS deixar somente o MCS qual deseja usar ao invés de deixar todos marcados.

Att

_Rafael Themístocles_
_[Consultor em Redes e Telecomunicações/NGN Network Project Engineer]_
http://www.telmetrics.com.br
_E-mail:_ rafael_themisto[email protected]
_Skype: rafaelthemistocles_




> se for SISO ai eh do MCS 8 para baixo?

----------


## JonasMT

Mesmo problema aqui, se no cliente nao cetar o mesmo data rate do ap mk ele simplismente nao conecta.

Queria usar 11 no ap e 8 nas sxt, teste desde a versao 6.20 a 6.32.1 sem sucesso.




> Boa tarde Rubem
> 
> Sr, nao deu certo, continua mesma coisa.
> No AP se eu colocar MCS8, 9, 10, na estação colocar MCS8, ele não conecta. Agora se eu colocar no AP MCS8, e na estação colocar MCS8, 9, 10, ele conecta so que com MCS8,

----------


## FMANDU

Amigo @*JonasMT* , apos diversos testes vi que é possivel conectar as cpes com rates diferentes sem ter que usar o dafaut. O que eu fiz aqui foi marcar somente o MCS 12 e MCS9 em HT Supported MCS e não marcar nada em HT Basic MCS. As cpes mais longes coloquei em mcs 9 e as mais perto em mcs12. So que o ap não vai transmitir em mcs 12 para todos, ele vai ficar trabalhando em somente mcs 9 para a cpe que esta setado em 9 e a mesma coisa para 12. Creio eu que gaste menos processamento na rb do que deixasse em defaut com o monte de rate variando. Notei uma melhora na latência das cpes mais longes por causa do ganho na sensibilidade. E como eu nao sabia como ficaria o tx power, acabei deixando em defaut, fazendo com que o ap decida a potencia para cada MCS.






> Mesmo problema aqui, se no cliente nao cetar o mesmo data rate do ap mk ele simplismente nao conecta.
> 
> Queria usar 11 no ap e 8 nas sxt, teste desde a versao 6.20 a 6.32.1 sem sucesso.

----------


## FMANDU

Eu senti uma melhora muito boa no ccq e na latencia dos cliente que necessitavam de mais sinal. Agora não sei se dessa forma limita o desempenho e throughput do ap.

----------


## rubem

Limita o throughput sim, mas diminui processamento (Uso de CPU e chipset de RF).

Pra quem precisa tráfego alto (Uns 30Mbps agregado por rádio) não é uma boa, mas pra plano comum (<10M) não faz efeito no throughput geral.

----------


## FMANDU

Pior @*rubem*, pois preciso aqui justamente de uns 35M por rádio, o consumo subiu muito por aqui, meus clientes estão com 4 ou 6M de down. Esse setor foi um que instalei um SXT SA 90º só tem 3 clientes nesse lado, vou instalado com cuidado e sempre monitorando pra ver como vai se comportar esse AP. 
Mas qual base de throughput vou ter? MCS 12 ou 9 ? Acho q a MK errou so nisso, em limitar juntos o tx e rx. Nos UBNT a gente pode ter mcs 12 no ap e mcs 9 no cliente tranquilo.

----------


## silviola

@*rubem* , vou alugar um pouco teu conhecimento, mas meu egoísmo, se me permitires, talvez vá servir pra muita gente.

Aqui nós basicamente vinhamos tratando quase que de MK, deixa eu desvirtuar um pouco pro lado UBNT, te apresentar um cenário "default" da maioria dos provedores pequenos que usam UBNT, e pedir tua sugestão:

Cenário:
1 - POP com painéis SiSo com Bullet M5 .
2 - ~30 Clientes com Airgrid M5 por painel .
3 - Planos entre 0,5Mb e 3Mb .
4 - Células com máximo de 1Km de Raio .
5 - APs com ~6dBm
6 - Clientes entre ~4dBm e 12dBm ( 23 e 27 dBi's para manter um mínimo de -66 de sinal, com foco em -62 )

As dúvidas:
a) UBNT permitindo apenas fixar um único MCS, no AP setar fixo ? no máximo ? ( 7 ) ? menos ? deixar automático ? não, quanto ? ( célula SiSo - até MCS 7 ) 
b) mesmo questionamento, só que agora nos equipamentos dos clientes.
c) aproveitando o embalo, falando sobre ACK, mas nesta mesma balada, nos clientes e no AP: fixo, automatico, fixo de um lado, automatico do outro... enfim.

----------


## rubem

> Pior @*rubem*, pois preciso aqui justamente de uns 35M por rádio, o consumo subiu muito por aqui, meus clientes estão com 4 ou 6M de down. Esse setor foi um que instalei um SXT SA 90º só tem 3 clientes nesse lado, vou instalado com cuidado e sempre monitorando pra ver como vai se comportar esse AP. 
> Mas qual base de throughput vou ter? MCS 12 ou 9 ? Acho q a MK errou so nisso, em limitar juntos o tx e rx. Nos UBNT a gente pode ter mcs 12 no ap e mcs 9 no cliente tranquilo.


Essa é a parte chata de múltipos datarates, pode ter um datarate diferente pra CADA cliente.
Se 5 trocam dados em MCS12 e 5 em MCS9 o throughput vai ser menor que todos os 10 usando MCS12.
O problema é o tempo gasto pra cada troca de pacote, pra enviar os mesmos bytes de dados do cliente um datarate mais baixo usa mais tempo. E... throughput se mede em trafego POR SEGUNDO. 

Eu não tô com tempo nem equipto pra testar isso, mas parece que tem relação com preambulo, as vezes selecionando só preambulo longo tudo conecta, as vezes tem que marcar o datarate mais baixo na aba datarate (6Mbps, que é o que o preambulo uso, ou 1/2Mbps)), ou pior, usar modo A/N ao invés de somente N (E marcar só 6M em A). Tá uma zona esse negócio de datarate em versão recente, mas não consegui achar a "regra" ainda, vou mexer num ptp e acho que vou ter problema, mas configuro tudo do mesmo jeito e conecta com datarates diferentes dos 2 lados. Depois em outro acho que vai ser tranquilo e não conecta se não deixar no default ou setar qualquer coisa anormal.







> @*rubem* , vou alugar um pouco teu conhecimento, mas meu egoísmo, se me permitires, talvez vá servir pra muita gente.
> 
> Aqui nós basicamente vinhamos tratando quase que de MK, deixa eu desvirtuar um pouco pro lado UBNT, te apresentar um cenário "default" da maioria dos provedores pequenos que usam UBNT, e pedir tua sugestão:
> 
> Cenário:
> 1 - POP com painéis SiSo com Bullet M5 .
> 2 - ~30 Clientes com Airgrid M5 por painel .
> 3 - Planos entre 0,5Mb e 3Mb .
> 4 - Células com máximo de 1Km de Raio .
> ...


Em UBNT na verdade você seleciona o TX Rate MAXIMO. Se marcar um MCS5 e deixar o automatic do lado marcado ele vai variar de 6M a 54M em A (Já que UBNT é fixo em modo A/N), e de MCS0 até MCS5 em N.
Sem a caixa automatic marcada você fica fixo no datarate selecionado (É o máximo, mas ele não muda automaticamente/sozinho pra datarates menores).

Meu problema com datarate mudando é que o rádio é burro e não respeita uma relação sinal/ruído decente (SNR decente pra datarate alto devia ser 25dB ou mais), e respeita menos ainda uma relação decente entre sinal e sensibilidade (Pra até uns 3 ou 4Km uma relação boa é acima de 12dB, se a sensibilidade do datarate é -74dBm então o sinal mínimo aceitavel seria -62dBm, são 12dBm de relação). Ou seja, deixando automatico as vezes essas bestas quadradas desses softwares insistem em MCS7 mesmo com sinal ridículo tipo -70dBm, sendo que isso é inferior até à sensibilidade do datarate! Ocorre muita perda de pacote, o ping fica com jitter enorme (Não perde todos os pacotes, são alguns, por isso o ping não fica fixo em digamos 200ms, mas sim varia, um dá 2ms mas outro dá 50ms, isso é tempo gasto reenviando esse pacote, perda zero significa ping sempre baixo tipo 1-3ms).

Em UBNT se tiver sinal suficiente eles só caem pra datarate baixo (1M ou 6M exibidos no status) quando NÃO tem tráfego sendo trocado, isso é o datarate do preambulo, as confirmações de presença ("-Ainda tá conectado?" "-Tô sim"), enfim, se ver esses datarates quando não tem tráfego não se preocupe, não é burrice do rádio e sim economia de processamento, se só tem dados sobre a conexão pra trocar (Nada de dados do clientes) não tem porque usar datarate mais alto que tem mais risco de sair ilegível devido a ruído e cia.
Enfim, pode usar um MCS5 com automatic marcado, se todos os clientes chegarem na torre com -62dBm tá ótimo.

Mas não se engane com sinal exibido, o "signal strength" geralmente é o sinal do preambulo, que é feito no menor datarate, o sinal REAL é exibido separado e é sempre mais baixo.
Em UBNT é exibido:


Em MK fica mais claro, ele mostra o sinal por datarate, dá pra ver que o sinal exibido é na verdade no menor datarate, e o sinal real é o do datarate em uso no momento, nesse caso tem uma diferença gigante de 6dBm (Suficiente pra mudar um CCQ de 80% pra 100%):

Notar na imagem que quem tem sinal -50dBm é 6M, o menor datarate, que é usado pelo preambulo, e é o que tem atualização a 0 segundos (Preambulo é trocado toda hora, pacote de cliente só troca quando o pc/note/smartphone acessa algo).


(Como você usa SISO não vai ter sinal do chain0 e chain1 (Horizontal e vertical), fora isso mais nada muda)

Se os softwares dos radios mal sabem lidar com margem considerando o sinal do preambulo (signal strenght), que dirá saber ver o sinal real do datarate! Eles insistem em datarate alto mesmo que isso signifique 20% de pacotes perdidos, geralmente a tomada de decisões pra subir ou descer um datarate era (Nos livros até o começo da era N era normal citar isso) ter 3 ou 4 pacotes perdidos na sequencia. Explico: Perde um e reenvia, perde outro e reenvia, mas o 3º é enviado: Mantém o datarate. Mas poxa, perdeu 2/3 do que enviou! É assim porque wifi é protocolo feito pra uso movel dentro de um local fixo, alguém passa na frente e atrapalha a troca de 2 ou 3 pacotes, wifi foi planejado pra ignorar essa variação e continuar em datarate alto. Mas no uso que damos isso é terrível porque se perder 2 pacotes pode ter certeza que não é um passaro ou o godzilla passando rapidinho na frente, se perdeu 2 pacotes ocorreu algo muito errado no trajeto e precisa baixar o datarate.

O datarate module alternative nos Ubiquiti (Nos firmwares de menos de 2 anos) tem um modo diferente de tomar essas decisões, como esse tipo de decisão não existe no padrão o fabricante não precisa divulgar/padronizar isso, essa opção tem dado throughput melhor nuns lugares com sinal meia-boca então imagino que ele analise de outra forma os pacotes e faças as predições de outro modo (Diferente do default dos firmwares).

Enfim, se tiver sinal -62dBm (E não for o signal strength, que é só o preambulo), eu não usaria MCS7 nunca, porque a sensibilidade dos radios nesse datarate está geralmente nuns -64 a -65dBm (Essa informação está no datasheet, google datasheet nanostatiom m5 pdf). E a margem entre sinal e sensibilidade devia ficar acima de 10dBm até por indicação da UBNT. PTP bom só existe com margem de uns 15 a 20dBm! Eu recomendo 12dBm. Se o sinal está em -62dBm, tem que usar o datarate cuja sensibilidade seja -74dBm ou menos, que deve ser MCS5 ou MCS6 (Tem que conferir no datasheet).

Nos clientes uma seleção baixa de datarate limita o upload, só isso. Se tiver upload de 1M nos planos ainda assim pode usar neles um max tx rate de MCS2 ou 3 tranquilamente, esses datarates permitiriam um upload agregado na casa dos 10Mbps, e duvido que chegue sequer a 2Mbps por rádio SISO.

Uma coisa interessante a fazer pra diminuir perdas de pacotes (E portanto o tempo que cada cliente "toma" do AP na torre) é no ack timeout da torre colocar um valor 10 a 20% maior que o cliente mais distante. Se o cliente mais longe está a 1Km, marque cerca de 1,2Km. E em cada cliente idem, se ele aparenta estar uns 500m, colocar acktimeout fixo em 600m ou pouco mais.
E usa o acktimeout auto (Logo na instalação) pra ver qualidade da visada e tal, se o cliente está a 500m (Acostuma a olhar num mapa e medir (No dedo mesmo, não precisa muita precisão) a distância antes de ir instalar) mas em auto está marcando 900m então tem algo errado na visada, seria caso de erguer antena ou como quebra-galho colocar um acktimeout ainda maior tipo 1500m (Se for plano de velocidade tipo 1Mbps tá tranquilo). O acktimeout maior que o ideal ignora uns reflexos, nem sempre muda o CCQ mas muda o ping (-l 32 e -l 1450), o ping tem relação direta com pacote perdido, um ping de 20ms em 500m é sinal que o o primeiro pacote enviado foi perdido e precisou reenviar, pacote perdido na conexão wifi não significa que o PC do cliente vai ter que reenviar, é a CPE do cliente que reenvia pro AP da torre, mas esse reenvio custa tempo e espaço na memória (Tem que guardar enquanto não recebe o checksum ("Recebi um pacote, checksum XXXX")), a CPE do cliente ter que reprocessar isso é tranquilo porque ele só tem 1 conexão pra cuidar, ele pode RECEBER sinal baixo, mas o AP da torre não pode, ele tem duzias de conexões pra cuidar, o RX nele tem que ter CCQ de perto de 100%, o resto pode ser pior mas o RX na torre tem que ser muito bom.
(E geralmente essa é a parte negligenciada)

----------


## silviola

Rubens, vou precisar dar uma racionalizada então pra entender bem.


De fato, meu pior cliente está com sinal de RX em -66 de Signal Strength com -92 de Noise Floor, teríamos aí um sinal real de -74 . Correto ?
Devo, pela lógica então, fixar um MCS no AP de tal modo que ele consiga atender este pior cliente, seguindo a margem de segurança recomendada de 12dBm. Mas minha distância máxima é de 1Km, logo posso reduzir um pouco esta margem de 12 para 8 ?
Se sim, com meu sinal real já em -74 , somando -8 de margem , tenho -82 de sinal puro com margem.
O datasheet da Airgrid M5 ( https://dl.ubnt.com/datasheets/airgridm/airGrid_HP.pdf ) em MCS5 me mostra sensibilidade de -83 .
Se meus cálculos e minha lógica estiverem corretos, visto este pior cliente, seria por aí MCS5 fixo no meu AP ? Ou MCS5 auto ? vantagens e desvantagens ?


Vamos adiante, é claro que projetar throughput em um meio tão imprevisível como wi-fi é quase como especular na bolsa de valores, mas pela sua experiência, seja teórica ou prática, em um ambiente de 50 clientes conectados, com planos variando 0,5Mb a 3Mb, com quantos mega agregado esta célula
começará a degradar a latência ( chamo aqui degradação de latência, uma latência média acima de 5ms e/ou com picos acima de 30ms e/ou com perda de pacotes ) ?


Ainda, agora deixando o Ap de lado e focando no equipamento do cliente, obviamente que o upload médio de uma célula de clientes domésticos não ultrapassa a faixa de 15% em relação ao download. Um MCS 3 fixo seria de bom tamanho ? Aliás, fixar em todos os clientes ou fixar a la carte, dependendo do sinal de cada um ? Se sim ( a la carte ) não haverá muito processamento ? onde ( cliente ou AP ) ? Ou MCS 3 auto ?
Setar um MCS mais baixo no cliente, não vai aumentar sua latência ? Mais de 2ms médios ? ( ok, de novo é algo imprevisível na prática, mas falando em projeção apenas )


Mais um pouco, se eu fixar o Datarate, tanto faz os modos "alternative" ou "default" do firm da UBNT correto ?

Sobre ACK, nenhuma dúvida.

----------


## rubem

O "sinal real" tem que ver no setup, ele não tem relação com signal strength ou com o ruído.

Se usar MCS0, ou 6M em 802.11A, o signal strength será igual o sinal no datarate em uso.

E o ruído independe de nível de sinal ou qualquer coisa, o ruído tá presente ou não, seja lá qual for o sinal escaneado. Só é importante que o sinal escaneado esteja pelo menos uns 25dB acima do ruído (SNR de 25dB).

Sobre margem de 8dBm, é muito pouco. 12dBm é o mínimo que muito cálculo aponto. Tem muita discussão mas se recomenda geralmente 10dBm como mínimo pra manter conexão, 15dBm pra ter troca decente de pacotes, e 20dBm pra ter conexão ótima. Outro time defende uma margem maior conforme aumenta a distancia mas começando com 12dBm, seja a 100m ou a 2Km.
(Esse cara aqui fez um algoritmo muito bom pra definir essa margem conforme a distância, em PTP até uns 30Km isso sempre bateu certinho (Acima nunca fiz): http://mayo.nuvisions.net/ubnt_link/ )

Se a sensibilidade em MCS5 é de -83dBm, o sinal nos clientes (Não o signal strength) deveria ficar pelo menos 12dBm acima disso, -83 + 12 = -71dBm. Esse seria o sinal mínimo pra deixar nos clientes (MCS5 no AP significa que o cliente vai receber pacotes nesse datarate, no setup da CPE do cliente o sinal deve ficar acima de -71dBm).

Já o sinal DOS clientes (Sai do cliente e chega na torre) deveria levar em conta a sensibilidade do AP. Se for NS M5: 
https://dl.ubnt.com/datasheets/nanos...nsm_ds_web.pdf
A sensibilidade de MCS3 (Que será configurado no MAX TX Rate na CPE no cliente) é de -90dBm, com 12dBm de margem: -90 + 12 = -78dBm.
Ou seja, se todos os clientes estiverem em MCS3, deverão ter sinal acima de -78dBm (O que não é difícil).

Só que -78dBm já ia tropeçar no SNR. Se o ruído (Noise floor) aí é -92dBm, isso é uma relação sinal-ruído (*S*ignal-to-*N*oise *R*atio) de só 14dB.
Tem muita tabela de SNR pela web (Nenhuma minha), a forma de cálculo também varia (Porque depende do percentual de erros aceitável, um percentual de erros de 10% é absurdo, geralmente se usa 1% como taxa aceitável). Exemplo:

MCS3 com preambulo curto é esse datarate de 28M. Indica SNR necessário de 17dB.

Aqui outro:

MCS3 é modulação 16QAM, e usa codificação 1/2, logo, SNR recomendado também seria de 17dB.

E -92 + 17 = -75dBm.

Ou seja, na torre você deve escanear todos os clientes chegando com sinal acima de -75dBm. Quem está abaixo precisa ter instalação refeita, ou potência aumentada, ou equipamento trocado, etc.



Datarate pode deixar fixo, todos os clientes no mesmo, mas Acktimeout e potência não, esses sim variam conforme distância. Cliente a 100m precisa potência baixa e acktimeout mais curto que um cliente que está a 1Km.

Se fizer como você faz, de usar potência limitada (Isso exige caprichar na visada, coisa que muito provedor ignora) é fácil fazer todos os clientes chegarem na torre com sinal igual, digamos que -70dBm tá ótimo se eles usarem MCS3.

Já o sinal nos clientes não tem como padronizar. A torre emite digamos 30dBm EIRP, o sinal vai estar mais alto no cliente próximo e mais baixo no cliente distante, com isso não tem o que fazer (Exceto colocar antenas de ganhos diferentes, se existissem a venda). Mas se a torre emite com potência decente, nem os clientes a 100m vão receber sinal absurdo tipo -30dBm (Que ia gerar tantos erros e CCQ baixo como receber sinal lá pelos -75dBm, sinal alto demais tem um monte de reflexo, atrapalha o chipset, fica ilegível igual sinal baixo).

Torre> Cliente: Datarate fixo ou limitado, acktimeout fixo, potência fixa.
Cliente>Torre: Datarate fixo ou limitado, actimeout conforme distância, potência conforme sinal chegando na torre.


Datarate automatico (Indo até MCS7) só daria uma rede com CCQ ótimo (95-98%) se tivesse sinal suficiente pro maior datarate. Se a sensibilidade é -74dBm, e a margem de 12dBm é ok, o sinal mínimo pra datarate automático de todos os clientes seria -62dBm. Tanto no RX da torre como no RX dos clientes.

O sinal cliente>torre geralmente é mais baixo, e como o upload é sempre baixo, a melhor coisa do mundo é limitar o TX Rate nos clientes. Na torre as vezes mal faz diferença mudar porque uns rádios tem processamento decente (Um Rocket com AR9344 dá de 10 a zero num Bullet como AP). Se for deixar algo com datarate automatico faça isso na torre, mas limite as CPE's dos clientes num datarate bem baixo, afinal o sinal delas vai chegar na torre muito mais baixo que devia.


Sobre throughput, sempre falo que ele é metade do datarate, porque é mais simples lidar assim. MCS5 tem 52M de datarate, o throughput máximo conseguível vai ficar na casa dos 25Mbps. Até em PTP as vezes dá trabalho chegar nisso, imagina em PTMP.
Agora... o problema é cliente com sinal ruim: Ele perde pacotes. O radio precisa enviar, reenviar, e talvez reenviar pela 2ª vez um pacote que o radio/cliente com sinal baixo não entendeu (Ou entendeu mas mandou o checksum e o checksum é que saiu ilegível! Gritando com alguém a 100m de distância pode acontecer de um "Sim" ser entendido como "Não"... "Se falar com a boca debaixo do nariz" como dizem aqui).
Se no processo todo tiver muita perda de pacote, não tem como chegar nesse throughput agregado, é a situação que 1 cliente de sinal ruim tem que fazer tanto reenvio de pacotes que ele "pesa" por 2 ou 3 clientes de sinal bom. Se for cliente de sinal ruim e for um cliente que navega o dia todo tá feita a desgraça, o radio vai ficar o dia todo perdendo tempo com ele, tempo que podia ir pra clientes onde é enviar só 1 vez e tá tudo resolvido.

Então com sinal insuficiente não tem mesmo como chutar throughput, se todos estiverem com CCQ perto de 100% (95-98% já tá muito bom) vai chegar em metade do datarate (Uns 25M de download agregado se usar MCS5 pra isso, e uns 13M de upload agregado se usar MCS3 pra isso).

(O CCQ do upload conta, não adianta o envio do pacote ser ok se o cliente responder pra torre chegando com sinal tipo -78dBm, isso é só 14dB acima do piso de ruído (Noise floor), não é muito legível, o "Ok, recebi o pacote, checksum XXXX" fica ilegível e o AP da torre talvez reenvie o pacote porque ele não sabe se o pacote foi recebido ou se a falha foi no envio da resposta. Pra CCQ bom nos 2 lados. E não estranhe CCQ TX/RX 99/85% na torre, e no cliente ver algo tipo CCQ TX/RX 95/95%, (Quando devia ser 85/99%, o TX de um é o RX do outro) conforme o firmware a métrica muda, e o tempo de atualização e espaço em cabeçalho pra colocar essas informações irrelevantes também, você (Como um AP) só sabe direito quantas vezes você teve que repetir algo, logo você só sabe ter certeza do CCQ de TX. Você teria que perguntar pra outra pessoa (Como station/cliente) quantas vezes ELE teve que repetir algo pra você (Afinal alguma vez você pode literalmente não ouvido nada, não é que "ouviu mas não entendeu", pode ter 2 ou 3 sinais chegando ao mesmo tempo e ficando os 3 ilegíveis a ponto de você nem saber quem falou com você, enfim, exibir o CCQ de RX depende de trocar informação sobre isso, as vezes tem diferenças e isso não é o fim do mundo))


E por fim, sobre "datarate module", seja com datarate fixo ou automatico, conforme o datarate modulo o comportamento muda quando tem sinal ruim, é algoritmo de tomada de decisão diferente, independente de usar airmax ou não, de usar canal ou largura x ou y, numas conexões faz diferença, não é um "modulo especial pra datarate auto e com airmax". Se quiser testar, teste de qualquer jeito, não precisa ser nada específico pra ele (Mas ele só faz efeito quando o gargalo está sendo a tomada de decisões sobre alguns aspectos do pacote. Assim como Airmax, só faz diferença quando o gargalo é o congestionamento que os pacotes padrão tem (E que TDMA enfilera de outro modo). Pode testar Airmax de qualquer jeito (Datarate, canal, acktimeout, distância), mas só vai notar diferença em ambientes específicos (Onde algo gera o gargalo que ele resolve)).

----------


## silviola

Racionalizando, dessa vez vou puxar a sardinha um pouco pro meu lado, e não falar mais de forma genérica, mas do meu cenário.
Ok, então a margem é 12dBm no mínimo, anotado.
SNR tem haver com Signal Strength menos Noise Floor, no caso que apresentei, meu pior cliente está com -92 NF ( - ) -66 SS = SNR de 26
Este sinal de -66 que me referia é sim medido lá no cliente.

Algumas considerações sobre a imagem:
1. Não estranhe o fato de todos os clientes estarem 65/65 , eu faço alguns testes com minhas células, e esta é uma delas ( a única ) que está trabalhando com MCS 7 fixos em ambos lados ( mesmo vale para ACK - AP fixo no maior - Cliente fixo com ~10% acima do real )
2. O sinal do meu pior cliente no momento da medição ficou em -65, acredito que por causa da baixa umidade, em compensação o Noise Floor está em -91 ( alho por bugalho ).
3. A potência deste AP está em 6dBm.
4. A potência de todos os clientes está em 4dBm, a lista de associações está em ordem de pior para melhor sinal de RX ( AP ) , o último da lista (mais forte, não aparece na imagem ) está em -55 RX ( AP ) / -52 RX ( CPE ) ( no momento haviam 46 clientes conectados ).
5. A relativa "paridade" de sinais se deve ao fato de que uso Airgrid 23 e 27 dBi , e nos clientes muito próximos, caso o retorno fique mais forte que -55 em 4dBm , os instaladores acham o melhor sinal possível, e depois erguem o "bico" da Airgrid um pouco até que o sinal fique -55 (RX AP). Afinal, pendendo pro lado do céu, penso eu, fujo de uma interferência de outro equipamento ou concorrente que estão próximos ao solo ( não sei se me fiz entender o raciocínio ). Ah sim, em alguns casos, sabe aquelas UBNT com perda de potência, então, em alguns casos, eu guardo elas para instalar nestes clientes muito próximos, por acaso este cliente "Delmar_F" , o "F" é de fraca ( pra meu controle ) , ele está a 100m da torre bem apontado, ele é um dos únicos que está com potência mais acima, voltando ao AP com -63 porque regulei assim.
Um adendo: eu sempre me preocupo mais em deixar os "longes" chegarem com mais sinal do que os "pertos", os "pertos" já têm a vantagem de estarem perto, então me preocupo pouco se um "perto" fica com -66 , mas jamais deixaria um "longe" pior que -63 .
6. O script na imagem é um teste de hora em hora em todos os clientes conectados com parâmetros size=1450 do-not-fragment e o resultado é como pode ser visto, sem percalços... de fato em horário de pico, em um ou 2 dias da semana, perco algum pacote neste monitoramento. Mas meu objetivo aqui, é acertar para não perder nunca.
7. O círculo em verde é minha única preocupação atual, 89,2% de TX CCQ na CPE , este valor quando está trafegando por volta de ~10Mb oscila entre 70% e 99% em todos os clientes, quando o CCQ está em uma maré baixa, ao fazer um Speed Test da UBNT no AP em direção a um cliente, obtenho resultados Duplex TX=~20Mbps RX=~3Mbps , quando o CCQ está mais alto, os resultados Duplex ficam na faixa de TX=~30Mbps RX=~8Mbps.
8. Reforçando: O sinal de TX que volta ao AP sempre deixo na faixa ~63 , impreterivelmente ( mas como disse, quase sempre mexendo no ganho da antena e no posicionamento, quase nunca na potencia, que deixo sempre que possível a mínima 4dBm ). Perceba ainda que no AP o CCQ médio é 99% e que o seu Noise Floor é maior que as CPEs, de -94 .
9. Aqui é interior, mas em uma cidade pequena de 50mil habitantes, somos 6 concorrentes de rádio e uns 50 transmissores brigando pelo espectro 5.8 . Até por isso, uso ( e não viveria sem ) o Airmax.

Imagem comentada, vamos adiante... minha intenção basicamente é a seguinte... tentar deixar o MCS de TX do AP de uma forma que fique estável sem perder throughput e consequentemente ( e principalmente ) latência . Hoje este AP com 50 simultâneos trafega no máximo 14Mbps ( confesso que não sei se é porque estou causando este limite por falta de otimização ou se é o tráfego máximo dos clientes mesmo ).

De fato trabalho atualmente com planos de 0,5Mb até 2Mb . E gostaria de trabalhar com até 5Mb se fosse possível. Sendo MCS5 52 teóricos, seriam ~25Mbps práticos. Será que é possível trabalhar com planos de até 5Mb ? E usando MCS4 que são 39 teóricos, dando por volta de ~18Mbps práticos mas utilizando 16-QAM 3/4 será que rolaria também ?

Aliás, utilizar um QAM para transmitir e um QPSK para receber não incide carga de processamento, chaveamento, etc do que se utilizássemos QAM <-> QAM ?

Falando sobre o upload agora, como os clientes não usam mais que 20% dos seus uploads, a intensão é colocar o MCS nas CPEs de forma que eu deixe ainda mais estável sem prejudicar o throughput e principalmente a latência . Eu sei, bato muito na latência, é que tenho muitos gamers no provedor, e já criei fama na cidade por desmitificar que jogar em internet via rádio é sim muito possível.

----------


## rubem

Sobre a estratégia de sinal bom pra quem está longe, a ideia de quem está perto tem alguma vantagem por estar perto não confere, a diferença de tempo pra luz percorrer 100m ou 1000m é muito pequena pra fazer diferença, o acktimeout faz diferença porque ele atua no tempo pra ignorar reflexos, justo porque RF é muito rápido um sinal reflete em mil lugares e vários ecos/reflexos chegam no destino, um tempo maior no acktimeout ignorar ele. Quem terá desvantagem é quem tem sinal baixo, indepentende da distância.
(Se todos tiverem zona de fresnel 100% limpa e o acktimeout correto, o ping e o throughput será igual, a diferença existiria entre cliente a 300m e a 30Km, mas é algo tipo 1 a 2ms a mais, no throughput geral não muda quase nada)

Sobre processamento por usar 16QAM num lado e QBPSK no outro: Nada muda.
Quanto maior o datarate menor o processamento, porque o mesmo pacote de navegação de X bytes será feito com menos pacotes wireless. Mas... precisa ter sinal bom pra isso (Todos nivelados lá pelos -55dBm pra usar MCS7). Usar datarate alto com sinal baixo é até pior porque o processamento gasto pre reenviar pacote (Ou perguntar por resposta não recebida) é muito pior, ocupa espaço na ram e na fila de tarefas. Se a intenção é economizar processamento não tem que se preocupar com esquema de modulação mas sim em ter 100% de CCQ, pra que nenhum pacote seja perdido.

-65dbm vai dar CCQ baixo em MCS7, CCQ baixo implica pacotes perdidos. O mesmo nível de sinal vai dar CCQ ótimo lá por MCS4 ou 5, o datarate baixa mas a perda de pacotes acaba. Pacote perdido gera mais processamento e toma tempo, derruba o throughput também de outros clientes. 
Bom seria se os rádios fossem inteligentes pra usar datarate automaticamente só com 12dBm de margem com relação à sensibilidade, e mais de uns 25dB de SNR. Mas o software não testa throughput, se tiver tráfego baixo só com pacotes pequenos não haverá perda de pacotes, aí o radio talvez até suba o datarate. PTP sempre tem trafego constante e pacotes grande (1472 bytes, o MTU menos 28B do cabeçalho wifi e autenticação geralmente), de modo que se ele subir o datarate (Onde o sinal é baixo) rapidinho ocorre 3 ou 4 pacotes perdidos, nesse cenário o datarate automático acaba funcionando as vezes, mas é só ter trafego menor que isso deixa de funcionar direito, pacotes pequenos raramente são perdidos (Dar ping com -l 32 e com -l 1450 ajuda a ver a diferença de perdas conforme o tamanho), mas os chipsets tem um limite de pacotes, não de tráfego.

Um exemplo, lá no final da página a tabela, o numero de Kpps com pacotes de 1518, 512 e 64 bytes:
http://routerboard.com/RB912UAG-5HPnD
Independente do tamanho do pacote, o chipset só lida com 60 mil pacotes por segundo (K pps). Pacote pequeno quem tem é coisa tipo troca de texto curto no whatsapp, verificação de status e conexão do Windows e uns softwares, após abrir uma página tem ad's que verificam tempo de conexão na página (Pra gerar estatística) com pacotes pequenos, enfim, muito do que usamos hoje trabalha com pacotes pequenos, e esses pacotes não são perdidos facilmente, se o cliente só tiver esses pacotes pequenos nada será perdido e será exibido CCQ ótimo, mas... hora que ele abrir uma página, abrir um vídeo no YT ou Facebook, aí vai usar pacotes de quase 1500 bytes, esses pacotes é que serão perdidos numa conexão ruim, o CCQ só vai cair hora que tiver esse tráfego, e o real problema é que esse pacote grande perdido vai consumir o processamento de 5 ou 6 clientes com pacotes pequenos (Que não são perdidos), a sensação de navegação dos outros clientes pode variar conforme o consumo do cliente de sinal ruim.

Descer só 1 ou 2 datarates já ajudam muito, mesmo que fique em MCS6 já tem uma perda menor de pacotes com sinal baixo porque ele usa só 3/4 (75%) dos streams com dados úteis, enquanto MCS7 usa 5/6 (Uns 83%), esses streams sem dados fazem diferença em caso de sinal ruim, MCS0, 1 e 3 usam só metade (1/2) desses streams por isso tendem a ter perda minúscula de pacotes, colocar os clientes em MCS3 é ótimo especialmente por isso, seria como escrever só em metade de uma página e entregar pra um cachorro levar, cachorro que baba vai inutilizar uma parte da página, as chances da parte escrita ser destruída é menor quando você escreve só em metade da página (Aleatoriamente escolhendo qual metade ou posição do texto), se escrever em 83% da página (MCS7) a chance de parte do texto sair ilegível é muito maior, tem mais chances de perder o pacote como um todo (Mas se for um cachorro que não baba nada (Sinal alto tipo -55dBm) vai ser bem mais rápido trocar um livro usando páginas escritas em 83% (5/6) delas que em 50% (1/2).

Enfim, tem muitos motivos pra tratar -65dBm como sinal ruim pra MCS7. O CCQ pode parecer bom as vezes por conta dessa questão do tamanho dos pacotes, muito cliente usa só whatsapp e só visualizar miniaturas no facebook, situação onde o tráfego é mínimo, nem tem como ter muitos pacotes perdidos porque eles nem trafegam muitos pacotes grandes.

----------


## silviola

Ok. Acredito que eu tenha assimilado praticamente tudo.


Gostaria da sua opinião pessoal sobre alguns aspectos então:


1o. Utilizar a tática de aplicar antenas enfraquecidas assim como antenas normais mas com o ato de levantar o bico, desde que mantenha-se um sinal de RX no AP de por volta de -63 seria uma boa prática. Ou seria melhor instalar antenas boas e bem apontá-las fazendo com que o sinal chegue -48 ~ -50 no AP ? Eu, até então, venho evitando isso para não saturar o AP.


2o. Sempre fui avesso a muita potência, você acha que devo subir a potencia no AP de 6dBm para algo em torno de 15dBm ? Isso elevaria o sinal do pior cliente acredito que para uns -60 ... mas não degradaria um pouco a qualidade da onda / ruído ?


3o. Olhando o meu cenário, no meu lugar o que você faria com as modulações ? MCS5 no AP, MCS3 nos clientes ? Elevação de potência no AP ? Ou seja, ponha-se no meu lugar, supondo que tu comprou minha célula, que mudanças faria ?

----------


## rubem

1 - "Saturar o AP" seria um cliente chegar com sinal lá pelo -30dBm. Só mais ou menos acima disso que existe saturação. Abaixo de uns -40dBm não tem risco, é só um sinal excelente.
Mas ter 1 cliente chegando com -48dBm e outro com -65dBm não dá, pra isso tem que ajustar a potência de modo diferente em cada cliente. No cliente mais próximo vai ter que por uns 4 a 8dBm, e nos clientes distantes uns 12 a 15dBm. Usar Airgrid pra cliente a menos de 1Km é um enorme desperdício porque NS Loco pra essa distância já precisa limitar a potência!
Quanto ao sinal da torre chegar muito alto nos cliente (Tipo -45dBm), não tem problema, a CPE do cliente tem só 1 (Uma) conexão pra lidar, se ela for com nível alto não vai ter erro. Já a torre tem 20-30 conexões pra lidar, com uns chegando com sinal alto e outro baixo os de sinal baixo vai ficar ilegíveis em caso de colisão.
O que falo de nivelar os clientes é isso, regular a potência de cada um de modo que todos cheguem na torre com o sinal similar, lá pelos -55 a -60dBm já tá ótimo de quiser usar MCS6. Pra MCS4 até -70dBm tá bom.

2 - Respondido no anterior. Não é o que você gosta mas o que a distância e ganho da antena pede. Potência problemática geralmente é alto tipo a potência maxima e uns 4 a 5dBm a menos que isso.

3 - É o que sugeri o tempo todo, MCS5 na torre com acktimeout grande e fixo, potência fixa, e nos clientes MCS3 com acktimeout diferentes em cada cliente (Conforme distância, sempre 20% maior que a distância real) e com potência de acordo com o sinal chegando na torre.

(Escaneia o cliente na torre com -65dBm. No cliente está com 6dBm. Pra chegar a -60dBm então tem que subir de 6 pra 11dBm (Subir 5dBm na potência, ou trocar por uma antena 5dBi maior, aumenta em 5dBm o sinal (RX) na torre)

Se o cliente recebe sinal baixo: Troca por antena de maior ganho.
Se a torre recebe sinal baixo: Entre no setup da CPE do cliente e aumenta a potência (Talvez também aumenta ainda mais o acktimeout), ao menos temporariamente até fazer uma visita pra subir a antena e tirar de trás daquelas árvore que cresceu.

Configura a torre pra emitir uns 30dBm EIRP, talvez 35dBm EIRP (Potência do radio + ganho da antena = Potência EIRP. Exemplo: Setorial 17dBi + Radio a 15dBm = 17+15= 32dBm EIRP), e nunca mais mexe. 
Já nos clientes configura a potência de modo que o sinal DESSE cliente na torre chegue igual os demais, digamos -60dBm. Num rádio vai precisar 4dBm pra isso, noutro 10dBm, noutro talvez 14dBm. Depende da distância e do percentual da zona de fresnel que está sem obstáculos.

O sinal cai X dBm num espaço, é a queda no espaço livre:
http://www.radio-electronics.com/inf...a-equation.php
Em 1Km o sinal vai cair uns 108dBm, seja com o AP configurado a 4dBm, a 8dBm, a 30dBm.

Se o radio está a 15dBm, e a antena tem 15dBi, tem 30dBm EIRP. Isso é a emissão.
Sai 30dBm, em 1Km o sinal cai 108dBm.
Logo: 30 - 108 = -78dBm será o sinal no ar.

Mas a CPE do cliente tem ganho, digamos um Airgrid 21dBi. Ela pega o sinal e aumenta ele em 21dBm.
Logo: -78 + 21 = -57dBm
Esse deve ser o sinal escaneado por esse Airgrid a 1Km (Se a torre tem 30dBm EIRP, seja 15dBi+15dBm, seja 20dBi+10dBm, seja 25dBi+5dBm). 
Se diminuir a potência do AP em 1dBm, o sinal escaneado vai cair 1dBm, vai cair pra -58dBm.
O contrário, sinal do cliente rumo a torre, é a mesma coisa, é calculável conforme a distância, mas se a zona de fresnel for parcial ele diminui, quanto menor o percentual dela limpo mais o sinal cai. Com 80% dela limpa o sinal cai uns 8dBm. Com 70% dela limpa cai pouco mais de 10dBm. Na prática então a conta não bate sempre, e você precisa ver no AP qual o nível de sinal que o cliente que você acabou de instalar chega.

(E geralmente se configura isso só na instalação, leva notebook ou pelo desktop/note do cliente acessa a CPE dele, mas também o AP da torre, só pra ver como o sinal dessa CPE está chegando no AP na torre, regula a potência da CPE de modo que ela chegue no AP da torre lá pelos -60dBm, aumentando ou diminuindo a potência conforme a necessidade)

----------


## silviola

Ok tudo assimilado, falando especificamente sobre potencia vs MCS agora.

Na sua opinião:

1. Vc manteria a potência do AP em 6dBm e sinal mais fraco a -65 modulando a MCS5 e MCS3 ( AP - Cli ) ou aumentaria a potencia do AP ? Se sim, qual seria o ideal, a potência alvo, para as CPE's receberem de sinal ?

2. Ou você além de aumentar a potência também aumentaria os MCS's ? Se sim, para quais MCS's ?

3. Você acha que com MCS5 consigo oferecer planos de 5Mb em uma célula de 50 clientes ? Claro, nesta célula serão 2 ou 3 no máximo com 5Mb, e a massiva maioria com 1Mb ... minha preocupação seria entregar garantido os 5Mb aos poucos que contratarem, consigo isso, estes 5Mb trabalhando com MCS5 ? Se não consigo, com MCS7 conseguiria ?

3b. Hoje esta célula tem 50 clientes, e destes, 40 são planos de 0,5Mb a 1Mb e 10 são planos de 1,5Mb até 2Mb. O tráfego de pico é por volta de 14Mb/s sem aparente perda de pacotes ou lentidões ( pelo menos não detecto nada no script de monitoramento ).

** Lembrando que : nenhum cliente da célula está com obstrução, as instalações sempre possuem excelente fresnel ( sou chato pra ..... ) e estou trabalhando com potências bem baixas, então possivelmente eu consigo sinal -55 neste cliente que tem atual -65 aumentando o AP para 16dBm e mantenho meu EIRP em 33 ( minhas setoriais são de 17dbi ).

----------


## rubem

1 - Recomendo a potência que for necessária pra que todos os clientes tenham sinal igual na torre. Seja 4dBm, 10dBm ou 18dBm. Colocar todos os clientes na mesma potência não faz sentido porque a queda de sinal depende da distância, ou seja, cada cliente vai ter nível de sinal diferente, um ficaria mais legível que outro se todos tiverem potência similar. Nivelar conforme o RX na torre, não conforme a potência "dos outros".

2 - Nos clientes não vejo porque usar mais que MCS3. Só pelo upload de 1Mbps na verdade até MCS0 serve, mas é bom usar algo maior tipo MCS2 ou 3 por conta das respostas de pacotes (Protocolo TCP/IP requer respostas). Na torre seria lindo usar MCS7, mas... aí precisa sinal muito bom, lá pelos -55dBm nos clientes.

3 - Se hoje tem 14Mbps de tráfego agregado com planos até 2M, passando pra 5M isso dificilmente vai passar dos 25Mbps, só se der azar de todos os clientes de 5M serem heavy users que usarão p2p 24x7 comendo toda a banda disponível.

Sobre o **: Subir a potência dos clientes pra usar algo maior que MCS3 não vale muito a pena, -65dBm pra MCS3 tá bom, seria só questão de nivelar todos de modo que cheguem com sinal igual. Talvez seria mais interessante subir a potência da torre pra 35dBm EIRP e usar MCS6 (Com sinal na casa dos -60dBm) ao invés de MCS5 com sinal chegando nos cliente lá pelos -65dBm. O bicho pega é no trafego de download nos clientes (Limitado pelo TX Rate no AP da torre), não no de upload (MCS3 nos clientes vai ficar até sobrando).





Pra colocar muita gente em planos de 5Mbps no futuro vai ter que usar dupla-polarização, SISO não dá conta de muito tráfego. Com dupla-polarização o tthroughput é simplesmente dobrado, com aparelho barato tipo NS Loco a 1Km dá pra vender 5Mbps pra algumas duzias tranquilo (Usando MCS12 na torre e MCS10 nos clientes, por exemplo).

----------


## alexchiele

Alguém poderia me dizer se essa tabela que fiz esta correta, usei informações aqui do forum e própria MK
Obs. data rate de 400ns (nv2 usa esse)

Grato a todos

----------


## rubem

Perfeita a tabela, é bem isso.

----------


## silviola

> Alguém poderia me dizer se essa tabela que fiz esta correta, usei informações aqui do forum e própria MK
> Obs. data rate de 400ns (nv2 usa esse)
> 
> Grato a todos


Show Alex.
Poderia fazer a tabela completa com os MCS's mais baixos ?

----------


## alexchiele

Muito obrigado Rubem é grande parte graças a ti, e com todo respeito você é um gênio , parabéns a ti .

Saviola então eu usei 3db a mais que o normal por ser modulação MIMO, não me lembro aonde mas li que por ai é o ideal, e quando usado 40MHz você deve ter mais 4db que na mesma modulação SISO.
Mas se tiver tempo hoje ainda modifico ela e posto aqui...

----------


## silviola

Jóia Alex, seria de maior aproveitamento pra todos se pudesses completar.

----------


## rubem

É que MCS0 a MCS7 é EXATAMENTE o mesmo que MCS8 a MCS15.

MCS0 = MCS8
MCS1 = MCS9
MCS2 = MCS10
MCS3 = MCS11
MCS4 = MCS12
MCS5 = MCS13
MCS6 = MCS14
MCS7 = MCS15

(Idem pra MCS16 a MCS23)

Com 1 ou com 2 chains, se o rádio tem suporte a MIMO e a antena tem isolamento entre polarizações tipo 20dBm ou mais (Qualquer antena decente tem), tudo o que vale pra MCS0 vale pra MCS8.

Com 3 chains não tem um jeito de ter tanto isolamento entre polarizações, mas se conseguir usar 3 chains isolados um do outro por algum outro meio, também vale.


Em 802.11AC com multiplos chains (Até 8!) o foco não é trafego full-duplex, e sim algo tipo 4 antenas no roteador e 1 ou 2 no notebook ou smartphone, pra você BAIXAR em digamos 1Gbps (Algo da rede, não necessariamente da internet), e upar só as respostas dos pacotes. Envia em 1 antena, mas recebe o sinal de 4, tem coisa tipo 20M de up e 500M de down. Pra provedor esse tipo de cenário não é tão útil, a gente precisa tráfego full-duplex ótimo, trafego bom nos 2 sentidos.

----------


## alexchiele

Então assim como o rubem dice seria a mesma coisa , eu usei uma margem maior porque em alguns dos pdf da MK eu vi isso.

Fiz mais esses mas 2.4 e protocolo A/G é meio difícil de achar alguma coisa , ate porque não acho que seja muito usado actualmente.....(obs: me corrijam se estiver errado sobre os valores das tabelas )

----------


## silviola

Vc fez algo com fórmulas, gostaria de adaptar a Rocket / Bullet / Airgrird .

----------


## alexchiele

Usei umas tabelas postadas aqui no forum, dicas principalmente do rubem e de outros. E para saber sobre equipamento procurei nos datasheets do fabricante.
Pensei em fazer algo sobre os ubqt mas devido ao seu noise floor ser muitas vezes baixo (ate demais tipo -90) iria me confundir muito devido a margem mínima de cada modulação.

----------


## silviola

Sim, é esta justamente a confusão comum, por isso seria interessante adequar, já que tanto MK quanto UBNT dividem o cenário da realidade dos provedores WISP.

Rubem, podia ajudar nesta ?

----------


## alexchiele

Eu acredito que não precise de tanta margem quanto MK (uso minha pouca experiência com ubqt para dizer isso), aqui as poucas que temos apesar de sinal não tão bom ela funcionam bem.

----------


## silviola

Entendo Alex, e´que a intenção aqui é a busca pela otimização total, com busca de parâmetros bem fundamentados.

----------


## rubem

> Então assim como o rubem dice seria a mesma coisa , eu usei uma margem maior porque em alguns dos pdf da MK eu vi isso.
> 
> Fiz mais esses mas 2.4 e protocolo A/G é meio difícil de achar alguma coisa , ate porque não acho que seja muito usado actualmente.....(obs: me corrijam se estiver errado sobre os valores das tabelas )


É bem por aí mesmo, não tem unanimidade sobre qual seria uma margem boa ou mínima.
Sobre a margem pra MIMO, na verdade tem cálculo pra SNR e margem que leva em conta o número de elementos da antena (Um dipolo é só 1 elemento, uma biquad são 2 elementos, a antena patch de um SXT lite tem 9 elementos), mas é daquelas contas teóricas sobre não ter perda total de pacotes, e nos precisamos perda zero, e não aceitamos nem perda de 10%, que dirá a perda de 99% que é a base de uns cálculos).

O problema é que é tanta variável pra dar número exato (Dependendo também do VSWR exato da antena no canal usado) que ninguém arrisca tabelar tudo, e prefere jogar pra cima tipo 20dBm de margem como mínimo pra uma rede boa.

(E no caso de MIMO, eu digo que é bom não passar de uns 40dBm de margem, porque com sinal tipo -45dBm, o sinal do chain0 já é legível no chain1 de qualquer CPE no mercado, também já começa a comer throughput)






> Vc fez algo com fórmulas, gostaria de adaptar a Rocket / Bullet / Airgrird .



Não tem fórmula, é basicamente a sensibilidade do equipamento no datasheet, acrescido de uma margem de 10 a 20dBm pra definir qual seria o sinal mínimo e bom pra cada datarate.

Rocket, Bullet e Airgrid tem características parecidas (MK também), porque são chipset Atheros de gerações iguais, na prática pode pegar os números de um Nanostation e aplicar pra todo equipamento MK ou UBNT que não terá rede ruim.

Já que citou o Airgrid, olha o datasheet:
https://dl.ubnt.com/datasheets/airgridm/airGrid_HP.pdf

Lá na tabela com sensibilidades de cada datarate tem números só 1 ou 2dBm diferente da tabela:

Mas olha a coluna mais na direita, tolerance: + ou - 2dBm de variação.
Conforme o canal usado, ou variação na fabricação (E talvez temperatura do chipset) o número varia.

Por isso é complicado definir "O mínimo é 12dBm" e fazer todas as instalações assim, em horários de calor ou dia que mudar de canal isso vai tudo mudar.

Trabalhando com coisa mais simples tipo pelo menos 20dBm ACIMA da sensibilidade (Do datarate escolhido, ou do MAIOR se for deixar automático) a chance de rede ruim é quase zero.

A coisa é mais simples do que parece:
Precisa passar 50Mbps: Quer dizer que precisa de um datarate de mais de 100Mbps, que é MCS13. E MCS13 precisa pelo menos uns -58dBm (Mas seria bom MAIS que isso, nada de deixar ZERO margem, lembra que sinal cai quando chove, é fácil cair 2dBm).

Pode complicar um pouco se não tiver sinal suficiente.
"Instalei e não tem -58dBm, tem só -60dBm".
Então olha o MCS12, ele funciona com isso.
E pra ter data rate de mais de 100M nele é só passar de largura de canal de 20MHz pra 30MHz (Se em 20MHz tem 78M, aumentando o canal em 50% na largura, o datarate aumenta em 50%, passa de 78M pra 117Mbps, mas configurando o rádio em 30MHz ele automaticamente muda os numeros dos data rates, nem precisa fazer conta!).

(Canal mais largo geralmente exige sinal um pouco mais alto, mas de 20 pra 30MHz uma diferença de 1dBm conta pouco. A maior diferença é mudar 100% a coisa, pulando de 20 pra 40, ou de 20 pra 50MHz)

Respeitando uma margem (Signal margin) entre sensibilidade e sinal presente, dificilmente vai desrespeitar o SNR.

(E na prática pode ter CCQ ótimo com margem de só 12 ou 13dBm em PTP, mas é PTP, antena com só 1 conexão pra lidar, o bicho pega é com PTP, vários rádios falando nas orelhas do AP, o throughput fica meia-boca quando tem muito cliente com sinal baixo, eles perdem pacotes e isso precisa ser reenviado, toma tempo que poderia estar sendo gasto com outro cliente. É tipo quando tem alguém lerdo num caixa do super-mercado, por mais ágil que o caixa seja, se a pessoa for lenta demais pra tirar as coisas do carrinho toda a filha tem que ficar esperando a vez, não existe ir pra outra fila em wifi, se tem uma lesma na frente, todo mundo vai ter que esperar)

----------


## rubem

> Sim, é esta justamente a confusão comum, por isso seria interessante adequar, já que tanto MK quanto UBNT dividem o cenário da realidade dos provedores WISP.
> 
> Rubem, podia ajudar nesta ?


Perdi o fio da meada...

O que não entenderam mesmo?

Se é sobre o noise floor, ele é medido igual se escaneia SSID, basicamente um SSID ou ruído que fique acima da MENOR sensibilidade (Geralmente MCS0 em canal de 10MHz) será identificado.

A emissão do SSID é feita com o preambulo, também usa o menor datarate, por isso você pode escanear um SSID a -70dBm, mas hora que conectar exibir sinal -75dBm.

Aquela exibição de detalhes de conexão em Mikrotik é educativa pra caramba! Ela mostra como o sinal do SSID está sempre acima do sinal real dos pacotes:


O ruído as vezes varia conforme você seleciona um ou outro datarate, se isso acontecer, é bom desconfiar do rádio gerando ruído pra ele mesmo.
(Falo de mudar demais, tipo -88dBm em MCS15, e -96dBm em MCS12, não tem como isso se outra coisa senão reflexo por culpa de antena perto demais de algo, ou num angulo ruim em que uma barra de ferro chato da torre acerta em cheio muito sinal refletido, mover a antena meio palmo as vezes resolve)

Se o ruído escaneado ficar abaixo de uns -96dBm em MK ou UBNT, é porque não tem ruído no local mesmo, e o noise floor exibido será mais ou menos a menor sensibilidade do equipamento.

O datasheet de um SXT fala em sensibilidade -96dBm. Mas... isso é pra 20MHz, e ele opera com 10MHz e 5MHz, a sensibilidade com canal mais estreito talvez fique em -99 e -102dBm, mas ainda tem mais: O preambulo usa tão poucos dados que um SSID a -110dbm as vezes é legível, e se chegar em -115dBm ficará ilegível mas o rádio identificar que tem algo a -115dBm, como é ilegível ele vai dizer que é ruído.

Até tem vento solar e espacial gerando ruído na faixa, mas ele fica abaixo de -120 a -140dBm, então num lugar sem wifi 5GHz por perto realmente não haverá ruído nenhum, mas o rádio mostra um noise floor, que é basicamente tudo que é ilegível, tudo o que está perto da menor sensibilidade fica ilegível demais.



Eu tenho uma vizinha idiota na frente que fala muito alto, dá pra entender tudo o que ela fala dentro da própria casa de tanto que fala alto.
Mas nos fundos é um pessoal que fala baixo, a 1 hora atrás eu até ouvia que eles estavam falando algo, mas não conseguia entender nenhuma palavra. 
Acho que é isso que chamam de burburinho, você escuta que tem alguém falando, mas não consegue entender nada porque é baixo demais. É baixo pra entender, mas não é baixo pra não ouvir, então... é ruído, tem algo mas é ilegível.

Já a sensibilidade do data rate é: 
Se alguém falar uma média de 120 palavras por minuto, eu entendo mesmo o som chegue tão baixo tipo 40dB.
Se alguém falar uma média de 150 palavras por minuto, eu entendo só se o som for mais alto tipo 50dB.
E se alguém falar muito rápido tipo 180 palavras por minuto, precisa falar lá pelo 60dB pra que eu consiga entender!

Um "sim" ou "não" com som fraco tipo 20dB eu entendo, mas alguém falando normalmente nesse volume é alguém cochichando a 5m, num lugar aberto é ilegível, não adianta eu ouvir algumas coisa a 10 ou 15dB, sendo que o que é útil, que é conversar, eu preciso pelo menos 40dB (E se quiser falar rápido, precisa falar mais alto pra ficar mais claro).

(Esse valores pra conversa são em ambiente silecioso, se for do lado de um caminhão roncando a 60dB, alguém gritando a 65dB até é entendível se falar devagar, é uma margem entre sinal e ruído muito baixa. Se for do lado de um carro roncando a 40dB, e falar normal a 50dB, já dá pra entender QUASE tudo (Ainda tem uns 10% de perda de pacotes).

Imagina wifi como uma professora ditando palavras pros alunos copiarem, a diferença entre a voz e o ruído precisa ser boa, mas se ela falar devagar o volume da voz pode ser menor, ou mais perto do ruído. Fazer MIMO é colocar 2 professoras ditando pra 2 alunos, um de cada lado da sala (Isolamento de uns 20dB), se uma professora falar algo demais atrapalha o ditado da outra. 

Tudo que é situação que vocês imaginarem com as pessoas conversando (Especialmente falar um ahã depois de cada frase pra indicar que entendeu, isso é uma resposta de pacote) tem algo igual em wifi.

----------


## Rinaldo011015

Minha rede eu tenho nas torres 912UAG-5HPnD/ base station ubiquiti 17 dbi, e nos clientes um mistão de de SXT e Ubiquiti,queria saber qual a melhor configuração em HT MCS para o caso.

----------


## emilidani

A automatica sem duvidas!!!

----------


## alexchiele

A melhor na minha opinião era ter apenas uma fabricante para ativar os protocolos autoritários e poder ter o melhor desempenho, só isso já iria dar uma boa melhorada no desempenho, a airgrid é SISO e a SXT MIMO mas daria para testar algumas opções de configurações, aqui não teve uma receita mágica que serviu em todos os casos.
Tudo depende de sinal e qualidade das instalações (visada, fresnel, etc), aqui o que mais funcionou era se todos os clientes estavam na faixa de -55-69db usar MCS4-12(39-78mb), CCQ sempre ficava acima de 90(quase todos 97-100). Não posso dizer o ganho que tivemos pois não faz muito tempo mas acredito que ganhamos uns mb ai kkkk.
Só uma obs se você tiver como separar os clientes MIMO e SISO em Painéis diferentes acho que ficaria melhor (opinião apenas)

----------


## FMANDU

O que ainda fico intrigado é qual a diferença entre o MCS Supported e Basic. Alguem saberia me dizer a diferença?

----------


## rubem

Marcando múltiplos data rates, o software seleciona do maior pro menor conforme quantidade de perdas de pacotes (Que depende do nível e qualidade do sinal).

Basicamente o "basic" tem os menores rates que serão testados, tanto no lado onde você configura (Um AP, digamos) como no outro lado (Outro MK em "default", ou um roteador qualquer).
Em supported entram os rates altos que serão testados. Ainda que você marque e um não seja usado no TX, ele poderá ser usado no RX (TX do outro lado).

Se marcar digamos 9, 18 e 36M em supported, e 9M em basic. Se tiver sinal ruim tipo -76dbm e tiver umas paredes no meio e tal, o software vai optar por 9M, que é o rate MÍNIMO.

Hora que esse sinal subir pra um -65dBm, e/ou tiver um CCQ um pouco maior, talvez o software suba pra 18M.

Mas o maior uso é: Se você tem uma antena de 25dBi, mas tem potência ridícula tipo 8dBm. Pode ocorrer de você receber sinal -60dBm, logo, no sentido A>B vai usar 18M, mas com potência tão baixo o sinal cliente>torre, ou sentido B>A, está em -75dBm, logo, o rate nesse sentido será o mínimo marcado, 9M.

Dependendo de potência e ganho de antena, a qualidade AP>cliente ou cliente>AP pode ser diferente, mas se você precisa uma qualidade mínima maior, digamos PELO MENOS 10Mbps, é melhor marca em basic apenas 18M, assim você chavearia entre 18 e 36M.

Mas se tem conexão lixo as vezes (Usa como AP doméstico, digamos), uns lixos tipo smartphones terão sempre sinal ruim, se o rate basico a ser usado for 18M, eles vão perder muito pacote, melhor usar um rate mínimo mais baixo, tipo 9M ou 12M.

Pode marcar vários rates básicos, mas não faz sentido, se marca 3 ou 4, o mínimo mesmo será o mais baixo.

Mas se tiver sinal alto, tanto faz o mínimo, o rádio vai subir de datarates até o onde o sinal der, se o maior marcado em supported é 36M, vai subir até 36M se tiver sinal bom.

Um problema é que quando você está com pacotes pequenos, tráfego de baboseiras tipo o ping do Windows pra ver se tem internet, ou status de messenger, com esses pacotes pequenos não há perda de pacotes mesmo com sinal ruim tipo -75dBm, aí sem tráfego grande o rádio chega em 36M, mas... hora que tiver muitos pacotes de navegação, de quase 1500 bytes, aí ocorrem diversas perdas de pacotes até que o software defina que é melhor baixar o rate, ele vai baixar (No exemplo) pra 18M, se a perda continuar ele baixa pro basic, que é 9 ou 12M, se a perda continuar ele não baixa porque já está no basic.

Se você marcar digamos 9M em supported, mas não em basic, ele vai eventualmente testar esse rate quando tiver CCQ péssimo, mas quando houver troca REAL de pacotes grandes (E não uma conexão quase ociosa) o software não vai testar esse rate, o menor que ele vai estabilizar é no que está marcado em basic.

Enfim, é uma questão de mínimo e máximo, mas você só vê isso em ação quando tem pacotes de tráfego real e grande. Quando os rádios estão ociosos podem usar vários datarates momentaneamente, porque pacotes pequenos passam até com sinal ruim tipo -85dBm.
(Faz uma conexão a -85dBm com 18M e dá um ping -l 1, o ping com 1 byte passa fácil com sinal baixo, mas aí compara quanto de sinal precisa pra um ping -l 1450 não ter perda, e será lá pelos -70dBm, e pra não ter delay (Um ping de 50ms) algo lá pelos -60dBm. Por causa desse comportamento burro de subir data rate quando não tem tráfego, é complicado marcar múltiplos rates, a perda de pacotes pequenos será diferente da perda com pacotes grandes, e navegação e downloads usam pacotes grandes, usar rate alto demais pro sinal que tem gera justamente navegação ruim, o status do WhatsApp funciona normal, mas engasga justo na navegação)

----------


## FMANDU

@*rubem* Não seria interessante deixar o AP setado em digamos Mcs12 e os clientes automáticos? Ou degradaria muito a performance do ap com as modulações em rx diferente das outras. Pq penso eu que o AP mantendo o TX constante os clientes iriam se adequar com a modulação automática. Apesar do rx no ap, se o up dos clientes.

----------


## rubem

Eu diria que se é pra deixar alguém em auto, deixa a torre.

O cliente tem pouco dado pra enviar, só o upload, rajadas de 100 a 200kbps geralmente, não precisa de muita coisa.

A torre tem que "ouvir" todo mundo, se o sinal de todos chega em digamos 54M mas em algo baixo tipo -60dBm, a torre vai ficar pedindo reenvio pra todos.

(Porque o software NÃO se adequa como devia, o software é burro e insiste em subir de rate mesmo não tem sinal suficiente)

Já se os clientes todos estiverem transmitindo em digamos 12V, o sinal de -60dBm será mais que suficiente pra todos esses sinais serem legíveis, a torre vai entender tudo no primeiro envio, não vai precisar pedir repetição.

Geralmente se coloca um equipto bom na torre, rádio a 20dbm e antena de 19dBi. Isso dá 39dBm EIRP.
Mas o equipamento dos clientes nem sempre é bom, tem muita CPE barata que só tem 17dBm de potência, se a antena é de 12dBi, isso dá 29dbm EIRP.

Ou seja, o sinal AP>cliente será 10dBm maior que o sinal cliente>AP, logo, faz sentido que o data rate setado na torre seja digamos 36M, e o data rate setado nos clientes seja 12M.
(Alias, são 2 motivos então, a menor potência nos equiptos dos clientes, e a menor banda necessária, digo, upload é geralmente 15 a 50% dos download)

O cliente só tem que ouvir 1 contraparte, então a CPE do cliente consegue entender melhor caso chegue um sinal a -60dBm com data rate de 36M. Pelo menos vai entender bem melhor que se isso chegar assim no AP, que vai ter 10 ou 15 sinais chegando juntos.

Quando tem sinal suficiente pro maior data rate (54M, já que estamos usando data rate de A e G), tipo -50dBm, se deixar o data rate automatico tudo funciona porque ele vai tender a ir pro maior data rate.

Mas em PTMP é normal a torre receber dos clientes uns sinais ridículos tipo -65 ou -70dbm, se deixar em automático a maioria dos softwares é burro o suficiente pra usar 54M mesmo com sinal baixo, quando tem só 1 pessoa assim não tem problema, reenvia pacotes até dar certo, mas quando tem 10 pessoas navegando cada pacote é reenviado 3 vezes, ao invés de 30 pacotes por segundo são trafegados 90 pacotes por segundo, os 2MB pra abrir o site no navegador vão passar, mas vão ser tantos reenvios que vai levar 10 segundos, dá uma média de 1,6Mbps, enquanto sem reenvios de pacotes se houvesse a limitação nos mesmos 1,6Mbps não seriam 10 segundos de tráfego (Ocupação do AP), mas só 3 segundos, ocupa menos tempo do rádio e abre a página mais rápido pro cliente.


Mikrotik ensina um pouco sobre essas perdas quando na aba Wireless a gente ativa a coluna TX/RX packets, lá dá pra ver a quantidade de pacotes enviados e recebidos. Se a conexão monitorada tiver uma CPE MK ou algo que exiba a quantidade de pacotes enviados e recebidos, dá pra olhar as perdas. Numa conexão muito boa os números serão quase iguais nos 2 lados, mas quando tem sinal ruim num dos sentidos, os numeros são muito diferentes, uma lado diz que teve 400 mil pacotes de TX, mas o outro disse que teve só 300 mil de RX, ou seja, um enviou 400 mil, mas o outro recebeu só 300 mil. Isso dá 25% de reenvio a mais que o necessário (Mas só pesa quando o AP está tendo muito pacote pra enviar, só em horário de pico talvez).

----------


## raumaster

EDITADO: Só depois que postei que li o post do rubem, acima. Mas enfim, ainda ficou algumas questões abaixo...

Tentei realizar alguns ajustes nos meus MCS aqui usando Mikrotik e NV2 ativado, os cliente todos SXT, mas só obedecem ao AP, não importa se eu coloco pra conectar só MCS 1 e MCS 9 nas SXT ou só um MCS apenas nas SXT, ele sempre vai pelo maior MCS do AP que é uma RB912. Isso é por causa do NV2 ou comportamento do RouterOS mesmo? 

Outra dúvida que tenho é que no RouterOS tem a aba Data Rates, que só tem Data Rates do modo G e na aba HT MCS tem Supported e Basic MCS Rates. Isso é meio confuso. Pra que serve cada opção? Sei que pra mexer nos MCS tem que ativar a configuração do Data Rate em modo G, senão fica tudo desativado as checkboxes das abas HT's e o Supported rates tem que bater igual ao Basic Rates, não adianta selecionar MCS x y z em Supported e em Basic selecionar apenas y e z, q não aceita. Então acho meio confuso essas opções e qual a utilidade delas?

----------


## JonasMT

@*raumaster* tbm nao consegui setar mcs11 no ap e 8 na cpe simplismente nao conecta entao deixei auto na cpe mesmo e fixo no ap.

----------


## raumaster

Desmarquei todos Data Rate G, defini só um Basic MCS, o minimo 2x2, 13Mbps, e o Supported deixei por enquanto todos 2x2, ja que a potencia que u so, 23dbm, é suportada tb pelos Rates mais altos MCS14 e MCS15. Agora na ponta dos clientes, SXT, mesmo que eu deixe só um rate setado, ele continua pegando o rate mais alto selecionado no AP, na pratica ele abaixa quando ha trafego, o rate de down sempre fica mais alto que o de UP na maioria dos clientes, mas continua pegando rates mais altos do que aquele que setei no lado do cliente..

----------


## rubem

Se olhar no setup do cliente, realmente as vezes aparece como se estivesse conectando em data rate alto.

Se olhar no setup do AP, aparece o rate real usado pelo cliente, as vezes ele é diferente do data rate exibido no setup do cliente. 

Isso acontece com muito AP, não sei bem porque, se tem relação com preambulo, tráfego baixo, mas parece que isso não "pesa" pros AP's, digo, não gera CCQ baixo pros outros usuários.

(Como um cliente com -70dBm fixo em MCS15 de fato geraria)

----------


## rubem

Ah, e sobre a utilidade do Basic e Supported Rates, no basic você marca só 1, o mínimo a usar em caso de sinal baixo. Em supported marca todos que quer usar quem em teoria o rádio seleciona qual usar conforme o sinal.

A utilidade de marcar um rate mínimo é permitir ou não conexão ruins, com data rate de 2M até um sinal -80dBm conecta, mas... vai dar um CCQ terrível, vai ocupar tempo de processamento do AP. Se marcar digamos só 18M no basic (E no suported de 18 a 36M), com -80dBm o cliente não vai conseguir conectar em 18M, digamos que "não vai incomodar".

A utilidade planejada é uma, mas na prática conforme as versões e misturas de equipamentos isso realmente não funciona.

Eu vi isso de não conectar com HT MCS só 1 ou 2 vezes, o resto sempre usei datarates diferentes nos 2 lados, porque upload é sempre mínimo comparado ao download. Não tenho equipto suficiente pra conseguir definir se isso é mais comum numa versão ou nalguma configuração específica do RouterOS, eu lembro de ver isso em coisa tipo RB711 level3 e quando atualizei RB pra firmware novo (Eu não atualizo por atualizar, HOJE só faço isso se tiver bug em versão antiga. Pra mim, atualização é trocar os bugs de fábrica por bugs mais novos e ainda não relatados, prefiro ficar com os bugs conhecidos).

----------


## jmathayde

> Ah, e sobre a utilidade do Basic e Supported Rates, no basic você marca só 1, o mínimo a usar em caso de sinal baixo. Em supported marca todos que quer usar quem em teoria o rádio seleciona qual usar conforme o sinal.
> 
> A utilidade de marcar um rate mínimo é permitir ou não conexão ruins, com data rate de 2M até um sinal -80dBm conecta, mas... vai dar um CCQ terrível, vai ocupar tempo de processamento do AP. Se marcar digamos só 18M no basic (E no suported de 18 a 36M), com -80dBm o cliente não vai conseguir conectar em 18M, digamos que "não vai incomodar".
> 
> A utilidade planejada é uma, mas na prática conforme as versões e misturas de equipamentos isso realmente não funciona.
> 
> Eu vi isso de não conectar com HT MCS só 1 ou 2 vezes, o resto sempre usei datarates diferentes nos 2 lados, porque upload é sempre mínimo comparado ao download. Não tenho equipto suficiente pra conseguir definir se isso é mais comum numa versão ou nalguma configuração específica do RouterOS, eu lembro de ver isso em coisa tipo RB711 level3 e quando atualizei RB pra firmware novo (Eu não atualizo por atualizar, HOJE só faço isso se tiver bug em versão antiga. Pra mim, atualização é trocar os bugs de fábrica por bugs mais novos e ainda não relatados, prefiro ficar com os bugs conhecidos).



Certo rubem li varios topicos a respeito do MCS ,fixando o MCS de um cliente na rede o mais baixo o setor nao ficara comprometido a aquela velocidade ? penso assim que a alguns anos atras era falado sobre quando a um cliente esta no throughput baixo a rede toda fica limitada a isso , e fico na duvida colocando uma base com mcs automatico certo , um apc 5m -90 mimo e clientes todos mimo , e colocar os clientes em mcs 3 sera que não iria diminuir a capacidade real da mesmo , ou outro exemplo , rede em G mesmo ainda uso  :Smile:  fixando os clientes em 18M e deixando o MK em automatico , seria a mesma coisa , trafego de 5 a 8 MB ,no total ?

----------


## rubem

Sim limita o tráfego geral, se o AP ficar digamos em 18Mbps, ele vai trocar dados alternadamente com todos os clientes nesse data rate, e o throughput agregado máximo será de uns 10Mbps.

Na prática isso é o que se consegue em PTP nesse data rate, num PTMP sempre tem pacote sendo reenviado, eu diria que se o AP ficar fixo em 18M, entregará um agregado de uns 8Mbps se tiver meia duzia de clientes.
(Acima de uns 15, aí depende do tráfego de cada um, mas duvido que baixe pra uns 7Mbps)

18M é exagero, mas com 24M é fácil conseguir agregado de 10Mbps em PTMP.

Já se o AP fica digamos em 36M, e os clientes usam 12M do TX deles, o AP vai pegando os dados dos clientes um depois do outro (Não é TDMA mas 2 clientes enviando sinal junto zoam o pacote no ADC, perde o pacote e o AP manda pra só 1 deles um "Envia de novo", e hora que esse chegar aí sim ele manda pro outro o "Envia de novo"), serão 12M de RX, o throughput real vai ficar nuns 4Mbps agregado. E 10 clientes dificilmente trafegarão mais que 4Mbps de UPLOAD somados.

Então limitar limita, mas é um limite alto pra idade desses padrões. Quem está usando A ou G pra vender planos tipo 3 ou 4Mbps tá lascado, precisa MUITO sinal pra isso já que 15 clientes simultâneos de 4Mbps vão consumir demais até se usar o data rate de 54M (Que quando muito dá um 20Mbps de throughput). Esses data rates tipo 18M servem pra uns 15 clientes simultaneos em planos de 1M cada, na prática ele provavelmente vão ficar abaixo até dos 4Mbps, que dirá chegar nos 8Mbps que um PTMP com esse data rate deve entregar.

A prática que vou sugerir é ter throughput na medida pra rede cheia, digo, se tem 10 clientes de 1Mbps, melhor usar 18M e ter CCQ de 100% nos 4Mbps circulando, que usar 54M e ter CCQ de 80% com reenvios de pacotes pros mesmos 4Mbps circulando. Se o limite do cliente é no concentrador e não na interface wireless no caminho, não precisa um throughput muito maior que o que concentrador vai aplicar, mas em PTMP tem vários clientes ao mesmo tempo e se usar data rate baixo demais (6M, digamos) esse choque de dados vai criar um gargalo extra, eu sugiro pesar a banda agregada que a setorial trafega, e ter throughput pra pelo menos o dobro da banda agregada média.

(10 clientes de 1Mbps cada vão ficar acho que nuns 2-4Mbps boa parte do dia, só se tiver muito heavy-user vai chegar nos 6 ou 7Mbps, então o uso de 18M AP>cliente até serve. Se tem clientes próximos e sinal sobrando pra usar 24M melhor ainda, mas o que não dá é ter sinal baixo (Uns -74dBm) e usa data rate tipo 24M, aí a perda de pacotes cria um gargalo mais incômodo que o uso de 18M (Ou: Melhor 18M com CCQ de 98%, que 24M com CCQ de 78%))

----------


## jmathayde

Então na pratica colocar no MK ou APC fixo exemplo como voce falou em 24M e fixar os clientes em 18Mb caso houver clientes com sinal melhor fixa em 24M tambem seria o melhor cenário ?

Estou fazendo alguns testes aqui na APC 2M -90 com 5 clientes pendurados e me conectei com eles , o maldito nao passa de 2MB o trafego geral usando o Btest to ficando maluco ja kkkk , mesmo assim otima dica , vamos testando e ajustando o bicho , o MK é bem mais facil para ajustes deste tipo bem mais facil .



.

Ja mudei mudei de tudo e nao passa mais que 2 MB , alguma dica de alguem

----------


## jmathayde

Notei aqui tambem muito erros tx 


Estou usando 2.4 ok

----------


## raumaster

Rubem, tanto faz no cliente como no AP, a modulacao aparece igual, a mais alta setada no AP mesmo colocando taxa baixa na CPE do cliente. Deve ser algum bug.

----------


## chocobama

ALguém aqui consegue usar datarate diferente no cliente e no AP. Exemplo do Ap transmitindo em MCS12 e cliente em MCS8?

----------


## jmathayde

> ALguém aqui consegue usar datarate diferente no cliente e no AP. Exemplo do Ap transmitindo em MCS12 e cliente em MCS8?



Mais ou menos isso minha duvida alem do base os clientes terem fixos datarate diferente , digo melhor sinal mcs alto menor sinal mcs baixo , e se isso nao iria prejudicar a rede como um todo ,

----------


## rubem

Que eu mesmo usei por um bom tempo, foi R52HN em MCS3 e clientes 2,4GHz em auto por falta de ter a opção, SXT-primeira-geração como AP em MCS5 e clientes em MCS2 e 3 (Airgrid e Nanobridge), RB Crossroads (RB com RF, tipo RB711 5hn) em MCS4 e clientes 5GHz em MCS1 (Airgrid, SXT, NS Loco M5, Oiwtech 5817, PCBA Eternetec , ao longo do tempo foram vários clientes entrando e saindo, não teve nenhum que não conectava, nesse era uma enorme zona, acho que teve setorial com 20 clientes com 20 modelos diferentes de CPE's, a única coisa em comum era estarem fixos em MCS1.

Numa cidade do lado só instalei um Rocket M5 em MCS12, só tinha 4 ou 5 clientes, com NS Loco M5 e todos ficaram em MCS9 ou 10. Como o dono não me ligou depois, tudo deve ter conectado. Tinha Bullet M5 numa omni e isso teve que ficar em 36M (De modo A) porque tinha no meio dos clientes muita CPE velha, a mistura A/N com datarate em automatic estava dando CCQ baixo pra todos, fixo em 36M normalizou, fixo em MCS4 normalizava mas os clientes com aparelho apenas A não conectavam. Em automatic era coisa tão ruim que nem conseguia acessar o setup e carregar tudo, depois de fixo em 36M como que por milagre tudo abria rápido.


Numa fazenda foi RB912 num "PTP triplo", digo, um lado na fazenda, e na cidade 3 antenas conectadas nela, na fazenda acho que era MCS12 também, na cidade sei que era MCS8, o mínimo.

O que tive problema foi numa Omnitik, tive que deixar em auto porque nada conectava, era MK 6.alguma-coisa, 6.27 provavelmente, mas só tinha meu próprio notebook (Dualband) e um airgrid velho pra testar, acabei deixando pra lá porque tinha até antena presa em cabo de vassoura (Não ia adiantar caprichar, com instalação sem visada e sem zona de Fresnel o CCQ vai pro lixo independente da configuração), fora que é longe demais pro meu carro velho...

Num mini-PTP tive problema entre SXT Lite5 e Nanobridge, não lembro quem era AP e quem era estação mas a config. inicial só aceitava ambos em automatic (Que dava CCQ péssimo), invertendo AP e estação funcionou. Os outros PTP's sempre funcionaram com qualquer configuração, uso muito MCS12, mas se tem antenas diferentes (Pra aproveitar o que os clientes já tem) uso data rates diferentes tranquilo, coisa tipo Nanobeam 5AC num lado e NS Loco5 (Não M5) nem sei como funcionou, e se não me engano passa uns 15Mbps!

Se tem bug, tem bug em muito aparelho diferente! Em MK me parece que é coisa de versão mais nova, isso só começou de pouco tempo pra cá, em tempos de 4.17, 5.23, não tinha errado, agora com 6.x pra mim que tem mais bug (Usando um par de RB911 baratinha fim do ano passado não consegui usar 10MHz, simplesmente o scan não achava nada se colocava em 10MHz, não é que não vi o AP, ele não escaneava nada, zero, também fiz downgrade pra normalizar.

----------


## lpcs007

boa noite amigo @*rubem*, precisava do seu serviço para ajustar alguns enlaces. Será que podemos conversar melhor por mensagem? Abraços.

----------


## raumaster

O que tem "diferente" nos meus APs é, uso do procolo NV2, Uso do recurso Noise Immunity AP/Client, Superchannel habilitado, DFS desabilitado, mas creio que o NV2 deve ser o que faz o MCS ficar igual nas duas pontas, só uma suspeita minha... Engraçado que posso habilitar qualquer combinação de MCS no lado do cliente, SXTs, que ele so obedece ao AP. Minha rede esta uma mistura de versoes 6.33 e 6.34. Tem 6.33.3, 6.3.4...

----------


## sombra

> O que tem "diferente" nos meus APs é, uso do procolo NV2, Uso do recurso Noise Immunity AP/Client, Superchannel habilitado, DFS desabilitado, mas creio que o NV2 deve ser o que faz o MCS ficar igual nas duas pontas, só uma suspeita minha... Engraçado que posso habilitar qualquer combinação de MCS no lado do cliente, SXTs, que ele so obedece ao AP. Minha rede esta uma mistura de versoes 6.33 e 6.34. Tem 6.33.3, 6.3.4...


Creio que não seja por causa do nv2, pq em 802.11 tb acontece! Creio que seja um bug do routerOS. O mesmo serve para se conectar em um AP ubnt com data rate fixo em mcs 12 e o cliente sendo sxt só conecta se estiver com mcs default ou marcado o mcs12.

----------


## chocobama

Aqui uso um omnitik em N conectando alguns loco M5 e SXT. Irei colocar uma nano M5 para funcionar como AP, pois não consigo fixar o MCS nos SXT. Mas loco M5 basta colocar o MCS em 8 ou 9 e pronto. Nos SXT ele obedece ao AP e se eu tentar forçar apenas MCS 8 ou 9 simplesmente não conecta.

----------


## FMANDU

Ainda sobre o MCS e de problemas para conectar com SISO ou Mimo setado diferente do AP... Depois de inúmeros testes vi que se desmarcar o MCS Basic, é possivel fazer conectar de acordo com o Supported. Por exemplo: se eu marcar MCS 10,11,12,13 no ap e marcar somente o 10 no station, a sxt não vai conectar, mas tem que desmarcar todos do basic, conecta. Segue os prints:

----------


## sombra

> Ainda sobre o MCS e de problemas para conectar com SISO ou Mimo setado diferente do AP... Depois de inúmeros testes vi que se desmarcar o MCS Basic, é possivel fazer conectar de acordo com o Supported. Por exemplo: se eu marcar MCS 10,11,12,13 no ap e marcar somente o 10 no station, a sxt não vai conectar, mas de desmarcar todos do basic, conecta. Segue os prints:


Começou a melhorar  :Smile:  o ideal mesmo seria usar 12 no AP e 9 no cliente, iria ficar show, aparecendo um tempo aqui vou fazer novos testes..

----------


## FMANDU

Na verdade o certo seria usar o mesmo Mcs no ap e no cliente. O AP iria trabalhar bem mais redondo. Porem... tem instalação complicada, arvore que cresce no meio do caminho, construção nova que atrapalha a visada e etc, que somos obrigados a baixar o mcs e subir o ganho no lado do station.




> Começou a melhorar  o ideal mesmo seria usar 12 no AP e 9 no cliente, iria ficar show, aparecendo um tempo aqui vou fazer novos testes..

----------


## sombra

> Na verdade o certo seria usar o mesmo msc no ap e no cliente. O AP iria trabalhar bem mais redondo. Porem... tem instalação complicada, arvore que cresce no meio do caminho, construção nova que atrapalha a visada e etc, que somos obrigados a baixar o mcs e subir o ganho no lado do station.


MCS do cliente é responsável pelo UPload que quase sempre é bem baixo, dando possibilidade de se trabalhar com um MCS minimo no cliente possibilitando estabilidade na conexão.

----------


## jmathayde

> MCS do cliente é responsável pelo UPload que quase sempre é bem baixo, dando possibilidade de se trabalhar com um MCS minimo no cliente possibilitando estabilidade na conexão.


Caro , mais sera que não iria atrapalhar a performe-se da rede mesmo upload deixando muito baixo o mcs ?

E teria mais informações sobre mcs , sinceramente não sabia que no cliente so serve para Upload

----------


## rubem

Se tem upload de 1Mbps, e usar MCS0, em 20MHz ele tem throughput na casa dos 3Mbps, é meio pouco mesmo. Mas em MCS1 já são uns 6Mbps, já tem dado de sobra.

Quem usa dupla polarização (Pra que usar single em pleno 2016?), os equiptos operam com mesmos sinais em MCS8 ou 9, ou seja, pode usar MCS9 no cliente, que tem throughput na casa dos 10 a 14Mbps, ter um upload de 1M num data rate desse é absolutamente tranquilo.


O checksum de cada pacote de wifi enviado pelo AP é respondido pelo cliente no mesmo datarate do envio. Mas a resposta do pacote TCP dado pelo computador do destinatário é feita no que se contabiliza como upload mesmo. Ou seja, um data rate baixo não diminui a capacidade de envio de pacotes por parte do AP.

Assim como tem que ver o throuhput agregado no data rate de TX da torre, tem que ver o throughput agregado de upload dos clientes. Se os clientes tem, na média, uns 2 ou 3Mbps de tráfego de upload, é melhor não usar MCS0 como TX neles, mas sim MCS1, porque o tráfego está muito perto do limite de throughput do MCS0.

Mesmo que você venda planos tipo 2M de download e 1M de upload, o trafego vindo dos clientes (O upload somado de todos) será muuuuuito baixo, se digamos 20 clientes de 2Mbps de download consomem uns 12Mbps de trafego agregado, o upload mal vai chegar em 2Mbps, usar um data rate com throughput 3 ou 4x maior que essa média é mais que suficiente, o download até sobe muito as vezes (5 ou 6 pessoas abrem um vídeo maior, mais ou menos ao mesmo tempo), mas o upload raramente tem picos muitos altos.


Volto a repetir: O checksum do pacote na parte de wifi é respondido no data rate da parte que enviou, e a parte de sincronia e cia (Envio do SSID, por exemplo) é feito no preambulo, que é o menor data rate do modo, o preambulo em A é de 1 ou 2Mbps, em N a 6Mbps. Ainda que você selecione o uso de MCS15 nos 2 lados, tem um moooooooooonte de dados passando em data rate de 2 ou 6Mbps o tempo todo, numa modulação BPSK bem "lenta", e isso é feito porque esses dados tem prioridade, pode perder um pacote do cliente que se for preciso ele reenvia, mas se perder pacote de sincronização a conexão cai e demora muitos segundos pra reconectar (Renegociar chave e cia). Ter data rate baixo no meio não degrada rede quando ele tem tráfego baixo, geralmente é o contrário, data rate baixo não perde pacotes (MCS15 com sinal -70dBm perde muito pacote) então o gasto total de tempo nesse envio é menor, mesmo usando um data rate mais baixo (Porque não precisa ficar reenviando pacotes perdidos).

----------


## jmathayde

> Se tem upload de 1Mbps, e usar MCS0, em 20MHz ele tem throughput na casa dos 3Mbps, é meio pouco mesmo. Mas em MCS1 já são uns 6Mbps, já tem dado de sobra.
> 
> Quem usa dupla polarização (Pra que usar single em pleno 2016?), os equiptos operam com mesmos sinais em MCS8 ou 9, ou seja, pode usar MCS9 no cliente, que tem throughput na casa dos 10 a 14Mbps, ter um upload de 1M num data rate desse é absolutamente tranquilo.
> 
> 
> O checksum de cada pacote de wifi enviado pelo AP é respondido pelo cliente no mesmo datarate do envio. Mas a resposta do pacote TCP dado pelo computador do destinatário é feita no que se contabiliza como upload mesmo. Ou seja, um data rate baixo não diminui a capacidade de envio de pacotes por parte do AP.
> 
> Assim como tem que ver o throuhput agregado no data rate de TX da torre, tem que ver o throughput agregado de upload dos clientes. Se os clientes tem, na média, uns 2 ou 3Mbps de tráfego de upload, é melhor não usar MCS0 como TX neles, mas sim MCS1, porque o tráfego está muito perto do limite de throughput do MCS0.
> 
> ...



Bom gostaria de analisar o meu cenario , esta abaixo a tabela de clientes neste setor , estou usando protocolo ativo da intelbras , e nos clientes estou usando MCS 11 nos clientes , então seria equivoco meu fazer isso certo , se fixar nos clientes MCS 0 , 1 ou ate 3 estaria suficiente seria isso ?

----------


## rubem

Se tem equipto MIMO, não use MCS0 a 7, isso são data rates de polarização simples.

Esses sinais -65dBm pra mim dá pra MCS13, tem que conferir o datasheet pra ter certeza, mas no mínimo MCS12 eles suportam. -71dBm talvez só MCS11 (Tem que ver o datasheet, a sensibilidade). Mas com esses sinais não vejo nenhuma necessidade de usar digamos MCS8 ou 9, tem sinal suficiente pra MCS11.

(MCS8 é um MCS0 duplo, não use data rates de polarização simples (Só 1 chain) se o equipamento suporta 2. Veja os data rates nominais em www.mcsindex.com )

----------


## Haylan

Ola rubem tenho acompanhado o tópico a algum tempo. Quero parabenizar e agradecer você pelo, esforço e a disposição que você tem para responder as duvidas da galera e trazer para o grupo um material bacana e consistente, pucos se dispõe a fazer isso. Aprendi bastante sobe mcs e consegui aplicar boa parte desse conhecimento na pratica. Porem eu cheguei a um empasse e gostaria, que se você pudesse esclarecer alguma duvidas que eu tenho.
A rede do provedor que eu trabalho consiste em MK e Ubiquit. Mas todos trabalham de modo separado (nao conecto mk em Ubi e vice-verça). A maioria de rede e Mk. 
Trabalhamos com Rb 912 e 922 nas torres, e todos os clientes usam sxt.
Consegui melhorar bastante a rede porem ainda to enfrentado alguns problemas.
Em alguns painéis com bastante clientes nivel de ccq ficou muito bom, mas ja em outros com um numero reduzido de clientes eu nao consegui ategir a mesma qualidade. Nas imagens pode observar o painel mais lotado da rede. Ele ficou muito bom( não sei se e possível melhorar) mas ja em outros que tem menos clientes eu não consigo um bom resultado. Tenho algumas reclamações sobre perdas de pacotes, eu faço ping do painel para o cliente e fica alto ou para de responder, as vezes isso acontece com apenas 1 cliente do painel enquanto os outros fica tudo ok. 
Se tiver como você me dar algumas dicas de como melhorar agradeço. E agradeço mais uma vez pelo esforço de vir aqui e compartilha o conhecimento com a galera.

----------


## rubem

Também não acho que tenha como melhorar isso, 70 clientes numa RB912 é coisa pra caramba, é um hardware meio comum (Só com um sistema operacional ótimo pra ficar ok), se tivesse instalações porcas duvido que teria esses CCQ com mais de 15 clientes.

Acho que o pouco que dá pra melhorar são esses clientes com RX meio ruim:


Na prática eles só vão atrapalhar hora que eles requisitarem muitos pacotes. Estar apenas conectado, sem gerar tráfego, não consome processamento da RB, precisa consumo de tráfego pra "incomodar", por isso não necessariamente o cliente de sinal ruim é o que tem ping ou CCQ ruim, teria que ver o tráfego (Marca pra exibir as colunas Ack Timeout e TX/RX bytes (Somatória), veja se hora que tem ping ruim não tem tráfego nalgum cliente com TX/RX bytes aumentando rápido (Indicando consumo)).

Ou marca a aba P Throughput, o pass throughput tá meio relacionado ao CCQ mas quando o sinal é ruim (Por culpa da zona de Fresnel parcial) ele é alto quando o rádio está sem tráfego, mas hora que há consumo de dado o pass throughput cai, e falo cair pra menos de 1Mbps as vezes, sem que o CCQ caia tanto. O cliente que tiver um pass thrgouhput tão baixo quando tem tráfefo (Quando não tem tráfego não conta) tem problema físico no sinal, precisaria ir nesse cliente ver se tem como subir antena ou reposicionar.

----------


## gfqsw

@*rubem*, estou no mesmo barco que o amigo Haylan e estou seguindo suas recomendações também.

Ativei o P Throughput, mas não aparece nada nesta coluna, será qye tem a ver com o Nv2? Pois nenhum AP meu com Nv2 aparece algo nesta coluna.

Estou com o mesmo equipamento e configuração, 54 cadastrados e 48 clientes conectados simultaneamente. No momento em que a latência subiu, desabilitei todos que estavam com sinal acima de -60 e sobraram 43 e mesmo assim a latência continuou.

----------


## Haylan

@*rubem*,Humm entendi isso explica o porque de eu ter um painel com 24 cliente e nao consegui um ccq decente. Vou ter para passar em cada cliente para revisar as instalações feitas( a galerinha que instala e fogo) na pressa de fazer o serviço acaba colocando a antena no cliente de qualquer jeito.

----------


## gfqsw

Caro Arthur, vou dar uma olhada com mais atenção em ruido.

Aqui estou usando como limite -60, mas alguns poucos clientes chegam a -65. Nesse caso em particular, tem apenas 3 clientes com esse sinal, o resto de -60 para melhor.

Abraço.

----------


## RaiSantos

Fala galera sou novo por aqui e estou com problemas em minha net via rádio mikrotik, quase 1 mes estou com problemas em download, p/ baixar arquivos a taxa esta muito baixa net de 2 megas dando na maioria das vezes taxa de transferência de 46k no máximo chegando a 100k, gostaria de saber o que esta acontecendo essas configurações dentro do meu rádio

----------


## RaiSantos

Fala galera sou novo por aqui e estou com problemas em minha net via rádio mikrotik, quase 1 mes estou com problemas em download, p/ baixar arquivos a taxa esta muito baixa net de 2 megas dando na maioria das vezes taxa de transferência de 46k no máximo chegando a 100k, gostaria de saber o que esta acontecendo essas configurações dentro do meu rádio estao certas

----------


## euanent

Meu problema e o seguinte quando tento fixar mcs no sxt cliente o ap usa o mcs para up e para down ... Já em todas as outras cpes não tem este vinculo.
queria saber se e possível desvincular o mcs de subida com de decida no mikrotik cliente com mikrotik AP

----------


## sombra

> Meu problema e o seguinte quando tento fixar mcs no sxt cliente o ap usa o mcs para up e para down ... Já em todas as outras cpes não tem este vinculo.
> queria saber se e possível desvincular o mcs de subida com de decida no mikrotik cliente com mikrotik AP


Já tentei de todas as formas e também sem sucesso.

----------


## NielsonPadilha

> Fala galera sou novo por aqui e estou com problemas em minha net via rádio mikrotik, quase 1 mes estou com problemas em download, p/ baixar arquivos a taxa esta muito baixa net de 2 megas dando na maioria das vezes taxa de transferência de 46k no máximo chegando a 100k, gostaria de saber o que esta acontecendo essas configurações dentro do meu rádio estao certas 
> 
> 
> Anexo 66153Anexo 66154


Você já tentou baixar de outro site?

Enviado de meu SM-E700M usando Tapatalk

----------


## euanent

Por favor alguém a duvida ainda permanece...



> Meu problema e o seguinte quando tento fixar mcs no sxt cliente o ap usa o mcs para up e para down ... Já em todas as outras cpes não tem este vinculo.
> queria saber se e possível desvincular o mcs de subida com de decida no mikrotik cliente com mikrotik AP

----------


## FMANDU

> Por favor alguém a duvida ainda permanece...


Impossível, no MK quem manda é o ap

Enviado via Moto G (4) usando UnderLinux App

----------


## rubem

Essa questão depende da versão do RouterOS. Não mapeei que versões exigem o mesmo data rate em RX e TX, mas o mais comum é você ter que marcar no AP o data rate que a estação vai usar.

Digo, marca digamos MCS10 e MCS12 no AP, e somente MCS10 na estação. Nalgumas versões nem isso resolve.

Isso é limitação em software, não em hardware, os chipsets e o padrão do IEEE não exigem data rates similares.

----------


## mkmarcio

Boa noite?

Estou com problemas na polarização, uso uma omnitik na torre e airgrid nos clientes, mas não consigo usar na vertical sinal fica ruim. Como posso regular isso?

----------


## rubem

Tá marcado chain0 e chain1 na Omnitik?

E se o sinal na vertical fica bem mais baixo que na horizontal, é porque a zona de Fresnel da vertical está insuficiente, e isso é falta de altura (Sinal passando metros SOBRE os obstáculos. Na horizontal precisa metros pro LADO dos obstáculos).

----------


## emilidani

[QUOTE=mkmarcio;808660]Boa noite?

Estou com problemas na polarização, uso uma omnitik na torre e airgrid nos clientes, mas não consigo usar na vertical sinal fica ruim. Como posso regular isso?[/QUOT

A polarização vertical SEMPRE é mais afetada pelas atenuações porem tem que testar em vários pontos para concluir esta com problemas no AP.

----------


## SenhaLivre

Olá Rubem, muito obrigado por compartilhar tanto conhecimento, tem sido muito agregador para meus projetos.

Eu percebi que a discussão é voltada para provedores que utilizam wireless. E para Wi-Fi Indoor o que você indicaria para um AP suportar mais usuários? Na maioria dos nossos projetos utilizamos controle de banda entre 3 e 5 mbps por usuário. Datarates mais baixos ajudariam a suportar mais clientes simultâneos?

----------


## joaopaulodelfinomc

> Eu diria que se é pra deixar alguém em auto, deixa a torre.
> 
> O cliente tem pouco dado pra enviar, só o upload, rajadas de 100 a 200kbps geralmente, não precisa de muita coisa.
> 
> A torre tem que "ouvir" todo mundo, se o sinal de todos chega em digamos 54M mas em algo baixo tipo -60dBm, a torre vai ficar pedindo reenvio pra todos.
> 
> (Porque o software NÃO se adequa como devia, o software é burro e insiste em subir de rate mesmo não tem sinal suficiente)
> 
> Já se os clientes todos estiverem transmitindo em digamos 12V, o sinal de -60dBm será mais que suficiente pra todos esses sinais serem legíveis, a torre vai entender tudo no primeiro envio, não vai precisar pedir repetição.
> ...





Boa tarde amigo me fala como e feito esse calaculo de qual potência dBm usa no AP e qual potência usa no clientes


Obrigado 
Abraço

----------


## joaopaulodelfinomc

Qual potência coloca no AP-PMTP usando clientes ate 3km e clientes proximo tipo 30metro da torre essa conta de potência eu não sei fazer pode me da essa dica vo usa Setorial ALGcom + RB922NETMETAL e no cliente SXT
obrigado
abraco

----------


## rubem

> Boa tarde amigo me fala como e feito esse calaculo de qual potência dBm usa no AP e qual potência usa no clientes
> 
> 
> Obrigado 
> Abraço


Em teoria a queda de sinal depende apenas da distância, é free space path loss, se saem 30dBm EIRP de um rádio, seja UBNT, MK ou qualquer coisa, seja 20dBm do rádio + 10dBi da antena ou seja 10dBm do rádio + 20dBi da antena, em 1km em 5,8GHz o sinal vai cair 108dBm. 

Logo, 30 - 108 = -78dbm é o sinal chegando no ar a 1km. 

Se diz que uma antena tem digamos 18dBi de GANHO porque esse é o aumento prático de sinal que terá. Se no ar tem -78dBm, ao usar um rádio com antena acoplada de 18dBi, o sinal vai aumentar 18dBm. Logo, -78 + 18 = -60dBm.

O sinal chegando no rádio será -60dBm então.

Se for uma CPE com antena de 24dBi, -78 + 24 = -54dBm. Mesmo sinal de -78dBm no ar, a placa da CPE pode ser até a mesma, só muda o ganho da antena.

Eu acho mais fácil calcular em sites, digamos aqui:
http://mayo.nuvisions.net/ubnt_link/

Um exemplo, uma torre com rádio MIMO (E tanto faz ser Rocket, RB912, Intelbras APC 5M, ou qualquer AP com 2 chains), e uma antena de 16dBi (Tanto faz ser antena MK, UBNT, Algcom, Intelbras), com o rádio setado pra 18dBm de potência:


Em 2km (1,25 milhas), se a CPE do cliente tem 16dBi de ganho, e pode ser um SXT Lite5, pode ser um Nanobeam 16dBi, pode ser uma CPE Intelbras de 16dBi, enfim, sendo dupla-polarização com 2 chains, vai ter margem suficiente até pra MCS12, afinal tem -63dBm e a sensibilidade em MCS12 de quase toda CPE com suporte a MIMO é uns -83dBm. Isso aí tem dados de UBNT, mas os chipsets de outras marcas são muitos similares, isso se não forem exatamente os mesmos, tanto faz a marca, pra efeitos de cálculo o que vale é a sensibilidade da etapa de RF, que é bem similar nos equipamentos comuns que provedor usa.

Só que isso é o cálculo com a zona de Fresnel limpa. O uso disso aí na verdade é contrário, você deixa a torre lá por 18-20dBm pra não aquecer o amplificador interno a toa, e SE depois de instalada a CPE no cliente não deu -63dBm, e sim uns -70dBm, quer dizer que tem algo na zona de Fresnel COMENDO esses 7dBm de sinal que estão faltando. E com -70dBm não dá pra muita coisa, só MCS10 ou MCS11 com estabilidade, então se a intenção é deixar a torre fixa em MCS12, a única solução é não usar nesse cliente uma CPE de 16dBi, e uma uma de maior ganho, tipo 20-23dBi.

Já se o cliente tem a CPE de 16dBi a apenas 200m da torre, como o sinal seria altíssimos -43dBm chegando na torre, pra equalizar ele em relação aos clientes mais distantes, você BAIXA a potência desse cliente, coloca no setup em digamos 1dBm ao invés de 20dBm, aí terá sinal 19dBm mais baixoc (Afinal você baixou a potência do cliente em 19dBm), vai cair de -43 pra -62dBm, é sinal ok pra digamos MCS12.

No AP você meche APENAS 1 vez, configura pra potência baixa e segura tipo 16-20dBm, eu recomendo 17dBm como padrão. NUNCA MAIS mexa nisso, se um cliente tem sinal baixo, aumenta a antena dela, não mexa no AP!

A CPE escolhida pro cliente depende da distância dele da torre, faça o cálculo no site com valores na direita tipo 8dBi, 12dBi, 14dBi, 16dBi, 20dBi, e veja em que distâncias terá digamos -60 a -65dbm caso queira usar MCS12 como padrão no AP. Só que... com o tempo você vai pegar o jeito, ir na casa do cliente, e se a visada não parecer ter a zona de Fresnel totalmente limpa, vai usar CPE de ganho maior que o idealmente necessário. 

Na prática o jeito é botar a CPE, e ver que sinal tem. Se tem sinal abaixo do calculado, não é que o cálculo está errado, e sim que a visada não é totalmente limpa, e as 2 soluções possíveis são:

1- Demolir as casas no caminho e podar as árvores no caminho

2- Simplesmente botar uma CPE de ganho maior nesse cliente.

Até eu, que sou fã de demolir cidade feia e não-planejada, recomendo seguir a opção 2, botar CPE com antena de ganho maior. Se tem sinal -80dBm e precisa sinal 20dBm maior, se hoje tem antena de 16dBi, então precisaria colocar antena de 36dBi (16+20 = 36), obviamente NESSE CASO a visada deve estar bem comprometida e não dá pra atender esse cliente, é bem simples essa questão, fala pro cliente que não dá pra atender ele porque tem construções na frente, e que a casa dele não é alta o suficiente (Já nem comece a instalar CPE a só 20cm acima do telhado, pegue o hábito de usar pelo menos 1m acima! Tubo 1" chapa 18 custa uns R$ 30, dividindo em tubos de 1,5m dá R$ 7,5 por cliente! Isso é 3% do custo de uma CPE! Usar tubo curto é uma economia muito burra, ferra sua rede por uma economia pra lá de insignificante!).

Enfim, o cálculo é útil, mas é mais útil pra você ir aprendendo na prática o poder da zona de Fresnel parcial. Não tem como calcular no olho qual a zona de Fresnel, nem com binóculo dá pra ter precisão, o jeito é instalar e ver na prática o quanto ficou abaixo do cálculo (E se ficou 20dBm abaixo do calculado, vá no oculista, essa visada está pra lá de ruim e você não viu? Nem se TENTA instalar nada quando a visada é visivelmente obstruída demais, é perda de tempo, ferra a rede com bobeira).

----------


## joaopaulodelfinomc

@*rubem* você pode passa um e-mail o WhatsApp que consigo fala com vc?

----------


## joaopaulodelfinomc

@*Haylan*, Boa noite amigo primeiramente parabéns pela sua rede ccq 100% pode me da umas ajuda to começando agora e tenho muitas dúvidas qual potência vc usa no Ap e vc usou mcs 11 e no cliente vc usa qual mcs pode ajuda fico grato

----------


## joaopaulodelfinomc

@*rubem* você me fala que no AP a potência transmissão do radio tem fica em 20dBm eu vou usa clientes so ate 3km e o radio e uma RB922NETMETAL

----------


## rubem

Eu nunca disse que a potência no AP tem que ficar em 20dBm. Olha ali no texto, recomendo 16-18dBm pra aquecer menos o amplificador.

Fiz o cálculo com 20dBm mas VOCÊ pode refazer o cálculo com a potência que quiser usar na torre, não tem segredo nenhum nessas calculadoras prontas, é muito simples usar. Faça a conta dos níveis de sinal que vai ter a 3km usando Nanobeam 19dBi nesses clientes, ou LHG 24dBi, ou SXT Lite5 16dBi. Se o provedor é seu, você que faz os cálculos e define qual os valores ideais.

O que recomendo sem falta é: NÃO MEXER no AP caso 1 ou 2 clientes tenham sinal ruim! Configura o AP 1 vez na vida e NUNCA MAIS MEXE! Que se lasquem esses 2 clientes com sinal ruim, eles que moram mal pra caramba, se eles não querem colocar CPE mais cara (Se bem que LHG 24dBi não é cara) ou uma torrezinha em casa pra passar por cima das árvores, não atenda eles! Perca cliente mas não mexe no AP pra tentar conquistar 1 ou 2 clientes a mais, se ficar mexendo em AP vai só piorar a rede pros demais clientes. Então seja lá qual for a potência e ack-timeout escolhidos, configure na hora de iniciar a rede e nunca mais mexa! E se mexer, faça testes de DIAS, aumentando ou diminuindo 10 ou 20uS de ack-timeout, ou 1dBm a mais ou a menos de potência, vai ver que não é isso que melhora grandes coisas sua rede, é a instalação de CADA cliente (Não de 70% dos clientes. Tem que ter 100% das instalações perfeitas).

----------


## joaopaulodelfinomc

@*rubem* certo! Entendi eu vi que vc mandou deixa o AP deixa mcs Default e no Data Rates escolher qual Mbps ?

----------


## joaopaulodelfinomc

@*rubem* no radio usando Setorial Algcom + RB921NM e nos clientes usando SXT, LHH 24dBi consigo entrega ate que velocidade? To querendo vende esses planos 2,4,7,10,15,20Mega consigo?

----------


## rubem

No RouterOS a aba Data rates só seleciona os data rates dos modos A, B e G. Se você colocar em modo somente N, tanto faz o que setar na aba data rates. 

Os data rates de modo N estão na aba MCS, é nessa aba que tem que se preocupar. Se por acaso as vezes ver no monitoramento um data rate de A, tipo 6Mbps, não se preocupe, é só um cliente sem tráfego, que está usando o data rate de sincronia e cia, você só saberá o data rate real que o cliente usa quando ele estiver trocando dados de navegação com o AP.

Sobre SXT Lite5 e LHG, é só fazer o cálculo no site: http://mayo.nuvisions.net/ubnt_link/

Bota rocket M5, bota na esquerda o ganho da setorial Algcom, e na direita bota rocket m5 com antena de 16dBi (Que é a da SXT Lite5), pra planos de 20Mbps vai ter que usar MCS15 mesmo, se tiver digamos 20 clientes nessa setorial, isso exige margem de sinal bem acima de 15dBm! Ou seja, vai precisar sinais lá pelos -57dBm pra cima (-56, -55, -54, etc), isso provavelmente só vai existir em cliente a menos de 1km. Já com a LHG provavelmente vai ter esses sinais até uns 3km de distância (Isso tudo com zona de Fresnel mais que 100% livre). Calcula no site pra ter certeza, inverte os lados (Põe 24dBi da LHG na esquerda e 16dBi da setorial Algcom na direita, pra ver o nível teórico de RX da torre), gasta meia hora com cálculos.

----------


## joaopaulodelfinomc

@*rubem* no AP eu deixo o MCS default e só coloco a potência 16dBm. o MCS eu só mecho no rádio do cliente?

----------


## rubem

Eu usaria MCS fixo no AP. Depende que banda quer vender, planos até 5-10Mbps dá pra usar MCS12. Mas com planos de 20Mbps precisa MCS15! (E sinal lá por -55dBm pra cima se quiser CCQ ótimo nesses clientes). Então NESSE CASO é um dos pouquíssimos casos que MCS default faz sentido. Eu usaria fixo em MCS15 na verdade.

Nos clientes mesmo com planos de 20Mbps é bom usar MCS fixo e baixo, um MCS12 já vai ter todo o upload que vender (Provavelmente 4 a 5Mbps mesmo em plano de 20Mbps). Se usa upload de 15-20Mbps vai precisar MCS14 ou MCS15 nos clientes também! Se for upload baixo tipo 2-3Mbps pode usar MCS11, talvez MCS10 se tiver até uns 20-25 clientes por setorial.

----------


## joaopaulodelfinomc

@*rubem* entendi mas eu le em algum forum e vi um pessoal falando que se deixa mcs fixo no ap e ser por acaso vc tem um cliente ruim esse ap vai força pra entender esse cliente ruim. Eu estava estudando e vou vende planos 2,3,4,5,6,8,10Megas pelo fato 20Mega exigir muito 



Outra dúvida me ensina usa essa tabela to perdido entendo nada disso ,
E como é feito os calculo SNR pq vejo um pessoal falando que vc tem internet de qualidade ser tive dentro SNR

https://mikrotik.com/test_link.php

----------


## rubem

SNR é uma *r*elação entre *s*inal e ruído.

(Signal Noise Ratio)

É bem simples, na verdade. Se o sinal é -70dBm, e o ruído é -100dBm, a relação entre eles é 30dB. Entre -70 e -100 existe 30 de distância. Logo, nesse caso o SNR é 30dB.

O SNR mínimo necessário depende do data rate e do rádio, mas em geral NO INTERIOR DO BRASIL não é tão comum ter ruído alto. O nível de ruído na maioria das cidades pequenas ou média vai ficar abaixo de -95dBm. Pra poder vender planos tão grandes você precisa ter data rate MUITO alto, que exige sinal MUITO alto, tipo -55dBm, então não tem como ter só 25dB de SNR, pois 25dBm mais baixo que -55dBm é -80dBm, e só existe ruído absurdo assim se você estiver numa torre dividida por uma duzia de provedores.

O SNR mínimo recomendando pra MCS15 vai pra casa dos 30dB, se nivelar os sinais na casa dos -55dBm implica que qualquer ruído (Noise floor, ou piso de ruído na tradução direta) abaixo de -90dBm tá mais que ótimo.

Se colocar antena digamos a 20cm de parede, ou a 30cm de estrutura metálica, o RouterOS (MK) ou o AirOS (Ubiquiti) vão mostrar ruído alto tipo -86dBm, mas isso não é ruído vindo da vizinhança, é problema criado pelo próprio equipamento (Digo, quem criou o problema foi o porco que instalou tão mal a antena), é só instalar direito que não terá esse problema. No forum da UBNT vai achar muito norte-americano com problemas assim, mas é que eles tem aqueles condomínios de casa onde há proibição de grandes estruturas nas casas, eles TEM QUE colocar as CPE's na posição mais porca do mundo, a só 20cm do telhado, por isso ELES tem essa impressão que certos ambientes são muito poluídos, mas fora da Avenina Paulista, e de torres divididas por provedores, é raro ver ruído real tipo -80dbm (Que ainda nem é absurdo pra quem tem sinais -55dBm).

Agora sobre o site de cálculo de link, fiz aqui um exemplo de outra RELAÇÃO, é a relação entre sinal e sensibilidade. Coloquei a sensibilidade em MCS15 da maioria das CPE's e rádios pra torres, -74dBm (Essa sensibilidade de cada data rate está no datasheet dos equipamentos):


Ele trata como 12dBm a margem mínima, mas na real muitos autores do ramo calculam ela aumentando conforme a distância (Por isso não passo esse link, e sim esse: http://mayo.nuvisions.net/ubnt_link/ Ele leva em conta uma relação maior quando a distância é maior). Se fizer muitos PTP's você verá isso na prática, um sinal -60dBm a 1km permite MCS15 se tiver zona de Fresnel 100% limpa. Mas... em 25km esse mesmo nível de sinal é suficiente mal e mal pra MCS13! Quanto maior a distância, maior o efeito da 2ª e 3ª zonas de Fresnel. PTP de morro a morro também fica ok em altas distâncias, simplesmente por ter uma maior zona de Fresnel sem reflexos.

Pra ter CCQ decente em todos os clientes, ou seja, CCQ de 98-99%, precisa relação na casa dos 20dBm, ou seja, se a sensibilidade do data rate escolhido é -74dBm, o sinal bom é -54dBm (Tem 20dBm entre eles). Esquece SNR por enquanto, porque só uma cidade muito lixo vai ter ruído tipo -80dBm, e qualquer ruído abaixo disso não é um problemão (Perfeito é lá pelo mínimo da sensibilidade do aparelho, uns -98 a -106dBm dependendo do equipamento. Em periferia com só 1 ou 2 provedores 5GHz operando é isso que terá na maioria dos canais. Em área rural terá coisa ainda mais baixa. Se tiver mais alta, a antena está refletindo em mastro ou suporte, é instalação mal-feita).

----------


## joaopaulodelfinomc

@*rubem* eu me confundo em exemplo 30dB o que é isso esses negócios dBm dB confundi muito minha cabeça não leva a mal amigo desculpa ai ser você pode me explicar isso
Outra coisa qual melhor equipamento usa que da mas qualidade na rede Rocket + nano , airgrid ou RB922NETMETAL + SXT, LHG

----------


## rubem

Decibel é uma medida antiga, um décimo de bel, ou um décido do som de um sino. Mais de um século atrás não existiam muitos padrões, então a referência que se achou pra medir a intensidade de um som era o sino. 10 dB então dá o mínimo som que um determinado sino faria (Na real HOJE sabemos que não ouvimos sons baixos, mas qualquer toque num metal gera som). Então dB na prática só se usa pra som.

dBm é só um jeito de fazer uma escala em dB, mas baseada numa potência, o miliwatt, ou milésimo de watt, o "m" da sigla. Watt é uma medida de potência, que basicamente é consumo elétrico, por isso se diz que uma lâmpada consome 10W. Então dBm é um decibel por miliwatt (Na verdade 0dBm é 1mW). dBi é só o correlato mas pra ganhos de antena. É a mesma referência, só que usamos dBm pra potência de RF nos rádios, e dBi pra ganho de antena.

Toda escala baseada em dB tem o seguinte: A cada 3dB o valor medido deve DOBRAR. Ou seja, se 1dB$ é R$ 1, então 4dB$ tem que ser R$ 2. Os valores intermediários serão percentuais dessa diferença. De R$ 1 pra R$ 2 nada muda, mas quando parte pra casa dos milhões aí é bom ter uma medida assim, talvez 20dB$ seja R$ 1 milhão. Estabelece uma base, e crie seu "padrão decibélico", se muita gente aceitar, talvez vire um padrão comercial de fato ("Muita gente" nesse caso é milhares de engenheiros, não adianta angariar curtidas no Facebook).

Se usa dBm ou dBi porque um sinal fraco tipo -71dBm seria escrito 0,000000079mW. Enquanto -69dBm muda pra 0,00000012mW. É muito zero! Tem que ficar contando zero toda hora (Em celular é pior, as vezes tem sinal lá por 0,000000000001mW. Radar as vezes tem 0,00000000000000001mW). Basicamente ao invés de usar watt, você faz uma escala cuja referência é o watt, se quiser usar um pra potência de lâmpada de ler pode criar um onde digamos um 1dblamp é 1W de consumo, aí você diz que uma lâmpada de 15W tem 15dBlamp. Pronto, fez uma escala baseada em alguma referência (Na natureza não temos como tirar referência de nada, nem a intensidade da luz do sol, ou sua cor, é estável ao longo dos anos. Todas as referências pros padrões são só um consenso de um grupo, no caso de intensidade de sinal em RF, a base é o miliwatt, mas pra facilitar a conta usamos o dB por miliwatt, porque em dB você pode usar valores negativos, -1dBm é sinal 2dBm maior que 1dBm, é igual dinheiro, dever R$ 1 é ter saldo de R$ -1, e isso é R$ 2 a menos que ter R$ 1 no bolso. Pensa sempre em dinheiro, se você tem -70, e ganha 10, você fica com -60. Se o sinal numa CPE de 10dBi é de -70dBm, ao mudar pra uma CPE de 20dBi vai ter 10dBm a mais de sinal, logo, terá -60dBm de sinal. Troque dBi por dBm na conta tranquilamente, aumentar ganho de antena aumenta no mesmo número o nível do sinal.

Sobre qualidade de Rocket+Nano, ou RB922+SXT, aí é questão de fé, minha religião diz que setups simples tipo de Ubiquiti são pecado, então eu não uso pra mim, uso só pros clientes, porque eles travam pouco e caso dêem problema tem um setup bem simples de mexer. Já Mikrotik em geral tem sistema operacional mais customizável, numa mesmo RB922 posso fazer roteamento, autenticação, página http pra hotspot, SSID's múltiplos, múltiplas senhas pra clientes diferentes, enfim, quase tudo que pode ser feito em matéria de rede um RouterOS de uma RB922 faz. Mas... pra cliente doméstico isso é inútil, eles nunca vão usar nada disso. Mas eu não sou cliente doméstico por isso prefiro Mikrotik.

Mas cuida com Airgrid, é uma CPE com só 1 chain, ele só usa 1 polaridade da torre pra trocar dados, enquanto todos os equipamentos de hoje usam 2 polarizações. Já que está ocupando um canal de 20MHz, usa 2 polarizações e passa logo o dobro do thrpoughput por ele. Se com um par de Nanostation passa digamos 50Mbps com um determinado nível de sinal, com o Airgrid vai passar só 25Mbps, já que está usando só 1 polarização. É tipo som stereo na música ou filme, já que vai ocupar o ouvido do telespectador, então coloca 2 canais diferentes de som, com um leve atraso num ouvido as vezes, pra parecer que um veículo passa da direita pra esquerda ou algo assim, PARECE ser só 1 som mas na real são 2 canais DIFERENTES com som. Em wifi você também pode transmitir 2 "canais" de dados num mesmo canal (20MHz de largura no espectro), é só colocar um em polarização diferente no outro, transmite um com a antena em pé (Vertical) e outro com a antena virada de lado (Horizontal), a intensidade é baixa o suficiente pro sinal de uma polarização não ser lido na outra (Assim como o som de um fone de ouvido numa orelha não pode chegar na outra orelha, senão perde parte do efeito estereoscópico; Efeito que se aplica também a imagens, uma imagem 3D é uma imagem estereoscópica, na real o dia todo você encher 2 imagens diferentes nos olhos, a análise das diferentes nelas é que fazem a gente estimar a distância do que estamos vendo).

Eu não usaria airgrid pra cliente de mais de 2Mbps nunca, com só 1 polarização vai fazer muito uso do processador da etapa de RF da RB922 ou do RocketM5, acaba afetando o tempo que sobra pra sua torre trocar dados com os clientes que tem CPE's dupla-polarização (Nanostation M5, Nanobeam, SXT, LHG).

----------


## joaopaulodelfinomc

@*rubem* eu vi um camarada falando em um forum da Mikrotik seguinte cenário coloca cada Radio AP com servidor pppoe e deixa a ccr so como firewall e Nat e o radio do cliente fica como bridge e quem fazer o roteamento e o roteado wifi do cliente o que vc acha desse cenário?

“ outra dúvida ser eu for montar um pop em outra cidade qual melhor forma desse pop dessa cidade eu crio um servidor pppoe pra essa cidade o fazer que esses clientes desse pop dessa cidade venha conectar onde fica minha central?”

“Outra dúvida qual melhor forma autenticação da CPE do cliente deixa ela como pppoe roteador bridge o deixa CPE do cliente como bridge e roteador do cliente como pppoe?”

----------


## rubem

Roteamento e cia não é minha área.

Meu negócio é RF e eletrônica.

Mas eu prefiro PPPOE e com a CPE do cliente autenticando, aí se ele vai plugar o cabo da CPE direto num desktop, ou se vai colocar um roteador wifi dentro de casa, tanto faz, a rede interna dele está devidamente isolada da rede do provedor pela CPE roteando, ele pode colocar switch, conversor de fibra, enfim, dentro de casa ele pode fazer o que quiser, afinal a casa é dele, se ele quiser colocar um switch na saída da CPE ele tem que poder fazer isso sem pagar visita do provedor.

----------


## avatar52

Pra que você quer encher a sua tabela de roteamento com os prefixos da rede interna do seu cliente? Não vejo ganho nenhum nisso, só um uso idiota de recursos operacionais.

----------


## joaopaulodelfinomc

@*rubem* qual melhor canal pra usa PtMP, PtP e esses canal do Brasil precisa ativa o DFS? Aqui não tem aeroporto próximo só 320km mesmo assim precisa ativa?

----------


## rubem

DFS usa apenas nos canais que tem radar no Brasil, é a faixa de 5470 a 5725MHz, que é a faixa que a legislação impõe limite de potência mais baixo.

Usar DFS em canais fora dessa faixa não faz NENHUM sentido, quem faz isso faz por noobice, o DFS só atua com radares, e não existe radar meteorológico no Brasil acima de 5,7GHz nem abaixo de 5,4GHz.

Sobre melhor canal, tem que ver o mais limpo em CADA torre. Pra PTMP o ideal é usar a faixa onde a potência é limitada, é essa faixa de 5470 a 5725MHz. Guarda a faixa dos 5725-5850MHz pra PTP, que PRECISAM potência maior. A faixa abaixo dos 5350MHz não foi feita pra uso outdoor, ela é só pra uso indoor no Brasil, só pra aqueles roteadores dual-band dentro de casa. 

Essa legislação é a mesma em boa parte do mundo ocidental, 5150-5350MHz pra uso indoor, 5450-5720MHz pra uso outdoor mas com DFS e com potência limitada lá pelos 27dBm EIRP, e 5725-5850MHz pra uso outdoor com limite de potência lá pelos 34dBm EIRP ou virtualmente ilimitado caso use antena direcional pra PTP. EUA, Canadá e outros países tem legislação similar, caso algum desinformado que o Brasil é ridículo por impor essas restrições. As restrições existem justo porque os usuários são leigos pra cacete e poluem todo o espectro por bobeira caso libere tudo. Provedor 2,4GHz não tem mais como existir em área urbana porque há abusos demais na faixa dos 2,4GHz, roteador doméstico com 30dBm EIRP pra passar 3 paredes e atender 1 (UM!) único smartphone, é um péssimo uso do espectro, e a maioria dos usuário faz um péssimo uso do espectro. É similar a estacionar carro em fila dupla na frente de casa, _"tá na frente da minha casa"_ não é desculpa pra atrapalhar a passagens dos outros pela rua, mas com RF é assim que a maioria dos usuários leigos pensam.

----------


## joaopaulodelfinomc

@*rubem* então eu coloquei um canais do Brasil mesmo que não tem radar perto preciso ativa o DFS?

----------


## rubem

Repetindo: Não faz sentido ativar DFS acima de 5725MHz.

E abaixo de 5350MHz provedor NÃO PODE usar (É faixa apenas pra uso indoor).

DFS tem que usar nas faixas de 5460-5725MHz. Fora disso não faz sentido ativar isso, não serve pra NADA se não tem radar nessa frequência.

----------


## joaopaulodelfinomc

@*rubem* você já chegou usa aquele novo recurso que a Mikrotik lançou na versão 6.41 nv2 sync que possibilita coloca todos Ap no mesmo Canais?

----------


## joaopaulodelfinomc

> Repetindo: Não faz sentido ativar DFS acima de 5725MHz.
> 
> E abaixo de 5350MHz provedor NÃO PODE usar (É faixa apenas pra uso indoor).
> 
> DFS tem que usar nas faixas de 5460-5725MHz. Fora disso não faz sentido ativar isso, não serve pra NADA se não tem radar nessa frequência.


Certo! Eu sou estou perguntando no canais que exige o DFS tem de ativa ele a 5500 a 5700 nesses canais o DFS sempre tem fica ativo?

----------


## rubem

Sobre DFS sempre ativo, se selecionar o pais CORRETO sim, o DFS é ativado corretamente. Noobs que ficam trocando de país pra poder burlar legislação são outra história, com seleção de país errado o firmware vai ativar o DFS só nos canais que a legislação daquele país obriga.

Sobre o nv2 sync, nunca usei não, sendo do mesmo fabricante tem potencial pra funcionar (Mas se tentar mk+ubnt no mesmo canal provavelmente não), sempre fiz mais mini-ptp pra zona rural, zero problema de falta de canais livres, nem sei bem como é ter 20 SSID em cada faixa (Com 3 ou 4 já tenho throughput ruim, imagino a merda que é viver em metrópole com todas a faixas lotadas de uso).

----------


## joaopaulodelfinomc

@*rubem* certo qual os países que tem ativa o DFS?

----------


## rubem

Se está no Brasil, coloque o país Brasil, qualquer RouterOS (Mikrotik) depois do 3.3, e qualquer AirOS (Ubiquiti) depois do 2.5 vão respeitar a legislação atual.

Se está na Argentina, coloque o país Argentina. Se estiver no Afeganistão, coloque o país Afeganistão.

É só colocar o país certo na configuração. A função dessa configuração de país é essa, ativar DFS e limitar potências e canais conforme a legislação de cada pais (Tá salvo no sistema operacional uma lista dos limites e obrigações de cada país, não precisa fazer nada além de usar um sistema minimamente atualizado, e configurado com a localização correta, pra tudo ficar certinho). Essa função não serve pro fabricante ter estatísticas de uso.

----------


## joaopaulodelfinomc

> Eu nunca disse que a potência no AP tem que ficar em 20dBm. Olha ali no texto, recomendo 16-18dBm pra aquecer menos o amplificador.
> 
> Fiz o cálculo com 20dBm mas VOCÊ pode refazer o cálculo com a potência que quiser usar na torre, não tem segredo nenhum nessas calculadoras prontas, é muito simples usar. Faça a conta dos níveis de sinal que vai ter a 3km usando Nanobeam 19dBi nesses clientes, ou LHG 24dBi, ou SXT Lite5 16dBi. Se o provedor é seu, você que faz os cálculos e define qual os valores ideais.
> 
> O que recomendo sem falta é: NÃO MEXER no AP caso 1 ou 2 clientes tenham sinal ruim! Configura o AP 1 vez na vida e NUNCA MAIS MEXE! Que se lasquem esses 2 clientes com sinal ruim, eles que moram mal pra caramba, se eles não querem colocar CPE mais cara (Se bem que LHG 24dBi não é cara) ou uma torrezinha em casa pra passar por cima das árvores, não atenda eles! Perca cliente mas não mexe no AP pra tentar conquistar 1 ou 2 clientes a mais, se ficar mexendo em AP vai só piorar a rede pros demais clientes. Então seja lá qual for a potência e ack-timeout escolhidos, configure na hora de iniciar a rede e nunca mais mexa! E se mexer, faça testes de DIAS, aumentando ou diminuindo 10 ou 20uS de ack-timeout, ou 1dBm a mais ou a menos de potência, vai ver que não é isso que melhora grandes coisas sua rede, é a instalação de CADA cliente (Não de 70% dos clientes. Tem que ter 100% das instalações perfeitas).


 @*rubem* certo em qual cenário eu vou sabe fazer calculo da potência que vou usa vou lembrando que vc recomenda la em cima 16~18 vou atende clientes so ate 2.5km

----------


## joaopaulodelfinomc

@*rubem* nos clientes qual potência que vou deixar em cada CPE funciona assim quanto mas perto for o cliente a potência da CPE dele e mas baixa e quanto mas longe for o cliente a potência da CPE dele e mas auta outra coisa para mim deixa tudo em um sinal mas o menos o clientes posso tenta deixa assim -50dbm -55dbm - 60dbm - 65dbm porque le um comentário um colega falando ser eu deixa ex -40dbm - 67dbm uma CPE fica gritando muito no AP seria isso?

” Outra coisa vou vende planos de 2~10MB gostaria sabe qual MCS vou usa no rádio e qual MCS usa na CPE do cliente”

Att 
Abraço 

Desculpa ser falei uma coisa ai errada mas afinal tamos aqui pra aprender

----------


## emilidani

> Já tentei de todas as formas e também sem sucesso.


Quem tem esse controle é o AP. A grande virtude do algoritmo e justamente automatizar todo o MCS para que cada cliente tenha a melhor condição segundo sua situação e voces querem tirar ela e daiexar fixo? não entendo qual a vantagem.

----------


## emilidani

> Eu nunca disse que a potência no AP tem que ficar em 20dBm. Olha ali no texto, recomendo 16-18dBm pra aquecer menos o amplificador.
> 
> Fiz o cálculo com 20dBm mas VOCÊ pode refazer o cálculo com a potência que quiser usar na torre, não tem segredo nenhum nessas calculadoras prontas, é muito simples usar. Faça a conta dos níveis de sinal que vai ter a 3km usando Nanobeam 19dBi nesses clientes, ou LHG 24dBi, ou SXT Lite5 16dBi. Se o provedor é seu, você que faz os cálculos e define qual os valores ideais.
> 
> O que recomendo sem falta é: NÃO MEXER no AP caso 1 ou 2 clientes tenham sinal ruim! Configura o AP 1 vez na vida e NUNCA MAIS MEXE! Que se lasquem esses 2 clientes com sinal ruim, eles que moram mal pra caramba, se eles não querem colocar CPE mais cara (Se bem que LHG 24dBi não é cara) ou uma torrezinha em casa pra passar por cima das árvores, não atenda eles! Perca cliente mas não mexe no AP pra tentar conquistar 1 ou 2 clientes a mais, se ficar mexendo em AP vai só piorar a rede pros demais clientes. Então seja lá qual for a potência e ack-timeout escolhidos, configure na hora de iniciar a rede e nunca mais mexa! E se mexer, faça testes de DIAS, aumentando ou diminuindo 10 ou 20uS de ack-timeout, ou 1dBm a mais ou a menos de potência, vai ver que não é isso que melhora grandes coisas sua rede, é a instalação de CADA cliente (Não de 70% dos clientes. Tem que ter 100% das instalações perfeitas).


É assim mesmo que deve se trabalhar.

----------


## joaopaulodelfinomc

@*rubem* me ajuda aqui amigo eu falei com alguma ingnoracia que voce nao gostou perdao!

Em questa desse aqui abaixo me ajuda aqui 

Qual é o melhor a se usar, esse Ceee, eCee, eeCe, eeeC, XXXX o que eles significa de fato, obrigado

----------


## emilidani

[QUOTE=mkmarcio;808660]Boa noite?

Estou com problemas na polarização, uso uma omnitik na torre e airgrid nos clientes, mas não consigo usar na vertical sinal fica ruim. Como posso regular isso?[/QUOTE.

Quan do fala fica ruim , quer disser recebe menos de 30dB a menos? O despeje do Fresnel nao tem nada a ver pois se horizontal recebe quer disser esta resolvido. O mais provável seja saída vertical do omnitik queimada, verifica essa posibilidade.

----------


## rubem

> @*rubem* me ajuda aqui amigo eu falei com alguma ingnoracia que voce nao gostou perdao!
> 
> Em questa desse aqui abaixo me ajuda aqui 
> 
> Qual é o melhor a se usar, esse Ceee, eCee, eeCe, eeeC, XXXX o que eles significa de fato, obrigado


Isso é só o centro do canal.

Um canal de 80MHz de largura, digamos com centro a 5740MHz, em Ceee irá de 5730MHz até 5810MHz.

O 5740MHz seria o centro de um canal de 20MHz, mas um canal de 20MHz obviamente não será exatos 5740MHz, se tem 20MHz de largura então é 10MHz pra cada lado do centro, ou seja, 5730 a 5750MHz.

Cada C ou e nesse sistema da MK é uma faixa de 20MHz.

eCee a 5740MHz será 30MHz antes, e 50MHz depois do centro, resulta em canal ocupando 5710 a 5790MHz.

eeCe é o contrário. 50MHz antes e 30MHz depois do centro. Com centro a 5740MHz fica 5690-5770MHz.

Com 40MHz não tem isso, se o centro é 5740MHz, será 20MHz pra cada lado, ou seja, 5720-5760MHz. Idem pras configurações de 5MHz, 10MHz, 15MHz, 30MHz ou 50MHz de canal em N que UBNT e MK usam, a frequencia informada sempre é o centro exato do canal. AC usa canal de 80 e 160MHz por isso fizeram esse sistema, basicamente pra mudar o centro do canal, com umas portadoras de sincronia e cia. Basicamente nada muda, tem que se virar pra achar uma faixa limpa na vizinhança com 80MHz de largura pra poder fazer um PTP com tanta largura (A maioria é ptp porco que entregaria a banda necessária até com 30MHz de largura. Muito leigo não obedece à limpeza na zona de Fresnel por isso faz cagadas tipo usar potência mais alta e canal mais largo pra compensar a alta perda de pacotes pela instalação porca). Tem o analisador de espectro nos UBNT com Airos 7 em diante pra isso, ver ver certinho a FAIXA mais, ou menos, poluída, porque ver SSID em centro de canal é o mesmo que perguntar pra astrólogo qual o melhor canal pra usar, SSID não diz nada sobre o uso real do espectro, SSID em si demanda menos de 500bps, ter um SSID a -50dBm num canal, desde que não tenha tráfego nele, não incomoda em nada um PTP, tem que ver o uso DE DADOS da faixa escolhida (Digamos 5730-5810MHz).

----------


## joaopaulodelfinomc

@*rubem*, certo tendi!
Minha dúvida aqui essa 

nos clientes qual potência que vou deixar em cada CPE funciona assim quanto mas perto for o cliente a potência da CPE dele e mas baixa e quanto mas longe for o cliente a potência da CPE dele e mas auta outra coisa para mim deixa tudo em um sinal mas o menos o clientes posso tenta deixa assim -50dbm -55dbm - 60dbm - 65dbm porque le um comentário um colega falando ser eu deixa ex -40dbm - 67dbm uma CPE fica gritando muito no AP seria isso?

” Outra coisa vou vende planos de 2~10MB gostaria sabe qual MCS vou usa no rádio e qual MCS usa na CPE do cliente. 
Coloca o country como BRAZIL em
Frequency: manual-tx-power para fica dentro das normas da Anatel e seta potência do radio? Seria assim?

Att 
Abraço 

Desculpa ser falei uma coisa ai errada mas afinal tamos aqui pra aprender

----------


## rubem

Bem isso, cliente a 200m do provedor provavelmente terá 5dBm de potência configurada, e cliente a 2km com CPE bem maior terá 18dBm. 

Sobre planos de 2-10Mbps, precisa data rate alto porque 5 ou 6 clientes de 10Mbps tem potencial pra consumir tudo o que o throughput de MCS12 passa! 

As vezes o jeito é usar no AP algo tipo MCS14, e nos clientes usar MCS10, afinal o upload é muito mais baixo que o download. Planos de 2-5Mbps rodam perfeito em MCS12 até com 20 clientes, mas conexão de 10Mbps exige o maior data rate das CPE's comuns, MCS14 ou MCS15, é muito mais tráfego.

Sobre limite de potência pra cada país, se setar pra país correto (Se está no Brasil, configurar pro país Brazil) o firmware vai limitar a potência conforme legislação, se não me engano 27dBm EIRP de 5450-5720MHz, e 34dBm EIRP de 5730-5850MHz, se informar o tamanho correto da antena (No caso de firmwares que são comuns a mais de 1 CPE geralmente tem essa opção). Se usar a faixa dos 5650MHz, por exemplo, e informar que a CPE tem 16dBi, como o limite da legislação é 27dBm EIRP o rádio vai limitar a potência a 11dBm (Afinal 11dBm + 16dBi = 27dBm EIRP), no setup não aparece a limitação, mas será a limitação prática, nesses clientes se você aumenta a potência pra digamos 19dBm mas nada muda, é só testar se entre 9 e 11dbm o sinal muda, se mudar, então não é limitação por zona de Fresnel parcial e sim por potência limitada no firmware. Seguir a legislação tem seu preço, te obriga a usar CPE bem mais grande em distâncias maiores caso na sua região a faixa dos 5730-5850MHz não tenha espaço (Em compensação se não tiver clientes a mais de 1km, NÃO use nada acima de 5730MHz, use abaixo, que é a faixa pra potências mais baixas. Pra 1km NÃO PRECISA mais que 27dBm EIRP mesmo).

----------


## wlaninformatica

@*rubem*. parabéns pela ajuda que tem dado aqui para o pessoal, estou apreendendo muito. uma dúvida que tenho é a respeito do sinal ap x cliente. nesta print temos -75 cliente e no ap -65 , com o noise floor em -117, gostaria de saber se isso esta correto ou não. estou usando mcs 0 a 7 no AP e mcs 7 em uma airgrid...

----------


## rubem

Se está usando Airgrid, ignora o outro chain, o sinal real é -63dBm, que é um sinal ok pra banda nem tão grande.

(E ignora o sinal relatado como TX, ele as vezes está errado, só é confiável olhar o RX de ambos os lados. Explico: As vezes um AP diz que o sinal de TX é -75dBm, que é um sinal lixo, mas aí você vai no cliente e o sinal de RX dele (RX de um vem do TX do outro) na realidade é -60dBm, que é ok. Nesse print esse sinal informado de TX a -72dBm talvez não seja correto. Se for, -72dBm mal dá pra MCS3, é um sinal ruim pra cliente receber dados (Todo download sai pelo TX do AP, e vira o RX na estação, em estação RX deve ter sinal muito melhor que o RX no AP por isso, download será bem maior que o upload)

----------


## adilsoncamargo

> Sobre a estratégia de sinal bom pra quem está longe, a ideia de quem está perto tem alguma vantagem por estar perto não confere, a diferença de tempo pra luz percorrer 100m ou 1000m é muito pequena pra fazer diferença, o acktimeout faz diferença porque ele atua no tempo pra ignorar reflexos, justo porque RF é muito rápido um sinal reflete em mil lugares e vários ecos/reflexos chegam no destino, um tempo maior no acktimeout ignorar ele. Quem terá desvantagem é quem tem sinal baixo, indepentende da distância.
> (Se todos tiverem zona de fresnel 100% limpa e o acktimeout correto, o ping e o throughput será igual, a diferença existiria entre cliente a 300m e a 30Km, mas é algo tipo 1 a 2ms a mais, no throughput geral não muda quase nada)
> 
> Sobre processamento por usar 16QAM num lado e QBPSK no outro: Nada muda.
> Quanto maior o datarate menor o processamento, porque o mesmo pacote de navegação de X bytes será feito com menos pacotes wireless. Mas... precisa ter sinal bom pra isso (Todos nivelados lá pelos -55dBm pra usar MCS7). Usar datarate alto com sinal baixo é até pior porque o processamento gasto pre reenviar pacote (Ou perguntar por resposta não recebida) é muito pior, ocupa espaço na ram e na fila de tarefas. Se a intenção é economizar processamento não tem que se preocupar com esquema de modulação mas sim em ter 100% de CCQ, pra que nenhum pacote seja perdido.
> 
> -65dbm vai dar CCQ baixo em MCS7, CCQ baixo implica pacotes perdidos. O mesmo nível de sinal vai dar CCQ ótimo lá por MCS4 ou 5, o datarate baixa mas a perda de pacotes acaba. Pacote perdido gera mais processamento e toma tempo, derruba o throughput também de outros clientes. 
> Bom seria se os rádios fossem inteligentes pra usar datarate automaticamente só com 12dBm de margem com relação à sensibilidade, e mais de uns 25dB de SNR. Mas o software não testa throughput, se tiver tráfego baixo só com pacotes pequenos não haverá perda de pacotes, aí o radio talvez até suba o datarate. PTP sempre tem trafego constante e pacotes grande (1472 bytes, o MTU menos 28B do cabeçalho wifi e autenticação geralmente), de modo que se ele subir o datarate (Onde o sinal é baixo) rapidinho ocorre 3 ou 4 pacotes perdidos, nesse cenário o datarate automático acaba funcionando as vezes, mas é só ter trafego menor que isso deixa de funcionar direito, pacotes pequenos raramente são perdidos (Dar ping com -l 32 e com -l 1450 ajuda a ver a diferença de perdas conforme o tamanho), mas os chipsets tem um limite de pacotes, não de tráfego.
> 
> ...


Boa, tarde Rubem, então estava acompanhando ontem seu post aqui no Forum, estou com essa questão aqui estou usando antena SISO como Airgrid e LiteBean, gostaria que pudesse me dizer se assim esta bom.. Aqui na minha cidade tem muito interferência ainda estou conseguindo entregar os planos de 10 Megas sem problema.. Estou para abrir um outro POP em outra cidade da mesma forma, só que vou usar RB 912+ Painel 2Flex 120º acha que seria bom ? Segue a foto da 921 com os clientes.. 

https://ibb.co/Bzw6910

----------


## rubem

Se continuar com pouco cliente por pop sem problemas, esses sinais tipo -66dBm (O que importa é o RX na torre) quando tem baixo tráfego não são problema, o rádio consegue processar isso (Se fosse uma RB711 talvez não teria CCQ tão bons, hardware mais novo e com processador melhor dá conta de mais gente com sinal ruim).

----------

