2 Anexo(s)
Re: Ajuste de MCS do MikroTik RouterOS
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)).
Re: Ajuste de MCS do MikroTik RouterOS
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.
Re: Ajuste de MCS do MikroTik RouterOS
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)