Ajuste de MCS do MikroTik RouterOS

[rubem]

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

[silviola]

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.

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.

[rubem]

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.

[silviola]

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 ?

[rubem]

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)

[silviola]

Ok tudo assimilado, falando especificamente sobre potencia vs MCS agora.

Na sua opinião:

1. Vc manteria a potência do AP em 6dBm e sinal mais fraco a -65 modulando a MCS5 e MCS3 ( AP - Cli ) ou aumentaria a potencia do AP ? Se sim, qual seria o ideal, a potência alvo, para as CPE's receberem de sinal ?

2. Ou você além de aumentar a potência também aumentaria os MCS's ? Se sim, para quais MCS's ?

3. Você acha que com MCS5 consigo oferecer planos de 5Mb em uma célula de 50 clientes ? Claro, nesta célula serão 2 ou 3 no máximo com 5Mb, e a massiva maioria com 1Mb ... minha preocupação seria entregar garantido os 5Mb aos poucos que contratarem, consigo isso, estes 5Mb trabalhando com MCS5 ? Se não consigo, com MCS7 conseguiria ?

3b. Hoje esta célula tem 50 clientes, e destes, 40 são planos de 0,5Mb a 1Mb e 10 são planos de 1,5Mb até 2Mb. O tráfego de pico é por volta de 14Mb/s sem aparente perda de pacotes ou lentidões ( pelo menos não detecto nada no script de monitoramento ).

** Lembrando que : nenhum cliente da célula está com obstrução, as instalações sempre possuem excelente fresnel ( sou chato pra ..... ) e estou trabalhando com potências bem baixas, então possivelmente eu consigo sinal -55 neste cliente que tem atual -65 aumentando o AP para 16dBm e mantenho meu EIRP em 33 ( minhas setoriais são de 17dbi ).

[rubem]

1 - Recomendo a potência que for necessária pra que todos os clientes tenham sinal igual na torre. Seja 4dBm, 10dBm ou 18dBm. Colocar todos os clientes na mesma potência não faz sentido porque a queda de sinal depende da distância, ou seja, cada cliente vai ter nível de sinal diferente, um ficaria mais legível que outro se todos tiverem potência similar. Nivelar conforme o RX na torre, não conforme a potência "dos outros".

2 - Nos clientes não vejo porque usar mais que MCS3. Só pelo upload de 1Mbps na verdade até MCS0 serve, mas é bom usar algo maior tipo MCS2 ou 3 por conta das respostas de pacotes (Protocolo TCP/IP requer respostas). Na torre seria lindo usar MCS7, mas... aí precisa sinal muito bom, lá pelos -55dBm nos clientes.

3 - Se hoje tem 14Mbps de tráfego agregado com planos até 2M, passando pra 5M isso dificilmente vai passar dos 25Mbps, só se der azar de todos os clientes de 5M serem heavy users que usarão p2p 24x7 comendo toda a banda disponível.

Sobre o **: Subir a potência dos clientes pra usar algo maior que MCS3 não vale muito a pena, -65dBm pra MCS3 tá bom, seria só questão de nivelar todos de modo que cheguem com sinal igual. Talvez seria mais interessante subir a potência da torre pra 35dBm EIRP e usar MCS6 (Com sinal na casa dos -60dBm) ao invés de MCS5 com sinal chegando nos cliente lá pelos -65dBm. O bicho pega é no trafego de download nos clientes (Limitado pelo TX Rate no AP da torre), não no de upload (MCS3 nos clientes vai ficar até sobrando).





Pra colocar muita gente em planos de 5Mbps no futuro vai ter que usar dupla-polarização, SISO não dá conta de muito tráfego. Com dupla-polarização o tthroughput é simplesmente dobrado, com aparelho barato tipo NS Loco a 1Km dá pra vender 5Mbps pra algumas duzias tranquilo (Usando MCS12 na torre e MCS10 nos clientes, por exemplo).

[alexchiele]

Alguém poderia me dizer se essa tabela que fiz esta correta, usei informações aqui do forum e própria MK
Obs. data rate de 400ns (nv2 usa esse)

Grato a todos

[rubem]

Perfeita a tabela, é bem isso.

