AP Ubiquiti x Cliente Mikrotik = Sofrimento de mais de 1 ano

[pablozac]

Amigo @rubem,

Fiz o seguinte, mandei o funcionário ao POP acrescentar uma SXT-SA para dividir os clientes, porém antes disso, já que eles já estão querendo me esfolar vivo, uma horinha a mais ou a menos não fará diferença. Queria deixar todos na SA primeiro para ver como o MK se comportaria nessa situação como AP. Como devo configura-lo para substituir a Rocket apenas para testes. Lembrando que estão misturados SXT e Nano 2X2 juntamente com Grid 1x1.

[inquiery]

A meu ver o maior problema de usar misturado é a perda do TDMA, que pra PTMP vai fazer o CCQ cair bastante.
Se pudesse conectar os equips ubiquiti no Rocket e as estação SXT no AP SXA-SA, e abilitar AirMax no Rocket e nv2 no SXT-SA, acho que iria melhorar bastante.

[rubem]

Rubem, primeiramente algo além do meu muito obrigado !!!

É o seguinte, fiz as alterações que você cita e entendi a explicação sobre os MCS.

Com potencia em 10dbm o nível de sinal ficou em -51/-51, logo, coloquei 1dbm a mais e fez com que o enlace fosse fechado a -49/-50 tudo bem?

Lá na aba DATA RATES em Supported Data Rates A/G, só deixei marcado o 54mbps.

Na aba HT, deixei marcado todos os AMPDU Priorities, alias, para que propriamente serve esta função?

Na aba HT MCS em:

HT Supported MCS deixei marcado 14 e 15 (sim, você disse para deixar apenas um deles mas por questão psicologica deixei os dois assim por 24 horas para ver como o enlace se comportaria).

HT Basic MCS deixei marcado também o 14 e o 15. Faz-se necessário?

Anexo 58625

Quanto ao ACK, onde fica esta config?

O AMPDU é um tipo de agregação de dados numa parte do envio de dados, a parte de sincronia e cia é mantida, a parte de inicio de prembulo não muda, mas quando chega na parte do processo (Que leva nansegundos, por isso preambulo LONGO é 800ns, ou seja, 0,8us, ou 0,0008ms, ou 0,0000008 segundos) em que o layer chamado MAC trafegaria os dados (Cada dado é um PDU, Protocol Data Unit, unidade de dados do protocolo, um PDU pode ser um bit ou um pacote inteiro) esse AMPDU pode Agregar (Daí que vem o A) mais unidades de dados (Mais pacotes, ou mais bit), pra aproveitar melhor o trafego.

