Ajuste de MCS do MikroTik RouterOS

Citação:

---

Postado originalmente por 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 ?

---

Perdi o fio da meada...

O que não entenderam mesmo?

Se é sobre o noise floor, ele é medido igual se escaneia SSID, basicamente um SSID ou ruído que fique acima da MENOR sensibilidade (Geralmente MCS0 em canal de 10MHz) será identificado.

A emissão do SSID é feita com o preambulo, também usa o menor datarate, por isso você pode escanear um SSID a -70dBm, mas hora que conectar exibir sinal -75dBm.

Aquela exibição de detalhes de conexão em Mikrotik é educativa pra caramba! Ela mostra como o sinal do SSID está sempre acima do sinal real dos pacotes:
Anexo 62474

O ruído as vezes varia conforme você seleciona um ou outro datarate, se isso acontecer, é bom desconfiar do rádio gerando ruído pra ele mesmo.
(Falo de mudar demais, tipo -88dBm em MCS15, e -96dBm em MCS12, não tem como isso se outra coisa senão reflexo por culpa de antena perto demais de algo, ou num angulo ruim em que uma barra de ferro chato da torre acerta em cheio muito sinal refletido, mover a antena meio palmo as vezes resolve)

Se o ruído escaneado ficar abaixo de uns -96dBm em MK ou UBNT, é porque não tem ruído no local mesmo, e o noise floor exibido será mais ou menos a menor sensibilidade do equipamento.

O datasheet de um SXT fala em sensibilidade -96dBm. Mas... isso é pra 20MHz, e ele opera com 10MHz e 5MHz, a sensibilidade com canal mais estreito talvez fique em -99 e -102dBm, mas ainda tem mais: O preambulo usa tão poucos dados que um SSID a -110dbm as vezes é legível, e se chegar em -115dBm ficará ilegível mas o rádio identificar que tem algo a -115dBm, como é ilegível ele vai dizer que é ruído.

Até tem vento solar e espacial gerando ruído na faixa, mas ele fica abaixo de -120 a -140dBm, então num lugar sem wifi 5GHz por perto realmente não haverá ruído nenhum, mas o rádio mostra um noise floor, que é basicamente tudo que é ilegível, tudo o que está perto da menor sensibilidade fica ilegível demais.



Eu tenho uma vizinha idiota na frente que fala muito alto, dá pra entender tudo o que ela fala dentro da própria casa de tanto que fala alto.
Mas nos fundos é um pessoal que fala baixo, a 1 hora atrás eu até ouvia que eles estavam falando algo, mas não conseguia entender nenhuma palavra.
Acho que é isso que chamam de burburinho, você escuta que tem alguém falando, mas não consegue entender nada porque é baixo demais. É baixo pra entender, mas não é baixo pra não ouvir, então... é ruído, tem algo mas é ilegível.

Já a sensibilidade do data rate é:
Se alguém falar uma média de 120 palavras por minuto, eu entendo mesmo o som chegue tão baixo tipo 40dB.
Se alguém falar uma média de 150 palavras por minuto, eu entendo só se o som for mais alto tipo 50dB.
E se alguém falar muito rápido tipo 180 palavras por minuto, precisa falar lá pelo 60dB pra que eu consiga entender!

Um "sim" ou "não" com som fraco tipo 20dB eu entendo, mas alguém falando normalmente nesse volume é alguém cochichando a 5m, num lugar aberto é ilegível, não adianta eu ouvir algumas coisa a 10 ou 15dB, sendo que o que é útil, que é conversar, eu preciso pelo menos 40dB (E se quiser falar rápido, precisa falar mais alto pra ficar mais claro).

