Duvdas sobre MCS PTMP

Bom dia pessoal do forum, me surgiu uma duvida

eu tenho uma rb912+basestation, estive vendo um video do grupo Escola de Provedores la do face, onde diz que para PTMP é necessário fixar um MCS, e essa é minha duvida, qual seria o mais adequado para PTMP

necessito de pelo menos 10mb por station, atualmente esta configurado com varios MCS pq configurei de acordo com alguns videos onde ensina para fixar varios mcs.

Anexo 54960


Alguém poderia me dar uma explicação sobre o assunto?

Estou usado 10mhz na modulação

Ih, mas 10MHz é gambiarra! Nem G ou A usam 10MHz.

Fixar MCS alto tem o problema de exigir sinal mais alto, a sensibilidade cai e a potencia de transmissão também, então acho mais útil NEM MARCAR os MCS altos.

Se todos os clientes tem CPE com antena dual-polarization marca também os MCS 8 a 14. Mas... tem roteador com 3 chains aí? Se não tem, pra que marcar MCS 16 a 23?

Eu sempre notei desempenho melhor (Estabilidade e alcance) com modulação 16QAM, que são 16 portadoras. Ela é usada em MCS3 e 4, e 11 e 12, é o que EU usaria (Uso MCS3 porque tenho muita CPE single-polarization, não tenho link pra vender muita conexão mesmo). Em MCS11 e 12 (Supondo que todos os cliente tem CPE com suporte a MIMO) você teria com canal de 20MHz (Que é a largura padrão do protocolo, 10MHz é gambiarra) e GI de 400nS (Short guard interval) 57 e 86M de datarate, que vai dar uns 45 a 70Mbps de throughput total. Aqui não entra a pergunta "Quando mega isso dá pra cada cliente", mas sim quanto cada cliente consome na media. Se tem 10 clientes online consumindo 10M o tempo todo, lascou, mas se tem 10 clientes simultaneos de media, com só 1 ou 2 consumindo mais que uns 6 ou 7M, e a maioria consumindo micharia tipo 1 ou 2M, esses 2 datarates são mais que suficientes.

Lembra: MCS alto exige sinal melhor, muuuuito melhor, pra ter MCS15 precisa ter praticamente 30dB a mais que pra ter conexão estável em MCS9. Fora que a potencia de emissão maxima de transmissão nesse MCS cai, se você usar roteador de 28dBm configurado pra 20dBm tranquilo, mas se usar coisa tipo cartão R52nm você terá ridículo 13 ou 14dBm em MCS16 (Contra 20dBm em MCS9). É bom conferir isso na ficha técnica do hardware, potencia e sensibilidade em MCS15 (Em mcs7 nem sempre é ruim, problema é mimo).

