Ajuste de MCS do MikroTik RouterOS

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 ?