Ajuste de MCS do MikroTik RouterOS

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

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.




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.

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




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.

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

[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

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?

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


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.