(Esse valores pra conversa são em ambiente silecioso, se for do lado de um caminhão roncando a 60dB, alguém gritando a 65dB até é entendível se falar devagar, é uma margem entre sinal e ruído muito baixa. Se for do lado de um carro roncando a 40dB, e falar normal a 50dB, já dá pra entender QUASE tudo (Ainda tem uns 10% de perda de pacotes).

Imagina wifi como uma professora ditando palavras pros alunos copiarem, a diferença entre a voz e o ruído precisa ser boa, mas se ela falar devagar o volume da voz pode ser menor, ou mais perto do ruído. Fazer MIMO é colocar 2 professoras ditando pra 2 alunos, um de cada lado da sala (Isolamento de uns 20dB), se uma professora falar algo demais atrapalha o ditado da outra.

Tudo que é situação que vocês imaginarem com as pessoas conversando (Especialmente falar um ahã depois de cada frase pra indicar que entendeu, isso é uma resposta de pacote) tem algo igual em wifi.

Minha rede eu tenho nas torres 912UAG-5HPnD/ base station ubiquiti 17 dbi, e nos clientes um mistão de de SXT e Ubiquiti,queria saber qual a melhor configuração em HT MCS para o caso.

A automatica sem duvidas!!!

A melhor na minha opinião era ter apenas uma fabricante para ativar os protocolos autoritários e poder ter o melhor desempenho, só isso já iria dar uma boa melhorada no desempenho, a airgrid é SISO e a SXT MIMO mas daria para testar algumas opções de configurações, aqui não teve uma receita mágica que serviu em todos os casos.
Tudo depende de sinal e qualidade das instalações (visada, fresnel, etc), aqui o que mais funcionou era se todos os clientes estavam na faixa de -55-69db usar MCS4-12(39-78mb), CCQ sempre ficava acima de 90(quase todos 97-100). Não posso dizer o ganho que tivemos pois não faz muito tempo mas acredito que ganhamos uns mb ai kkkk.
Só uma obs se você tiver como separar os clientes MIMO e SISO em Painéis diferentes acho que ficaria melhor (opinião apenas)

O que ainda fico intrigado é qual a diferença entre o MCS Supported e Basic. Alguem saberia me dizer a diferença?

Marcando múltiplos data rates, o software seleciona do maior pro menor conforme quantidade de perdas de pacotes (Que depende do nível e qualidade do sinal).

Basicamente o "basic" tem os menores rates que serão testados, tanto no lado onde você configura (Um AP, digamos) como no outro lado (Outro MK em "default", ou um roteador qualquer).
Em supported entram os rates altos que serão testados. Ainda que você marque e um não seja usado no TX, ele poderá ser usado no RX (TX do outro lado).

Se marcar digamos 9, 18 e 36M em supported, e 9M em basic. Se tiver sinal ruim tipo -76dbm e tiver umas paredes no meio e tal, o software vai optar por 9M, que é o rate MÍNIMO.

Hora que esse sinal subir pra um -65dBm, e/ou tiver um CCQ um pouco maior, talvez o software suba pra 18M.

Mas o maior uso é: Se você tem uma antena de 25dBi, mas tem potência ridícula tipo 8dBm. Pode ocorrer de você receber sinal -60dBm, logo, no sentido A>B vai usar 18M, mas com potência tão baixo o sinal cliente>torre, ou sentido B>A, está em -75dBm, logo, o rate nesse sentido será o mínimo marcado, 9M.

Dependendo de potência e ganho de antena, a qualidade AP>cliente ou cliente>AP pode ser diferente, mas se você precisa uma qualidade mínima maior, digamos PELO MENOS 10Mbps, é melhor marca em basic apenas 18M, assim você chavearia entre 18 e 36M.

Mas se tem conexão lixo as vezes (Usa como AP doméstico, digamos), uns lixos tipo smartphones terão sempre sinal ruim, se o rate basico a ser usado for 18M, eles vão perder muito pacote, melhor usar um rate mínimo mais baixo, tipo 9M ou 12M.

Pode marcar vários rates básicos, mas não faz sentido, se marca 3 ou 4, o mínimo mesmo será o mais baixo.

Mas se tiver sinal alto, tanto faz o mínimo, o rádio vai subir de datarates até o onde o sinal der, se o maior marcado em supported é 36M, vai subir até 36M se tiver sinal bom.

Um problema é que quando você está com pacotes pequenos, tráfego de baboseiras tipo o ping do Windows pra ver se tem internet, ou status de messenger, com esses pacotes pequenos não há perda de pacotes mesmo com sinal ruim tipo -75dBm, aí sem tráfego grande o rádio chega em 36M, mas... hora que tiver muitos pacotes de navegação, de quase 1500 bytes, aí ocorrem diversas perdas de pacotes até que o software defina que é melhor baixar o rate, ele vai baixar (No exemplo) pra 18M, se a perda continuar ele baixa pro basic, que é 9 ou 12M, se a perda continuar ele não baixa porque já está no basic.

Se você marcar digamos 9M em supported, mas não em basic, ele vai eventualmente testar esse rate quando tiver CCQ péssimo, mas quando houver troca REAL de pacotes grandes (E não uma conexão quase ociosa) o software não vai testar esse rate, o menor que ele vai estabilizar é no que está marcado em basic.

Enfim, é uma questão de mínimo e máximo, mas você só vê isso em ação quando tem pacotes de tráfego real e grande. Quando os rádios estão ociosos podem usar vários datarates momentaneamente, porque pacotes pequenos passam até com sinal ruim tipo -85dBm.
(Faz uma conexão a -85dBm com 18M e dá um ping -l 1, o ping com 1 byte passa fácil com sinal baixo, mas aí compara quanto de sinal precisa pra um ping -l 1450 não ter perda, e será lá pelos -70dBm, e pra não ter delay (Um ping de 50ms) algo lá pelos -60dBm. Por causa desse comportamento burro de subir data rate quando não tem tráfego, é complicado marcar múltiplos rates, a perda de pacotes pequenos será diferente da perda com pacotes grandes, e navegação e downloads usam pacotes grandes, usar rate alto demais pro sinal que tem gera justamente navegação ruim, o status do WhatsApp funciona normal, mas engasga justo na navegação)

@rubem Não seria interessante deixar o AP setado em digamos Mcs12 e os clientes automáticos? Ou degradaria muito a performance do ap com as modulações em rx diferente das outras. Pq penso eu que o AP mantendo o TX constante os clientes iriam se adequar com a modulação automática. Apesar do rx no ap, se o up dos clientes.

Eu diria que se é pra deixar alguém em auto, deixa a torre.

O cliente tem pouco dado pra enviar, só o upload, rajadas de 100 a 200kbps geralmente, não precisa de muita coisa.

A torre tem que "ouvir" todo mundo, se o sinal de todos chega em digamos 54M mas em algo baixo tipo -60dBm, a torre vai ficar pedindo reenvio pra todos.

(Porque o software NÃO se adequa como devia, o software é burro e insiste em subir de rate mesmo não tem sinal suficiente)

Já se os clientes todos estiverem transmitindo em digamos 12V, o sinal de -60dBm será mais que suficiente pra todos esses sinais serem legíveis, a torre vai entender tudo no primeiro envio, não vai precisar pedir repetição.

Geralmente se coloca um equipto bom na torre, rádio a 20dbm e antena de 19dBi. Isso dá 39dBm EIRP.
Mas o equipamento dos clientes nem sempre é bom, tem muita CPE barata que só tem 17dBm de potência, se a antena é de 12dBi, isso dá 29dbm EIRP.

Ou seja, o sinal AP>cliente será 10dBm maior que o sinal cliente>AP, logo, faz sentido que o data rate setado na torre seja digamos 36M, e o data rate setado nos clientes seja 12M.
(Alias, são 2 motivos então, a menor potência nos equiptos dos clientes, e a menor banda necessária, digo, upload é geralmente 15 a 50% dos download)

O cliente só tem que ouvir 1 contraparte, então a CPE do cliente consegue entender melhor caso chegue um sinal a -60dBm com data rate de 36M. Pelo menos vai entender bem melhor que se isso chegar assim no AP, que vai ter 10 ou 15 sinais chegando juntos.

Quando tem sinal suficiente pro maior data rate (54M, já que estamos usando data rate de A e G), tipo -50dBm, se deixar o data rate automatico tudo funciona porque ele vai tender a ir pro maior data rate.

Mas em PTMP é normal a torre receber dos clientes uns sinais ridículos tipo -65 ou -70dbm, se deixar em automático a maioria dos softwares é burro o suficiente pra usar 54M mesmo com sinal baixo, quando tem só 1 pessoa assim não tem problema, reenvia pacotes até dar certo, mas quando tem 10 pessoas navegando cada pacote é reenviado 3 vezes, ao invés de 30 pacotes por segundo são trafegados 90 pacotes por segundo, os 2MB pra abrir o site no navegador vão passar, mas vão ser tantos reenvios que vai levar 10 segundos, dá uma média de 1,6Mbps, enquanto sem reenvios de pacotes se houvesse a limitação nos mesmos 1,6Mbps não seriam 10 segundos de tráfego (Ocupação do AP), mas só 3 segundos, ocupa menos tempo do rádio e abre a página mais rápido pro cliente.


Mikrotik ensina um pouco sobre essas perdas quando na aba Wireless a gente ativa a coluna TX/RX packets, lá dá pra ver a quantidade de pacotes enviados e recebidos. Se a conexão monitorada tiver uma CPE MK ou algo que exiba a quantidade de pacotes enviados e recebidos, dá pra olhar as perdas. Numa conexão muito boa os números serão quase iguais nos 2 lados, mas quando tem sinal ruim num dos sentidos, os numeros são muito diferentes, uma lado diz que teve 400 mil pacotes de TX, mas o outro disse que teve só 300 mil de RX, ou seja, um enviou 400 mil, mas o outro recebeu só 300 mil. Isso dá 25% de reenvio a mais que o necessário (Mas só pesa quando o AP está tendo muito pacote pra enviar, só em horário de pico talvez).

EDITADO: Só depois que postei que li o post do rubem, acima. Mas enfim, ainda ficou algumas questões abaixo...

Tentei realizar alguns ajustes nos meus MCS aqui usando Mikrotik e NV2 ativado, os cliente todos SXT, mas só obedecem ao AP, não importa se eu coloco pra conectar só MCS 1 e MCS 9 nas SXT ou só um MCS apenas nas SXT, ele sempre vai pelo maior MCS do AP que é uma RB912. Isso é por causa do NV2 ou comportamento do RouterOS mesmo?

Outra dúvida que tenho é que no RouterOS tem a aba Data Rates, que só tem Data Rates do modo G e na aba HT MCS tem Supported e Basic MCS Rates. Isso é meio confuso. Pra que serve cada opção? Sei que pra mexer nos MCS tem que ativar a configuração do Data Rate em modo G, senão fica tudo desativado as checkboxes das abas HT's e o Supported rates tem que bater igual ao Basic Rates, não adianta selecionar MCS x y z em Supported e em Basic selecionar apenas y e z, q não aceita. Então acho meio confuso essas opções e qual a utilidade delas?

@raumaster tbm nao consegui setar mcs11 no ap e 8 na cpe simplismente nao conecta entao deixei auto na cpe mesmo e fixo no ap.

Desmarquei todos Data Rate G, defini só um Basic MCS, o minimo 2x2, 13Mbps, e o Supported deixei por enquanto todos 2x2, ja que a potencia que u so, 23dbm, é suportada tb pelos Rates mais altos MCS14 e MCS15. Agora na ponta dos clientes, SXT, mesmo que eu deixe só um rate setado, ele continua pegando o rate mais alto selecionado no AP, na pratica ele abaixa quando ha trafego, o rate de down sempre fica mais alto que o de UP na maioria dos clientes, mas continua pegando rates mais altos do que aquele que setei no lado do cliente..

Se olhar no setup do cliente, realmente as vezes aparece como se estivesse conectando em data rate alto.

Se olhar no setup do AP, aparece o rate real usado pelo cliente, as vezes ele é diferente do data rate exibido no setup do cliente.

Isso acontece com muito AP, não sei bem porque, se tem relação com preambulo, tráfego baixo, mas parece que isso não "pesa" pros AP's, digo, não gera CCQ baixo pros outros usuários.

(Como um cliente com -70dBm fixo em MCS15 de fato geraria)

Ah, e sobre a utilidade do Basic e Supported Rates, no basic você marca só 1, o mínimo a usar em caso de sinal baixo. Em supported marca todos que quer usar quem em teoria o rádio seleciona qual usar conforme o sinal.

A utilidade de marcar um rate mínimo é permitir ou não conexão ruins, com data rate de 2M até um sinal -80dBm conecta, mas... vai dar um CCQ terrível, vai ocupar tempo de processamento do AP. Se marcar digamos só 18M no basic (E no suported de 18 a 36M), com -80dBm o cliente não vai conseguir conectar em 18M, digamos que "não vai incomodar".

A utilidade planejada é uma, mas na prática conforme as versões e misturas de equipamentos isso realmente não funciona.

Eu vi isso de não conectar com HT MCS só 1 ou 2 vezes, o resto sempre usei datarates diferentes nos 2 lados, porque upload é sempre mínimo comparado ao download. Não tenho equipto suficiente pra conseguir definir se isso é mais comum numa versão ou nalguma configuração específica do RouterOS, eu lembro de ver isso em coisa tipo RB711 level3 e quando atualizei RB pra firmware novo (Eu não atualizo por atualizar, HOJE só faço isso se tiver bug em versão antiga. Pra mim, atualização é trocar os bugs de fábrica por bugs mais novos e ainda não relatados, prefiro ficar com os bugs conhecidos).

Citação:

---

Postado originalmente por rubem

Ah, e sobre a utilidade do Basic e Supported Rates, no basic você marca só 1, o mínimo a usar em caso de sinal baixo. Em supported marca todos que quer usar quem em teoria o rádio seleciona qual usar conforme o sinal.

A utilidade de marcar um rate mínimo é permitir ou não conexão ruins, com data rate de 2M até um sinal -80dBm conecta, mas... vai dar um CCQ terrível, vai ocupar tempo de processamento do AP. Se marcar digamos só 18M no basic (E no suported de 18 a 36M), com -80dBm o cliente não vai conseguir conectar em 18M, digamos que "não vai incomodar".

A utilidade planejada é uma, mas na prática conforme as versões e misturas de equipamentos isso realmente não funciona.

Eu vi isso de não conectar com HT MCS só 1 ou 2 vezes, o resto sempre usei datarates diferentes nos 2 lados, porque upload é sempre mínimo comparado ao download. Não tenho equipto suficiente pra conseguir definir se isso é mais comum numa versão ou nalguma configuração específica do RouterOS, eu lembro de ver isso em coisa tipo RB711 level3 e quando atualizei RB pra firmware novo (Eu não atualizo por atualizar, HOJE só faço isso se tiver bug em versão antiga. Pra mim, atualização é trocar os bugs de fábrica por bugs mais novos e ainda não relatados, prefiro ficar com os bugs conhecidos).

---

Certo rubem li varios topicos a respeito do MCS ,fixando o MCS de um cliente na rede o mais baixo o setor nao ficara comprometido a aquela velocidade ? penso assim que a alguns anos atras era falado sobre quando a um cliente esta no throughput baixo a rede toda fica limitada a isso , e fico na duvida colocando uma base com mcs automatico certo , um apc 5m -90 mimo e clientes todos mimo , e colocar os clientes em mcs 3 sera que não iria diminuir a capacidade real da mesmo , ou outro exemplo , rede em G mesmo ainda uso :) fixando os clientes em 18M e deixando o MK em automatico , seria a mesma coisa , trafego de 5 a 8 MB ,no total ?

