+ Responder ao Tópico



  1. Citação Postado originalmente por 1929 Ver Post
    Rubem, só uma dúvida, quando por ex fixa o MCS4 no AP e no cliente fixa em MCS1 por exemplo, o AP vai transmitir num data rates mais alto mas a CPE está configurada para o MCS1 e daí ela não vai dar uma segurada para absorver este mcs4?
    Nunca vi nos firmwares mas eu imagino que se fosse possível configurar TX e RX diferentes na station não teria melhor resultado ainda?
    Toda a transação ao redor do envio de um pacote torre>cliente é feito em MCS4 se setar assim.

    Se o datarate é fixo há algo tipo um request-to-send em MCS4, o cliente manda um clear-to-send em MCS4, e há mais pre-estabelecimentos de comunicação feitos por ambos os lados em MCS4 afinal quem requisitou essa troca de dados foi a torre.

    Se o datarate, potencia ou ack-timeout é automatico a maioria dos firmwares manda um tipo de packet-probe que ajuda na analise de qualidade pra definir se vai aumentar ou reduzir algo, são nanosegundos gastos com essas trocas.

    Esse pacote hipotético é um pacote TCP/IP comum, ele saiu do linux no AP da torre e ele precisa um checksum (Ou algo do tipo), esse ckecksum que o linux da CPE precisa enviar já é outro pacote, ele será iniciado pelo linux da CPE, a wlan da CPE vai fazer automaticamente a transação, se ela está configurada pra MCS1 tudo ao redor desse mísero checksum ou simples "OK" pro pacote anterior será feito em MCS1 pelos 2 lados.

    No fim das contas todo o download é feito em MCS4, e todo o upload é feito em MCS1. As respostas de pacotes que são resposta SO <> SO são feitas como se fosse download ou upload, elas é que tomam muito tempo de conexão, as respostas pra estabelecer comunicação não perdem quase nada de tempo, são poucos nanosegundos.
    (Por isso nunca sugiro algo agressivo tipo -70dBm pra MCS15, em PTP isola até dá as vezes, mas em PTMP isso ia gerar muita perda de pacote nesse ato de responder cada conexão estabelecida)


    Que teria muita vantagem em usar um datarate lindo tipo MCS15 nos 2 lados isso teria!
    Tudo fixo em MCS15 seria perfeito, rede perfeita igual rede cabeada.
    Mas olha o nível de sinal e de limpeza da zona de fresnel que ia precisar!

    Em ambiente poluído o SNR necessário pode ser esse absurdo aqui:
    Clique na imagem para uma versão maior

Nome:	         snr_x1.gif
Visualizações:	363
Tamanho: 	21,4 KB
ID:      	59425


    Segundo o livro isso é pra ser analise do SNR em cada pacote, e abaixo uma aferição chamada "efetiva" de SNR levando em conta não o ruído geral no ambiente mas sim o que tem potencial pra atrapalhar o sinal depois do conversor analogico>digital (Que dizer, um transmissor FM a 100MHz, com harmonicas a 100, 200, 400, 800MHz, 1600 e 3200MHz, não deve incomodar, o ADC não vai converter isso).

    O problema é: Você vê um ruído indicado em -96dBm, mas o PTP passa pouca banda. Você troca de canal, noutro canal onde também é exibido -96dBm de ruído, mas o PTP fica bom. Analisa bem, e o que tem no canal antigo? Um monte de SSID. Oras, mas SSID não é ruído, canal ocupado com outros sinais não é ruído, então apenas levar em conta o SNR não adianta, e ter um método supostamente "efetivo" ajuda menos ainda, SE usassem um método de SNR por pacote a gente veria ruído variando ora em -80, ora em -116dBm, talvez confundiria uns usuários, mas seria mais realista, perturbação não é um chiado de fundo, é o uso do canal com outros dados, esse uso varia mesmo, hora tem mais pacotes ou menos pacotes sendo trocados na vizinhança.

    Ó uma suposta tomada em tempo-real do SNR:
    Clique na imagem para uma versão maior