[silviola]

Alguém poderia me dizer se essa tabela que fiz esta correta, usei informações aqui do forum e própria MK
Obs. data rate de 400ns (nv2 usa esse)

Grato a todos

Show Alex.
Poderia fazer a tabela completa com os MCS's mais baixos ?

[alexchiele]

Muito obrigado Rubem é grande parte graças a ti, e com todo respeito você é um gênio , parabéns a ti .

Saviola então eu usei 3db a mais que o normal por ser modulação MIMO, não me lembro aonde mas li que por ai é o ideal, e quando usado 40MHz você deve ter mais 4db que na mesma modulação SISO.
Mas se tiver tempo hoje ainda modifico ela e posto aqui...

[silviola]

Jóia Alex, seria de maior aproveitamento pra todos se pudesses completar.

[rubem]

É que MCS0 a MCS7 é EXATAMENTE o mesmo que MCS8 a MCS15.

MCS0 = MCS8
MCS1 = MCS9
MCS2 = MCS10
MCS3 = MCS11
MCS4 = MCS12
MCS5 = MCS13
MCS6 = MCS14
MCS7 = MCS15

(Idem pra MCS16 a MCS23)

Com 1 ou com 2 chains, se o rádio tem suporte a MIMO e a antena tem isolamento entre polarizações tipo 20dBm ou mais (Qualquer antena decente tem), tudo o que vale pra MCS0 vale pra MCS8.

Com 3 chains não tem um jeito de ter tanto isolamento entre polarizações, mas se conseguir usar 3 chains isolados um do outro por algum outro meio, também vale.


Em 802.11AC com multiplos chains (Até 8!) o foco não é trafego full-duplex, e sim algo tipo 4 antenas no roteador e 1 ou 2 no notebook ou smartphone, pra você BAIXAR em digamos 1Gbps (Algo da rede, não necessariamente da internet), e upar só as respostas dos pacotes. Envia em 1 antena, mas recebe o sinal de 4, tem coisa tipo 20M de up e 500M de down. Pra provedor esse tipo de cenário não é tão útil, a gente precisa tráfego full-duplex ótimo, trafego bom nos 2 sentidos.

[alexchiele]

Então assim como o rubem dice seria a mesma coisa , eu usei uma margem maior porque em alguns dos pdf da MK eu vi isso.

Fiz mais esses mas 2.4 e protocolo A/G é meio difícil de achar alguma coisa , ate porque não acho que seja muito usado actualmente.....(obs: me corrijam se estiver errado sobre os valores das tabelas )

[silviola]

Vc fez algo com fórmulas, gostaria de adaptar a Rocket / Bullet / Airgrird .

[alexchiele]

Usei umas tabelas postadas aqui no forum, dicas principalmente do rubem e de outros. E para saber sobre equipamento procurei nos datasheets do fabricante.
Pensei em fazer algo sobre os ubqt mas devido ao seu noise floor ser muitas vezes baixo (ate demais tipo -90) iria me confundir muito devido a margem mínima de cada modulação.

[silviola]

Sim, é esta justamente a confusão comum, por isso seria interessante adequar, já que tanto MK quanto UBNT dividem o cenário da realidade dos provedores WISP.

Rubem, podia ajudar nesta ?

[alexchiele]

Eu acredito que não precise de tanta margem quanto MK (uso minha pouca experiência com ubqt para dizer isso), aqui as poucas que temos apesar de sinal não tão bom ela funcionam bem.

[silviola]

Entendo Alex, e´que a intenção aqui é a busca pela otimização total, com busca de parâmetros bem fundamentados.

[rubem]

Então assim como o rubem dice seria a mesma coisa , eu usei uma margem maior porque em alguns dos pdf da MK eu vi isso.

Fiz mais esses mas 2.4 e protocolo A/G é meio difícil de achar alguma coisa , ate porque não acho que seja muito usado actualmente.....(obs: me corrijam se estiver errado sobre os valores das tabelas )