Sim limita o tráfego geral, se o AP ficar digamos em 18Mbps, ele vai trocar dados alternadamente com todos os clientes nesse data rate, e o throughput agregado máximo será de uns 10Mbps.

Na prática isso é o que se consegue em PTP nesse data rate, num PTMP sempre tem pacote sendo reenviado, eu diria que se o AP ficar fixo em 18M, entregará um agregado de uns 8Mbps se tiver meia duzia de clientes.
(Acima de uns 15, aí depende do tráfego de cada um, mas duvido que baixe pra uns 7Mbps)

18M é exagero, mas com 24M é fácil conseguir agregado de 10Mbps em PTMP.

Já se o AP fica digamos em 36M, e os clientes usam 12M do TX deles, o AP vai pegando os dados dos clientes um depois do outro (Não é TDMA mas 2 clientes enviando sinal junto zoam o pacote no ADC, perde o pacote e o AP manda pra só 1 deles um "Envia de novo", e hora que esse chegar aí sim ele manda pro outro o "Envia de novo"), serão 12M de RX, o throughput real vai ficar nuns 4Mbps agregado. E 10 clientes dificilmente trafegarão mais que 4Mbps de UPLOAD somados.

Então limitar limita, mas é um limite alto pra idade desses padrões. Quem está usando A ou G pra vender planos tipo 3 ou 4Mbps tá lascado, precisa MUITO sinal pra isso já que 15 clientes simultâneos de 4Mbps vão consumir demais até se usar o data rate de 54M (Que quando muito dá um 20Mbps de throughput). Esses data rates tipo 18M servem pra uns 15 clientes simultaneos em planos de 1M cada, na prática ele provavelmente vão ficar abaixo até dos 4Mbps, que dirá chegar nos 8Mbps que um PTMP com esse data rate deve entregar.