Se não tem nenhum cliente com equipamento sem suporte a MIMO pode desmarcar MCS0 a 7, se o sinal está ruim demais numa polarização o padrão N evita o uso dessa polarização automaticamente sem perder tempo testando as modulações (E aqui entra o problema de marcar um monte de MCS, o padrão tenta sempre o maior datarate possível, as vezes ele sobe pra MCS14 mas 2 minutos depois cai de volta pra MCS13, nesses 2 minutos houveram respostas mais lentas (Ping aumenta) e quando huveram 3 ou 4 perdas de pacotes seguidas o padrão desceu um MCS. 3 ou pacotes perdidos DEPOIS. O padrão não é inteligente a ponto de ver que vem chuva, que tem vento e a arvore que fica na zona de fresnel começou a chacoalhar, que o sol saiu de tras das nuvens e vai torrar aquele telhado que fica na beirada da zona de fresnel... enfim, o padrão muda os MCS conforme a qualidade da conexão vai mudando, eu prefiro fixar em 1 único MCS (Suficiente, e não "o mais alto possível") pra não ter essa perda de tempo testando profiles e modulações diferentes, nem perder processamento com esse dado. Com MCS fixo dá mais trabalho instalar nos clientes só se deixar os cliente no modo AUTO, se quer menos trabalho fixe os clientes em MCS1 ou 2 e pronto (Ou se tiverem upload alto vendido algo tipo MCS9, mas deve ter airgrid então é mais negocio usar MCS1 ou 2 neles. Se o upload for baixo tipo 1M pode até usar MCS0 nos clientes, melhor pro processamento da torre, terá menos dados pra processar de cada conexão, MCS no cliente e na torre podem ser diferentes (E sempre são), não vejo motivo pra usar modo AUTO nos clientes se estes tem upload tipo 1M, claro que propagação de broadcast precisa link maior, por isso falo em usar MCS1 ou 2, afinal 10 a 20M de datarate é mais que suficiente, nessa modulação terá sensibilidade maxima, maxima potencia, permite instalação em locais de sinal pior (Onde deixa tudo no AUTO teria jitter enorme, por ficar variando MCS, largura de canal e ack time).

Deixar tudo automatico facilita a vida de quem quer tudo plug-and-play, mas pra otimizar um PTMP tem que reduzir o uso de processamento e perdas de pacotes na torre, isso se faz NÃO usando os modos automaticos (Que em 802.11AC em MK não tem mais possibilidade pelo visto (Só AUTO), mas os chipsets prometem muuuuuito mais poder de processamento, e em roteadores de mesa AC tem essas config's igual, então no futuro provavelmente teremos como fixar alguma modulação específica em AC também).

Pode usar modulação diferente, e ela quase sempre é usada.
Pode ver que a velocidade de RX/TX é sempre diferente quando deixa no modo auto, o hardware vai se ajeitando até achar uma modulação que tenha a maior velocidade possível, mas normalmente o custo disso é ter ping alto, afinal datarate alto não garante throughput alto nem resposta rapida.

Em B, G ou A também dá pra usar velocidades diferentes no cliente e torre, no modo auto deles isso também ocorre, normal ver coisa tipo RX/TX 12M/36M em A ou G. Muita gente tinha problema em G com adaptadores PCI ou USB porque a tendencia em G é subir pra 48 ou 54M, aí a potencia e sensibilidade da placa PCI ou USB cai e a conexão vira um lixo, enquanto em B o maximo é 11M, que não tem sensibilidade e potencia tão diferentes de 1M ou 5,5M, criou-se a "fama" que G é péssimo nesses casos. E até tem diferença no alcance com estabilidade, mas seria 10% de diferença, e não cair o alcance de 5Km pra 1Km (Aí entra o maldito modo auto).

Eu olharia o sinal em dia de chuva e veria que modulação está nesse dia, então usaria ela ou o MCS logo abaixo, pra mim não vejo lucro em ter MCS alto de madrugada e no sol da tarde ou em dia de chuva cair, prefiro constancia.

@Arthur Bernardes; Provavelmente você já tenha dado outra reputação ao mesmo recentemente e isso afeta sua capacidade de dar reputação. Eu mesmo não posso dar 2 reputacoes pro mesmo usuario em curto periodo de tempo ou em algum post que eu ja tenha feito.

Citação:

---

Postado originalmente por Arthur Bernardes

Então @rubem, no caso de eu permitir somente MCS 12 no AP, é interessante no cliente selecionar o mesmo MCS?

---

Ao contrário, é melhor selecionar no cliente um MCS mais baixo, afinal é normal na torre ter 22dBm transmitindo em antena de 17dBi, enquanto no cliente o hardware tem antena tipo 11 ou 13dBi (Citando um NS Loco, por exemplo), de modo que torre>cliente o sinal é melhor que cliente>torre.

Claro que você pode ter sinal ótimo cliente>torre, mas ao usar MCS fixo mais baixo (O que é possível, já que o upload é sempre muuuuito menor que o download) você pode fazer instalações com "sinal pior".

Digo, o cliente a 1500m teria digamos sinal -74 com MCS7, a solução seria trocar o NS Loco por Airgrid. Mas... e se fixar em MCS1? O sinal vai melhorar, provavelmente vai pra -68 ou algo do tipo (Geralmente vejo melhora tipo 6 a 10dBi ao baixar o MCS uns 2 ou 3 numeros).

Se for ver pelo lado do "tempo" que cada cliente em MCS1 versus MCS7 ocupa da torre, claro que MCS1 demora mais tempo pra transmitir os mesmos dados que MCS7, mas... estamos falando de na prática coisa tipo 1 ou 2Mbps de trafego em datarate de 19Mbps, tem "espaço" de sobra pra broadcast e cia.

O problema que vejo com MCS mais alto chegando na torre é que são varios sinais simultaneos, ao usar algo tipo 64QAM (MCS6 e 7) são 64 portadoras, você precisa ter um sinal muito nítido pra conseguir ler essas 64 portadoras, enquanto num 16QAM (MCS3 e 4) com 16 portadoras você precisa ter um sinal menos nítido, por isso a sensibilidade do hardware em MCS7 seria DIGAMOS -70dBm e em MCS3 seria -61dBm, ou seja, pra ter o mesmo SNR (22-25dB) você precisa ter sinal em nível mais alto, se não tiver e usar MCS7 vai ter perdas nalgumas portadoras, que implica perda de alguns pacotes (Ping demora, cai throughput se usar pacote grande), não vai perder "muito" pacote porque eles tem tamanho variado, o uso das 64 portadoras não será perene, e o thermal fadding também não será perene, obstruções em 100 ou 200% da zona de fresnel causam reflexos não-perenes, essa falta de perenidade nos incomodos só é um problema quando o SNR está baixo, e se MCS menor tem SNR maior no mesmo ambiente, ponto pra MCS menor.

Eu pelo menos nunca ví um bom argumento em favor do uso de MCS alto. O tempo de exclusividade da conexão pra transmitir seria um bom motivo, mas seria se vendessemos conexão UL : DL 1:1, como vendemos upload bem baixo (Que seja metade do download, a media de uso do upload é bem baixa) podemos colocar muito mais clientes num radio, e com sinal pior (Portanto mais distantes, ou com antenas mais baratas) do que se usassemos UL : DL 1:1.

Imagina uma torre central atendendo repetidoras, coloca uma setorial em MCS15 e coloca 8 RocketDish nas repetições como clientes também em MCS7, a torre vai sofrer pra entregar toda conexão com qualidade. Já um PTMP com 24 (3x8) clientes em MCS2 a torre vai trocar dados num um pé nas costas, porque o trafego cliente>torre será muito menor. Poderia usar MCS7 nesses clientes, mas usando MCS mais baixo você pode colocar clientes com sinal pior e não perder qualidade com isso.

Na torre é importante não marcar MCS0 ou 1 mesmo, afinal a torre precisa transmitir mais dados, mas o cliente precisa mandar pouca coisa pra torre, usando MCS menor o sinal do cliente chegará mais nítido do mixer e decoder da etapa de RF, porque MCS menos tem menos portadoras ou menos bits por chip, com sinal mais nítido tem menos pacotes perdidos.

Veja que me baseio na praxe de ter sinal torre>cliente muito melhor que cliente>torre. Se usar na torre anteninha de 8dBi e 18dBm, e no cliente antena de 16dBi em radio de 22dBm, você pode fazer o contrário, colocar no cliente um MCS mais alto que na torre, pra torre gastar menos tempo com cada conexão de cada cliente, mas é porque nesse cenário você PODE fazer isso, já que terá sinal pra lá de melhor cliente>torre.

Mas eu bem que espero uma boa motivação pra NÃO usar MCS baixo nos clientes, eu procuro faz tempo mas não encontro.

No setup do roteador (Ou no winbox) você seleciona a modulação que será usada pra transmissão. Roteador A transmite na velocidade que quiser, roteador B transmite na velocidade que quiser, ambos se entendem sem problemas.


Se você setar MCS12 num SXT como AP na torre, por exemplo, e deixar os cliente no modo automatico, terá RX de tudo que é datarate, com tudo que é modulação, um em MCS3 (Airgrid), um em MCS12 (NS M5), um em MCS10 (NS Loco M5). Mas o SXT da torre transmitirá sempre em MCS12 afinal você marcou apenas esse profile.

Você tem que ajustar um MCS alto na torre, e em cada cliente marcar velocidade fixa baixa. RX e TX podem ter velocidade diferentes e praticamente 90% das vezes tem!

Dá uma olhada nos RX/TX na sua rede, vai ver valores diferentes, são modulações diferentes em uso. Wireless > Registration > Ativa a aba RX/TX rates. Os numeros antes e depois da / são iguais ou diferentes nos clientes? Se for como a grande maioria das redes terá valores diferentes, digamos 19Mbps/39Mbps, indicando que a torre está usando MCS4 (39M) rumo à esse cliente, mas esse cliente está usando MCS2 (19M) rumo à torre.

Só tem que cuidar com MCS alto demais no AP porque isso reduz o alcance da rede. MCS tipo 12 pra quem vende conexão tipo 1M não tem lucro nenhum, só diminui a possibilidade de colocar cliente distante.

Mas o conceito é bem esse, põe o MCS suficiente pro thourghput necessario, usando o conceito de suficiência você pode ter clientes mais distantes ou com zona de fresnel mais comprometida (Sem que um derrube a qualidade geral da rede).

Se usar MCS12 tanto no AP como nos clientes, vai ter desempenho ótimo se tiver sinal suficiente. O que cito sempre é que as vezes não tem sinal suficiente pra MCS12 mas tem sinal suficiente pra MCS2 ou MCS10, como o upload é baixo não tem porque forçar o uso de MCS12.

Se você tem instalações que permitem MCS12 em todos os clientes, vai dormir porque você é ninja e não precisa trabalhar pelas proximas semanas! :-)
O problema é que sempre tem cliente com sinal pior, você fixa um MCS mais baixo e isso vai dar mais estabilidade (Porque com MCS mais baixo a sensibilidade aumenta)

Uma rede perfeita tem todos os clientes com sinal igual, como não dá pra querer um sinal alto tanto em cliente a 200m como em cliente a 5000m, acho mais facil usar esse cliente a 5000m como referencia, ele tem sinal suficiente só pra MCS10 então coloca todos transmitindo em MCS10, só variando potencia e ack time, todos terão os "mesmos direitos" na hora de consumir banda.
(E eu não sou comunista)

Outra vantagem de MCS fixo não muito baixo (MCS0 ou MCS8) ou de MCS automatico: Se o sinal ficar ruim a ponto de cair pra MCS0 ou MCS8 é sinal que tem obstrução física, e portanto deve haver perdas de pacotes torre>rede, é a mesma lógica de negar conexões abaixo de digamos -75: Se o sinal está ruim, fica sem internet até um técnico ir ver isso, ao invez de ficar com conexão ruim mas derrubando a qualidade da conexão dos outros (Por consumir processamento da torre). Eu tenho receito de usar MCS0 por isso, essa "desgraça" de MCS0 as vezes mantem conexão mesmo com cliente a -86! A conexão fica ruim mas o cliente só abre facebook e não nota, mas consome processamento da torre, o CCQ dos outros cai.

eai galera, estive meio ausente, vi q o tópico ta parecendo um livrinho =D

Vou ler amanha e seguir as dicas do @rubem

Ja vou ver, mudar para 20mhz =D

Obrigado

Li e re li 2x, fiz uns teste aqui

Ap rocket m5 mcs fixo em 7 depois baxei para 3

Cliente airgrid m5 mcs fixo em 0 "plano de 600k"

Tive uma pequena melhora no ccq no mais nao ouve ganho no nivel do sinal que com tudo auto era -65 continuo assim mesmo apos as modificaçoes

Citação:

---

Postado originalmente por Arthur Bernardes

@rubem, interessante falar em ACK.

No AP PTMP eu coloco o "distance" considerando o cliente mais distante, certo?

E no caso do "station", eu coloco a distância do cliente da torre?

---

Pode usar ACK time até maior que a distancia do cliente distante, é outra forma de contornar problemas de visada/zona de fresnel usar ack maior na torre.

Eu testei ack time gigante tipo 140uS sem ver diminuição no thourghput ou demora em ping, perdi o medo de usar valores bem mais altos que devia.

Citação:

---

Postado originalmente por JonasMT

Li e re li 2x, fiz uns teste aqui

Ap rocket m5 mcs fixo em 7 depois baxei para 3

Cliente airgrid m5 mcs fixo em 0 "plano de 600k"

Tive uma pequena melhora no ccq no mais nao ouve ganho no nivel do sinal que com tudo auto era -65 continuo assim mesmo apos as modificaçoes

---

A sensibilidade muda, mas o nível de sinal chegando vai ser o mesmo, só ia mudar se aumentasse a potencia do outro lado, o problema está em placa tipo R52nm que tem potencia em MCS14 beeeem baixa tipo 14dBm enquanto em MCS1 ou 9 tem 20dBm, aí sim muda muito o sinal. Em Rocket e cia você podia usar 22dBm de MCS0 a MCS15, aí não faz diferença mesmo, faria diferença se eles tivessem potencia muito menor em MCS15 (Acho que é 23dBm em MCS7 e 15 nos Rocket, algum UBNT tem 20dBm em MCS7 e 15, eu só sou feliz com 22dBm por aqui, aí sim ia incomodar cais 2dBm por usar MCS maior).

Baixando a sensibilidade (De digamos -80 pra -85) muda o SNR porque reduz o limiar inferior de sinal. Tem o termo fade margin, a quantidade de sinal presente mas tão baixo que o radio não consegue ler (O mixer e o demodulador não conseguem discernir os pacotes), o noise floor geralmente é isso, vira ruído porque tem tanto pacote ilegível que a etapa de RF vê que tem algo mas não consegue identificar o que é (Identifica como ruído, mas são conexões proximas e reflexos), dependendo da antena você tem noise floor tipo -92, trocando antena passa pra -94, mudando os MCS isso varia um pouco também, mas tem um "approach" diferente no noise floor por parte da MK e da UBNT, você tem noise floor tipo -116 em SXT e no mesmo lugar um NS M5 apresenta noise floor tipo -98, acredito que o SXT tem um numero bem realista e a UBNT põe o fade margin na conta e só exibe o sinal acima do qual ela consegue realmente identificar os pacotes.

Enfim, nem sempre vai mudar SNR em UBNT ao alterar os MCS, mas em MK o noise floor muda mais, dá pra ver mais facilmente a sensibilidade variando, mas a diferença está na estabilidade em caso de sinal ruim, sinal ruim variar PERCENTUALMENTE mais o SNR, digo, SNR variando de digamos 28 a 32 não causa perda de pacotes, mas se o SNR estiver no mínimo aceitavel, 20, e variar pra 16 quando o sol ficar forte, aí sim teríamos muita perda de pacotes. Um MCS menor permitiria sinal menor sem perder pacotes, mas onde tem sinal alto e que nunca varia realmente não acho que faça tanta diferença, só reduziria o processamento no radio da torre, e em radio mais parudo o processamento nem sempre falta.

Eu tinha a rede em B com CCQ variando, 78%, 64%, as vezes caindo pra 48%, raramente tinha cliente com CCQ de 80%, como notei que todos os clientes naquela torre tinham equip. com suporte a N coloquei 2 setoriais em N e fui transferir uns clientes, testei primeiro MCS0, de 11M pra 13,5M devia ser suficiente, vai ví que dava pra subir até MCS5, deixei em MCS5 então, só que conforme fui acrescentando clientes o CCQ voltou a cair, 92%, 84%, 78%, era uma melhora, mas antes de sair melhorando os sinais (-64 a -74) experimentei MCS4 e 3, não tive CCQ menor que 92% com MCS3, deixei nisso. Alteração nos clientes foi apenas mudar de modo B pra N e fixar a velocidade em 13,5M (Sempre fiz comodato, equipamento simples). Provavelmente então com sinal mais que suficiente tipo -65 não faça muita diferença, com -74 ví muita diferença na estabilidade e no CCQ. Hoje limito o sinal dos clientes em -64, notei que quando um ou outro cliente com algo tipo -51 conecta o CCQ de quase todos caía, era queda igual se conectasse um ou 2 com sinal -80. Não testei subir o sinal de todos porque não tem como, o jeito foi baixar o de quem está proximo, criou estabilidade do mesmo jeito, mas com sinal baixo "só MCS baixo salva" :-)

Essa 912 é uma cavala ta doido.

Entendi rubem obrigado.

Uma coisa ruim se tiver radio 1x1 e 2x2 no mesmo ap, mesmo setando mcs 7 e 12 os radios 1x1 nao conectao mais. E necessario apenas mcs7 para baixo no Ap. Teste feito em omnitik com cliente airgrid/nano e sxt.

Show essa screen em Arthur ele esta usanod nv2?

Citação:

---

Postado originalmente por Arthur Bernardes

Anexo 54990

Imagem de um SuperPOP com Basebox 5, ele disse estar setando MCS 11 e 12 tanto no AP e nos clientes.

Veja o "tx/rx rate" e o CCQ.

---

Ô coisa linda, tudo equalizado, nem 10dB de diferença de sinal entre os clientes, SNR lindo.

Eu não ia resistir e ia instalar uns clientes mais distantes com sinal -70, o bolso fala mais alto :-)

