Olá Pessoal gostaria de saber se alguém sabe como eu acerto o mcs do mikrotik para que ele mantenha o CCQ mais proximo de -100% mantendo o radio com o sinal dentro do envelope determinado pelo radio???
Versão Imprimível
Olá Pessoal gostaria de saber se alguém sabe como eu acerto o mcs do mikrotik para que ele mantenha o CCQ mais proximo de -100% mantendo o radio com o sinal dentro do envelope determinado pelo radio???
MCS 0
mas... desculpe minha ignorancia rsrs. mas o que é precosi mara habilitar esta função?
normalmente no radio do cliente. :hmmmm2:
Entendo que se esta usando 802.11n , ele vai se ajustar automaticamente para obter o maior CCQ. Se trabalhar com a menor banda oferecida (alguns permitem 5mHz) com certeza estará na melhor condição para obter maior CCQ possivel. Será que estou equivocado?
se os 2 forem mikrotik tem sim
Mais qual o motivo de sair ajustando o MSC para obter melhor CCQ se o equipamento faz isso automaticamente da forma mais conveniente?
O problema não é cair em MCS0 se deixar no modo auto, se cair no MCS0 é porque o sinal está ruim. O problema é subir pra MCS5 ou 6 mas o troughput ficar ridículo.
Isso não ocorre só em modo N, você consegue conexão a 54M em G com sinal -65, mas vai ter troughput digamos 2Mbps, se baixar pra 18M no datarate a sensibilidade melhora, o nº de bits por simbolo diminui e tem menos perdas nas sub-portadoras, e o troughput sobe de 2 pra 12Mbps (Baixando o datarate, mudança que altera potencia e sensibilidade).
Se vai trafegar 2Mbps, pra quem usar MCS7? Esse MCS vai usar sempre todos os bits do simbolo, com muitos bits por simbolo a sensibilidade do hardware cai muuuuuuito (Vide ficha técnica dos aparelhos, a sensibilidade em MCS5 a 7 é péssima comparada em MCS0 ou 1), e o hardware e o software tem que processar todos os bits do simbolo pra "obter" os míseros 2Mbps. Porque não usar MCS0 nesse caso? Vai ter sensibilidade ótima, vai ter potencia maior, vai ter tempo de processamento menor, portanto as perdas de pacotes serão menores.
Eu testei MCS3 na torre, e nos clientes livre de MCS0 a 3, mas hoje penso em fixar nos cliente em MCS0. Porque? Porque em MCS0 cabe perfeitamente o upload do cliente e as respostas dos pacotes. MCS baixo no cliente tem vantagem? Tem, cria menos processamento pra torre. Tem desvantagem? Não permite upload alto, tipo não mais que 4Mbps. Quem aí vende conexão com mais de 4M de upload?
Você pode ter datarate diferente na torre e no cliente, quanto menor o datarate menor o trafego MAXIMO, mas também será menor o processamento, e em torre quando você quer muitos clientes num painel você tem que optar por modulações que exijam menos processamento. Usar por exemplo modo G pra PTP de 15M (Em 48-54M) é bobeira em hardware de hoje porque o processamento nesse modo é grande comparado a modo N em MCS3, que terá até mais que 15Mbps de troughput com tempos de respostas e perdas menores.
Largura de canal tem efeito menor ou similar a usar menos bits por simbolo, é mais interessante usar canal padrão (20MHz) com poucos bits por chip (MCS0 ou 1) do que usar gambiarra/despadronização tipo canal de 10MHz que terão muitos bits por simbolo igual, só terão menos sub-portadoras. Se há perda de subportadoras, independente de ter 20 ou 50 subportadoras, você perderá muito mais dados com 6 bits por símbolo (MCS7) do que com 1 bit por símbolo (MCS0). Onde o sinal não está bom você VAI perder subportadora, perder pacote grande piora mais o troughput do que perder pacote pequeno.
Mas o grande fator é:
MCS7 = Potencia baixa, sensibilidade ruim, varios clientes simultaneos usam mais processamento
MCS0 = Potencia alta, sensibilidade ótima, varios clientes simultaneos usam pouco processamento
Essa diferença altera alcance (Derivado da potencia e sensibilidade dos hardwares domesticos, e da sensibilidade em hardware de torre) e altera nº maximo de clientes por painel (MCS baixo exige menos processamento da etapa de RF, portanto permite mais clientes ou permite mais qualidade de conexão).
A um bom tempo já implementamos MCS fixo no cliente e na torre, além de fixar sinal mínimo de -69 na torre.
Não posso reclamar.
O que me confunde um pouco no MK é que quando vc usa o NV2 em 40mhz (estou usando ele num PTP com duas SXT lite 5) vc tem vários MCS vão do 0 ao 23, ai fico meio perdido...Citação:
Postado originalmente por rubem
Se eu tenho 25 clientes fixados MCS0 (6,5 Mbps) e meu upload liberado é de 2 Megas, se 3 clientes utilizarem todo seu upload eles ocupariam quase que 100% do rádio (0,3 segundos cada) ??? Como fica os outros 22 clientes iram ter uma navegação decente???
Aqui eu uso MCS10 (81 Mbps) em cliente empresarial :|
Os esquemas MCS mudam o tipo de modulação, e nº de bits por simbolo.Citação:
Postado originalmente por gabrielest
MCS0 a 7 é o basico, canal de 20 ou de 40MHz, 1 a 6 bits por chip, com 4 tipos de quadratura de modulação.
MCS8 a 15 é o mesmo nº de bits por simbolo que MCS0 a 7, mesmas modulações, mas usa MIMO, seja 2x1 ou 2X2
MCS16 a 23 usa o mesmo nº de bits por símbolo que MCS0 a 7, mesmas modulações, mas usa 3 conexões (TriTro?), 3x1, 3x2 ou 3x3.
A sensibilidade do MCS16 será igual ou muito proxima ao MCS8 e MCS0. O nº de bits por símbolo e o tipo de modulação (Tipo de quadratura escolhida) muda se repetindo a cada 7 esquemas, só aumenta o troughput porque aumenta o numero de canais (chains) fazendo multiplas conexões. Ou seja, MCS8 é um MCS0 x2, MCS16 é um MCS0 x3, e por aí vai.
Veja que o nº do esquema não quer dizer troughput, MCS16 tem 20 ou 40M de datarate (Afinal é só 1 bit por chip, mesmo que seja 3x1), enquanto MCS15 tem 130 ou 270M, mesmo que seja 2x2 o que faz a diferença é a modulação usada e o que mais muda na modulação que é nº de bits por chip.
É só olhar sempre a tabela:
http://mcsindex.com/
(O tempo de trafego de pacotes uteis de 400 ou 800nS muda POUCO a coisa, o que mais influencia é a largura do canal e a modulação. Aumentar largura de canal não é solução eficiente, porque polui o espectro, exige muito mais processamento em caso de PtMP, e não permite muitos AP's proximos porque simplesmente não tem canal disponível no mundo, então o negócio é evoluir os tipos de modulação)
O padrão 802.11AC tem modos com modulação em 256QAM, graças a ele a numeração dos MCS fica zoneada, não confundir MCS de 802.11AC com o MCS padrão. Ignore AC por enquanto.
Por isso você não pode vender conexão com upload de 2M e fixar na torre MCS0. Se tem media de 20 clientes consumindo, com trafego tipo 6-7M, melhor fixar em MCS1.Citação:
Postado originalmente por mkre0
Veja que MCS0 no cliente e MCS4 na torre é tranquilo, a codificação de um não obriga a do outro. Veja pelo seguinte lado: Torre em MCS4, vai mandar 4 bits por simbolo, e serão 16 simbolos porque são 16 fases de simbolo, isso popula mais o canal:
http://electronicdesign.com/site-fil...0956-fig-5.jpg
Mas você tem um throughput maior pra dividir entre os clientes, digamos 32-35Mbps.
MCS0 no cliente vai fazer CHEGAR na torre, ou melhor, no radio da torre, um monte de conexões com apenas 1 bit por símbolo, e apenas 2 simbolos, em 2 fases:
1ª figura, a de cima: http://electronicdesign.com/site-fil...0956-fig-4.jpg
São menos dados pra processar, então o processamento consumirá menos hardware, haverá menos perdas também no processamento mas o principal: São só 2 fases, ou nível alto ou nível baixo (0 ou 1, apenas 1 bit), a chance disso distorcer a ponto de perder muitos pacotes é pequena, o SNR necessario pra MCS0 é uns 5dB menor que o SNR necessario em MCS4, e o melhor, por estar ocupando pouco tempo de processamento a etapa de RF terá mesmo a maior sensibilidade possível, ou seja, poderia ter SNR menor que funcionaria, mas com certeza terá SNR maior!
Em modo N esquece esse negocio de "6,5M dividido por X clientes", não é bem por aí em qualquer modulação. Como o beamforming "pergunta" por qualidade de conexão ele gasta banda grande em MCS4 pra isso, ele "para" as comunicações por muito tempo útil, por isso em PtMP você não consegue grandes coisas com MIMO e canal de 40MHz, o tempo gasto sem trafegar pacote útil é grande (Quanto mais clientes, mais tempo), diferente de um PTP, em que datarate mais alto é mais eficiente afinal so tem 1 contraparte pra trocar dados.
O throughput em MCS0 vai ficar nuns 5Mbps, a estratégia de usar esse datarate baixo é impedir que 1 cliente tenha todo a banda de upload só pra ele, MCS baixo tende a equalizar as conexões, não que 1 cliente ruim derrube demais a qualidade dos demais apenas no upload, não tem como, mas o cliente ruim não deixa de poder usar uma parcela significativa do upload. SE fosse um MCS alto nos clientes, tipo MCS4, tem grandes chances dos clientes de melhor sinal ficarem com toda a banda de upload e não sobrar nada pra quem tem o sinal um pouco pior (Qualquer 5dB a mais de SNR, ou qualquer 20uS a mais no ack time, etc). Ou seja, clientes com MCS alto são tratados de forma desigual pela torre, a torre transmitindo a MCS4 atinge todos igualmente, troca pacotes igualmente da sua parte, mas tendo respostas mais lentas ela vai alocando cada vez menos banda pra quem responde lentamente, cria uma diferença abissal de troughput quando a diferença no sinal nem é tão grande. Usar MCS baixo no cliente freia esse comportamento, SE chegar no ponto em que o consumo de upload está alto é hora de colocar mais paineis, mas enquanto ele estiver dentro do suporte do modo (5-6Mbps pra MCS0, 11-12Mbps em MCS1, etc) você não vai ter desequalizações grandes.
Vejam que falo do consumo REAL e continuo de todo o upload por parte do cliente. Quem só tem consumo variável (Navegação) pode usar modo auto, mcs alto, pode usar mimo misturado com siso, que tudo vai funcionar, mas falo de ter a disposição da maioria dos clientes todo a banda contratada de forma contínua e com o mínimo de variação conforme outros clientes consomem a mais ou a menos (Caracteristica do modo N não é derrubar as conexões boas pelas ruins, mas sim tirar um pouco das boas pra garantir pras ruins, muito mais por conta do modo AUTO cair no MCS0, que tem uma modulação propícia pra alcance e estabilidade, do que por caracteristica de processamento (Software).
SE tem sinal suficiente, não há problema em usar MCS alto no cliente, mas SE não tem upload grande não há motivo pra exigir instalação melhor (Com mais sinal), SE MCS0 ou 1 com seus 5-10Mbps de throughput REAL por painel servem, recomendo que a usem, isso vai permitir mais clientes e clientes de sinal pior sem grande degradação das grandes bandas.
(É que instalação excelente em area urbana não é simples, 200% zona de fresnel afetada por reflexo não falta, alta tensão sempre está na altura dos telhados, mas o pior: Hardware barato pro cliente tem sinal pior, anteninha de 8 a 12dBi, com transmissão a 20-22dBm, enquanto na torre é normal ter 22-24dBm com antena de 17 a 21dB, ou seja, é uma conexão nativamente desigual, em alcance mais longo você sempre terá sinal cliente>torre muito pior que torre>cliente, e isso não é problema, o problema é com multiplas conexões, pra não haver atendimento desigual e um cliente ruim derrubar demais a qualidade geral você tem que equalizar os sinais cliente>torre, se equalizar eles com MCS0 em -70dB você podera simplesmente baixar a potencia nos clientes proximos, e manter os clientes distantes com hardware normal, digamos a 22dBm em 1500m com um NS Loco, enquanto o cliente proximo com NS Loco opera a apenas 16dBm, simples, equaliza o atendimento e equaliza o custo pros clientes (Que nunca estão distribuidos todos na mesma distancia, com os mesmos obstaculos, sempre varia).
MCS alto não é problema, o problema é sinal variando, em ambiente urbano uma hora tem -60, de noite sobe pra -66, um dia choque e dá -70, outro dia aparece -60 denovo... modo auto exige que o hardware prove os modos ou espere 3 perdas de pacotes até reduzir o modo, onde o sinal varia isso cria uma grande redução de troughput. Em PTP de longa distancia (Quilometros) você PODE ter sinal -70 e contar com míseros 18dB de SNR pra ter throughput alto, tipo 50Mpbs. Mas em ambiente urbano quem tem sinal -70 raramente está distante, o motivo do sinal baixo geralmente é obstrução física do sinal, é facil ter -70 em 300m com zona de fresnel muito obstruída, esse tipo de obstrução proxima causa muita perda de pacote de apenas algumas sub-portadoras, se a sub-portadora trafegar mais dados (Mais bits por símbolo) tem mais chance de ela ter distorção e um simbolo distorcido exigir retransmissão do pacote todo, o fator que distorceu um conjunto de 4 bits dum simbolo dos 64 existentes (MCS6 ou 7) dificilmente iria distorcer o símbolo de 1 bit do MCS0. Seria perfeito ter MCS0 também na torre, mas aí teria muito pouco trhoughput pra dividir entre os clientes, recomendo usar o MCS mais baixo que atenda a banda necessaria (Se for menos de 4Mbps pode até usar modo B :-) pra aproveitar essas perdas reduzidas, mas a torre envia pacotes pra muito aparelho, o aparelho do cliente só recebe sinal da torre, ele geralmente está em espera, com sensibilidade alta, e pode pegar um sinal ruim da torre. A torre ouve muito aparelho, ela não estará sempre esperando na maior sensibilidade possível o cliente, por isso se o cliente mandar sinal mais legível (MCS0 e seu bit por simbolo, com 2 simbolos apenas) tem muuuuuito menos chance de a torre não entender o sinal (Sinal chega na antena, vai pro mixer que mistura oscilação local de sub-banda, vai pro LPF, aí é convertido em digital (Pacote digital é uma coisa, mas antena recebe e envia pelos cabos sinal bruto, tensão pura, o mixer mistura tudo como se analógico fosse), pra DEPOIS o processamento separar o que é útil (Cliente devido enviou) de inútil (Ruído, cliente mandou pacote na hora errada (Ignorou RTS e CTS), esse processamento é que é afetado por 4 bits distorcidos num dos 64 símbolos do MCS4, se a torre tiver 20 clientes transmitindo em MCS4 ela terá umas 6x mais dados pra processar que se eles transmitirem em MCS0. Mas SE há sinal suficiente pra não ter essas perdas, e o painel não está cheio, pode usar MCS alto, só não vai poder colocar tanto cliente de sinal um pouco pior (5 ou 6dB a menos, 20uS a menos no ack), ou seja, vai ter que caprichar muito mais nas instalações, e negar atendimento a muito mais clientes em que instalação meia-boca é impossível.
vlw professor @rubem
então é mas viável fixar o mcs no cliente, e no caso de um cascateamento?
supondo
torre>stx>5 cliente conectados por switch, cada cliente com 4mbs, como ficaria o MCS?
Rubens,
Parabéns, novamente mais uma aula, devo dizer-te que foi muito útil e ajudou e preencher algumas lacunas que eu tinha, mas deixa eu resumir pra ver se entendi bem:
Pelo que entendi são 8 tipos de MCS para cada tipo de operção:
- Siso: do 0 ao 7:
- Mimo 2x2 ou 2x1: do 8 ao 15;
- Mimo 3x3, 3x2 ou 3x1: do 16 ao 23.
1- Em linha geral dentro, de cada tipo de operação, quanto mais alto o MCS maior o troughput em banda correto?
2 - Um caso atipico, mas que acredito que tenha gente que usa assim veja, o MK permite que eu tenha um MIMO na transmissão (torre) e um siso na recepção (cliente). Se, por exemplo eu estiver fazendo uma transmissão numa SXT5 Lv4 em MCS 16 em 20Mhz me dá um troughtput de 21mb, o cliente pode usar uma groove (por exemplo) com MCS0 em 20Mhz correto?
3 - Uma coisa que não consegui entender foi como fica com o NV2??
4 - Outra pergunta, a única variável que influencia no ajuste do MCS é a quantidade de banda que se quer usar?? acredito que não, parece-me que a qualidade do sinal (que deriva da visada limpa e zona de freznell ok) também influencia né?
Em caso de cascateamento a última etapa de RF, seja em bridge ou em roteamento, é o que conta, ela que é responsavel pela maior deterioração da qualidade da conexão.
(Bridge ou roteamento, o que atrapalha é sinal ruim pro modo escolhido, desde que o gargalo não seja o resto da rede (Exemplo: PtMP de 20M, PTP de 2M, obvio que o PTP vai ser o gargalo, mas isso é raro)
E o pensamento com MCS é esse mesmo, 1x1 de 0 a 7, 2x2 ou 2x1 de 8 a 15 e etc Em geral quanto maior o MCS mais a banda DESDE QUE com o mesmo numero de chains. MCS8 vai ser MENOS que MCS7, porque tem modulação diferente e nº de chains diferente, então nem sempre MCS maior terá banda maior.
Conexão 2x1 (2T na torre, 1R no cliente) é tranquila pra PtMP, o processamento pro RX da torre não é grande, se tiver 2T em 2 polaridades diferentes não há muito lucro porque a antena do cliente (1R, 1 receptor, em 1 polaridade) vai receber o sinal na polaridade nativa 30dB mais alto que na polaridade errada, e não há HOJE muitas opções de setoriais 2T de mesma polaridade, o que há muito é H+V, mas se a antena do cliente estiver apenas em H ou apenas em V não há lucro nenhum nisso, vai ser um 1,01x1, e não um 2x1 (Porque será um 1x1 mais 0,1x1, ou seja, a antena na polarização errada te dará 10% da qualidade de conexão). Cuidado com 2x1, a polarização das 3 antenas (2 de transmissão, 1 de recepção) precisa ser a mesma pra OTIMIZAR a coisa.
NV2 e airMAX, taí coisa que só sei o basico do basico, são modulações diferentes então tem POTENCIAL* pra ter desempenho 100% diferente.
(*POTENCIAL = O Rubem não sabe bem o tipo de modulação usada, sei que NV2 é TMDA, mas IMAGINO que tenha outra diferenças fundamentais, nunca me preocupei porque não quero e não vou me acorrentar a apenas 1 fabricante, os padrão IEEE (802.11N, por exemplo) independem de fabricante)
MCS faz variar a banda utilizavel por conta da modulação, mas a população/povoamento dos canais e/ou portadoras altera o alcance e a estabilidade, aí é que está o que defendo: MCS mais baixo tende a ter alcance e estabilidade maiores, se não vai passar banda grande num PtMP não tem motivo pra escolher datarate maior, já que datarate maior significa em linhas gerais menos alcance e menos estabilidade.
Ok,
Obrigado, mas quanto a questão sobre o MCS com operações diferentes ficou-me um pouco vago veja:
- se eu tiver 2 sxt eu tenho que trabalhar com os mcs dos modos 2x2 e 3x3, ou seja, do 8 ao 23 (dependendo do que eu queira fazer com o datarate);
- se eu tiver uma sxt e uma groove (ou um aparelho siso), a sxt eu seto no MCS que eu quiser do 8 ao 23 mas o groove só vou poder setar do 0 ao 7 pq ele é ciso correto??
- Me explica melhor a questão da interação do MIMO 3x1 com o siso 1x1?
Segundo a explanação o MCS que é fixado no AP pode ser diferente do Cliente? Entendo que o modo MCS fixado no AP será a que CADA cliente vai utilizar para se comunicar. Entao , independentemente do MCS que é fixado no Cliente, quem manda e o MCS do cliente, fixado no AP.
Quando você configura um roteador para usar MCS8, ele vai usar 2 streams de 6,5M pra transmitir, se a contraparte da conexão vai usar 1, 2 ou 3 streams pra transmitir de volta isso só influenciará no troughput final, não na conexão "basica" entre eles.
Ou seja, você define aqui nesse roteador como ele irá transmitir (1 canal, 2 canais, etc), se a contraparte da conexão vai transmitir do mesmo jeito, ou se vai usar outro data-rate, isso você não configura aqui, tem que ir lá na contraparte configurar isso.
SXT só tem 2T2R, certo? (Se tem um 3T3R tô por fora) Se ele for o AP da conexão você pode configurar no MCS8 que ele irá mandar sempre 2 streams de dados pra começar a negociação, se o outro SXT estiver com 1 antena desligada/removida, a comunicação será 2X1. Se nesse 2º SXT você selecionar MCS0, mesmo ele tendo 2 antenas ele irá usar os switches da saída de RF pra fazer diversidade, serão 2 antenas num único chain. Isso é o que a maioria dos hardwares com antena de "dupla polaridade" tem feito, eles não tem MIMO mas tem 2 antenas em polaridades diferentes, com um switch que define qual polaridade irá usar ou se usará as 2, a cada pacote praticamente.
Num SXT em MCS8, se ele se comunicar APENAS com uma CPE de antena de polarização única, é bem possível que esse SXT deixe de usar 2 chains depois de algumas perdas de pacotes enviados na polarização que a CPE não capta direito (São geralmente 25-30dB a menos na polarização "errada"), num PTP essas perdas de pacotes contam muito, mas é questão de segundos ou minutos até as partes do PTP verem que polarização e chain tem respostas mais rapidas ou menos perdas, o software não é burro, ele faz esse tipo de escolha (Por isso digo que liberar a capacidade de processamento é importante).
Num PtMP algumas estações responderão melhor na pol. H, outras na V, mas o importante é: Você tem 2 chains trocando dados, a parte de mixer e encoder/decoder é importante na etapa de RF (Então quanto mais etapas de RF, melhor), se tiver muito pacote de níveis diferentes (De muitos clientes) tem distorção no ADC (Analog to digital converter) ou no decoder. Por isso usar hardware com 1 chain mas com antena de dupla polarização é importante, a maioria das CPE's tem isso hoje, porque isso melhora muuuuuito a conexão pro lado da torre (Que tem 1 etapa de RF em cada polarização).
MCS8 só vai se comunicar direito com CPE's com antena de dupla polarização com switch, se a CPE tiver antena de polarização única a torre vai se comunicar com essa CPE em MCS0, não em MCS8, não por limitação do 802.11N, mas porque a antena de polarização "errada" nunca terá resposta, CPE V não captará sinal H com intensidade suficiente pra responder, todos os pacotes na H serão perdidos e a torre vai perceber isso e passar a ignorar a possibilidade de uso dessa polarização (O software é inteligente). Em PtMP não é bom ter essa mistura de H aqui, V alí, isso exige mais processamento da torre, mas usando CPE V+H não há problema, a torre escolherá a polarização que melhor lhe atende sem gastar tanto processamento, mas usará as 2 polarizações pra transmitir, ou seja, dividirá os dados por 2 encoders, por 2 mixes, porque serão 2 etapas de RF (E por receber nas 2 polarizações a CPE vai mandar ora por uma e ora por outra conforme a torre responder, porque atenuação de sinal varia conforme inclusive polarização (Algo atenua a V mas não a H, e vice-versa).
Blz Rubens,
Novamente obrigado
Hummm deixa eu ver se entendi então no caso dos UBNT usar airgrid e nanoloco em clientes e usar rocket na torre e uma combinação ruim visto que forca o processamento no radio da torre.
O ideal era deixar tudo 2*2 ou seja rocket com nanosloco.
Se quiser ter um bom arranjo como já uso nanoloco e airgrid nos clientes e baixar o MCs na torre também !.
Falei alguma bobagem ou e isso mesmo ?
NS Loco com sua polarização dupla em teoria "pesaria" menos no processamento, já que sempre vai se adaptar pra polarização de melhor sinal na transmissão, mas... é uma anteninha tão ridícula de 13dBi, com 20dB de isolamento entre polarização, que faz pouca diferença comparado a um airGrid de polarização simples, que tem 22dBm de isolamento entre polarização, mas tem antena de ganho muito maior (Ou seja, num mesmo cliente ele vai receber o sinal V ok, mas o H vai estar uns 22dBm abaixo, e os 10dBi a mais de ganho dum airGrid M5 23 comparado com NS Loco 13dBi, darão algo acima dos 22dBm na polarização errada).
Tanto NSLoco como airGrid não são uma maravilha no 2x1, o NS Loco seria menos pior desde que proximo da torre (O que é meio impossível no mundo real) e com sinal bom em ambas as polarizações (O que também não é tão comum). Se tiver CCQ excelente em ambas as polarizações, NS Loco vai ser perfeito. Com CCQ meia boca, tanto faz, o gargalo deixa de ser o processamento da torre.
Mas como todo mundo mistura NS, NS Loco, airGrid, nanoBridge, usar 2x1 economizaria processamento na conexão com NS, NsLoco e nanobridge, e gastaria um pouco a mais nos airGrid, acho que ainda é lucro.
Mas veja que estamos falando de perda de processamento significativa com 30 clientes conectados e navegando, quem tem 10 conectados num Rocket, com conexão tipo 1-5Mbps, não tem diferença preocupante.
Com 30 simultaneos, se metade por airGrid, ao escolher MCS10, de 40M, essas conexões vão a longo prazo se adaptando pra fazer apenas 1x1, na prática elas vão se limitar a 20M, A outra metade, com NS, NSLoco e NanoBridge vai conseguir usar 2x1 mesmo, vai poder chegar nos quase 40M do datarate. SE esses airGrid precisam somados mais que 20M, é bom passar pra MCS11 ou 12, tem que escolher o datarate 2x que atenda as CPE's single-polarization com a banda que elas precisam (MCS10 equivale a MCS2, MCS11 a MCS3, etc).
Alias, usar coisa como NS na torre também tem essa vantagem de se adaptar a polarização de melhor sinal, mas desde que esteja usando NS/NSLoco/nanoBridge/SXT ou CPE de dupla polarização nos clientes. Pra grandes bandas essa feature é fantástica, mas pra banda pequena e sinal "ruim" (O normal de se ver em 802.11B, CCQ de 80-90%) isso consome mais processamento que devia, pra banda pequena de qualquer forma serve, mas pra banda grande TEM QUE ter CCQ perfeito em todos os clientes, pra não haver gasto de processamento exagerado pra uns e isso derrubar o throughput pros outros.
(Ah sim, Rocket M em antena de dupla polarização, se configurado pra MCS0-7, também faz autoadaptação de polaridade. Mas se tiver apenas airGrid isso é um tiro no pé, ela vai gastar processamento com sinal na horizontal, sendo que ninguém responderá nessa polarização. São pacotes probatórios, são poucos por conexão, mas em 30 conectados a soma consome processamento que derruba trhoughput)
Um pergunta pertinente e se fossem apenas 10 clientes digamos todos airgrid com rocket na torre .
Mas 10 clientes consumindo 10 MB sem parar ao mesmo tempo a AP rocket iria abrir o bico ?
Seriam 100MB, teria que ser MCS6 ou 7 com canal de 40MHz. Aguentar aguenta, isso não é problema.
O problema é: "Vou usar MCS12, que tem datarate de 162M, deve dar". Não vai dar, porque uma da polarizações vai ser inútil (Exceto talvez se o sinal for muuuuuito bom, tipo 50dBm de SNR), com apenas 1 polarização funcional o MCS12 vai ser um MCS4, de 80M. Precisaria então MCS13 ou 14, mas se vai ter apenas airGrid não vale a pena pagar por multipla polarização se não vai usar, não tem lucro em usar isso se não tiver algo similar nos clientes, tem é um leve prejuízo de processamento (V+H > H).
Já SE você usar airGrid conectado numa torre com 2 ou 3 setoriais V afastadas o suficiente, fazendo 2x1 ou 3x1 na mesma polarização, tanto a teoria como alguns experimentos mostram que você tem MAIS banda do que num sistema V+H de antenas proximas (No mesmo refletor). Aí que entram os Wavion e outros sistemas multi-omni que prometem banda alta, autoadaptative é excelente, permite througput excelente, mas as antenas precisam ficar distantes ou precisam baixa potencia, e com baixa potencia automaticamente o alcance diminui. Imagino que 2 setoriais V a 2m uma da outra já fariam um belo trafego a mais pros airGrid que V+H juntos (NS, BaseStation) rumo a NS Loco e cia, metade pela distancia entre irradiantes e metade pelo ganho maior dos airGrid.
bela discussão esse post...muito bacana...da prazer de ler....
Graças e esse post e outros fechei um PTP com 2 SXTLite5 em 1.8km, assim;
- Nstream
-5300mhz
Sinal: -50/-50
Potencia: 22dbm (elas chegam a 27)
Teste de banda fechando 90mb full (isso pq setei no Nstream) em NV2 + NStream passo 120full no teste de banda.
Shou mesmo
O que eu aprendi já estou testando o ruben e show sussesso.
Mas é bom vocês lerem por conta propria outros conteúdos sobre o assunto, porque tem pouco conteúdo sobre isso.
Quando um padrão é lançado o pessoal do marketing usando tanto o "Até 150M" ou "Até 3,2Gbps" que acaba tendo pouca informação técnica, divulgam um resumão sobre as novidades no maior datarate do padrão mas esquecem de falar sobre modulações intermediarias, sobre subportadoras em canais mais estreitos ou mais largos que o padrão, sobre comportamento das modulação fazendo mimo com polarização dupla...
Muito do conteúdo encontrável é sobre roteadorzinho domestico Linksys com 2 ou 3 antenas na vertical, com um notebook qualquer conectado, ignoram o fato de notebook ter 2 ou 3 antenas em polarizações diferentes, ignoram a recomendação que as vezes a propria linksys (Só pra seguir o exemplo) dá de colocar uma ou 2 das antenas a 45°, falam sobre beamforming e autoadaptação mas com apenas 1 micro conectado (Quem compra roteador Linksys de R$ 500 e usa apenas 1 dispositivo móvel nele?).
Enfim... tem muito conteúdo academico sobre isso, tem que ler 10 pdf's academicos pra extrair 2 ou 3 informações práticas. E as vezes se baseiam em featura específica de algum chipset que a gente (Ou o proprio autor) generaliza pro protocolo todo.
(Mas talvez se comprar os textos da IEEE facilite... no cadastro gratis não tem nada útil)
Nobre amigo, boa tarde!Citação:
Postado originalmente por rubem
Tendo sua experiência no assunto e lembrando que sou novato na área, gostaria se possível que você pudessem fazer um análise nessa tela em anexo e se possível me orientar.
Obrigado.
Dá uma olha em baixo, no nível de sinal e no datarate dos 2 aparelhos conectados.Citação:
Postado originalmente por Jhonvalter
Sinal -77 e ruído a -92 são ridículos 15dB de SNR, devia ter 25!
O outro tem sinal -71, são 21dB de SNR, EM TEORIA seria suficiente pra um MCS14 sem problemas. E... está mesmo em MCS14. Mas... na prática use SNR 20 ou 21 apenas em MCS0 a 3, 8 a 11 9. Acima disso é bom ter uns 25dB de SNR pra ter estabilidade (CCQ tipo 99% em MCS14. Afinal não adianta ter CCQ 85% em MCS14, vai perder pacote legítivo, o datarate teórico será maior que 99,9% de CCQ em MCS12, mas CCQ menor significa menos perdas de pacotes, o throughput você vê de cara pelo CCQ, não pelo datarate).
Pra mim você tem o classico problema do modo AUTO com sinal variando conforme o cliente, o airMAX está com capacidade péssima porque o sinal está ruim, e o throughput real deve estar ruim porque no modo auto e com 2 "clientes" o datarate variando faz muito "teste" de datarates e pacotes (Procura sempre o melhor datarate possível).
Enfim, com esse SNR acho que só terá estabilidade se fixar em MCS9 ou 10. Se quiser mais banda nos 2, vai ter que melhorar o sinal desse "UBNT", pra uns -71. Enfim, tem que equalizar os sinais, e com SNR pelo menos nos 20-22dBm.
Alias, -71 não é um sinal ruim, seu ruído é que está meio alto pro meu gosto. Se for Querencia - MT devia ser -104, se for Primavera do Leste - MT imagino que uns -97, se tem esse -92 não tem outro radio muito proximo? Ou o sinal não passa sobre rede de alta tensão? (10m pra cima de rede de 2,3KV ou mais é um problemão) Acho meio estranho esse ruído todo no interior de MT. Mas enfim, se o ruído está alto mesmo, o jeito é melhorar o sinal pra ter SNR maior, ou fixar num MCS menor pra ter sensibilidade maior.
EU só usaria airmax com SNR tipo 25dBm, e só o manteria ativo se a capacidade dele no setup fosse maior que 60%. Porque ví muuuuita perda de pacotes com sinais piores que isso, 22dB se SNR dá pra 60-70Mbps de throughput com MCS12 (400nS pelo que lembro), mas ao ativar airMAX a capacidade ficava sempre nos 50%, e o throughput baixava 10-15Mbps.
Se tiver 30dBm de SNR é claro que airMax vai fazer a banda aumentar muito, mas TODOS tem que ter esse SNR.
Equalização. -71 e -77 num provedor não é problema, vender pacote de 1 a 5M de internet com modo auto e esses sinal está ok, mas se é PTP tem que fixar o MCS pra ter estabilidade, e fazer das tripas coração pra ter SNR acima de 25dBm.
(Cuida que se baixar o MCS o SNR automaticamente sobe em metade dos casos, tipo: MCS14: 15dBm de SNR. MCS10: 21dBm de SNR. Wow... etapa de RF em MCS menor tem uns dBm a mais de potencia, e uns dBm a mais de sensibilidade.
Obrigado meu amigo Rubem pelas preciosas informações. Esse equipamento é uma base station que no momento ta com 3 clientes pendurados. Essa região não é mato grosso e sim RS, acredito que seja algo como refração pra ta tando ruido assim em um desses clientes já que essa é uma região de muito telhado de zinco. Vou ver o que posso fazer. Abração.Citação:
Postado originalmente por rubem
Pelo pouco que tentei brigar com telhados de zinco / aluminio, eles não "produzem" um nível de ruído maior, só fazem o CCQ diminuir muuuuuito.
Quem afeta muito o nível de ruído, e passa desapercebido, é rede de alta tensão. HOJE considero ideal ter 200% da zona de fresnel livre de linha de alta tensão, porque já sofri com linha de 13KV a pouco mais de 100% da zona e o desempenho era péssimo por mais que mechesse.
(Veja o detalhe: Não é rede longe da antena, mas sim longe da zona de fresnel! Não dá pra evitar esse obstaculo as vezes, mas é bom pelo menos saber o que está atrapalhando. Se tem rede AT na zona de fresnel: A culpa é dela, não da sua configuração ou do equipamento. Dá pra minimizar o problema, mas nunca soube como resolver efetivamente (Sem ser fibra ou FSO))
Olha eu novamente meu amigo Rubem. Veja essa tela, mu TX fica oscilando entre 52 e 117. Em que isso pode prejudicar meu enlace? Grato.Anexo 54822
O que está oscilando é o data rate, não necessariamente o throughput passante está variando.
Data rate muda quase toda hora quando você usa o modo AUTO, eu sempre defendo que isso gasta processamento a toa, e perde pacotes a toa (Pra descar um mcs tem que ter um certo nº de perdas de pacotes), por isso insisto no uso de MCS fixo, escolhe um data rate suficiente e fixa nele. Um data rate "suficiente" e não "o maior data rate possível" porque em datarates menores GERALMENTE tem respostas mais rapidas. Digo, você pode ter 80Mbps de throughput em MCS12 mas com ping variando de 10 a 40mS, acho isso péssimo, baixando pra MCS11 o throughput cai pra 45Mbps mas a tem ping de 1-2mS. Ping é referencia? Mais ou menos, lembra de dar ping ou fazer teste de velocidade com pacotes pequenos e grandes, a maior parte dos seus cliente vai trafegar pacotes grandes (1450 a 1472 bytes) então ter resposta grandes justo neles (Tipo 40mS) dá uma sensação de ruim de navegação.
No seu caso pelo visto está com tempo de guarda de 400ns, afinal tem 52 e 117M de datarate (MCS10 e 14 se não me engano) isso indica 400nS de GI. Se quer aumentar o throughput e tem sinal (Tem mais de 30dB de SNR) o jeito que não piora nada é aumentar o GI pra 800nS.
Mas não ligue pra datarate variando, isso indica que o sinal não está completamente estável, mas com noise floor tão alto tipo -91 deve ter muito equipamento 5GHz por perto (Não necessariamente no mesmo canal). Testa canal mais alto, lá pelo 5750MHz pra cima, pra ver se a antena não tem ganho melhor, ou VSWR melhor, nessa frequencia mais alta (As vezes tem diferença de 2dB no ganho ao subir ou descer 60MHz).
Se não quer variação nenhuma é só fixar a velocidade, desativa o auto, mas veja que a transmissão no modo auto está sendo feita em MCS10, que é o datarate de 52M, ou seja, é o modo que os aparelhos "definiriam" via testes ser o de maior velocidade conseguível, então pra ter estabilidade talvez você precise fixar no MCS abaixo (MCS9) e aumentar o GI pra 800nS (Não lembro o local exato no setup de AirOS, não tenho nenhum agora pra olhar e ver o nome exato, tempo de guarda, guard interval, gi, qualquer coisa com opção 400 e 800nS é isso, talvez 0,4 / 0,8mS)). Enfim, o sinal dessa estação do print pra outra não está ótimo, por isso no modo auto fica em 52M (MCS9 ou 10, não lembro), talvez esteja bom pro throughput que você precisa, mas o sinal da outra estação rumo a essa do print está muuuuito melhor, por isso está em MCS14 de 117M. Talvez uma antena seja diferente da outra, e trocando canal (Mudando 100MHz ou mais) chegue num canal onde ambas as antenas tem ganho similar e ficam com datarate mais parecido no RX e TX.
Parabéns pelo tópico, tenho o PTP RB 912 modulando em MCS 12, normalmente passa 85Mbps, mas derrepente cai para 50Mbps.
Segue print para avaliar. Qual seria melhor solução para passar 100mbps, consigo isso só manipulando MCS?
Esse HT-40 2S SGI indica que está usando short guard interval, ou seja, já está no limite do MCS12.
Pra mais banda passante vai precisar passar pra MCS13, mas seria bom mudar pra intervalo de guard longo ("HT Guard intervall" em long na aba HT), porque parece que não tem zona de fresnel tão limpa (Senão o CCQ seria maior com esse nível de sinal).
MCS-13 GI longo é o datarate de 216Mbps. DEVIA dar mais de 100Mbps se a zona de fresnel estiver ok.
Ou a distancia é grande? Se for, melhor pensar em antena maior.
Antena de maior ganho não afeta a potencia de emissão, obdecendo o limite EIRP de 36dBm dá pra ir longe. Mas antena grande melhora o nível do sinal RECEBIDO, uma antena de 14dBi recebe um sinal digamos a -74, já uma antena de 28dBi nesse mesmo local vai receber esse sinal em -50 mais ou menos. -74 é suficiente pra um MCS10 talvez. -50 é suficiente até pra MCS15. Diferença enorme na banda passante.
Nessa mesma aba HT tem o HT AMPDU, marcando os 7 você DEVIA ter mais throughput pois vai haver mais agregação de frames, mas isso gera um pequeno delay a mais, então seria bom testar ack-timeout fixo e maior que o real, acho que uns 30 a 40% maior que o correto, pra dar tempo de "desagregar" os frames agregados no outro lado.
(E aqui é o único ponto em que o setup da UBNT me agrada mais que MK, na aba advanced você marca agregação de até 32 frames, e seleciona tamanho, o default acho que é 50KB, mas pode ir (Se não me engano) até 65535 (E 32 vezes 1500 bytes (Limite no MTU) dá só 48KB, então o default de 50KB tá ótimo). Num PTP distante onde perder 4ms não é problema desde que o throughput sejá bom e o jitter seja zero isso é ótimo. Não é a toa que tanta gente elogiava Rocket M5 em PTP, uma configuraçãozinha boba tipo a agregação de frames faz muita diferença no throughput)
Alias, falando em agregação, se tem MK nos 2 lados teste NV2, ele agrega com mais versatilidade, o throughput costuma ser maior com o mesmo sinal.
(Já se realmente tiver a zona de fresnel meio suja ele pode piorar a coisa, afinal frame agregado significa as vezes metade de uma conexão aqui e metade alí, se metade é perdida ele tem que armazenas mais conteúdo em cache até que o pacote perdido seja reenviado, aí ao invez de demorar 4ms ele demora 12ms (Chega ilegível em 4ms, volta o aviso de ilegibilidade em 8ms, é enviado denovo em 12ms), conforme a qualidade do link pode piorar muito mais que um simples ping ruim. Mas tem que testar)
Tem algo errado ai, com msc 12 consigo algo proximo de 110mb. Se estiver usando nstreme mude para nv2
Caro Rubem obrigados pela respostas.
1 - A Zona de fresnel esta limpa
Anexo 58606
2 - A distância é 38km
3 - São duas RB912 e Antenas Xwave 5831DPR
Então as configurações ficou MCS fixo no AP e Defalt na estação, estou usando NV2 com TDMA Period Size: auto Cell Radius: 38KM, frequency=5425, ampdu-priorities=0,1,2,3,4,5,6,7,band=5ghz-onlyn
ht-basic-mcs=mcs-10,mcs-11,mcs-12 \ ht-supported-mcs=mcs-10,mcs-11,mcs-12.
A pergunta é seguinte tem alguma configuração para fazer no MK para que diminuísse o throughput do RX visto que nesse enlace não usamos velocidades full duplex para que passasse somente uns 30% de Upload e que não degradasse o enlace, ou isso não ajudaria em nada.
Anexo 58607
Está passando quase 100Mbps no horário de pico, mas como da para ver gráfico nessas crista enlace continua instável, esta passando 80Mbps e derrepente cai para 50Mbps, leva um tempo volta normal.
deixe marcado apenas mc12 e teste, ja conferiu em outro canal?
Ja vi muita gente relatando que acima de 70mb ela começa a abrir as perna. Voce poderia testar um apc 5m pessoal costuma comentar que só nao passa mais de 100mb por causa da porta /100
E quanto a isso de ter RX menor, é só marcar HT MCS menor no outro lado.
O lado A pode transmitir com MCS12, e o lado B com MCS10, sem problemas. Vai ter no lado A TX/RX de 78M/39M no ponto A, e 39M/78M no ponto B.
Nas RB's recentes a Mikrotik não divulga mais a sensibilidade de CADA datarate, só de MCS0 e MCS7 (Que dá na mesma que MCS8 e MCS15), mas pelos numeros nessas 2 sensibilidades a gente tem idéia do resto. Em MCS12 a sensibilidade com canal de 20MHz deve ser cerca de -86dBm, então o sinal pra ter CCQ no máximo devia ser -66dBm até uns 10Km, e em 38Km eu diria que precisa 30dBm acima da sensibilidade, ou seja, -56dBm de sinal pra ter CCQ no máximo.
O último print mostra sinal em -62 ou -63, isso é sinal suficiente pra MCS10 nessa distancia (Se a intenção é CCQ maximo).
Quanto maior a distancia maior a margem de sinal entre sensibilidade e o sinal de RX, 38Km exige uns 30dBm de margem, isso é sinal pra caramba.
(Em 3Km pode ter só 12 ou 13dBm de margem que terá CCQ em 100%, em 10Km pula pra uns 20dBm de margem, e partir dos 25Km precisa 30dBm de margem, porque a perda por poeira e agua em distancia grande é maior, tem o "thermal fadding")
ACHO que com RB912 e antena de 31dB mandar sinal suficiente pra MCS12 vai ter que colocar a potencia em 24dBm, que é o máximo se não me engano. Com essa potencia deverá ter sinal em -55 no outro lado, suficiente com folga pra 100% de CCQ em MCS12.
(E o outro lado transmitindo em MCS10, com potencia também bem alta, tipo 22dBm)
(Baseio minha conta na perda de 140dB de sinal em 40Km. Radio a 24dBm + antena de 31dBi = 55dBm EIRP, 55 menos 140dBm de perda dá -85, com 31dBi de ganho da antena dá -85 + 31 = -54dBm de sinal chegando no outro radio. Com relação a sensibilidade de uns -86 isso dá 32dB de margem, excelente pros faddings no caminho tipo poeira, chuva, nuvens)
Consegui resolver o problema desse enlace, estava usando inicialmente antenas de 31dBi +RB912, dai optamos em trocar radio para ganhar mais nos sinal, trocamos para RB922 sinal foi para -55dBm mas na resolveu só ficava estável no MCS11 que passava em torno de 65Mbps, resolvemos trocar antena 34dBi da Ubiquiti+RB912, sinal caiu pra -43dBm com isso esta passando uns 130Mbps.
Caro @rubem, aproveitando da sua boa vontade, me tire uma dúvida, nas minhas torres tenho 4 painéis com RB912, os clientes dos painéis são em sua maioria SXT mas tenho algumas Nano Loco e AirGrids, nenhum cliente tem plano acima de 5Mb de download e 1.5Mb de upload. Eu deveria deixar o MCS automático nas RBs e configurar MCS fixo nos clientes? Se eu configurar MCS4 numa RB por exemplo, eu não conseguiria fornecer mais do que 40Mb de link para os clientes conectados nessa RB?
Mas você está usando polarização simples?
MCS4 é datarate de polarização simples, é o 16QAM de maior datarate, em 20MHz ele tem 39M nominal, na prática dá pra uns 20Mbps.
Aí entra a vantagem de dupla-polarização, quando coloca 2 chains fazendo MIMO, o mesmo 16QAM equivalente a MCS4 é o MCS12, cujo datarate em 20MHz é de 78M, que dá 40Mbps ao todo.
O problema de misturar polarização dupla com simples é desperdiçar capacidade do radio, o AP tem capacidade pra X troca de dados por segundo, se tiver uma duzia de clientes com Airgrid em pol. simples e MCS4 você vai gastar com eles o mesmo tempo que gastaria com uma duzia de clientes com pol. dupla (SXT, NS, NB, etc), mas em pol. dupla usando datarate maior passaria mais tráfego em menos tempo. E AP eficiente é o que tem duzias de clientes conectados.
O MCS automatico é lindo quando funciona, o problema é que o software é burro de OPTAR por datarates grandes quando NÃO HÁ sinal suficiente. Por exemplo, o cliente recebe sinal -70dBm da torre, o softwarte é burro o suficiente pra trocar dados usando MCS15, cuja sensibilidade é -78dBm, e portanto há entre sensibilidade e sinal uma margem de ridículos 8dBm. Em ambiente muito limpo essa margem até é suficiente pra banda grande, mas... se olhar o CCQ não verá ele grande. CCQ longe de 100% indica perdas de pacotes, indica que o radio está mandando digamos 10 pacotes em MCS15, e está tendo que repetir 2 porque o AP não entendeu, isso gera CCQ tipo 90%, mas o pior, esse reenvio de 2 pacotes tomou tempo que poderia estar sendo gasto com outros clientes (Aí é a situação que 1 cliente com CCQ ruim atrapalha toda a rede).
Quando todos os clientes tem mais de 100% da zona de fresnel limpa, ou quando usam uma banda muuuuuuito menor que os datarates (512Kbps com MCS15, por exemplo), aí o modo automatico opera bem, pra um datarate nominado como 135M (MCS15 em 20M) pode ter 90% de perdas que ele ainda vai conseguir levar 512Kbps sem problemas. O problema seria: O AP suportaria 40 clientes com 98-99% de CCQ, transferindo pra cada pelo menos 1Mbps. Já com CCQ de 80-90% ele mal suporta 30, e vai transferir pra cada menos de 500Kbps.
O problema do modo automático é que ele não aumenta só o datarate do cliente próximo que está com sinal -60dBm (18dBm de margem com relação a sensibilidade de -78 em MCS15), o problema é que ele COSTUMA aumentar o datarate de quem está longe, ou de quem tem sinal baixo por culpa de zona de fresnel parcial.
Bom mesmo seria um firmware onde você pudesse definir datarare por cliente, ou por nível de sinal, aí sim teriamos rendimento excelente.
Curioso que você encontra muita gente recomendando 20dBm de margem, exemplo:
https://community.ubnt.com/t5/Wirele.../464429#M35664
Em material oficial da UBNT também já ví a RECOMENDAÇÃO de 20dBm de margem. Mas... a desgraça do modo automático seleciona o datarate levando em consideração uma margem de apenas 6dBm! Nunca consegui 100% de CCQ nem com 10dBm de margem, pra mim que o mínimo é 12dBm, mas a meta é mais de 20dBm (E o modo automatico ignora isso)
Se não for olhar pelo lado da margem sensibilidade x sinal, olhe pelo SNR.
Ruído em -96dBm? Então se usar MCS15 e tiver sinal de -66dBm (12dBm de margem com relação a sensibilidade do MCS15 de -78dBm) terá CCQ de 100%?
Duvido muito. Por isso:
Anexo 59302
Segundo isso precisaria 32dB de SNR pra MCS15. E... -96 + 32 = -64dBm
Já em MCS12 segundo isso precisaria apenas 26dB de SNR. Se o ruído é -96dBm então o sinal mínimo pra MCS12 seria -70dBm.
Testa aí, um mini-PTP em modo automatico, ruído -96dBm, e ajusta a potencia de modo a ter sinal digamos -70dBm, veja se o software vai ser inteligente pra ir pra MCS12. Sempre que fiz isso ele foi burro de ir pra MCS15, e ter não só apenas 8dBm de margem, como apenas 26dB de SNR (Que segundo duzias de tabelas é insuficiente pra MCS15).
Mas tem que ver que SNR e margem falam apenas em PERCENTUAL de erro, não existe erro zero em wifi (Só via cabo existe), com RF sempre terá reflexo, vswr e etc. Mas com SNR baixo é fácil ver o percentual previsto de erros:
Anexo 59303
Veja que com 20dB de SNR em MCS12 a perda não é zero, é 0,00001%, ou 1 pacote perdido a cada 100 mil. O problema é que um pacote de 1500 bytes pode ser quebrado em várias transmissões via wifi, 1 erro a cada 100 mil pode gerar na verdade o reenvio de 1 pacote completo a cada 1 mil, e num AP com 50 clientes tendo essa parte isso pode ser 1 perda a cada 20 transações, isso dá uma perda de capacidade geral teórica de 5%! (Cai de 40Mbps pra 38Mbps).
Esse tipo de pequena diferença é fácil ver em PTP, você meche 1 fio de cabelo no angulo da antena e ela cai de 40 pra 38Mbps de média, em PtMP ninguém costuma dar bola porque o trafego real depende do que os clientes estão fazendo, mas falando em otimizar a capacidade a recomendação é trabalhar com margem mínima de 20dBm (Sinal -66dBm se usar MCS12 em UBNT ou MK), SNR mínimo de 32dBm (Se o ruído estiver em -90dBm tem que trabalhar com sinal acima de -58dBm), e trabalhar com zona de fresnel acima de 100% (E acima de 200% se tiver no caminho algo altamente reflexivo tipo telhado metalico ou agua), assim terá CCQ proximo a 100% (98, 99 ou 100%) e poderá enfiar 40 clientes trafegando muito num Rocket.
Isso é OTIMIZAÇÃO, não quer dizer que coisa pior não funcione. Mas se for pelo "funcionar funciona" o negócio é economizar ao máximo e botar um Greatek 700mW em 802.11b como AP, numa omni 15dBi, e antenas de grade com adaptador USB no cliente... funcionar funciona :-)
(Mas está longe de ser uma estrutura de qualidade, ou otimizada)
Utilizo polarização dupla nas RBs, estou postando os prints da configuração das RBs via winbox.
Anexo 59312Anexo 59313
Você está usando isso outdoor? Se sim, muda pra faixa que PODE ser utilizada pra ambiente outdoor, que é ACIMA de 5350MHz.
Seção X daqui:
http://www.anatel.gov.br/legislacao/...-resolucao-506
5150 a 5350MHz é APENAS pra uso indoor.
Por isso o espectro está uma zona no brasil, ninguém respeita regulamentação.
Se usar MIMO, use apenas os datarates de MIMO, isto é, MCS8 a MCS15.
E o uso de largura de canal auto em 20/40MHz, é pra passar mais banda? Mas lembra que 40MHz exige mais sinal, não só tem sensibilidade uns 2-3dBm menor como exige SNR uns 2-3dBm maior. A tabela de SNR que enviei é das poucas que agrupa 20 e 40MHz na mesma necessidade de SNR (Pois ela usa a conta de bits por hertz, que só funciona em laboratório), mas outras dão valores diferentes, exemplo:
Anexo 59344
Essa tabela tem SNR mais conservador porque aparentemente leva em conta uma taxa de erros maior tipo 99% (E a outra algo tipo 99,99%), o Bit Error Rate. Fora que se for ver tabelas oficiais de sensibilidade uns datasheets citam coisa tipo "-85dBm (10% error)", ou seja, se aplicar a margem sobre essa sensibilidade exata terá 10% de perdas "apenas" (E isso é considerado aceitavel no maldito mundo do marketing), 1 de cada 10 pings perdido, isso é uma rede lixo... mas pra fins de marketing tá tudo certo.
Citação:
Postado originalmente por evandrojso
perfeito, é bem simples so se trata de niveis de sinal!!!
Citação:
Postado originalmente por evandrojso
Mas tem alguma outra questão nesse caso, apontamento de antena provavelmente.Citação:
Postado originalmente por emilidani
Porque trocando de 31 pra 34dBi são 3dBi de diferença no ganho, 3dBm por lado, 6dBm ao todo, e -55 + 6 daria -49dBm.
Se subiu pra -43dBm é porque OU as antenas de 31dBi estavam mal alinhadas, OU tinha problema de fábrica nelas (E eu não confio é no acabamento das Algcom, solda feia tipo a que eu faço, e folha de alumínio na ponteira, não me inspiram confiança).
O ganho de uma antena em bom estado tem tudo a ver com nível de sinal, trocar antena de 33 por 34dBi só deve mudar 1dBm no nível de sinal, se trocar nos 2 lados dum PTP só deve mudar 2dBm, se mudar algo além (Ou diminuir) então tem algo variando além do ganho da antena, tipo apontamento, conector, cabo, ou antena de angulo mais aberto pegando reflexo do chão (Multipath diz a teoria que não tem poder pra derrubar sinal, teria que chegar muuuuuita onda em contrafase pra criar isso, devia derrubar o throughput mas não o sinal).
Rubens meu amigo dá uma olhada nessas imagens e veja que problema nos persegue. Durante o dia o ping para esse lado do enlace e 3, 5, 6 e por ai... agora depois das 20 horas fica desde jeito, porém já trocamos canal fizemos de tudo um pouco e nada de exito. Rocket m5 com disco de 25db. Tava pensando em testar um esse enlace de 3.5 km por um par de antena da intelbras APC 5M-18.Anexo 60356Anexo 60357Anexo 60359
Boa noite a todos !Citação:
Postado originalmente por rubem
Rubem por gentileza, teria como vc analisar as configurações e me dizer o que está de errado ? segue os prints do rocket m5 e da nano loco m5 de cliente.
Minha rede hj é de 30 clientes
link adsl 25 megas gvt
Rb 493-ah para autenticar os clientes ppoe
rocket m5 conectada a uma omni ubiquit 13 dbi 5.8 ghz
nos clientes tenho 5 airgrid m5 e 25 nano loco m5
obrigado
sucesso a todosAnexo 60415Anexo 60416Anexo 60417Anexo 60418Anexo 60419
segue abaixo configuração do equipamento de cliente
Anexo 60420Anexo 60421Anexo 60422Anexo 60423