Nome:	         real_snr.gif
Visualizações:	117
Tamanho: 	17,9 KB
ID:      	59426


    Então como não dá pra confiar em SNR (Ou melhor, dá pra confiar, mas dá muuuuuuito trabalho, alterando datarate toda hora, exigiria muito processamento), nem em RSSI (Uma melhoria do SNR), os sistema de escolha de datarate nos chipsets não leva em conta isso, mas sim são sistemas baseados em perdas de pacotes.
    São tipo auto rate fallback (Velho), adaptative auto rate fallback (Mais conservador nas tentativas de subir datarate), e um sistema de auto-rate baseado no receptor, onde o receptor informa AUMENTANDO/FUÇANDO no pacote original acrescentando dados sobre a qualidade da conexão anterior, e um algoritmo de adaptação de rate que é pra ser robusto, RRAA, que anda sendo muito usado.
    Nesse algoritmo há o uso ou não de RTS/CTS (Conforme necessidade), há o uso de estimativa de perda futura (Já envia 2x antes mesmo do cliente avisar que não recebeu pacote, porque notou alteração em ruído, e... sabe que o ruído na torre pode ser de outra fonte com relação ao ruído no cliente!), e o melhor, ele usa apenas 1 frame pra fazer o packet probe a cada conexão, ele não manda um packet probe embutido ou a cada troca de dados. A princípio se suspeita que o algoritmo "Alternative" da UBNT seja esse.
    (Enquanto o uso de AMPDU na MK diz que ela usa o sistema de auto-rate baseado no receptor, agregando dados no MPDU)

    Esse algoritmos de tomadas de decisões são tudo software, o software diz o que vai pra camada mac e o hardware da wlan (phy) transmite e dá um feedback pro software informando tempo de respostas ou algo assim. O problema é que o software usa processamento pra pegar esse dado, analisar estimativa de perdas futuras e definir se vai ou não trocar o datarate. Quando o chipset está sobrecarregado ele fica lerdo nisso (Está compartilhando CPU com outros funções) e gera CCQ baixo e cia porque não está conseguindo analisar e trocar rates de forma rápida ou bem pensada (O software faz burrice porque o hardware fica lerdo).

    Alias, tem mais uma hoje, como é sabido que muito hardware vagabundo é usado como AP em PtMP, e hardware vagabundo as vezes perde pacote porque a CPU está sobrecarregada, existe o modo de operação que CASO haja perda de pacote o próximo pacote só é enviado depois de um RTS respondido com um CTS. A intenção é: Se perdeu pacote é porque a CPU está lotada, pra não perder transmissão denovo vamos primeiro perguntar se podemos transmitir. Se esse pacote (Depois do RTS e CTS) for ok, aí os próximos pacotes são transmitidos sem RTS/CTS (Até que se perca algum denovo), o problema desse modo inteligente é: Ao invez de reduzir o datarate, o sistema insiste em datarate alto porque não sabe se a perda do pacote foi por sinal baixo ou por CPU hiperlotada, mas... sabemos que o ruído varia (SNR idem), algo comum é 1 pacote com RTS/CTS, 1 sem e perdido, 1 com RTS/CTS, 1 sem e perdido, e assim vai. Situação em que praticamente só há troca segura usando RTS/CTS. Como o pacote com RTS/CTS não é perdido nunca (Porque a contraparte da comunicação para a outras trocas de dados pra ouvir só 1 cliente) o software não experimenta baixar o datarate (Pra algum que tenha SNR melhor, e não precise RTS/CTS).

    (Acho que você já deve ter testado um RTS threshold baixo, pra que quase todo pacote passe pelo processo de pedido e autorização, as vezes funciona e ajuda, mas as vezes só consome mais processamento e o resultado prático é zero (Onde não há colisão não há motivo pra implantar algo pra evitar colisão, por isso não uso colete-a-prova-de-balas nem antivirus, são proteções pra problemas que eu não tenho))

    Pode parecer bobeira um algoritmo ser enganado por perda de dados, mas não podemos ver por esse lado, temos que ver a complexidade de produzir um algoritmo inteligente o suficiente pra saber diferenciar quando o pacote foi perdido por SNR baixo, quando foi por CPU lerda, quando foi por colisão, etc.
    Antigamente em tempos de 802.11a o algoritmo era burro de fazer isso:
    Clique na imagem para uma versão maior