A prática que vou sugerir é ter throughput na medida pra rede cheia, digo, se tem 10 clientes de 1Mbps, melhor usar 18M e ter CCQ de 100% nos 4Mbps circulando, que usar 54M e ter CCQ de 80% com reenvios de pacotes pros mesmos 4Mbps circulando. Se o limite do cliente é no concentrador e não na interface wireless no caminho, não precisa um throughput muito maior que o que concentrador vai aplicar, mas em PTMP tem vários clientes ao mesmo tempo e se usar data rate baixo demais (6M, digamos) esse choque de dados vai criar um gargalo extra, eu sugiro pesar a banda agregada que a setorial trafega, e ter throughput pra pelo menos o dobro da banda agregada média.

(10 clientes de 1Mbps cada vão ficar acho que nuns 2-4Mbps boa parte do dia, só se tiver muito heavy-user vai chegar nos 6 ou 7Mbps, então o uso de 18M AP>cliente até serve. Se tem clientes próximos e sinal sobrando pra usar 24M melhor ainda, mas o que não dá é ter sinal baixo (Uns -74dBm) e usa data rate tipo 24M, aí a perda de pacotes cria um gargalo mais incômodo que o uso de 18M (Ou: Melhor 18M com CCQ de 98%, que 24M com CCQ de 78%))

Então na pratica colocar no MK ou APC fixo exemplo como voce falou em 24M e fixar os clientes em 18Mb caso houver clientes com sinal melhor fixa em 24M tambem seria o melhor cenário ?

Estou fazendo alguns testes aqui na APC 2M -90 com 5 clientes pendurados e me conectei com eles , o maldito nao passa de 2MB o trafego geral usando o Btest to ficando maluco ja kkkk , mesmo assim otima dica , vamos testando e ajustando o bicho , o MK é bem mais facil para ajustes deste tipo bem mais facil .



Anexo 63412Anexo 63413.

Ja mudei mudei de tudo e nao passa mais que 2 MB , alguma dica de alguem

Notei aqui tambem muito erros tx Anexo 63414


Estou usando 2.4 ok