Eai pessoal, linda essa imagem
O @rubem me tira uma duvida então
tenho todos os rádios clientes MiMo, se eu setar os MCS 11 e 12 em 20mhz, terei uma melhoria significativa em relação a sinal e de thoroughput?

E nos clientes seria uma boa fixar MCS baixo certo, no caso eu pretendo cascatear, colocar aproximadamente 10 clientes por radio, colocando MCS 2 seria uma boa escolha?

Mais uma coisa, por esta cascateando, seria necessário esta com WDS ativo ou não a necessidade?

10MHz pode ter sinal mais baixo que 20MHz, então você vai ter uma "piora" de uns 3dB na sensibilidade ao mudar de 10 pra 20MHz (Sensibilidade que devia alterar o noise floor e o snr, não o nível de sinal), mas se hoje seus clientes estão na maioria em MCS14 ou 15 não vai haver melhora ao colocar fixo em MCS10 ou 11, porque tem sinal suficiente.
Se o sinal é baixo e eles ficam pulando de 6 pra 39M a cada poucos minutos, aí sim fixar num MCS mais baixo ajuda.

Ao reduzir o MCS a sensibilidade melhora, então você pode usar canal de 20MHz. Afinal com canal de 10MHz a banda é muito baixa, em MCS8 dá o que, 6Mbps? Dá na mesma que SISO em MCS0 com canal de 20MHz (6 ou 6,2Mbps, algo assim).

Só lembra que na torre você só altera o MCS do TX, tem que mecher na CPE dos clientes pra fixar a velocidade que verá no RX. Veja aí na aba registration como anda o RX, testa um padrão tipo 10 ou 11 se todos estiverem acima disso, se estiverem baixos vai ter que usar nesse cliente um MCS mais baixo, e é nos sinais baixos que vejo muita diferença ao fixar isso em mcs baixo.

Ao passar de 10 pra 20MHz vai ter uma piora no CCQ talvez, mas você tem o dobro de datarate, o mínimo que se espera é que piore. Ao trocar de MCS12 pra MCS15 o datarate não dobra, mas ao mudar de 10 pra 20MHz na largura do canal sim dobra.

(Alguém fala aí sobre WDS, nunca me preocupei com isso, sempre ativei sem me perguntar o porque...)

WDS nesse caso serve para repassar o MAC de quem está trafegando os dados e não da antena.
Exemplo..
Tenho um prédio usando um Nano Station M5 conectado em um Rocket M5.
Dentro desse prédio tenho 5 clientes e quero autenticar PPPoE neles.
Se você não tiver Access Point WDS ativo no Rocket e Cliente WDS no prédio o MAC que vai tentar autenticar no servidor sempre será o da antena do prédio.
Os 5 clientes irão tentar autenticar com o mesmo MAC, o da antena.
Quando ativa WDS no AP e no Cliente isso não ocorre.

Sem WDS ele não repassa os MACs.

Aqui uso ativo o WDS em todos os Access Points, nos clientes residenciais que autenticam na própria antena não marco WDS.
Nos clientes onde a antena vai ficar em bridge e algum outro aparelho irá autenticar depois da antena, marco WDS.

Muito obrigado pela explixcação @klabundee @rubem irei fazer as modificações de mcs e irei postar aqui o resultado, na parte onde tem supported MCS é melhor deixar todos ativos? ou desmarcar alguns, percebi que no omnitik a apenas 15 MCS, enquanto a RB912 tem os 23 MCS, alguém saberia me dizer o motivo?

Dá uma olhada com atenção em www.mcsindex.com , MCS0 a 7 é pra 1 chain (1 stream, 1 canal, 1 etapa de rf, 1 radio, não sei qual o termo pra melhor descrever), MCS8 a 15 é pra 2 chains, e MCS 16 a 23 é pra 3 chains.
ALGUMAS RB912 tem 2 chains e algumas tem 3 chains, os modelos são acD de dual chain, e acT de triple-chain. Omnitik só tem 2 chains.

