Ajuste de MCS do MikroTik RouterOS

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

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

boa noite entrei agora para saber sobre MCS, muito bom o que vcs estão falando, queria uma ajuda...Anexo 60866Anexo 60867Anexo 60868Anexo 60869Anexo 60870

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... :D

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

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

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

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?

Citação:

---

Postado originalmente por 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?

---

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

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

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.

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

Citação:

---

Postado originalmente por 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

Citação:

---

Postado originalmente por 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.

---

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.

Citação:

---

Postado originalmente por rtfl

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.

Citação:

---

Postado originalmente por rubem

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.




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.

---

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

Citação:

---

Postado originalmente por rubem

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.




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.

---

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

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,

Citação:

---

Postado originalmente por rtfl

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.

Citação:

---

Postado originalmente por 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,

---

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.

Nossa Rubem valeu msm... obrigado. :)

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

Citação:

---

Postado originalmente por 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???

---

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

Citação:

---

Postado originalmente por 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

---

se for SISO ai eh do MCS 8 para baixo?

Citação:

---

Postado originalmente por rtfl

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/

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: [email protected]
Skype: rafaelthemistocles

Citação:

---

Postado originalmente por rtfl

se for SISO ai eh do MCS 8 para baixo?

---

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.

Citação:

---

Postado originalmente por 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,

---

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.

Citação:

---

Postado originalmente por 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.

---

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.

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.

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.

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

Citação:

---

Postado originalmente por 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.

---

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.

Citação:

---

Postado originalmente por 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.

---

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:
Anexo 62325

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%):
Anexo 62326
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)

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.

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 (Signal-to-Noise Ratio) 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:
Anexo 62333
MCS3 com preambulo curto é esse datarate de 28M. Indica SNR necessário de 17dB.

Aqui outro:
Anexo 62334
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)).

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.
Anexo 62339
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.

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.

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 ?

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)

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

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

Anexo 62461
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

Perfeita a tabela, é bem isso.

Citação:

---

Postado originalmente por alexchiele

Anexo 62461
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 ?

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

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

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

Anexo 62469Anexo 62470

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 )

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

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.

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 ?

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.

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

Citação:

---

Postado originalmente por alexchiele

Anexo 62469Anexo 62470

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)

Citação:

---

Postado originalmente por silviola

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:
Anexo 62472
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)