Rubem, tanto faz no cliente como no AP, a modulacao aparece igual, a mais alta setada no AP mesmo colocando taxa baixa na CPE do cliente. Deve ser algum bug.

ALguém aqui consegue usar datarate diferente no cliente e no AP. Exemplo do Ap transmitindo em MCS12 e cliente em MCS8?

Citação:

---

Postado originalmente por chocobama

ALguém aqui consegue usar datarate diferente no cliente e no AP. Exemplo do Ap transmitindo em MCS12 e cliente em MCS8?

---

Mais ou menos isso minha duvida alem do base os clientes terem fixos datarate diferente , digo melhor sinal mcs alto menor sinal mcs baixo , e se isso nao iria prejudicar a rede como um todo ,

Que eu mesmo usei por um bom tempo, foi R52HN em MCS3 e clientes 2,4GHz em auto por falta de ter a opção, SXT-primeira-geração como AP em MCS5 e clientes em MCS2 e 3 (Airgrid e Nanobridge), RB Crossroads (RB com RF, tipo RB711 5hn) em MCS4 e clientes 5GHz em MCS1 (Airgrid, SXT, NS Loco M5, Oiwtech 5817, PCBA Eternetec , ao longo do tempo foram vários clientes entrando e saindo, não teve nenhum que não conectava, nesse era uma enorme zona, acho que teve setorial com 20 clientes com 20 modelos diferentes de CPE's, a única coisa em comum era estarem fixos em MCS1.

Numa cidade do lado só instalei um Rocket M5 em MCS12, só tinha 4 ou 5 clientes, com NS Loco M5 e todos ficaram em MCS9 ou 10. Como o dono não me ligou depois, tudo deve ter conectado. Tinha Bullet M5 numa omni e isso teve que ficar em 36M (De modo A) porque tinha no meio dos clientes muita CPE velha, a mistura A/N com datarate em automatic estava dando CCQ baixo pra todos, fixo em 36M normalizou, fixo em MCS4 normalizava mas os clientes com aparelho apenas A não conectavam. Em automatic era coisa tão ruim que nem conseguia acessar o setup e carregar tudo, depois de fixo em 36M como que por milagre tudo abria rápido.


Numa fazenda foi RB912 num "PTP triplo", digo, um lado na fazenda, e na cidade 3 antenas conectadas nela, na fazenda acho que era MCS12 também, na cidade sei que era MCS8, o mínimo.

O que tive problema foi numa Omnitik, tive que deixar em auto porque nada conectava, era MK 6.alguma-coisa, 6.27 provavelmente, mas só tinha meu próprio notebook (Dualband) e um airgrid velho pra testar, acabei deixando pra lá porque tinha até antena presa em cabo de vassoura (Não ia adiantar caprichar, com instalação sem visada e sem zona de Fresnel o CCQ vai pro lixo independente da configuração), fora que é longe demais pro meu carro velho...

Num mini-PTP tive problema entre SXT Lite5 e Nanobridge, não lembro quem era AP e quem era estação mas a config. inicial só aceitava ambos em automatic (Que dava CCQ péssimo), invertendo AP e estação funcionou. Os outros PTP's sempre funcionaram com qualquer configuração, uso muito MCS12, mas se tem antenas diferentes (Pra aproveitar o que os clientes já tem) uso data rates diferentes tranquilo, coisa tipo Nanobeam 5AC num lado e NS Loco5 (Não M5) nem sei como funcionou, e se não me engano passa uns 15Mbps!

Se tem bug, tem bug em muito aparelho diferente! Em MK me parece que é coisa de versão mais nova, isso só começou de pouco tempo pra cá, em tempos de 4.17, 5.23, não tinha errado, agora com 6.x pra mim que tem mais bug (Usando um par de RB911 baratinha fim do ano passado não consegui usar 10MHz, simplesmente o scan não achava nada se colocava em 10MHz, não é que não vi o AP, ele não escaneava nada, zero, também fiz downgrade pra normalizar.

boa noite amigo @rubem, precisava do seu serviço para ajustar alguns enlaces. Será que podemos conversar melhor por mensagem? Abraços.

O que tem "diferente" nos meus APs é, uso do procolo NV2, Uso do recurso Noise Immunity AP/Client, Superchannel habilitado, DFS desabilitado, mas creio que o NV2 deve ser o que faz o MCS ficar igual nas duas pontas, só uma suspeita minha... Engraçado que posso habilitar qualquer combinação de MCS no lado do cliente, SXTs, que ele so obedece ao AP. Minha rede esta uma mistura de versoes 6.33 e 6.34. Tem 6.33.3, 6.3.4...

Citação:

---

Postado originalmente por raumaster

O que tem "diferente" nos meus APs é, uso do procolo NV2, Uso do recurso Noise Immunity AP/Client, Superchannel habilitado, DFS desabilitado, mas creio que o NV2 deve ser o que faz o MCS ficar igual nas duas pontas, só uma suspeita minha... Engraçado que posso habilitar qualquer combinação de MCS no lado do cliente, SXTs, que ele so obedece ao AP. Minha rede esta uma mistura de versoes 6.33 e 6.34. Tem 6.33.3, 6.3.4...

---

Creio que não seja por causa do nv2, pq em 802.11 tb acontece! Creio que seja um bug do routerOS. O mesmo serve para se conectar em um AP ubnt com data rate fixo em mcs 12 e o cliente sendo sxt só conecta se estiver com mcs default ou marcado o mcs12.

Aqui uso um omnitik em N conectando alguns loco M5 e SXT. Irei colocar uma nano M5 para funcionar como AP, pois não consigo fixar o MCS nos SXT. Mas loco M5 basta colocar o MCS em 8 ou 9 e pronto. Nos SXT ele obedece ao AP e se eu tentar forçar apenas MCS 8 ou 9 simplesmente não conecta.

Ainda sobre o MCS e de problemas para conectar com SISO ou Mimo setado diferente do AP... Depois de inúmeros testes vi que se desmarcar o MCS Basic, é possivel fazer conectar de acordo com o Supported. Por exemplo: se eu marcar MCS 10,11,12,13 no ap e marcar somente o 10 no station, a sxt não vai conectar, mas tem que desmarcar todos do basic, conecta. Segue os prints:
Anexo 63500
Anexo 63501

Citação:

---

Postado originalmente por FMANDU

Ainda sobre o MCS e de problemas para conectar com SISO ou Mimo setado diferente do AP... Depois de inúmeros testes vi que se desmarcar o MCS Basic, é possivel fazer conectar de acordo com o Supported. Por exemplo: se eu marcar MCS 10,11,12,13 no ap e marcar somente o 10 no station, a sxt não vai conectar, mas de desmarcar todos do basic, conecta. Segue os prints:
Anexo 63500
Anexo 63501

---

Começou a melhorar :) o ideal mesmo seria usar 12 no AP e 9 no cliente, iria ficar show, aparecendo um tempo aqui vou fazer novos testes..

Na verdade o certo seria usar o mesmo Mcs no ap e no cliente. O AP iria trabalhar bem mais redondo. Porem... tem instalação complicada, arvore que cresce no meio do caminho, construção nova que atrapalha a visada e etc, que somos obrigados a baixar o mcs e subir o ganho no lado do station.

Citação:

---

Postado originalmente por sombra

Começou a melhorar :) o ideal mesmo seria usar 12 no AP e 9 no cliente, iria ficar show, aparecendo um tempo aqui vou fazer novos testes..

