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:
MCS3 com preambulo curto é esse datarate de 28M. Indica SNR necessário de 17dB.
Aqui outro:
MCS3 é modulação 16QAM, e usa codificação 1/2, logo, SNR recomendado também seria de 17dB.
E -92 + 17 = -75dBm.
Ou seja, na torre você deve escanear todos os clientes chegando com sinal acima de -75dBm. Quem está abaixo precisa ter instalação refeita, ou potência aumentada, ou equipamento trocado, etc.
Datarate pode deixar fixo, todos os clientes no mesmo, mas Acktimeout e potência não, esses sim variam conforme distância. Cliente a 100m precisa potência baixa e acktimeout mais curto que um cliente que está a 1Km.
Se fizer como você faz, de usar potência limitada (Isso exige caprichar na visada, coisa que muito provedor ignora) é fácil fazer todos os clientes chegarem na torre com sinal igual, digamos que -70dBm tá ótimo se eles usarem MCS3.
Já o sinal nos clientes não tem como padronizar. A torre emite digamos 30dBm EIRP, o sinal vai estar mais alto no cliente próximo e mais baixo no cliente distante, com isso não tem o que fazer (Exceto colocar antenas de ganhos diferentes, se existissem a venda). Mas se a torre emite com potência decente, nem os clientes a 100m vão receber sinal absurdo tipo -30dBm (Que ia gerar tantos erros e CCQ baixo como receber sinal lá pelos -75dBm, sinal alto demais tem um monte de reflexo, atrapalha o chipset, fica ilegível igual sinal baixo).
Torre> Cliente: Datarate fixo ou limitado, acktimeout fixo, potência fixa.
Cliente>Torre: Datarate fixo ou limitado, actimeout conforme distância, potência conforme sinal chegando na torre.
Datarate automatico (Indo até MCS7) só daria uma rede com CCQ ótimo (95-98%) se tivesse sinal suficiente pro maior datarate. Se a sensibilidade é -74dBm, e a margem de 12dBm é ok, o sinal mínimo pra datarate automático de todos os clientes seria -62dBm. Tanto no RX da torre como no RX dos clientes.
O sinal cliente>torre geralmente é mais baixo, e como o upload é sempre baixo, a melhor coisa do mundo é limitar o TX Rate nos clientes. Na torre as vezes mal faz diferença mudar porque uns rádios tem processamento decente (Um Rocket com AR9344 dá de 10 a zero num Bullet como AP). Se for deixar algo com datarate automatico faça isso na torre, mas limite as CPE's dos clientes num datarate bem baixo, afinal o sinal delas vai chegar na torre muito mais baixo que devia.
Sobre throughput, sempre falo que ele é metade do datarate, porque é mais simples lidar assim. MCS5 tem 52M de datarate, o throughput máximo conseguível vai ficar na casa dos 25Mbps. Até em PTP as vezes dá trabalho chegar nisso, imagina em PTMP.
Agora... o problema é cliente com sinal ruim: Ele perde pacotes. O radio precisa enviar, reenviar, e talvez reenviar pela 2ª vez um pacote que o radio/cliente com sinal baixo não entendeu (Ou entendeu mas mandou o checksum e o checksum é que saiu ilegível! Gritando com alguém a 100m de distância pode acontecer de um "Sim" ser entendido como "Não"... "Se falar com a boca debaixo do nariz" como dizem aqui).
Se no processo todo tiver muita perda de pacote, não tem como chegar nesse throughput agregado, é a situação que 1 cliente de sinal ruim tem que fazer tanto reenvio de pacotes que ele "pesa" por 2 ou 3 clientes de sinal bom. Se for cliente de sinal ruim e for um cliente que navega o dia todo tá feita a desgraça, o radio vai ficar o dia todo perdendo tempo com ele, tempo que podia ir pra clientes onde é enviar só 1 vez e tá tudo resolvido.
Então com sinal insuficiente não tem mesmo como chutar throughput, se todos estiverem com CCQ perto de 100% (95-98% já tá muito bom) vai chegar em metade do datarate (Uns 25M de download agregado se usar MCS5 pra isso, e uns 13M de upload agregado se usar MCS3 pra isso).
(O CCQ do upload conta, não adianta o envio do pacote ser ok se o cliente responder pra torre chegando com sinal tipo -78dBm, isso é só 14dB acima do piso de ruído (Noise floor), não é muito legível, o "Ok, recebi o pacote, checksum XXXX" fica ilegível e o AP da torre talvez reenvie o pacote porque ele não sabe se o pacote foi recebido ou se a falha foi no envio da resposta. Pra CCQ bom nos 2 lados. E não estranhe CCQ TX/RX 99/85% na torre, e no cliente ver algo tipo CCQ TX/RX 95/95%, (Quando devia ser 85/99%, o TX de um é o RX do outro) conforme o firmware a métrica muda, e o tempo de atualização e espaço em cabeçalho pra colocar essas informações irrelevantes também, você (Como um AP) só sabe direito quantas vezes você teve que repetir algo, logo você só sabe ter certeza do CCQ de TX. Você teria que perguntar pra outra pessoa (Como station/cliente) quantas vezes ELE teve que repetir algo pra você (Afinal alguma vez você pode literalmente não ouvido nada, não é que "ouviu mas não entendeu", pode ter 2 ou 3 sinais chegando ao mesmo tempo e ficando os 3 ilegíveis a ponto de você nem saber quem falou com você, enfim, exibir o CCQ de RX depende de trocar informação sobre isso, as vezes tem diferenças e isso não é o fim do mundo))
E por fim, sobre "datarate module", seja com datarate fixo ou automatico, conforme o datarate modulo o comportamento muda quando tem sinal ruim, é algoritmo de tomada de decisão diferente, independente de usar airmax ou não, de usar canal ou largura x ou y, numas conexões faz diferença, não é um "modulo especial pra datarate auto e com airmax". Se quiser testar, teste de qualquer jeito, não precisa ser nada específico pra ele (Mas ele só faz efeito quando o gargalo está sendo a tomada de decisões sobre alguns aspectos do pacote. Assim como Airmax, só faz diferença quando o gargalo é o congestionamento que os pacotes padrão tem (E que TDMA enfilera de outro modo). Pode testar Airmax de qualquer jeito (Datarate, canal, acktimeout, distância), mas só vai notar diferença em ambientes específicos (Onde algo gera o gargalo que ele resolve)).