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.
Versão Imprimível
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.
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.
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.