---

Citação:

---

Postado originalmente por FMANDU

Na verdade o certo seria usar o mesmo msc no ap e no cliente. O AP iria trabalhar bem mais redondo. Porem... tem instalação complicada, arvore que cresce no meio do caminho, construção nova que atrapalha a visada e etc, que somos obrigados a baixar o mcs e subir o ganho no lado do station.

---

MCS do cliente é responsável pelo UPload que quase sempre é bem baixo, dando possibilidade de se trabalhar com um MCS minimo no cliente possibilitando estabilidade na conexão.

Citação:

---

Postado originalmente por sombra

MCS do cliente é responsável pelo UPload que quase sempre é bem baixo, dando possibilidade de se trabalhar com um MCS minimo no cliente possibilitando estabilidade na conexão.

---

Caro , mais sera que não iria atrapalhar a performe-se da rede mesmo upload deixando muito baixo o mcs ?

E teria mais informações sobre mcs , sinceramente não sabia que no cliente so serve para Upload

Se tem upload de 1Mbps, e usar MCS0, em 20MHz ele tem throughput na casa dos 3Mbps, é meio pouco mesmo. Mas em MCS1 já são uns 6Mbps, já tem dado de sobra.

Quem usa dupla polarização (Pra que usar single em pleno 2016?), os equiptos operam com mesmos sinais em MCS8 ou 9, ou seja, pode usar MCS9 no cliente, que tem throughput na casa dos 10 a 14Mbps, ter um upload de 1M num data rate desse é absolutamente tranquilo.


O checksum de cada pacote de wifi enviado pelo AP é respondido pelo cliente no mesmo datarate do envio. Mas a resposta do pacote TCP dado pelo computador do destinatário é feita no que se contabiliza como upload mesmo. Ou seja, um data rate baixo não diminui a capacidade de envio de pacotes por parte do AP.

Assim como tem que ver o throuhput agregado no data rate de TX da torre, tem que ver o throughput agregado de upload dos clientes. Se os clientes tem, na média, uns 2 ou 3Mbps de tráfego de upload, é melhor não usar MCS0 como TX neles, mas sim MCS1, porque o tráfego está muito perto do limite de throughput do MCS0.

Mesmo que você venda planos tipo 2M de download e 1M de upload, o trafego vindo dos clientes (O upload somado de todos) será muuuuuito baixo, se digamos 20 clientes de 2Mbps de download consomem uns 12Mbps de trafego agregado, o upload mal vai chegar em 2Mbps, usar um data rate com throughput 3 ou 4x maior que essa média é mais que suficiente, o download até sobe muito as vezes (5 ou 6 pessoas abrem um vídeo maior, mais ou menos ao mesmo tempo), mas o upload raramente tem picos muitos altos.


Volto a repetir: O checksum do pacote na parte de wifi é respondido no data rate da parte que enviou, e a parte de sincronia e cia (Envio do SSID, por exemplo) é feito no preambulo, que é o menor data rate do modo, o preambulo em A é de 1 ou 2Mbps, em N a 6Mbps. Ainda que você selecione o uso de MCS15 nos 2 lados, tem um moooooooooonte de dados passando em data rate de 2 ou 6Mbps o tempo todo, numa modulação BPSK bem "lenta", e isso é feito porque esses dados tem prioridade, pode perder um pacote do cliente que se for preciso ele reenvia, mas se perder pacote de sincronização a conexão cai e demora muitos segundos pra reconectar (Renegociar chave e cia). Ter data rate baixo no meio não degrada rede quando ele tem tráfego baixo, geralmente é o contrário, data rate baixo não perde pacotes (MCS15 com sinal -70dBm perde muito pacote) então o gasto total de tempo nesse envio é menor, mesmo usando um data rate mais baixo (Porque não precisa ficar reenviando pacotes perdidos).

Citação:

---

Postado originalmente por rubem

Se tem upload de 1Mbps, e usar MCS0, em 20MHz ele tem throughput na casa dos 3Mbps, é meio pouco mesmo. Mas em MCS1 já são uns 6Mbps, já tem dado de sobra.

Quem usa dupla polarização (Pra que usar single em pleno 2016?), os equiptos operam com mesmos sinais em MCS8 ou 9, ou seja, pode usar MCS9 no cliente, que tem throughput na casa dos 10 a 14Mbps, ter um upload de 1M num data rate desse é absolutamente tranquilo.