E se marcar todos os HT MCS você vai usar o modo auto, pra fixar um MCS você marca só um, EXATAMENTE como já se faz a muitos anos na aba data rates, se marcar todos os data rates você terá data rate (Modulação) variável, se quer só 1 você marca só 1 (E a meu ver esse foi o problema de muita gente usando G que teve desempenho péssimo, usaram todos os data rates ou só datarates altos (36/48/54M) sem perceber que pra ter data rate (Ou MCS) alto tem que ter sinal mais alto. Obviamente sinal -60 é alto o suficiente pra qualquer data rate A, Bm G, N ou AC, a grande diferença está nos sinais baixos, um datarate baixo ou um HT MCS baixo permite sinal mais baixo sem perder estabilidade.

Ai o resultado, com MCS 11, omnitik com sxt, sem nv2 ou nstream. Distancia de 1km
No bandwidth teste passa em tcp media de 19~22mbps
Anexo 55219
Poderia ser feito mais alguma coisa para melhorar?

Rapaz esse ccq ta ruinzao hem. Creio que ele tenha prejudicado seu teste

Por isso estou postando, para ver se alguém me da uma luz pra ver oque melhorar

precisa de tudo isso mesmo de banda nesse cliente? Se nao precisa baixa mais o mcs dele.

A vizada desse cliente como esta?

Também acho que é bom diminuir esse MCS, afinal MCS11 tem sensibilidade segundo o datasheet na casa dos -80, isso dá só 10 a 16dB de SNR.

Ou aumentar esse nível de sinal.

Noise floor ultimamente é informado usando a maior sensibilidade do aparelho, que é o menor MCS, não dá mais pra confiar no SNR informado, tem que ver a sensibilidade de cada MCS e largura de canal no datasheet.

(Afinal um MCS15 tem sensibilidade tipo -75, se fixar nisso o SNR marcará 50dB igual está agora, mas o CCQ vai cair ainda mais, precisaria sinal tipo -50 pra ter SNR real de 25dB. A sensibilidade informada no datasheet não é sem motivo, é dado útil)

Rubem, parabéns pela explanação sobre as boas práticas sobre a correta utilização das modulações.

Vai ajudar muito ao pessoal entender o Trade-Off (relação perde-ganha) existente entre nas comunicações digitais, onde as taxa de transimissões estão em conflitos com o SNR requerido.

Nem sempre utilizar o maior o DATA RATE é melhor...

Porém, acho que precisamos debater sobre uma colocação sua: "10 Mhz é gambiarra". Qual o motivo para afirmar isso? Seria simplesmente porque a utilização canais de 10 Mhz não foi padronizado pela IEEE quando da elaboração dos padrões?

É que eu tenho na minha rede um case onde consegui ótimos resultados usando canais de 10 Mhz, sendo que a utilização de canais mais estreitos aliados a altos níveis de SNR foram os pontos chaves para o sucesso.

Na minha avaliação, assim como a escolha da modulação correta é fundamental, a escolha da largura do canal correta também é primordial, pois a escolha da largura correta do canal também remete a uma relação de conflito entre: Maior largura de banda X maior recepção de ruído e maior consumo de espectro.

Portanto, poderia falar um pouco mais sobre a sua não recomendação da utilização de canais de 10 Mhz?

Pois eh, eu também fiquei pensando o porque de 10 Mhz seria "gambiarra", pois aqui em minha rede uso a quase 3 anos e sempre funcionou legal, porem para planos menores que 2 Mbps.

Em 10 Mhz o hardware é: RB433AH + Cartão R52HM + Painel UBNT (Nas conexões uso pigtail de boa qualidade e 1,5 Metro de Cabo LMR-400 hyperlink)

Com a necessidade de atender os cliente com maiores planos instalei a uns 2 meses RB912 c/ Painel UBNT em 20 mhz e estou MUITO satisfeito com o resultado, estou finalizando as migrações dos planos maiores e alguns clientes de maior uso para elas e até agora a qualidade esta MUITO SUPERIOR!!

Tava pensando em até colocar umas RB912 em 10 Mhz só pra tirar a prova.

Sei que o hardware da RB912 é muito superior e também sei das perda nas conexões, mas dai fiquei na dúvida:

A melhoria significativa foi pelo HARDWARE ou LARGURA DE CANAL ??

Olivionet, tbm tenho 1 painel em 10mhz dentro da cidade a 3 anos sem problema algum. Na zona rural uso 10mhz e 2.4 só alegria.

Essa semana tbm subi 912 c/ basestation é absurda a diferença de Noise Floor se comparado a ubnt.

Tenho ambas nas torres, mas no caso da rb912 estou usando com 17dbi 90º

Isso isso isso, insisto que 10MHz é gambiarra porque não está no padrão 802.11n de 2009.
Tem chipset que não aceita canal de 5MHz em N, tem uns que aceitam, com 10MHz não é diferente, eu até tentei usar 10MHz, mas parece que nenhuma CPE barata não tem mais suporte a isso (NS, SXT e Airgrid não tem nada de baratas).

A melhoria que 10MHz traz com relação a 20MHz é uns 10dB a mais de sensibilidade, ao trocar MCS7 por MCS5 geralmente muda algo proximo dos 10dB de sensibilidade. Canal mais estreito perde o que? Perde capacidade. Diminuir o MCS diminui o datarate em 20%, diminuir a largura do canal diminui o datarate em 50%!

Exemplo:
Um NS Loco M5
- Sensibilidade de -74 em canal de 20MHz em MCS7. Datarate de 65M
- Sensibilidade de -86 em canal de 20MHz em MCS4. Datarate de 39M
São 12dB de diferença na sensibilidade, são 40% a menos no datarate (65 - 40% = 39).

- Sensibilidade de -74 em canal de 20MHz em MCS7. Datarate de 65M
- Sensibilidade de -84 em canal de 10MHz em MCS7. Datarate de 32,5M
São só 10dB de diferença na sensibilidade, são 50% a menos no datarate (65 / 2 = 32,5) porque você usa metade da frequencia, metade das portadoras.

O datarate e o throughput não tem relação exata, mas datarate maior implica througput maior quando tem sinal suficiente.

Nesse caso, melhor reduzir o MCS ou melhor usar canal mais estreito?


O datasheet nem sempre informa, mas praticamente em todo datasheet que informa a diferença de sensibilidade de 5 pora 10MHz informa que é de 10dB, de 10 pra 20MHz mais 10dB, de 20 pra 40MHz mais 10dB. A pouca variação que ví foi 9 ou 11dB em um ou outro equipamento, tomo como universal os 10dB a mais de sensibilidade ao usar canal com metade da largura.

O throughput com canal mais estreito será menor (Se tiver sinal suficientemente limpo) que a metade porque com mais pacotes você desperdiça mais espaço útil em cabeçalho de pacote, acho que chamam de mac overhead. Algo assim: Em MCS7, 20MHz, você tem 64 portadoras, cada portadora leva um trafego X por segundo, cortando o canal pela metade, passando pra 10MHz, o numero de portadoras cai pela metade (Apesar de tanto material na web não consigo confirmar essa info, de 20 pra 40MHz (O padrão) o numero de portadoras dobra, em A/G de 5, 10 e 20MHz o numero de portadoras tambem dobra quando dobra a largura do canal, só posso presumir que de 20 pra 10MHz em N a portadoras são cortadas pela metade), cada portadora vai usar os mesmo 135,7KHz de largura, cada portadora vai levar o mesmo numero de bits (Se usar a mesma modulação no comparativo), ou seja, com metade das portadoras terá metade do trafego, pra transmitir os mesmos dados (O mesmo 2MB de um upload, por exemplo) você vai precisar simplesmente mais pacotes, cada rajada de pacotes informa destino e cia no cabeçalho, o espaço ocupado por dados de destino e origem, de modulação/datarate usados, de largura de canal e cia, é tanto que quando você muda o intervalo de guarda (GI) de 800 pra 400nS (Diminui 50%!) o datarate sobe 11%. Também entra a quebra de pacotes, com mais mac overhead você tem que quebrar os pacotes em partes cada vez menores, SE ocorrer erro de 1 portadora esse erro pode comprometer partes quebradas que já chegaram no roteador de destino na rajada anterior, vai ocupar memoria por mais tempo, então a capacidade de ter mais clientes trafegando dados simultaneamente cai.

Claro que isso é uma analise bem resumida/porca, cada caso é um caso, mas a tendência de canais mais largos tem a intenção de aproveitar melhor o espectro, na verdade a diferença de 10 pra 20MHz deve ser mais de 100% de aumento no datarate, já que de 20 pra 40MHz em N, ou de 40 pra 80, ou de 80 pra 160 em AC, o aumento é de uns 107% na verdade, ou seja, ao comparar 10MHz (802.11n não padrão) com 80MHz (802.11AC) você passa por: 3,25M em 10MHz, 6,5M em 20MHz, 13,5M em 40MHz e 29,3M em 80MHz, enquanto se não houvesse economia no cabeçalho seria 6,5, 13 e 26M, a melhoria é de mais de 12%.

Eu entederia se estivesse usando MCS6 ou 7 com canal de 10MHz pra ter um PTP mais estável com sinal ruim ou coisa assim, afinal com mais portadoras (32 em MCS6 ou 7 em 10MHz, comparado a 16 em MCS3 em 20MHz) você consegue datarate melhor e mais throughput real, mas deixar no modo auto com multiplas modulações possíveis em 10MHz não dá lucro, vai pular entre modulações de 32, 8 ou 4 portadoras, vai "ocupar" o espectro e o hardware com datarates dignos de 802.11A ou G.

Channel overlapping é um problema? Num lixinho de 2002 tipo RTL8186 sim, num chipset de 2012 ou 2013 isso não é mais problema, o mixer e o ADC terão muitos pacotes pra lidar de qualquer forma, se ele tem que analisar sinal com 6dB de resolução ou com 20dB dá na mesma, então um segundo SSID com sinal -70 por perto incomoda tanto quanto um overlap do canal vizinho em algumas portadoras. Colocando um profile de 10MHz talvez tenha gente que se engane com o scan, como não escaneia praticamente nenhum SSID com canal tão estreito talvez ache que isso isola de alguma forma os outros SSID's, mas parece que isso não confere, pelo visto os mixers e ADC's processam tudo pra só depois separar, ou seja, um canal vizinho de 20MHz ou de 10MHz vai entrar junto no mixer de qualquer forma, o noise floor não comtemplará ele, o nível de sinal não mudará (Logo o SNR também não muda) mas o throughput (Ou o CCQ) não melhora tanto.

Deve ter chipset com suporte a N com canal de 5MHz, uns 1,6M de datarate em MCS0 provavelmente (Ví isso alguma vez, não lembro onde). Qual a sensibilidade disso? Uns -116dB, é o que os MK em geral mostram como noise floor. Opa, então o noise floor exibido não é o limiar inferior da sensibilidade da modulação usada? Nops, a sensibilidade da modulação e largura de canal está só no datasheet (Nem em todos infelizmente), e me parece que tem gente que não leva esse dado a serio. Se a sensibilidade em MCS7 com canal de 20MHz é de -74 num NS Loco M5, e precisa uns 25dB de SNR, que sinal precisaria? -49! Putz, um NS Loco com sinal -49 tem que estar meio colado na torre né! Se o sinal é apenas -60 isso dá só 14dB de SNR, aí o CCQ fica baixo, imagino que uns 75-80%. Ao cortar o canal pra 10MHz o CCQ sobe pra quase 100%. Porque? Oras, a sensibilidade subiu de -74 pra -84, o SNR de 14dB subiu então pra 24dB. Mas... e o throughput geral? MCS7 em 10MHz dá 32,5M de datarate, chutemos 25Mbps de throughput (Já que ter 50Mbps em MCS7 com canal de 20MHz é possível). Mas... e se tivesse baixado pra MCS4? A sensibilidade seria -86, melhor que -84, datarate de 39M com canal de 20MHz, e em MCS4 dá pra conseguir 30Mbps. São só 5Mbps de throughput, mas em rede grande isso significa poder atender 5 a 10 clientes a mais sem que o CCQ de todos caia demais, isso dá uma bela diferença no bolso.


Quem é feliz com 10MHz continue usando, não tem problema de espectro nem nada, mas essa é a motivação pra eu chamar isso de gambiarra, isso não está no padrão (E nem é suportado pelos chipsets e firmwares comuns) porque aproveita mal o espectro, canal mais largo gera mais channel overlapping mas os chipsets e S.O. de hoje sabem lidar muito bem com isso, digo, não perdemos mais muito troughput por isso (Comparado ao channel overlapping em 802.11G em chipset lixo de 2002).

802.11AC não está nem aí pra sobreposição de canal porque os chipsets não estão nem aí pro aumento de processamento que isso gera, eles estão com tudo no modo auto (Não tem mais seleção de modulação ou largura de canal em alguns) porque confiam muito na propria capacidade de processamento, e dá pra entender, lidar com 256 portadoras (MCS8 e 9 em AC) de uma conexão única não é pra qualquer um, o processamento MÍNIMO pra AC é um patamar muito superior do habitual de chipsets N.

Como é agradável ler um tópico assim!

@rubem , algumas duvidas:

1. Por qual motivo o cliente com sinal muito alto irá reduzir o ccq dos demais conectados na base?
2. Em caso onde se pode escolher configuração de modulação até somente certo ponto, tipo UBNT (MAX TX rate), é importante para o AP que todos os clientes estejam nivelados ou ele consegue lidar com MCS 8, 9, 10, 15, tudo junto? (sem denigrir capacidade e qualidade)
3. Um cliente que não consegue modular ao máximo mesmo com sinal dentro do padrão, ocupando mais tempo no ar por estar em AUTO devido ás varias tentativas, força os demais clientes à caírem em nível de modulação? Nesta questão vale considerar RX/TX, imaginando que o AP analisado seja misto 802.11a/n

Cliente com sinal alto acho que só é problema no modo AUTO, ele vai ter sinal suficiente pra digamos MCS7 e os outros só pra MCS3, mas o software nem sempre é inteligente o suficiente pra separar as conexões, ele acaba respondendo em datarate alto pra cliente com sinal baixo, e precisa repetir o envio usando datarate menor até "aprender" o datarate correto, mas é só o cliente de sinal alto conversar com a torre que todo o aprendizado é perdido, o software é meio lerdinho ainda.
(AC melhorou muito isso, meu roteador 1200AC lidava até bem com modo auto mesmo em A, B ou G, melhor que roteadores caríssimos ABG de 2009)

Minha conexão está bem limitada essa semana pra eu conseguir postar mais, mas pode acompanhar os CCQ's dos clientes baixos e altos, conecta uma antena com sinal alto depois vira ela pra baixar e acompanha o CCQ exibido por todos, qualquer um desequalizado pra mais ou pra menos altera CCQ dos outros, e não é só a exibição do CCQ, se mantiver um ping rumo a eles verá jitter acompanhando CCQ baixo, se for muita diferença gera muita perda de pacote, porque o software no chipset não consegue acompanhar as variações nos sinais, sinal alto e baixo vai tudo pro mesmo misturador pra ser demodulado da portadora pra ser lido, se tiver outros SSID's perto mesmo em canal diferente você terá perda de desempenho também (Pouca, mas tem), tem que ver como é a etapa de RF, pra transmitir um mixer mistura modulação e pacotes, pra receber um demodulador usa outro sinal de modulação de modo que uma modulação "abata" a outra (Tipo afinar violão, quando as 2 cordas tem o som no mesmo tom o som de uma abafa o da outra, quase cancela se forem sinais iguais) e só reste pacotes de wifi, sinal fraco é distorcido pelos sinais fortes nessa hora, a distorção é pequena, e ter 2 ou 3 conexões muito diferentes não tem problema, mas quando tem 20 aí começa a ter perda de pacotes, o CCQ cai, as repetições de pacotes tomam tempo, as propria repetições geram trafego extra (Uma conexão boa trafega 10 pacotes, uma ruim tenta trafegar os mesmos 10 mas repete CADA pacote umas 2 ou 3 vezes até que recebe uma confirmação de recebimento legível, uma conexão ruim vale por 3 boas então, mas bom ou ruim depende do nível medio de todos, eu falo sempre em padronizar em algo tipo -55 a -65 pra ter alcance, -65 é sinal baixo e baixo assim permite muitos Km de alcance com datarate baixo, quem tem densidade grande e só clientes proximos não precisa se preocupar com isso e pode usar datarates altos, mas quem atende grandes distancias vai ter sinal baixo, o jeito de viver bem com isso é ter todos com sinal baixo e datarate baixo, pra que um sinal forte ou datarate alto no demodulador não torne sinais fracos ilegíveis, alias... mais ilegíveis ainda, afinal uma ou outra portadora sempre se perde em grande distancia, o negócio é diminuir as perdas, e não trabalhar com perda zero.

Valeu pelos esclarecimentos @rubem, boas festas!

Boa noite pessoal,

Encontrei este tópico hoje estava procurando sobre o assunto.

Fiquei com uma duvida é melhor utilizar mcs de 16 QAM ou 64 QAM no caso de ubnt dá pra escolher ex mcs 5 - 64QAM e mcs 11 - 16 QAM ambos de mesmo data rate 26mb em 10 mhz ou 52 em 20 mhz.

MCS8 a MCS15 são basicamente 2 (dois) MCS0 a MCS7, o datarate é o dobro porque de MCS0 a 7 você tem 1 chain (1 antena, 1 canal, 1 radio, 1 "via", enfim, tem 1 meio de envio) enquanto em MCS8 a 15 são 2 meios, o datarate é exatamente o dobro.

MCS16 a 23 são basicamente 3 (tres) MCS0 a 7, e MCS24 a 31 são 4 (quatro) deles, cada meio (antena, chain, radio, cada meio) opera isolado do outro, por isso se chama MIMO (Multiple-in Multiple-out), os roteadores de mesa com 1 antena não fazem mimo então são vendidos como "150M" (Porque MCS7 em 40MHz com tempo de guarda (GI) curto de 144,4M (Arredonda pra 150M), já os roteadores com 2 antenas são vendidos como "300M" porque tem 2 meios de trocar dados (2 antenas, que podem estar na mesma polarização ou não), eles tem 2 MCS7, ou seja, MCS15, que em 40MHz e GI curto tem 288,9M (Arredondado pra 300M), roteador com 3 antenas é vendido como "450M" porque tem 3 meios de 150M cada, roteador com 4 antenas é vendido como "600M", e por aí vai, são 150M por antena.

A tabela "oficial" fica em www.mcsindex.com
Vejam que pra 802.11N é uma numeração e pra 802.11AC é OUTRA numeração. MCS8 em N é uma coisa e em AC é outra.
Pode notar que os datarates em 20MHz são metade dos em 40MHz. Se usar canal de 10MHz terá datarates que são exatamente metade dos valores em 20MHz. 20MHz é o padrão, é o que 802.11A, B e G usaram por isso ele ainda é referencia, MCS7 tem 64 portadoras só em 20MHz, em 40MHz ela tem na verdade 128 portadoras.


Já com canais de 10, 20 ou 40MHz você também tem o dobro ou a metade do datarate porque CADA portadora (16QAM tem 16 portadoras, 64QAM tem 64 portadoras) tem uma largura fixa, aumentando a largura do canal você pode aumentar o numero de portadoras.

Se com 64 portadoras em 20MHz você tem datarate de 52M, ao dobrar o canal pra 40MHz terá 128 portadoras e datarate de 104M.
Já se usar canal de 10MHz será metade disso, "só" 32 portadoras, aí o datarate nominal será de 26M.

A modulação escolhida (MCS) não tem relação com a largura do canal, existem coincidencias porque além do numero de portadoras (8, 16, 64) o que conta é o numero de bits por cada simbolo enviado, é aquele numero depois do 16QAM ou 64QAM. Essa nomeclatura (symbol rate de 1/2, 3/4, 5/6) não permite uma conta fácil de cabeça, mas o que importa é que o tipo de codificação usado não tem relação com a largura do canal, é meio que coincidência alguns datarates em uma largura de canal baterem certinho com o de outra largura de canal porque se usa 2, 4, 16 ou 64 portadoras, e o numero de bits por simbolo (Visto no symbol rate) é fixo também.



O datasheet não traz todas as potencias e senbilidades, mas o equipto trabalha com sensibilidade por datarate, se selecionar um MCS11 em 20MHz você terá o mesmo alcance, sensibilidade, potencia, e throughput se selecionar MCS9 em 40MHz, diminuindo o datarate a sensibilidade aumenta, mas aumentando a largura do canal ela diminui, não tem como fazer mágica com um determinado sinal o único jeito de aumentar banda é colocando mais portadoras (Que 802.11AC fez, 256 portadoras) e colocando mais chains (Mais meios de transmissão, mais antenas com radios, 802.11N suporta 4 chains enquanto 802.11AC suporta 8), se você tem digamos um sinal -65 não tem muito o que tirar disso, é sinal suficiente pra digamos 25Mbps em datarate de certa de 50M, seja MCS9 de 54M em 40MHz, MCS11 de 52M em 20MHz, ou 52M em 10MHz (MCS14 com canal de 10MHz), por isso insisto que usar 40MHz é desperdício de espectro quando se usa modulação abaixo de MCS12, se pode conseguir os mesmos throughputs com canal de 20MHz (Ou até 10MHz, mas aí não sei como fica a fiscalização da Anatel, já que nas homologações constam modos de uso tipo 16QAM 1/2, mas colocando canal de 10MHz (Que seria muito bom pro espectro) teria na verdade 8QAM 1/2, se bem que dia que Anatel chegar com espectrografo pra verificar isso deve chover canivete).

A explicação pode ser complexa, mas o que é impornte reter é que o conta é o datarate, se você tem sinal insuficiente pra digamos 54M em 40MHz, não terá sinal suficiente pra digamos 52M em 20MHz, em um ou outro caso de zona de fresnel comprometida você pode ter melhora, mas com instalações decentes (Visada total, zona de fresnel 100% limpa, sem ruído demais no canal) você pode testar de 10, 20, 30 ou 40MHz que obterá estabilidade em datarates similares com o mesmo nível de sinal, não tem como extrair muita coisa de sinal baixo.
(E MCS8 a 15 é mais fácil, é MIMO, enquanto MCS0 a 7 é SISO, é só sempre olhar o mcsindex.com, de preferencia imprimir e colar na parede)

Rubem, muito boa a explicação é isso mesmo. A escolha entre a combinação entre a largura de canal, modulação, capacidade de transmissão e sensibilidade é relação de conflito, é uma relação de perde-ganha. Aumentando a largura de canal e a taxa de modulação aumenta-se a taxa de transmissão, porém perde em sensibilidade e necessita de um sinal mais forte (maior SNR). Diminuindo-se a largura de canal e a modulação, diminui-se a taxa de transmissão, porém aumenta-se a sensibilidade e pode-se trabalhar com sinais mais fracos (menor SNR).


Esse tema da modulação é um pouco complexo pro pessoal que tá começando, mas recomendo a todos que estudem bem, pois a melhora nos enlaces é impressionante.

Mas Rubem, gostaria somente de fazer uma correção no que vc tem dito sobre a modulação. Notei que você tem mencionado que 16QAM trabalha com 16 portadoras, 64 QAM trabalha com 64 portadoras, 256QAM trabalha com 256 portadoras e assim por diante e ainda que o número de bits enviado por símbolo, como vc mesmo disse "é aquele numero depois do 16QAM ou 64QAM"

Na verdade não assim não, o correto é o seguinte:

16QAM não quer dizer que trabalha com 16 portadoras ou subportadoras. É possível trabalhar com 16QAM e ter 10, 20, 30 ,40, centenas, ou até milhares de subportadoras, como é o caso das transmissões de TV Digital no padrão ISDBTb, que é o padrão adotado no Brasil para TV Digital. Ou seja, a nomemclatura 16QAM não guarda relação nenhuma com o número de portadoras ou subportadoras.

A nomemclatura 16QAM, 64QAM e 128QAM quer dizer que cada simbolo transmitido contém respectivamente: 16, 64 e 128 combinações diferentes de Amplitude e Fase da portadora. Não é algo simples de entender, levei um tempo pra entender isso. Na verdade pra entender a modulação QAM, tive que compreender primeiramente como funciona a modulação por Amplitude e depois a Modulação por Chaveamento de fase, pois a modulação QAM é uma mistura das modulações por amplitude e fase, ou seja, numa transmissão QAM a portadora sofre alteração de amplitude e fase simultaneamente, sendo que uma portadora em modulação 16QAM pode assumir 16 combinações diferentes de amplitude e fase, a portadora modulada em 64 QAM pode assumir 64 combinações diferentes de amplitude e fase e assim por diante. É um pouco desafiador entender isso aí, mas é muito interessante.

Com relação ao número de bits transmitidos por símbolo, funciona assim na transmissão digital:

BPSK- Cada símbolo pode assumir 02 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 1 bit

QPSK- Cada símbolo pode assumir 04 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 2 bits

8 QAM - Cada símbolo pode assumir 08 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 3 bits

16 QAM - Cada símbolo pode assumir 16 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 4 bits

32 QAM - Cada símbolo pode assumir 32 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 5 bits

64 QAM - Cada símbolo pode assumir 64 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 6 bits

128 QAM - Cada símbolo pode assumir 128 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 7 bits

256 QAM - Cada símbolo pode assumir 256 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 8 bits

512 QAM - Cada símbolo pode assumir 512 combinações diferentes de amplitude e fase, portanto cada símbolo transmite 9 bits

e assim, por diante.

Note que o aumento no número de bits transmitidos não é proporcional ao aumento no número QAM. Exemplo, aumentando-se a modulação de 16QAM para 64QAM, aumenta-se quatro vezes o número de diferentes combinações de amplitude e fase, porém aumenta-se somente em 50% a taxa de transmisão.

Essa é a explicação para a dificuldade de se transmitir dados a longas distancia e com estabilidade, em modulações superiores ao 16QAM, pois acima disso já é considerado uma modulação de alta ordem, com um número muito grande de combinações de amplitude e fase da portadora, exigindo altíssimo nível de sinal, baixo ruído e circuitos de rádio muito bem elaborados.

Na prática, como esses rádios Mikrotik e Ubiquiti que trabalhamos, somente conseguimos um bom resultado e estabilidade usando as modulações até 16QAM, que seria: 162 Mbps em 40 Mhz, 81 Mbps em 20 Mhz e 39 Mbps em 10 Mhz. Vejam o fracasso que tem se mostrado a linha AC que tenta usar modulação 256QAM.


Bom, é isso. Desculpem pelo tamanho do texto, mas é que não tinha como ser menor, na verdade esse é o resumo do resumo. Quem gosta de estudar Telecomunicações esse é um tema muito interessante e com muita aplicação prática.

Tá certo, nunca achei uma tradução boa (Nem ruim) pra explicar isso. Tá ótimo o modo colocado.

Boa noite amigos.

De uns dias pra ca venho tendo problemas de conexão com meus clientes, ja havia trocado radio, antena, pigtail, fonte e nada esta resolvendo, eles ficam associados na antena de transmissão só que do nada começam a cair e voltar.
Comecei dar um procurada do que poderia ser e cheguei até esse tópico, creio que com a ajuda de vocês eu consiga resolver meu problema.
Equipamentos que utilizo: RB 912UAG-2HPND + Basestation 5G20 20DBI 90º 5GHZ + SXT 5NDR2 (lite 5) em todos os clientes.
Faz 1 mes que estou com essa nova base, quando tinha uns 5 clientes transferidos para ela, estava tranquilo, agora que ja está chegando a 20 comecei a ter esse problemas citados acima.
Comercializo links de 1mb à 4mb (upload de 300k a 600k).
Minha idéia é somente utilizar esses equipamentos, não vou misturar fabricantes, por isso gostaria de uma idéia também de como tirar o maximo de rendimento deles, usa-los com nv2 por ex?
Lendo sobre o que foi postado pelos amigos, principalmente pelo rubem, vi que o que pode estar me prejudicando (ou uma das possibilidades) é a configuração correta de MCS, já que não estou utilizando nenhuma configuração setada, esta default.
Já estava cogitando voltar para minha antiga base esses meus clientes migrados para essa novo ambiente quando cheguei até esse tópico.
Por favor, peço a ajuda de vocês para uma correta configuração desse ambiente, sendo essa relação de equipamentos e links de 1mb a 4mb, como devo deixar meu MCS na base e nos clientes? Que velocidade devo setar em Data rates (hoje estão marcadas A/G 18/24/36/48/54)? Coloca-los tb em nv2 como um print postado acima por um colega?

Segue imagem de como está o sinal desses clientes na base.

Anexo 57925

OBS: Não gosto de pedir esse tipo de ajuda mastigada, gosto de entender o que estou fazendo e colocar em prática, no entanto, devida a minha urgência pelo menos com essa base de acesso, gostaria dessa ajuda de vocês.
Estou lendo, relendo o tópico e procurando mais material para estudar.

Desde já, muito grato a quem puder me ajudar.

Olhando a imagem, a torre está transmitindo pra uns em SISO e pra outros em MIMO, é isso mesmo?

65M é MCS6 somente 1 polarização com GI curto.
72M é MCS7 somente 1 polarização com GI curto.
144M é MCS15 dupla-polarização com GI curto.

Se tem antena de dupla-polarização tanto na torre como nos clientes tem que usar ela. SE fosse em Mikrotik seria só marcar os MCS HT de dupla-polarização, tipo MCS8 até MCS15. UBNT é mais limitada e você tem que escolher 1 (Um) datarate apenas, te recomendaria colocar o Max TX Rate em MCS12, que com GI curto vem a ser 86M. Na real vai ter throughput agregado de 40-50Mbps, mais que suficiente pra 30 clientes de 4Mbps cada (Metade costuma ter consumo, e metade dessa metade tem consumo alto, e metade dessa metade da metade costuma usar a banda toda (4Mbps).

Mas uma coisa que não tem muita utilidade é MAX TX rate alto no cliente. Na imagem tem cliente transmitindo (TX no cliente é RX na torre) em 6M (MCS0) e outros em 65M (MCS7 com GI longo), como o upload de todos é o mesmo, e com upload baixo tipo 1 ou 2Mbs pode usar nos clientes MCS9 (26M) tranquilo! A sensibilidade dos hardwares com esse datarate baixo é bem alta, com sinal -71 é quase impossível não ter CCQ de 95% com MCS9.

Então na torre marque MCS12 pra testar (Caixa automatic desmarcada, senão vai continuar como está, com varios datarates diferentes), e nos clientes marque no MCS-HT apenas rates de dupla-polarização, como o upload é baixo poderia usar MCS8, mas acho exagero, tem sinal suficiente até pra MCS10 na verdade, tanto faz o que colocar (MCS8 a 11), o que importa é não deixar cliente chegar com MCS15 quando o sinal dele é tão baixo tipo -70, esse tipo de sinal não está uns 20dB acima da sensibilidade do datarate, tem SNR mas não tem margem suficiente com relação a sensibilidade (Vide datasheet, lá tem as sensibilidades, cada datarate tem sensibilidade diferente).

Quanto a aba DATARATES dos SXT, não marca nada lá, aquilo é pra quem vive em 2007 e ainda usa 802.11A. Se marcar datarates A e deixar o modo em A/N (Automatico) em algum momento pode cair em A, que é um belo desperdício de equipamento! Se o equipto suporta N use N que o rendimento (Bits por hertz ocupado) é muito melhor que no antiquado e velho A, e se o equipamento tem dupla-polarização FORCE ele a usar isso (Com max tx rate fixo de dupla polarização, e com MCS-HT de dupla-polarização).

(O default no SXT é vir só com chain0 ativo, tem que marcar o chain1, na imagem só ví RX de 6M a 65M, PARECE que eles estão usando só 1 polarização, que é um belo desperdício de equipamento. Tem que marcar chain0 e chain1, e marcar APENAS MCS rates de dupla-polarização, que são MCS8 a 15, mas recomendo ficar em 9 a 11, TESTE)



Tenho a impressão que está subutilizando o equipto que tem, tem datarates de polarização simples na imagem, modos automaticos fazem essas bobeiras por isso digo pra NÃO usar NADA automatico, pra polarização simples poderia ter comprado setorial de metade do preço, e usado airgrid baratinha ao invez de SXT. Se tem dupla-polarização aproveite e use.

(E não use largura de canal em 20/40MHz. Pra essa banda pequena 20MHz dá e sobra, é desperdício de espaço gastar 40MHz pra apenas 4Mbps. Use fixo em 20MHz, tanto na torre como nos clientes. Quanto ao modo, UBNT tem a porcaria do modo A/N que não muda, mas SXT tem somente N (N-Only), use esse modo pra não ter risco da comunicação ser feita no antiquado e pouco produtizo modo A.)

Tenta manter os clientes com CCQ acima de 90%, mas enquanto ainda tiver 1 cliente transmitindo com MCS7 porém com sinal baixo (RX na torre) tipo -70 ele vai piorar o CCQ dos outros. Baixar o datarate de transmissão dos clientes é o mais importante pra começar, não precisa exagerar e baixar pra MCS0 (Que só usa 1 polarização) só porque o upload é de 600K, existe muito trafego de broadcast além do upload, usando dupla-polarização o menor datarate é MCS8, 13M, já é suficiente, mas você tem sinal suficiente pra mais que isso, MCS9 ou MCS10 acho que te dará o melhor desempenho (TESTE! Todos com o mesmo tx rate, veja CCQ's, depois teste o outro tx rate e veja CCQ's, mas fique sempre em dupla-polarização, e não exagere com MCS14 ou 15).

Muito obrigado pela ajuda Rubem.

Referente ao SISO, vou repassar a configuração das SXT e habilitar o chain1, algumas estão somente com o chain0 marcado.
Em Wireless estou utilizando 20MHz com Only-N (tanto na torre quanto nos clientes)

Torre de Transmissão

Para ativar/desativar determinados MCS, somente consigo colocando o Data Rates e Configured, caso fique em Default não consigo depois manusear os MCS.
No caso do Data Rates, deixo como está na imagem abaixo?

Anexo 57928

Indo agora para as guias HT e HT MCS, creio que a HT esteja ok, conforme primeira imagem abaixo, no entanto, a HT MCS pelo que eu entendi, ficara como a segunda imagem (não irei utilizar UBNT em minha rede, somente Mikrotik SXT)?

Anexo 57929 Anexo 57930

Configurações Clientes (SXT)

Também não consigo definir o MCS sem ter que configurar/setar o Data Rates (pelo menos eu não encontrei uma outra forma de setar sem retirar a opção de default do Data Rates)
No caso dos clientes, deixo a configuração de Data Rates igual está na da Torre de Transmissão informada em imagem acima?
Em HT marquei a opção chain1 e habilitei todos os HT AMPDU, ficando idêntica a configuração da Torre de Transmissão
Depois, em HT MCS, pelo que você disse para ativar, tenho que deixar conforme imagem abaixo?

Anexo 57931

Desculpe caso esteja fazendo algo errado, é que como falei, nunca havia feito essa configuração com MCS.

E novamente, grato pelo tempo que está dispondo em me ajudar.

Abçs

Ah, agora ví que você tem MK tanto na torre como nos clientes, putz, não sei como entendi que tinha Rocket M5 na torre.

Bom, na aba DATARATES não marque nenhum datarate. CASO algum SXT não conecte marque apenas o datarate de 54M, isso vai forçar ele a não usar modo 802.11A.
(Em N-only não tem esses datarates, só tem os MCS, é bug isso de uns MK precisar marcar pelo menos 1 datarate, as minhas RB's não precisam disso mas tem gente relatando que sem nenhum datarate marcado ninguém conectava mesmo em N-only, testa aí se precisa, mas se precisar marque apenas 54M, tanto suportado como basico).


Quanto a aba HT MCS, você marcou todos os "suported rates", desde polarização única (MCS0 a 7), até os de 3 chains (MCS16 a 23). Pra usar apenas 1 datarate marque apenas MCS12, tanto no suported MCS como no basic MCS (O basic é o mínimo, e o "suported" é por onde o datarate vai variar).

Na aba HT o "HT Guard Interval" é o GI, que tem na tabela www.mcsindex.com , um intervalo curto otimiza a banda, mas com zona de fresnel ruim ele costuma atrapalhar, como parece ter instalações ótimas nos clientes teste intervalo de guarda curto mesmo.

Nos SXT mesma coisa na aba HT MCS, marque um MCS tanto no "suported" como no "basic", MK tem a vantagem de permitir um "range" como você fez (9 a 11), não gosto de UBNT porque ela te obriga a usar apenas 1.

Eu até prefiro mais de um datarate, mas na torre. Nos clientes acho que o desempenho fica melhor com todos com datarate bem mais baixo que o da torre, e com todos os clientes com o mesmo datarate, pra você ter noção exata da qualidade do sinal de cada um.

Se tiver cliente gritando com sinal alto (-40 a -50) tem que baixar a potencia dele, 1dBm a menos na aba TX Power faz muita diferença! Já tem tiver cliente sussurando com sinal baixo (Tipo -70) o jeito é usar datarate mais baixo tipo apenas MCS9 nele (Deixa a torre sempre com MCS12), e talvez subir a potencia em 1dBm. Mas o ideal é pegar um patamar de sinal, tipo -55 a -65, ou talvez -70, e começar nos clientes com potencia alta, e ir baixando até que o sinal desse cliente chegando na torre seja uns -60 a -65, em alguns clientes você vai usar potencia baixa tipo 10dBm, e nem por isso vai ter CCQ tipo 98%, isso é coisa que se faz em cada instalação, a potencia e MCS da torre você não mecher, mas nos clientes você COMEÇA com apenas MCS9 e potencia tipo 20dBm, aí acessa a torre a partir do cliente e vai baixando a potencia (Ou sobe o MCS pra 10 ou 11) atpe usar a mínima potencia necessaria, potencia alta atrapalha os vizinhos e a própria torre (Sinal a -45 tem uns 30dB de atenuação ao virar a polaridade, ele chega então como -75 na outra polarização, ainda dentro da faixa de sensibilidade, fora os reflexos, o sinal pode refletir num predio o mesmo num telhado na zona de fresnel e chegar com 50uS de atraso (Aí que aumentar o ack-timeout ajuda) e com uns 30dB de atenuação, então só use sinal alto se usar datarate alto, afinal datarato alto tem sensibilidade menor.

Algo assim: Use pelo menos 20dB a mais que a sensibilidade do datarate (Link margin, MK e UBNT pouco falam disso mas recomendam 20dB pelo menos), e no máximo 30dB a 35dB a mais que a sensibilidade do datarate porque esse é o isolamento entre uma polarização e outra (Antena ruim talvez tenha só 25dB de isolamento).




O que você pode testar pra subir CCQ e melhorar ping é o ACK Timeout, ou distance dependendo da versão do MK. Na torre deixa ele em automatico (Afinal a torre transmite pra gente em tudo que é distancia), mas nos clientes coloque um valor 20 a 30% maior que a distancia real. Se a distancia real é 1Km teste 1.2Km, quando a zona de fresnel não está 100% livre isso diminui os pings demorados e de quebra melhora o CCQ, já tive aumento de quase 20% em throughput simplesmente colocando ack-timeout fixo 20% maior que o correto (Geralmente no "automatic" é exibida a distancia correta ou pouco maior, se ela é exibida muito maior é porque tem algo na zona de fresnel provavelmente).

Boa tarde Rubem,

Novamente, muito obrigado pelas orientações.

OBS: Após eu ativar o chain1 nos SXT clientes que estão na minha nova relatada acima, a 002, a queda de conexão parou de acontecer e por isso resolvi subir uns 3 clientes para uma outra nova base, a 001, e nela fazer esses testes e ajustes de conexão, pois como minha base 002 vinha a semanas com problemas, vou fazer esses testes na 001 com 3 clientes que tenho facil acesso e aplicar posteriormente na 002.
Estou dando essas explicações porque nas imagens que vou postar o SSID estará como WISP-NS-58-001 e não WISP-NS-58-002 como as anteriores.

Apliquei suas orientações em meu ambiente, no entanto ao desmarcar os Data Rates nas SXT (clientes), o cliente não associa mais na Torre.
- Ativo a opção de 54M na SXT mesmo assim não associa.
- Ativo a opção de 54M na SXT e também na Torre e também não associa.
- Marco a opção default no Data Rate na SXT e o cliente volta associar (Data Rates na torre estão todas desmarcadas).

Seguem abaixo os prints de tela da configuração da minha Torre e também de um SXT cliente.
Da forma que as configurações estão abaixo, a SXT não associa na torre. Para ele voltar associar eu tenho que voltar o Data Rates da SXT para default.

Torre de Transmissão:

Anexo 57949Anexo 57941Anexo 57942Anexo 57943Anexo 57944

Cliente SXT (é o primeiro cliente associado no Registration, conforme primeira imagem da Torre de Transmissão, com CCQ 97/56):

Anexo 57945Anexo 57946Anexo 57947Anexo 57948


Mesmo você detalhando bem o que era para ser feito, posso ter entendido bem errado em alguma configuração.

Abçs!

Hum, esse CCQ de RX de 56 e 76% tá péssimo, teria que testar outras coisas nos SXT.

Testa na torre o HT guard interval em long, o datarate fica menor mas acho talvez MK tenha melhor desempenho com ele já que NV2 usa isso (O TX rate vai cair de 86M pra 78M).

Nos SXT testa também o HT guard interval em long.

Na aba Advanced tanto da base como dos SXT pode sempre marcar o HW Protection mode em RTS CTS, e a opção em Adaptavie Noise imunity em Acess point and Client mode.

Está usando superchannel na base, mas precisa mesmo? 5820MHz é tão diferente de 5825MHz? Não sei se tem relação com seu problema, mas testa o frequency mode em Manual TX-Power, não devia ter nada a ver mas a única diferença com relação ao que configuro é isso pelo que notei.

(Se a aba Datarates precisou ficar em "default", beleza, muita gente comenta isso, não tenho idéia do porque pra alguns em "Configured" com todos os datarates desmarcados conecta normal)

Não sei porque o RX rate na base é 76/86M (MCS12) e não o MCS9 que configurou nos SXT.

Eu configuro tudo, tipo ganho da antena, wireless protocol similar nos 2 lados, configuro o país correto, e na aba TX Power coloco a opção "all rates fixed" e potencia baixa tipo 15 a 20dBm. Não sei se isso faz diferença, mas o HT MCS configurado em estação (cliente) é o RX Rate na base.
(Nunca usei superchannel, não sei se ele influencia nisso)

Alias, eu também coloco o canal igual em ambos, por mais que colocando canal diferente a estação conecta eu sempre tive a impressão que demora mais pra associar (Parece que escaneia de 5 e 5 ou de 10 em 10MHz até achar em que canal está o SSID, scan list grande pra mim sempre gerou demora em conexão, uso scan list pequeno, seja MK ou UBNT, e sempre canais padrão (Multiplos de 20MHz).

Correções e sugestões aplicadas amigo.

Na verdade, não uso superchannel em Torre de Transmissão, esse rádio estava em um ptp e por isso que estava com o superchannel, não me atentei nisso ao coloca-lo em modo AP, obrigado pelo toque.

Voltando agora a minha saga.. rsrsrs.. eu não consegui setar o MCS9 nos SXT sem que ele perdesse comunicação com a Torre, por isso que você viu 76/86M (MCS12) e não o MCS9, porque na verdade o SXT estava em default (na imagem
Quando mudo o Data Rates no STX para Configured, e vou em MCS e deixou somente o MCS9 ativo, ele perde a comunicação com a Torre até que eu volte novamente o Data Rates para default (mesmo setando em 54M não volta também a conexão), nos prints que mandei acima eu deixei com o MCS9 ativo para confirmar que estava correto o que eu estava fazendo, no entanto, com somente ele ativo o SXT perde comunicação com a Torre.
Caso eu deixe no SXT o data rates em default, ele volta a comunicação com a Torre no entanto eu não consigo definir o MCS.
Será que esse problema pode ser questão de versão do MK? (estou utilizando 6.22 na Torre e 6.27 na SXT

Tá, esquece a aba DATARATES por enquanto, usa como funcionar, você está se focando demais nela sendo que ela nem é usada em only-N (Os datarates só deviam fazer efeito se usasse modo A, ou A/N). Eu acho que só tenho versão 5.26 ou mais velha então talvez seja questão de versão mesmo, outra hora testo um 6.x pra verificar isso.

Testa marcar mais datarates na aba HT MCS, alguns de SISO, tipo MCS2 a 4, alguns de MIMO tipo 9 a 11.

Tenta seguir os passos:
http://api.ning.com/files/Vish0M*eub...orkshopSXT.pdf
ou
http://pt.scribd.com/doc/81317382/Config-SXT#scribd

Vai que está com algo diferente num ponto que não devia fazer diferença pra isso (prioridade HT AMPDU já testei e não notei diferença). Acho que seu problema está nesses outros detalhes, porque a aba Datarates em Configured (E só 1 HT MCS marcado) é o que tenho usado e não ví esse problema, mas realmente já lí mais gente falando nisso, só nunca consegui reproduzir o erro.

(E acho que ví gente falando nesse problema a uns anos antes da versão 6.x)

Conseguiu resolver o problema?

@rubem Utilizo aqui tudo em MCS 12 e MCS 12 nos clientes. Como no Mikrotik esta setado MCS12, se eu colocar MCS 9 no cliente o mesmo não conecta, ja tentei diversas vezes e nada. A não ser se eu marcar MCS 9 no ap tb. MK versão 6.29.

Citação:

---

Postado originalmente por rubem

No setup do roteador (Ou no winbox) você seleciona a modulação que será usada pra transmissão. Roteador A transmite na velocidade que quiser, roteador B transmite na velocidade que quiser, ambos se entendem sem problemas.


Se você setar MCS12 num SXT como AP na torre, por exemplo, e deixar os cliente no modo automatico, terá RX de tudo que é datarate, com tudo que é modulação, um em MCS3 (Airgrid), um em MCS12 (NS M5), um em MCS10 (NS Loco M5). Mas o SXT da torre transmitirá sempre em MCS12 afinal você marcou apenas esse profile.

Você tem que ajustar um MCS alto na torre, e em cada cliente marcar velocidade fixa baixa. RX e TX podem ter velocidade diferentes e praticamente 90% das vezes tem!

Dá uma olhada nos RX/TX na sua rede, vai ver valores diferentes, são modulações diferentes em uso. Wireless > Registration > Ativa a aba RX/TX rates. Os numeros antes e depois da / são iguais ou diferentes nos clientes? Se for como a grande maioria das redes terá valores diferentes, digamos 19Mbps/39Mbps, indicando que a torre está usando MCS4 (39M) rumo à esse cliente, mas esse cliente está usando MCS2 (19M) rumo à torre.

---

Citação:

---

Postado originalmente por Arthur Bernardes

@rubem, hoje presenciei um problema até estranho.

Usamos uma RB912 como AP, 802.11 A/N (sem TDMA) e "country set" em "Argentina", MCS 3,4,8,9 e temos clientes 2x2 (SXT) ativos com esses mesmos datarates.

Acontece que hoje foi necessário instalar um cliente Airgrid nesse mesmo AP e por incrível que pareça não se conectava. Configurações todas de acordo: Country em Argentina, scan-list igual e A/N, mas percebemos que ao deixar o datarate em automático no AP, o UBNT se conectava.

OK, fomos testar a seguinte coisa: Colocado SOMENTE MCS1 no AP e somente MCS1 no cliente, conectava normalmente, mas ao colocar MCS2 no AP e MCS4 AP o cliente não conectava.

Existe alguma via de regra que obrigue o datarate a ser igual em ambos os lados?

Obrigado rubem novamente.

---

Caro @rubem, complementando as informações que o @Arthur passou seguem outras.

Na mesma RB912 em pauta hoje tentei conectar um cliente com WOM5000 SISO e acontece a mesma coisa, não conecta apesar do sinal -54.

Tentei inclusive marcar TODAS as opções em Data Rate e em HT MCS e mesmo assim não conecta.

Marcando a opção Defaut em Data Rate o cliente conecta, mas ai fica de 6Mb/s, e de MCS 0 a MCS 7 (WOM SISO) e sabemos que não faz sentido ficar modulando assim para passar de 2 a 4 Mb para o cliente. Com a opção Defaut marcada, conecta tanto em A/N como Only N.

No entanto um Lite-5 conecta-se perfeitamente com Data Rate 12Mb/s e 18Mb/s e com MCS 1 e 8 marcados.

Porém, em outros APs com RB433 e R52H, Data Rate em 12Mb/s e 18Mb/s conecta de tudo.

Fazendo mais alguns testes em bancada notamos o seguinte:

Com Chain 0 e Chain 1 habilitados apenas radios MIMO como WOM MIMO e Lite-5 se conectam ao AP. Já com Chain 1 desabilitado, todos como WOM MIMO e SISO, Lite-5 e Airgrid se conectam ao AP.

Pelo observado é alguma coisa com SISO e MIMO, mas como fazer com que a RB912 aceite conexão tanto de SISO como de MIMO simultaneamente como são os Nanostations, por ex. ?

Grato.

Desculpem a demora...

Bom, sobre isso de não conectar com o uso de MCS fixo, tenho visto isso também, não consegui isolar se é culpa de alguma versão do MK (ME PARECE ser mais comum nas 5.x em diante), ou de algum chipset.

Vamos a o que eu notei nuns casos:
Caso 1: Só conectava se eu deixasse modo A/N (Não somente N) mas com o datarate de 1M ativo. Suspeito que seja porque o preamble (SSID e cia) é transmitido no menor datarate possível.

Caso 2: Só conectava se deixasse também MCS0 e MCS8 ativo. Não sei se o preamble (Curto ou longo) nalguns casos usa o menor datarate do modo N (Pol. simples ou dupla), até onde eu saiba ele usa 1M ou 2M (Curto ou longo).

Caso 3: Só conectava com preamble curto (Equipto 802.11A mais velho (Com RTL8186, sim ele suporta 802.11a) talvez tenha isso). Na verdade foi esse caso que me fez testar os datarates baixos nos casos acima.

Caso 4: Equiptos Ubiquiti não conectavam com PPPoE, só em bridge (Enquanto MK, Intelbras ou Oiw conectava), enquanto com datarate auto tudo conectava. Mesma coisa, marquei A/N, datarates de 1M e 2M apenas, só 1 MCS, preamble longo, e voilá, resolvido o problema (Tá, não testei marcar só 1M ou só 2M, ou só preambulo curto).

Eu desconfio dessa questão do preambulo porque quando não há trafego NENHUM o datarate mesmo com datarate fixo, é exibido como 1M, 2M ou 6M as vezes, é o momento em que há apenas a troca de dados básico de conexão (Preâmbulos).

Mas... faz pouco tempo com MK 5.23 ou algo assim não teve jeito, tive que deixar no automático senão não conectava, com cartões R52HN em 5GHz, enquanto em 2,4GHz o MESMO cartão e RB aceitavam tranquilamente conexão configurado em somente N com só 1 MCS alto. É algo com 5GHz, com alguns cartões ou RB's, talvez só em algumas versões novas do MK, vou dar uma de astrólogo e dizer que seu dia pode ser de sorte e você se conectar à sua RB amada... ou não.

Preciso testar mais coisas, a princípio tudo o que tenho aqui conecta com só 1 datarate e só 1 MCS marcado, quero até testar SSID's com caracteres especiais porque onde tive problema ME PARECE que sempre tinha isso.

Bom Dia Pessoal.

Vou lhes explicar minha situação.

eu tinha um pop que conectavam 28 usuários (Mk e Ubiquiti sinais diversos de -55 até -71) com autenticação PPPoE, certo tudo ok, porem avia um gargalo no pop q não deixava mais de 16mb de download passassem.
acreditei q era uma limitação do equipamento, então retirei a autenticação do pop e a transferi para um "concentrador", blz o processamento do pop diminuiu MUITO, porem também não vi um aumento no trafego, sempre a mesma base de 14 a 16mb.
depois de ler este topico, fiz algumas alterações de rate e mcs, depois disso consegui uma banda passante de 24MB. perfeito, é exatamente oque eu precisava.
porem durante esse final de semana alguns cliente começaram a cair, por problema de sinal e reassociating.
então desfiz as alterações do mcs e o problema parou.

agora vem a minha duvida. oque eu fiz de errado.
segue o print de como as configs estavam.
Anexo 60863

Sou leigo pessoal, então desculpe caso tenha falado alguma besteira.

Citação:

---

Postado originalmente por Prusch

Bom Dia Pessoal.

Vou lhes explicar minha situação.

eu tinha um pop que conectavam 28 usuários (Mk e Ubiquiti sinais diversos de -55 até -71) com autenticação PPPoE, certo tudo ok, porem avia um gargalo no pop q não deixava mais de 16mb de download passassem.
acreditei q era uma limitação do equipamento, então retirei a autenticação do pop e a transferi para um "concentrador", blz o processamento do pop diminuiu MUITO, porem também não vi um aumento no trafego, sempre a mesma base de 14 a 16mb.
depois de ler este topico, fiz algumas alterações de rate e mcs, depois disso consegui uma banda passante de 24MB. perfeito, é exatamente oque eu precisava.
porem durante esse final de semana alguns cliente começaram a cair, por problema de sinal e reassociating.
então desfiz as alterações do mcs e o problema parou.

agora vem a minha duvida. oque eu fiz de errado.
segue o print de como as configs estavam.
Anexo 60863

Sou leigo pessoal, então desculpe caso tenha falado alguma besteira.

---

Se todos os equipamentos suportarem o modo N, pode tentar demarcar tudo na aba data rates e deixar apenas no MSC que é referente a modulação do modo N.

Na foto acima os clientes estão modulando 48/36/24/18/6 e isso é modulação A, faz como citado acima, desactive todos na aba data rate, deixe uma MCS baixa (0-8) para preâmbulo e a que você quer que seus clientes conectem....faça os testes e veja se para com o problema de desconexão

Me corrijam se disse besteira

Olá rubem!

Em testes de bancada acontece o seguinte.
AP -> rb912 v 6.33.3
CPE -> SxT v 6.33.3

1. AP em A/N ou N com data rate 6 ou sem, MCS 0, 8, 12 ou somente 12 qualquer combinação, CPE SXT somente conecta se estiver exatamente igual ao AP.

2. AP com nv2 e somente um MCS (ex. 12) marcado, CPE conecta com qualquer MCS marcado (ex. 9) porém me parece que assume o MSC do AP.

2. AP em 802.11 e A/N data rate em default, CPE conecta com qualquer MCS (ex. 9) mas com data rate em 6M, porém percebo que tanto TX como RX assume o MCS da CPE (ex. 9).

Alguma coisa que possamos fazer?

Citação:

---

Postado originalmente por rubem

Desculpem a demora...

Bom, sobre isso de não conectar com o uso de MCS fixo, tenho visto isso também, não consegui isolar se é culpa de alguma versão do MK (ME PARECE ser mais comum nas 5.x em diante), ou de algum chipset.

Vamos a o que eu notei nuns casos:
Caso 1: Só conectava se eu deixasse modo A/N (Não somente N) mas com o datarate de 1M ativo. Suspeito que seja porque o preamble (SSID e cia) é transmitido no menor datarate possível.

Caso 2: Só conectava se deixasse também MCS0 e MCS8 ativo. Não sei se o preamble (Curto ou longo) nalguns casos usa o menor datarate do modo N (Pol. simples ou dupla), até onde eu saiba ele usa 1M ou 2M (Curto ou longo).

Caso 3: Só conectava com preamble curto (Equipto 802.11A mais velho (Com RTL8186, sim ele suporta 802.11a) talvez tenha isso). Na verdade foi esse caso que me fez testar os datarates baixos nos casos acima.

Caso 4: Equiptos Ubiquiti não conectavam com PPPoE, só em bridge (Enquanto MK, Intelbras ou Oiw conectava), enquanto com datarate auto tudo conectava. Mesma coisa, marquei A/N, datarates de 1M e 2M apenas, só 1 MCS, preamble longo, e voilá, resolvido o problema (Tá, não testei marcar só 1M ou só 2M, ou só preambulo curto).

Eu desconfio dessa questão do preambulo porque quando não há trafego NENHUM o datarate mesmo com datarate fixo, é exibido como 1M, 2M ou 6M as vezes, é o momento em que há apenas a troca de dados básico de conexão (Preâmbulos).

Mas... faz pouco tempo com MK 5.23 ou algo assim não teve jeito, tive que deixar no automático senão não conectava, com cartões R52HN em 5GHz, enquanto em 2,4GHz o MESMO cartão e RB aceitavam tranquilamente conexão configurado em somente N com só 1 MCS alto. É algo com 5GHz, com alguns cartões ou RB's, talvez só em algumas versões novas do MK, vou dar uma de astrólogo e dizer que seu dia pode ser de sorte e você se conectar à sua RB amada... ou não.

Preciso testar mais coisas, a princípio tudo o que tenho aqui conecta com só 1 datarate e só 1 MCS marcado, quero até testar SSID's com caracteres especiais porque onde tive problema ME PARECE que sempre tinha isso.

---