Assim como o uso de preambulo longo aumenta o trafego, porque o tempo perdido em sincronia e cia (Posso enviar? Pode. Tô enviando. Tá, tô recebendo. Chegou? Chegou. Mas chegou o que, lê aí a 5ª letra pra ver se chegou certo) é enorme. Alias, aumentando o tempo pra enviar unidades (PDU's) mesmo passando de 400 pra 800ns faz o datarate aumentar só pouco mais de 10% (Aumenta de 65M pra 72M, digamos), então tudo o que faça a torre perder menos tempo com cada pacote melhora o desempenho.

AMPDU também tem sistema que verifica erros, então onde a zona de fresnel é parcial ou onde o SNR é baixo ele devia ajudar.

Mas onde se trafega muita coisa (PTP), ele pode criar gargalo, o chipset vai perder tempo acrescentando dados, esse tempo pode atrapalhar o throughput, então de qualquer forma você tem que testar.
(Seja PTP ou PTMP. Agregar mais dados num único envio diminui o tempo que a torre gasta com cada cliente, aumenta o uso do processamento do chipset de RF então onde isso piora o resultado é porque o chipset de RF está no gargalo, está sendo utilizado demais)
Os numeros de 0 a 7 não indicam o numero de unidades agregadas, mas as unidades de quais prioridades serão agregadas, dados de sincronia e cia tem prioridade mais alta (0), dados do cliente tem prioridade mais baixa (8, ficou de fora), depende do chipset como ficará o desempenho de qualquer forma.

O HT MCS Basic é o datarate mais baixo que o sistema vai usar, se marcar 14 e 15 como "basico" é pra esses que o sistema vai baixar quando ficar sem tráfego (Economia de energia e cia, datarate mais baixo permite o uso de sinais mais baixos portanto potencias menores e etc, em modo auto isso funciona lá de vez em quando), pra provedor isso não tem muita utilidade.

Sobre o ack-time, essa opção fica na aba Advanced da interface wireless, mas lembra de clicar no botão Advanced Mode na direita em baixo, senão não aparecem todas as abas.
O ack-timeout é exibido nesse ponto em micro-segundos, us (Onde u é a letra grega mi), 1us é 0,001ms, ou 0,000001s. O default é dynamic (automatico), eu uso assim: Mínimo de 25uS se for 150m ou menos, e depois 1us a cada 133m.
(Ou seja, 1000m seria 1000/133 = 8, mais 25 do mínimo = 33uS, sobe pra 36 ou 39us (10-20%). Pra 2Km seriam 16 da distancia + 25 do mínimo = 41us, sobe pra 45 ou 49uS)
Se fizer a conta como 25 de mínimo, e 1us por 100m em distancia pequena já vai ter o numero um pouco maior que o real, já serve bem, é o que faço, aí só aumento 1/3 (mais 33%, que é o que 133 está para 100).

Na opção wireless, na aba registration, tem como setar pra exibir o ack-time, mas não sei bem porque as vezes isso não é exibido, se depende do modo ou da versão do firmware. Em dynamic lá geralmente fica o valor real da distancia SOMENTE quando a zona de fresnel é perfeita, se lá aparecer numero grande (Digamos 50us em cliente a 500m) pode ter certeza que tem algo físico atrapalhando, coloca esse cliente em digamos 60us pra quebrar o galho enquanto você não vai ver com os olhos a obstrução (E se pode resolver).

Sobre o ack-time na torre, ó o que a UBNT mesma diz:
If two or more stations are located at the considerably different distance from the Access Point are associated to, the highest ACK Timeout for the farthest station should be set at the AP side.
(Tá aqui: http://wiki.ubnt.com/AirOS_5.3 )

Ou seja, se tem cliente de 200m a 2Km, sete o ack no AP pra 2Km (Em 802.11n seria uns 41us, mas eu colocaria 45us por precaução.

Tá no site da UBNT... pra ninguém achar que eu tiro essas informações do ar.

[marcelorodrigues]

Prezados amigos,

Como não achei nada relacionado ao que estou passando aqui, resolvi abrir esse novo tópico para que alguém possa me ajudar a solucionar ou pelo menos esclarecer o que acontece:

A cerca de 1 ano passo por um problema de conexão entre AP UBNT (Rocket com Basestation) e Clientes Mikrotik (SXT Lite 5). Tudo começa sem aviso prévio e sem alteração no Cenário. Está tudo normal como mostra a Imagem em anexo, de repente o CCQ do AP começa a cair vertiginosamente (Chega a 30) levando os dos clientes junto, o tráfego para, e os clientes são desconectados. Em questão de menos de 1 minuto voltam a se conectar e tudo se normaliza. Já penei com varias configurações diferentes, realinhar cliente por cliente e trocar o AP por um novo. A única coisa que resolveu em definitivo foi dividir os Clientes por Fabricante. Colocar Clientes UBNT em AP UBNT e Clientes MK em AP MK. Queria uma solução mais barata pois ainda tenho torres UBNT com fabricantes misturados (UBNT e MK) onde não compensa de forma alguma eu colocar 2 interfaces 5.8 para atender 15 clientes.

Algumas considerações:

Pior Sinal da Torre usada como controle é -72
Acontece com todas os APs UBNT que tem 1 ou mais SXTs junto com as Nanos x Grids
Acontece de forma esporádica em horários e intervalos distintos e as vezes até dias de intervalo.
Não uso protocolo TDMA proprietário nos APs
O log do AP UBNT fala que o cliente está sendo desconectado por sinal ruim.
Problema de interferência já foi eliminado, pois estou sozinho e acontece em todas as torres com equipamento misto.
Só uso UBNT E MK.
Dividindo os Fabricantes o problema desaparece (Não é a solução adequada para mim no momento).

Se alguém já passou pelo problema e conseguiu uma configuração adequada para funcionamento, favor compartilhar. Ajudará uma alma desesperada a dormir em paz.
Anexo 58573

O airmax de todos equipamentos estão desativados? Tem que estar!
E nas SXT deixa o protocolo 802.11

[rubem]

Amigo @rubem,

Fiz o seguinte, mandei o funcionário ao POP acrescentar uma SXT-SA para dividir os clientes, porém antes disso, já que eles já estão querendo me esfolar vivo, uma horinha a mais ou a menos não fará diferença. Queria deixar todos na SA primeiro para ver como o MK se comportaria nessa situação como AP. Como devo configura-lo para substituir a Rocket apenas para testes. Lembrando que estão misturados SXT e Nano 2X2 juntamente com Grid 1x1.

Só pra referencia, é assim que "gosto" de usar:
sx1.zip

DFS depende do canal, potencia depende do canal. Nessa versão do RouterOS o ack-time está como distancia (Nos seus SA pode estar em us, colocaria 50us, se o cliente distante for 2Km), mas o grosso está aí.
(WDS marcado desse modo pro caso de usar pppoe, caso não use ignore essa aba)

[claudiohoki]

acompanhando o tópico!

[pablozac]

Obrigado @rubem. Vou aproveitar muitas coisas. Só de fazer a substituição pelo AP MK já houve uma melhora considerável. Sem fazer nenhum ajuste o consumo do pop que não passava de 8mb já virou de 15 a 20. Ainda ocorrem as desconexões, porem de 3 a 5 clientes dos 50. Na ubnt caiam todos. A desconexão dura segundos, a rocket chegou a demorar de 2 a 3 minutos para normalizar... Enfim, creio que com os ajustes corretos o problema será resolvido em breve. Vou mantendo todos informados...

Um grande abraço !

[pablozac]

Essa configuração que me enviou é PMP ou PTP ? Você tem uma tabela da relação de MCS x Sensibilidade da MK. Olhei o brochure da SXT_SA e não entendi muito bem. Estou com o Firmware 6.21.1. Quando habilito a opção Noise Floor Threshold o valor que aparece é -120. Devo deixar -90 ao contrario de 90 que está sua imagem ?

[rubem]

Pra PTP só não marcaria o HT MCS3, ele é um datarate de polarização simples (Em teoria pros Airgrid, mas algums equiptos MIMO de sinal baixo talvez usem esse datarate, não é preocupante).


Quanto as sensibilidades, a MK não divulga tabela completa de nada ultimamente, no caso dos SXT pode se basear nos dados do Rocket:
http://dl.ubnt.com/rocketM5_DS.pdf
A sensibilidade é 1dBm diferente, não faz muita diferença. A potencia é que muda mais, o SXT tem 1 ou 2dBm a mais de potencia em cada datarate, mas o grosso é igual o Rocket.
(E igual quase todo equipto recente, a sensibilidade dos chipsets anda muito igual. A potencia varia mais, porque depende do amplificador de saída usado (E da configuração dele))

[pablozac]

Grande @rubem,

Então de acordo com suas explicações, o MCS12 e 3 como você deixou marcado, permite uma sensibilidade de -84 e -90 de acordo com o datasheet (arredondando). Então o sinal ideal para MCS12 tirando a faixa de segurança de 20dB é de no mínimo -74. Ainda estou em dúvida de como calcular o máximo. Você explicou que o sinal máximo interessante seria 28 dB acima da sensibilidade, o que evitaria vazamento entre polaridades. Então nesse caso específico, o AP setado em MCS12 o sinal ideal tem que ficar entre -66 e -74 ?

Determinei as configurações que você mandou ontem pelo ZIP, porem elas não são todas compatíveis com UBNT. Se eu seguir ao pé da letra as configurações da Aba Advanced as UBNT (NanoL e Grid) conectam mais não trafegam. Nem acesso eu consigo depois das configs aplicadas. Só não descobri ainda o que é incompatível na aba, pois como está em produção estou com medo de fuçar a toda hora. Sei que Distance setada não é. E também verifiquei que com Preambulo Curto as UBNTs não se conectam...

Como diz você: Azar de quem mistura equipamentos.... Hehehe

[FMANDU]

pablozac, deixa eu ver se entendi, então você tirou um painel ubnt + rocket e colocou uma stx no lugar? esse seu problema todinho não pode ser o equipamento de algum cliente?

[pablozac]

Caro @FMANDU, provavelmente não, pois acontece em todas as torres onde tenho AP UBNT e Clientes SXT x UBNT e agora acontece também com o AP MK e clientes misturados, porem em grau e impacto muito menor. Já descobrimos aqui no tópico algumas incompatibilidades reais entre um equipamento e outro. O que estou tentando é faze-los trabalhar em comum acordo. Mais uma coisa já posso adiantar, para clientes híbridos, MK é a melhor solução e se possível for, não misture fabricantes, principalmente UBNT com MK para comunicação em radio frequência. Quando você precisa de ajustes manuais, que são altamente recomendados para um bom atendimento ao cliente, a UBNT fica devendo, o firmware é amarrado no automático e você não tem informações suficientes para tomar decisões, e no caso de problemas como o meu não ha muito o que fazer. Por isso substituí por MK, o que já me deu uma série de ferramentas e informações que eu não dispunha antes para correr atrás do prejuízo...

[Zucchi]

O AMPDU é um tipo de agregação de dados numa parte do envio de dados, a parte de sincronia e cia é mantida, a parte de inicio de prembulo não muda, mas quando chega na parte do processo (Que leva nansegundos, por isso preambulo LONGO é 800ns, ou seja, 0,8us, ou 0,0008ms, ou 0,0000008 segundos) em que o layer chamado MAC trafegaria os dados (Cada dado é um PDU, Protocol Data Unit, unidade de dados do protocolo, um PDU pode ser um bit ou um pacote inteiro) esse AMPDU pode Agregar (Daí que vem o A) mais unidades de dados (Mais pacotes, ou mais bit), pra aproveitar melhor o trafego.

Assim como o uso de preambulo longo aumenta o trafego, porque o tempo perdido em sincronia e cia (Posso enviar? Pode. Tô enviando. Tá, tô recebendo. Chegou? Chegou. Mas chegou o que, lê aí a 5ª letra pra ver se chegou certo) é enorme. Alias, aumentando o tempo pra enviar unidades (PDU's) mesmo passando de 400 pra 800ns faz o datarate aumentar só pouco mais de 10% (Aumenta de 65M pra 72M, digamos), então tudo o que faça a torre perder menos tempo com cada pacote melhora o desempenho.

AMPDU também tem sistema que verifica erros, então onde a zona de fresnel é parcial ou onde o SNR é baixo ele devia ajudar.

Mas onde se trafega muita coisa (PTP), ele pode criar gargalo, o chipset vai perder tempo acrescentando dados, esse tempo pode atrapalhar o throughput, então de qualquer forma você tem que testar.
(Seja PTP ou PTMP. Agregar mais dados num único envio diminui o tempo que a torre gasta com cada cliente, aumenta o uso do processamento do chipset de RF então onde isso piora o resultado é porque o chipset de RF está no gargalo, está sendo utilizado demais)
Os numeros de 0 a 7 não indicam o numero de unidades agregadas, mas as unidades de quais prioridades serão agregadas, dados de sincronia e cia tem prioridade mais alta (0), dados do cliente tem prioridade mais baixa (8, ficou de fora), depende do chipset como ficará o desempenho de qualquer forma.

O HT MCS Basic é o datarate mais baixo que o sistema vai usar, se marcar 14 e 15 como "basico" é pra esses que o sistema vai baixar quando ficar sem tráfego (Economia de energia e cia, datarate mais baixo permite o uso de sinais mais baixos portanto potencias menores e etc, em modo auto isso funciona lá de vez em quando), pra provedor isso não tem muita utilidade.

Sobre o ack-time, essa opção fica na aba Advanced da interface wireless, mas lembra de clicar no botão Advanced Mode na direita em baixo, senão não aparecem todas as abas.
O ack-timeout é exibido nesse ponto em micro-segundos, us (Onde u é a letra grega mi), 1us é 0,001ms, ou 0,000001s. O default é dynamic (automatico), eu uso assim: Mínimo de 25uS se for 150m ou menos, e depois 1us a cada 133m.
(Ou seja, 1000m seria 1000/133 = 8, mais 25 do mínimo = 33uS, sobe pra 36 ou 39us (10-20%). Pra 2Km seriam 16 da distancia + 25 do mínimo = 41us, sobe pra 45 ou 49uS)
Se fizer a conta como 25 de mínimo, e 1us por 100m em distancia pequena já vai ter o numero um pouco maior que o real, já serve bem, é o que faço, aí só aumento 1/3 (mais 33%, que é o que 133 está para 100).

Na opção wireless, na aba registration, tem como setar pra exibir o ack-time, mas não sei bem porque as vezes isso não é exibido, se depende do modo ou da versão do firmware. Em dynamic lá geralmente fica o valor real da distancia SOMENTE quando a zona de fresnel é perfeita, se lá aparecer numero grande (Digamos 50us em cliente a 500m) pode ter certeza que tem algo físico atrapalhando, coloca esse cliente em digamos 60us pra quebrar o galho enquanto você não vai ver com os olhos a obstrução (E se pode resolver).

Sobre o ack-time na torre, ó o que a UBNT mesma diz:
If two or more stations are located at the considerably different distance from the Access Point are associated to, the highest ACK Timeout for the farthest station should be set at the AP side.
(Tá aqui: http://wiki.ubnt.com/AirOS_5.3 )

Ou seja, se tem cliente de 200m a 2Km, sete o ack no AP pra 2Km (Em 802.11n seria uns 41us, mas eu colocaria 45us por precaução.

Tá no site da UBNT... pra ninguém achar que eu tiro essas informações do ar.

Sensacional Rubem, muito obrigado! Até salvei seu texto aqui para nunca mais esquecer e consultar!

[pablozac]

Caro, @Zucchi. Aprendi mais com o @rubem nesse tópico do que 6 anos trabalhando em provedor... Quem sabe, sabe... Essas dicas me deram um novo conceito e vou trabalhar na rede inteira por conta disso. Não só no POP ou na cidade que estou tendo problema... @rubem, se não vai lançar livro não ???

[rubem]

heheh... essa matemática avançada onde -84 + 20dB = -74 eu desconheço :-)

Se a sensibilidade está em -84 a -90 o sinal mínimo seria -64 a -70.
Quanto a esse "maximo" de 28dB, isso depende da isolamento de uma polarização pra outra. No caso do SXT o isolamento é de 35dB.
Ou seja, no SXT de o sinal chegar entre digamos -70 e -90 ele será lido por uma polarização, mas se ele for 35dB maior que -90, isto é, -55, ele será lido também pela outra polarização, ele é tão alto que "vaza" pra outra polarização.

Ou seja, com MCS3 com sensibilidade de -90, o sinal ideal seria p mínimo de -70 (20dB acima da sensibilidade) e o maximo de -55 (35dB acima da sensibilidade, pois acima desse ponto o sinal começa a ser lido nas 2 polarizações).

Um sinal -70 em MCS12 (Sensibilidade de cerca de -84, nesse caso) não é o fim do mundo, 14dB de margem tá bom pra distancia pequena, eu sempre falo em 20 por poder colocar 40 clientes num AP sem ter queda de CCQ, o problema não é ter 2 ou 3 clientes com margem pequena tipo 15dB, o problema é ter 40 deles. O FOCO deve ser 20dB ou mais (Mas não mais que o isolamento entre polarização CASO use mimo), mas excessões não matam ninguém.

Quanto a aplicar essas regras pra canais de 40MHz... aí complica, pra mim que só presta com sinal praticamente 10dB mais alto que quando se usa canal de 20MHz, láááááá de vez em quando algum datasheet da valores direrentes de SNR mínimo ou de sensibilidade entre 20 e 40MHz de largura, fora o problema de ter interferencia diferente numa largura tão grande (Geralmente se usa canal de 20MHz, pode ter interferencia em 20 ou mesmo só em 10 do 40MHz que for usar). Quanto maior a distancia maior a margem de sinal que GERALMENTE precisa pra ter throughput total (Abaixo de 1,5Km pode usar 10 ou 12dB de margem que o CCQ ainda será razoavel. Mas a partir de uns 6Km precisa 20dBm, e a partir de uns 15 ou 20Km precisa 25dB, e assim vai subindo), mas a largura do canal também influencia, pra MIM que 40MHz precisa quase 10dB a mais de sinal que 20MHz (Pra ter o mesmo througput percentual, tipo: Tem 35Mbps em MCS7 a 20MHz com sinal -55? Pra ter 70Mbps em MCS7 a 40MHz vai precisar sinal -45)

[maisonmdsgreen]

Rubens clientes tudo ubiquiti com sinal entre 55 e 69 qual mcs recomenda no ap e qual no cliente? Mcs 13 no ap e 10 no cliente? Levando em conta apenas mimo.

[rubem]

Rubens clientes tudo ubiquiti com sinal entre 55 e 69 qual mcs recomenda no ap e qual no cliente? Mcs 13 no ap e 10 no cliente? Levando em conta apenas mimo.

Isso, perfeito.
SE o CCQ não chegar a 100% depois de ajustar ack nos clientes, baixa pra MCS12 um dia pra testar, mas a maior diferença acho que vem da config. no cliente, que é datarate mais baixo e ack-time mais alto.

[maisonmdsgreen]

No caso do mcs 12 fala no ap ou clientes?

[rubem]

MCS12 ou 13 na torre.

Nos clientes nem MCS10 precisaria geralmente, pra maioria podia ser até MCS9 mesmo (Upload baixo, datarate mais baixo permite mais margem de sinal entre sensibilidade e sinal, diminui o numero de perdas cliente>torre, isso diminui o tempo que a torre perde com cada cliente).

O datarate cliente>torre não leva só o upload, leva também as respostas dos pacotes de download, então não seria bom algo tipo MCS15 na torre e MCS8 nos clientes, isso seria um ratio 10:1 download:upload, aí é exagero, mas MCS10 e 13, ou 9 e 12 em cliente e torre respectivamente dá um bom ratio.
(Mesmo que você venda upload tipo 1M em planos de 2 ou 3M pode usar tx rate baixo nos clientes, eles geralmente usam pouco upload).

[maisonmdsgreen]

No caso automático o Mcs ou seleciono o manual consigo passar até 5mb por clientes up e de down