O checksum de cada pacote de wifi enviado pelo AP é respondido pelo cliente no mesmo datarate do envio. Mas a resposta do pacote TCP dado pelo computador do destinatário é feita no que se contabiliza como upload mesmo. Ou seja, um data rate baixo não diminui a capacidade de envio de pacotes por parte do AP.

Assim como tem que ver o throuhput agregado no data rate de TX da torre, tem que ver o throughput agregado de upload dos clientes. Se os clientes tem, na média, uns 2 ou 3Mbps de tráfego de upload, é melhor não usar MCS0 como TX neles, mas sim MCS1, porque o tráfego está muito perto do limite de throughput do MCS0.

Mesmo que você venda planos tipo 2M de download e 1M de upload, o trafego vindo dos clientes (O upload somado de todos) será muuuuuito baixo, se digamos 20 clientes de 2Mbps de download consomem uns 12Mbps de trafego agregado, o upload mal vai chegar em 2Mbps, usar um data rate com throughput 3 ou 4x maior que essa média é mais que suficiente, o download até sobe muito as vezes (5 ou 6 pessoas abrem um vídeo maior, mais ou menos ao mesmo tempo), mas o upload raramente tem picos muitos altos.


Volto a repetir: O checksum do pacote na parte de wifi é respondido no data rate da parte que enviou, e a parte de sincronia e cia (Envio do SSID, por exemplo) é feito no preambulo, que é o menor data rate do modo, o preambulo em A é de 1 ou 2Mbps, em N a 6Mbps. Ainda que você selecione o uso de MCS15 nos 2 lados, tem um moooooooooonte de dados passando em data rate de 2 ou 6Mbps o tempo todo, numa modulação BPSK bem "lenta", e isso é feito porque esses dados tem prioridade, pode perder um pacote do cliente que se for preciso ele reenvia, mas se perder pacote de sincronização a conexão cai e demora muitos segundos pra reconectar (Renegociar chave e cia). Ter data rate baixo no meio não degrada rede quando ele tem tráfego baixo, geralmente é o contrário, data rate baixo não perde pacotes (MCS15 com sinal -70dBm perde muito pacote) então o gasto total de tempo nesse envio é menor, mesmo usando um data rate mais baixo (Porque não precisa ficar reenviando pacotes perdidos).

---

Bom gostaria de analisar o meu cenario , esta abaixo a tabela de clientes neste setor , estou usando protocolo ativo da intelbras , e nos clientes estou usando MCS 11 nos clientes , então seria equivoco meu fazer isso certo , se fixar nos clientes MCS 0 , 1 ou ate 3 estaria suficiente seria isso ?

Anexo 63896

Se tem equipto MIMO, não use MCS0 a 7, isso são data rates de polarização simples.

Esses sinais -65dBm pra mim dá pra MCS13, tem que conferir o datasheet pra ter certeza, mas no mínimo MCS12 eles suportam. -71dBm talvez só MCS11 (Tem que ver o datasheet, a sensibilidade). Mas com esses sinais não vejo nenhuma necessidade de usar digamos MCS8 ou 9, tem sinal suficiente pra MCS11.

(MCS8 é um MCS0 duplo, não use data rates de polarização simples (Só 1 chain) se o equipamento suporta 2. Veja os data rates nominais em www.mcsindex.com )

Ola rubem tenho acompanhado o tópico a algum tempo. Quero parabenizar e agradecer você pelo, esforço e a disposição que você tem para responder as duvidas da galera e trazer para o grupo um material bacana e consistente, pucos se dispõe a fazer isso. Aprendi bastante sobe mcs e consegui aplicar boa parte desse conhecimento na pratica. Porem eu cheguei a um empasse e gostaria, que se você pudesse esclarecer alguma duvidas que eu tenho.
A rede do provedor que eu trabalho consiste em MK e Ubiquit. Mas todos trabalham de modo separado (nao conecto mk em Ubi e vice-verça). A maioria de rede e Mk.
Trabalhamos com Rb 912 e 922 nas torres, e todos os clientes usam sxt.
Consegui melhorar bastante a rede porem ainda to enfrentado alguns problemas.
Em alguns painéis com bastante clientes nivel de ccq ficou muito bom, mas ja em outros com um numero reduzido de clientes eu nao consegui ategir a mesma qualidade. Nas imagens pode observar o painel mais lotado da rede. Ele ficou muito bom( não sei se e possível melhorar) mas ja em outros que tem menos clientes eu não consigo um bom resultado. Tenho algumas reclamações sobre perdas de pacotes, eu faço ping do painel para o cliente e fica alto ou para de responder, as vezes isso acontece com apenas 1 cliente do painel enquanto os outros fica tudo ok.Anexo 65151Anexo 65152Anexo 65153Anexo 65154Anexo 65155
Se tiver como você me dar algumas dicas de como melhorar agradeço. E agradeço mais uma vez pelo esforço de vir aqui e compartilha o conhecimento com a galera.

Também não acho que tenha como melhorar isso, 70 clientes numa RB912 é coisa pra caramba, é um hardware meio comum (Só com um sistema operacional ótimo pra ficar ok), se tivesse instalações porcas duvido que teria esses CCQ com mais de 15 clientes.

Acho que o pouco que dá pra melhorar são esses clientes com RX meio ruim:
Anexo 65156

Na prática eles só vão atrapalhar hora que eles requisitarem muitos pacotes. Estar apenas conectado, sem gerar tráfego, não consome processamento da RB, precisa consumo de tráfego pra "incomodar", por isso não necessariamente o cliente de sinal ruim é o que tem ping ou CCQ ruim, teria que ver o tráfego (Marca pra exibir as colunas Ack Timeout e TX/RX bytes (Somatória), veja se hora que tem ping ruim não tem tráfego nalgum cliente com TX/RX bytes aumentando rápido (Indicando consumo)).