Nome:	         ber.a.gif
Visualizações:	149
Tamanho: 	11,2 KB
ID:      	59427

    O BER é o bit error rate, 10 elevado a -4 é 4 zeros com um 10 depois, ou 0,00010, ou 0,0001%, ou 1 erro a cada 1000.
    10^-5 seria um zero a mais, 1 erro a cada 10 mil.

    Qual o problema disso pra chamar de algoritmo burro? O problema é que o erro JÁ OCORREU! O algoritmo não viu que o SNR era de só 10dBm? Não viu, ele esperou ter X erros pra depois perceber que era um rate ruim e então trocar.

    Hoje temos algo muito melhor, que "prevê" erros.

    E essa melhoria não depende do "querer fazer", mas sim do conseguir. Nunca mechi com programação porque não consigo esquematizar algoritmos (Ou falta paciência pra praticar), mas sei das dificuldades de um algoritmo que leve em conta um contador de frames perdidos, um analisador de qualidade de link (SNR, nível de sinal), um analisador de throughput necessário (E esse existe, muito ptp e ptmp cai pra 6M quando não tem tráfego, o problema disso é a demora pra "subir" o datarate quando aparecer tráfego), a coisa boba tipo "Se o índice de erros está baixo pode subir o datarate" não é suficiente, porque trafegando pacotes de 30 bytes (status de rede apenas) você tem uma taxa de ocupação do espectro, hora que passa pra pacotes de 1500 bytes (navegação/download) a ocupação aumenta, se usar um algoritmo bobo o datarate vai ficar variando.


    Enfim, o problema não é ser automático, o problema é o tempo perdido na definição de QUAL rate, potencia ou ack usar. Em ambiente urbano o problema são as outras redes wifi, hora que outra rede está parada o canal fica mais limpo e você pode subir o datarate, mas hora que outra rede começar a trocar dados aos montes o seu PTMP teria que reduzir o datarate pra perder menos pacotes (Senão vai ter que ficar reenviando pacotes, aumenta o ping ou diminui o throughput se não diminuir o datarate), mas essa troca automática é lerda, e... essa mudança na ocupação dos canais ou o ruído não ocorre 3x ao dia, ela ocorre 3x por segundo e as vezes 3x por minuto, pro AP fazer uma troca rápida ele precisaria sair disparando packets probe pra todo lado, pra todos os clientes responderem e ele então definir a troca do datarate, mas isso consome muito processamento (Que um AP com 40 clientes não tem).

    O resumo da coisa é estar preparado pra eventuais ruídos e ocupações alheias de canal. Um datarate baixo e fixo, com margem de sinal decente, e SNR decente, permite isso, ping constante (Sem jitter), com todos os clientes equalizados, sem variação de throughput conforme a hora do dia (Mais gente usando wifi de dia que de madrugada).

    Os padrões 802.11 da IEEE não padronizam algoritmo desse tipo, cada fabricante usa um, as vezes pode ocorrer de 2 AP's tomarem a MESMA decisão e ficarem se acotovelando por canais, então nem a troca automática de canais me agrada, até porque um canal pode estar com ruído nos clientes, mas estar limpo na torre, quem manda é a torre então pode ter rede ruim por bobeira.

    Sobre ack-time e SNR, também entra a questão da visada e zona de fresnel, nenhum algoritmo consegue ver qualidade da conexão física, eles olham nível de sinal, e numa zona de fresnel parcial a reflexão varia o tempo todo, varia 3x por segundo igual ruído ou SNR, um pacote curto (Uma rajada curta) vibra o elemento da antena por X picosegundos e para, mas um pacote longo (Grande) ressona ela por mais tempo de modo que altera em 1º pra baixo a emissão, porque antena multi-elemento é comum e se o sinal chegar levemente atrasado nos elemetos de cima a irradiação desse elemento cria uma quase contra-fase que empura o lóbulo de irradiação pra baixo, existe mais chance de pacote grande refletir com ganho maior, fora que pacote grande ficar em transmissão e recepção por um período de tempo maior, nesse tempo o ruído pode aumentar 10dBm "do nada" (E por ruído entenda ocupação do canal por outro AP, não entra no noise floor mas é sinal que atrapalha o desempenho da etapa de RF, é mais dado pro ADC converter).

    Alias, tema que quero ler faz tempo é sobre as alterações na velocidade das ondas conforme o ambiente. Diz a física que RF só viaja na velocidade da luz no vácuo, e conforme o material há uma queda na velocidade. Falando em luz visível, sei que em diamante a velocidade é praticamente 1/3 da velocidade no vácuo (300 mil Km/s), sei que existe atenuação de RF por chuva, umidade, temperatura, mas preciso ler sobre a possivel diminuição da velocidade em sí, algum tipo de refração deve existir, mas se a luz visível chega a perder 60% da velocidade, já pensou se RF tem alterações tipo 1% na velocidade? 1% de diferença pode perfeitamente cria uma perda de pacote em wifi, porque os tempos precisam ser bem precisos pro ADC separar direito (Wifi sofre muito com efeito doppler, isso se sabe). Se uma nuvem de poeira passando atras da torre atrapalha os clientes pra aquele lado, mas não os pro outro lado, isso só geraria ainda mais processamento pra CPU desse AP numa omni, ia ter bit error rate diferente conforme o lado, e nenhum algoritmo tem como descobrir que tipo de antena está em uso, um equipto que faz beamforming sim, mas beamforming anda cada vez mais esquisito na prática, MIMO tipo 2x3 ou 2x6 parece mais fácil de implantar do que beamforming, parece que precisa muito mais processamento pro mesmo resultado (throughput). Um sistema de beamforming sim ia poder usar um datarate por cliente de forma inteligente, mas os equiptos que fazem isso andam "um pouco caros".

    (E quem mais financia o mercado me parece que é o comprado de roteador de mesa midle-end, roteador de R$ 150 a 500, que atendem usuários de poucos dispositivos mas que querem muita banda, por isso tanto AP vem por default com canal de 40MHz (E vai pra MCS7 mesmo que conecte um celular com sinal -80dBm!))

    Pra mim que a UBNT tem algoritmos diferentes nos Rocket e nos Picostation (Unifi não pude usar mecher quase nada), acho que estão no caminho certo, WISP precisa outro tipo de approach na seleção de rates, precisa modo de seleção 100% diferente de conexão com dispositivo mobile. Infelizmente parece que gastam muito com modos proprietários (TDMA) ao invez de fazer como Cisco ou Arruba e focar $$$ totalmente em algoritmos cada vez mais inteligentes pra essas seleções, porque elas ainda são bem burrinhas, é fácil ver CCQ de 95-98% em ptmp com tudo automático, com throughput médio tipo 10Mbps por cliente, sendo que fixando tudo em datarate baixo o CCQ fixa em 100%, o throughput médio fica nos mesmos 10Mbps, mas o jitter nos pings some, porque o algoritmo não vai pelo "rate necessário", mas sim pelo "maior rate possível, pra enganar os trouxas que só olham pra rates nominais".

  2. Rubens so uma pergunta para PTP seria o mesmo caso o TX do ap download e o TX do Station Upload? No PTP recomenda usar no AP MCS alto e no Station Baixo? Ou os dois nivelados?



  3. Pra PTP geralmente o equipto é igual nos 2 lados, dá pra usar mesmos datarates (Eu sempre uso).

    Se fosse um PTP com equipto diferente (Rocket num lado, NS Loco no outro) talvez precise datarates diferentes pra ter CCQ em 100%.

  4. Citação Postado originalmente por rubem Ver Post
    Ruído em -91dBm não é o fim do mundo.

    O que eu acho o fim do mundo é sinal baixo tipo -76dBm usando datarate alto tipo MCS12.

    Acho insuficiente tanto pelo SNR, como pela margem entre sinal e sensibilidade.

    Se o SNR decente pra MCS12 em 5GHz é 26dBm:
    Anexo 59418
    Então teriamos -91 + 26 = -65dBm como sinal mínimo. Poderia padronizar como meta -55 a -65dBm

    Se a margem de sinal adequada é de 20dBm, e a sensibilidade de MCS12 nos Rocket é de uns -85dBm (-84 a -86, não lembro bem, olhar no datasheet se precisar), -85 + 20 = -65dBm. Wow, caiu denovo em -65dBm como sinal mínimo pra ter rede adequada.

    Sobre o datarate, você marcou MCS12 como TX maximo, mas com a caixa "automatic" marcada o radio ainda troca dados com datarates menos, tem uns TX Rates em MCS11 no status (52M é rate de MCS11).

    E nos clientes a coisa tá feia, tem RX Rate de 19,5M, que é MCS2, você tem Airgrid aí? Só assim pra justificar ter um datarate de single polarization. Outros estão em 26M, 39M, 52M, ou até 78M. Se tem upload baixo tipo 1 a 2Mbps, porque usar nos clientes um TX rate tão alto tipo 52 ou 78M? O problema desses datarate como vimos acima é que exige sinais muito altos, tipo -65dBm a -55dBm.

    Testa o seguinte: Configura a torre 1 vez na vida e não meche mais, usa somente MCS12 (Desmarca o "automatic" senão vai usar de MCS0 a MCS12). Configura uma potencia tipo 20dBm mas desmarca a caixa "auto adjust to EIRP limit" senão o radio sempre vai levar a potencia até o limite EIRP (Em 5,7 a 5,8GHz é 36dBm EIRP, como você não informou o ganho da antena ele está entendendo que tem ao menos um dipolo simples de 3dBi, ele está usando a maxima potencia que o datarate permite).
    E também marque um ack-timeout fixo, de acordo com último cliente. Se o cliente mais distante está a 4,5Km, marque o ack-timeot de uns 5Km, cerca de 10% acima do real.

    Já nos clientes você usa cada um com uma config., e altera conforme a zona de fresnel muda (Arvores crescem, construções aparecem na frente).
    Nos clientes use MCS9 como Max TX Rate (Desmarcando a caixa automatic), com MCS9 você poderá chegar na torre com sinal -70dBm (Torre > Cliente = -65dBm, Cliente > Torre > -70dBm). Como ack-timeout seleciona uma distancia 10 a 20% maior que o real (Desmarque a caixa automatic senão não adianta ajustar nada). Se a zona de fresnel está ruim use 20%. Se a zona de fresnel está 200% limpa pode usar o ack-timeout correto/exato e MCS10.
    E ajuste a potencia no cliente de modo que o sinal dele chegando na torre fique entre -60 e -70dBm, o ajuste de potencia serve pra isso (Mas lembra, "auto adjust to EIRP limit" impede seleção manual de potencia).

    Se não dá pra se livrar do ruído, conviva com ele, e o jeito de fazer isso é com datarates baixos cliente > Torre, com ack-timeout maior que o real, e melhorando a zona de fresnel entre torre e cliente, como tem tanto sinal em -75dBm imagino que tenha esse problema, CPE's baixas demais (E zona de fresnel parcial derruba sinal).

    Se o Rocket está a 20dBm, e tem setorial de 16dBi, tem 36dBm EIRP (Limite legal de 5,8gHz, tá bom assim), em 1Km o sinal cai 108dBm, 36 - 108 = -72dBm no ar, se tem a 1Km um cliente com Nanostation Loco M5 com antena de 13dBi, são 13dBm a mais de sinal (Ganho aumenta sinal), -72 + 13 = -59dBm, sinal pra lá de suficiente. Já se o NS Loco M5 transmitir em 23dBm, que é a potencia maxima em MCS9 nele, somando a antena de 13dBi isso dá 36dBm EIRP, vai chegar -72dBm no ar a 1Km, e a setorial de 16dBi vai passar isso de -72 pra -56dBm, que é sinal muito alto. Pra reduzir pra -60dBm você precisa baixar 4dBm na potencia do NS Loco M5, ou seja, baixar de 23 pra 19dBm no rádio.

    E assim você ajusta cada cliente pra quem ele compartilhe o mesmo tempo do Rocket, sem ninguém gritando (Sem sinal absurdo tipo -50 e outro a -75dBm), cada cliente com config. diferente afinal cada cliente está numa distancia diferente (E pode ter zona de fresnel com percentual diferente livre de obstaculos. Essa queda de sinal de 108dBm em 1Km que citei é com a zona de fresnel totalmente limpa, linha de visada 3m acima de qualquer obstaculo, já se for apenas 1m acima dos obstaculos isso dá zona de fresnel apenas 60% limpa, o sinal cai 10dBm a mais, o sinal cairia de -59 pra -69dBm, que é sinal insuficiente pra conexão DE QUALIDADE usando MCS12. Convenhamos que 2m de tubo de aço a mais na hora da instalação não são nada no custo de um provedor, custa R$ 15 a mais mas se o cliente paga R$ 50 por mes esse custo não é nada, zona de fresnel limpa é bem possível, e ela faz muuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuita diferença na qualidade da rede (Especialmente nos níveis de sinal).

    Eu resumiria todo seu problema a sinais baixos, não a ruído (Até porque ruído comum é -96dBm, se aplicar SNR de 26dBm isso significaria sinal de -70dBm pra MCS12, mas você tem cliente com -75dBm se sinal, insuficiente de qualquer forma).
    rubem, parabéns pela "aula", foi muito bem explicado. Uma pergunta: no caso de usar MCS, ACK Timeout manual e auto adjust to EIRP limit (automatic desmarcado), como fica a questão da potencia ? Exemplo, pelo datasheet do Nano Loco M5, MCS6 = 18dbm de potencia, o correto seria setar 18dbm de potencia independente da distancia, ou é melhor ajustar conforme a necessidade ?

    Detalhe, usei MCS6 porque a minha rede é MISO, MIMO no transmissão e MIMO/SISO nos clientes. Tenho varios c/ airgrid.

    Abraço.



  5. Tive um problema parecido com o seu, tinha um AP com os mesmos níveis de sinais do seu, porem latência alta, as conexões caindo direto, eu estava operando com canal limpo, porém o meu problema era um PTP que estava a 20 centímetros da minha basestation,e com trafego alto, ela estava em um canal bem distante do meu Ap, porem ele estava gerando auto interferência na minha torre justamente por esta muito próximo, só foi eu afastar ele e vualá, acabou as quedas, latência alta, tudo certo. então além de você verificar interferências externas, clientes com sinal baixo, tem que ver seus equipamentos na torres, se estão próximos de mais, eles tem que ter no minimo 1 metro de afastamento um do outro, da uma olhada nesta questão amigo.






Tópicos Similares

  1. Respostas: 5
    Último Post: 25-05-2011, 13:32
  2. Respostas: 9
    Último Post: 19-01-2009, 12:40
  3. Ambiente X trava tudo, não sei oque fazer?
    Por phyxsius no fórum Servidores de Rede
    Respostas: 3
    Último Post: 23-05-2005, 07:29
  4. Interferência / Ruído
    Por Carlos_Radlink no fórum Redes
    Respostas: 3
    Último Post: 27-08-2004, 09:18
  5. Webmail!!Oque fazer!!!
    Por no fórum UnderLinux
    Respostas: 1
    Último Post: 10-12-2002, 12:00

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L