É bem por aí mesmo, não tem unanimidade sobre qual seria uma margem boa ou mínima.
Sobre a margem pra MIMO, na verdade tem cálculo pra SNR e margem que leva em conta o número de elementos da antena (Um dipolo é só 1 elemento, uma biquad são 2 elementos, a antena patch de um SXT lite tem 9 elementos), mas é daquelas contas teóricas sobre não ter perda total de pacotes, e nos precisamos perda zero, e não aceitamos nem perda de 10%, que dirá a perda de 99% que é a base de uns cálculos).

O problema é que é tanta variável pra dar número exato (Dependendo também do VSWR exato da antena no canal usado) que ninguém arrisca tabelar tudo, e prefere jogar pra cima tipo 20dBm de margem como mínimo pra uma rede boa.

(E no caso de MIMO, eu digo que é bom não passar de uns 40dBm de margem, porque com sinal tipo -45dBm, o sinal do chain0 já é legível no chain1 de qualquer CPE no mercado, também já começa a comer throughput)

Vc fez algo com fórmulas, gostaria de adaptar a Rocket / Bullet / Airgrird .

Não tem fórmula, é basicamente a sensibilidade do equipamento no datasheet, acrescido de uma margem de 10 a 20dBm pra definir qual seria o sinal mínimo e bom pra cada datarate.

Rocket, Bullet e Airgrid tem características parecidas (MK também), porque são chipset Atheros de gerações iguais, na prática pode pegar os números de um Nanostation e aplicar pra todo equipamento MK ou UBNT que não terá rede ruim.

Já que citou o Airgrid, olha o datasheet:
https://dl.ubnt.com/datasheets/airgridm/airGrid_HP.pdf

Lá na tabela com sensibilidades de cada datarate tem números só 1 ou 2dBm diferente da tabela:

Mas olha a coluna mais na direita, tolerance: + ou - 2dBm de variação.
Conforme o canal usado, ou variação na fabricação (E talvez temperatura do chipset) o número varia.

Por isso é complicado definir "O mínimo é 12dBm" e fazer todas as instalações assim, em horários de calor ou dia que mudar de canal isso vai tudo mudar.

Trabalhando com coisa mais simples tipo pelo menos 20dBm ACIMA da sensibilidade (Do datarate escolhido, ou do MAIOR se for deixar automático) a chance de rede ruim é quase zero.

A coisa é mais simples do que parece:
Precisa passar 50Mbps: Quer dizer que precisa de um datarate de mais de 100Mbps, que é MCS13. E MCS13 precisa pelo menos uns -58dBm (Mas seria bom MAIS que isso, nada de deixar ZERO margem, lembra que sinal cai quando chove, é fácil cair 2dBm).

Pode complicar um pouco se não tiver sinal suficiente.
"Instalei e não tem -58dBm, tem só -60dBm".
Então olha o MCS12, ele funciona com isso.
E pra ter data rate de mais de 100M nele é só passar de largura de canal de 20MHz pra 30MHz (Se em 20MHz tem 78M, aumentando o canal em 50% na largura, o datarate aumenta em 50%, passa de 78M pra 117Mbps, mas configurando o rádio em 30MHz ele automaticamente muda os numeros dos data rates, nem precisa fazer conta!).

(Canal mais largo geralmente exige sinal um pouco mais alto, mas de 20 pra 30MHz uma diferença de 1dBm conta pouco. A maior diferença é mudar 100% a coisa, pulando de 20 pra 40, ou de 20 pra 50MHz)

Respeitando uma margem (Signal margin) entre sensibilidade e sinal presente, dificilmente vai desrespeitar o SNR.

(E na prática pode ter CCQ ótimo com margem de só 12 ou 13dBm em PTP, mas é PTP, antena com só 1 conexão pra lidar, o bicho pega é com PTP, vários rádios falando nas orelhas do AP, o throughput fica meia-boca quando tem muito cliente com sinal baixo, eles perdem pacotes e isso precisa ser reenviado, toma tempo que poderia estar sendo gasto com outro cliente. É tipo quando tem alguém lerdo num caixa do super-mercado, por mais ágil que o caixa seja, se a pessoa for lenta demais pra tirar as coisas do carrinho toda a filha tem que ficar esperando a vez, não existe ir pra outra fila em wifi, se tem uma lesma na frente, todo mundo vai ter que esperar)