Ou marca a aba P Throughput, o pass throughput tá meio relacionado ao CCQ mas quando o sinal é ruim (Por culpa da zona de Fresnel parcial) ele é alto quando o rádio está sem tráfego, mas hora que há consumo de dado o pass throughput cai, e falo cair pra menos de 1Mbps as vezes, sem que o CCQ caia tanto. O cliente que tiver um pass thrgouhput tão baixo quando tem tráfefo (Quando não tem tráfego não conta) tem problema físico no sinal, precisaria ir nesse cliente ver se tem como subir antena ou reposicionar.

@rubem, estou no mesmo barco que o amigo Haylan e estou seguindo suas recomendações também.

Ativei o P Throughput, mas não aparece nada nesta coluna, será qye tem a ver com o Nv2? Pois nenhum AP meu com Nv2 aparece algo nesta coluna.

Estou com o mesmo equipamento e configuração, 54 cadastrados e 48 clientes conectados simultaneamente. No momento em que a latência subiu, desabilitei todos que estavam com sinal acima de -60 e sobraram 43 e mesmo assim a latência continuou.

@rubem,Humm entendi isso explica o porque de eu ter um painel com 24 cliente e nao consegui um ccq decente. Vou ter para passar em cada cliente para revisar as instalações feitas( a galerinha que instala e fogo) na pressa de fazer o serviço acaba colocando a antena no cliente de qualquer jeito.

Caro Arthur, vou dar uma olhada com mais atenção em ruido.

Aqui estou usando como limite -60, mas alguns poucos clientes chegam a -65. Nesse caso em particular, tem apenas 3 clientes com esse sinal, o resto de -60 para melhor.

Abraço.

Fala galera sou novo por aqui e estou com problemas em minha net via rádio mikrotik, quase 1 mes estou com problemas em download, p/ baixar arquivos a taxa esta muito baixa net de 2 megas dando na maioria das vezes taxa de transferência de 46k no máximo chegando a 100k, gostaria de saber o que esta acontecendo essas configurações dentro do meu rádioAnexo 66153Anexo 66154

Fala galera sou novo por aqui e estou com problemas em minha net via rádio mikrotik, quase 1 mes estou com problemas em download, p/ baixar arquivos a taxa esta muito baixa net de 2 megas dando na maioria das vezes taxa de transferência de 46k no máximo chegando a 100k, gostaria de saber o que esta acontecendo essas configurações dentro do meu rádio estao certas


Anexo 66153Anexo 66154

Meu problema e o seguinte quando tento fixar mcs no sxt cliente o ap usa o mcs para up e para down ... Já em todas as outras cpes não tem este vinculo.
queria saber se e possível desvincular o mcs de subida com de decida no mikrotik cliente com mikrotik AP

Citação:

---

Postado originalmente por euanent

Meu problema e o seguinte quando tento fixar mcs no sxt cliente o ap usa o mcs para up e para down ... Já em todas as outras cpes não tem este vinculo.
queria saber se e possível desvincular o mcs de subida com de decida no mikrotik cliente com mikrotik AP

---

Já tentei de todas as formas e também sem sucesso.

Citação:

---

Postado originalmente por RaiSantos

Fala galera sou novo por aqui e estou com problemas em minha net via rádio mikrotik, quase 1 mes estou com problemas em download, p/ baixar arquivos a taxa esta muito baixa net de 2 megas dando na maioria das vezes taxa de transferência de 46k no máximo chegando a 100k, gostaria de saber o que esta acontecendo essas configurações dentro do meu rádio estao certas


Anexo 66153Anexo 66154

---

Você já tentou baixar de outro site?

Enviado de meu SM-E700M usando Tapatalk

Por favor alguém a duvida ainda permanece...

Citação:

---

Postado originalmente por euanent

Meu problema e o seguinte quando tento fixar mcs no sxt cliente o ap usa o mcs para up e para down ... Já em todas as outras cpes não tem este vinculo.
queria saber se e possível desvincular o mcs de subida com de decida no mikrotik cliente com mikrotik AP

---

Citação:

---

Postado originalmente por euanent

Por favor alguém a duvida ainda permanece...

---

Impossível, no MK quem manda é o ap

Enviado via Moto G (4) usando UnderLinux App

Essa questão depende da versão do RouterOS. Não mapeei que versões exigem o mesmo data rate em RX e TX, mas o mais comum é você ter que marcar no AP o data rate que a estação vai usar.

Digo, marca digamos MCS10 e MCS12 no AP, e somente MCS10 na estação. Nalgumas versões nem isso resolve.

Isso é limitação em software, não em hardware, os chipsets e o padrão do IEEE não exigem data rates similares.

Boa noite?

Estou com problemas na polarização, uso uma omnitik na torre e airgrid nos clientes, mas não consigo usar na vertical sinal fica ruim. Como posso regular isso?

Tá marcado chain0 e chain1 na Omnitik?

E se o sinal na vertical fica bem mais baixo que na horizontal, é porque a zona de Fresnel da vertical está insuficiente, e isso é falta de altura (Sinal passando metros SOBRE os obstáculos. Na horizontal precisa metros pro LADO dos obstáculos).

[QUOTE=mkmarcio;808660]Boa noite?

Estou com problemas na polarização, uso uma omnitik na torre e airgrid nos clientes, mas não consigo usar na vertical sinal fica ruim. Como posso regular isso?[/QUOT

A polarização vertical SEMPRE é mais afetada pelas atenuações porem tem que testar em vários pontos para concluir esta com problemas no AP.

Olá Rubem, muito obrigado por compartilhar tanto conhecimento, tem sido muito agregador para meus projetos.

Eu percebi que a discussão é voltada para provedores que utilizam wireless. E para Wi-Fi Indoor o que você indicaria para um AP suportar mais usuários? Na maioria dos nossos projetos utilizamos controle de banda entre 3 e 5 mbps por usuário. Datarates mais baixos ajudariam a suportar mais clientes simultâneos?