Duvida: Uma Setorial Basestation 120º Ubiquiti Cobre essa pequena área da foto?

[nelsonjrvoz]

Boa noite amigos do Under Linux, Estou com uma dúvida: Tenho um município pequeno para atender, apenas Oito Mil habitantes.. 01 Km de Largura e 2,49 Km de comprimento.. Consigo atender com apenas uma basestation 120º com uma rocket M5 este município?

Estou enviando uma foto com a marcação do ponto exato da torre de 30 Metros que se encontra instalada.. Eu sei muito bem que 50 clientes é demais para uma rocket M5, mais de acordo com o crescimento vou evoluindo com mais células também!!

[odtec]

dependendo da inclinação da antena vc terá dificuldade de atender os clientas próximos a torre, para esta localidade o mas viável é duas antenas uma encima da outra com uma distancia aproximadamente de três metro, uma cobrindo a área da torre até o meio do mapa, e outra do meia do mapa até o fim do mapa. é uma ideia.

[wondernetwork]

Você não quer atender a cidade toda com apenas uma setorial + rádio né?

rsrsrsr !!! falou pouco ,mais disse tudo.
hoje em dia todo mundo quer ver netflix.(com 4 megas).
30 cliente por painel vai de boooaaa!!

[hudsonsantos00]

Vc poderia ir de 03 Rb912, 03 basestation 16dbi 120º, numa are central se fosse possivel! assim vc cobriria quase 100%!

[dmagno]

Você não quer atender a cidade toda com apenas uma setorial + rádio né?

rsrsrsr !!! falou pouco ,mais disse tudo.
hoje em dia todo mundo quer ver netflix.(com 4 megas).
30 cliente por painel vai de boooaaa!!

Pessoal, quando voces citam "30 cliente por painel vai de boooaaa!!" isso quer dizer o quantitativo de contas (no meu caso, pppoe) do usuário final, correto? Ou seria o número de rádios associado ao setor?

Pensando que seja o número de usuários (e não de rádios), isso quer dizer que se naquele setor, existir somente um rádio, que atenda a, por exemplo, um único prédio, neste existindo 30 usuários pppoe sendo atendidos dentro dele, este setor já estará no limite?

Obviamente este limite de 30 muda conforme o perfil de utilização dos usuários, mas qual o principal componente do rádio (neste caso, o Rocket M5) que limitaria este número a 30? CPU, memória, pps, banda?

Se o rádio rocket estive como ponte (bridge) e o serviço de pppoe e roteamento estiver atrás dele, sendo realizado por uma RB, ainda assim este número limite de 30 permaneceria?

Este número 30 é um consenso prático específico para os rádios Rocket M5, ou para qualquer rádio neste papel?

ps.: sei que o número 30 é um valor aproximado, e como falei deve depender do perfil de utilização médio dos usuários, mas ainda assim tenho as curiosidades acima.

[rubem]

O normal é ter 1 usuário depois de cada CPE.

30 CPE's conectadas simultaneamente, com seus 30 usuários fazendo uso comum tipo abre página (6 segundos de trráfego), para por 30-40 segundos antes de abrir página denovo. 30 nesse uso, com banda tipo 1 ou 2Mbps liberado por CPE, é tranquilo.

Tá, que seja ter um desktop e um smartphone em cada CPE, não pesa muito. Smartphone em uso típico tem consumo baixo, firulas tipo WhatsApp não consomem muita banda na maioria dos smartphones (Os videos vem em resolução otimizada tipo 240p na maioria dos aparelhos, coisa tipo 1MB por minuto de vídeo, e raramente tem vídeo tão longo. As imagens não tem resolução alta, e são compactadas pra caramba (Jpeg com 75% de qualidade ou algo assim).

Usar uma CPE comum pra atender 30 clientes é pedir pra sofrer, pra esse uso precisa fazer um mini-PTP, com equipto dedicado só pra isso, é muito dado pra uma CPE comum plugada num PTMP.

Se tiver 2 ou 3 clientes numa CPE, a CPE vai ordenar isso pra repassar pro AP do PTMP, pesa bem menos que 2 ou 3 CPE's nesse mesmo AP (Porque cada uma vai transmitir por cima da outra, não vai haver agregação de frames ).

Não dá pra falar em "X clientes simultaneos" com tanta precisão porque um adolescente gammer com p2p ligado 24x7 consome por 10 ou 15 senhorinhas que só abrem o facebook 30 minutos por dia antes dos olhos ficarem cansados, são perfis muito diferentes, o jeito é falar num usuário doméstico típico que consome 4 ou 5h de internet, que até fica com equipto ligado mais tempo mas só com tráfego mínimo tipo messenger (Whatsapp no smartphone, facebook no desktop/notebook).

Cliente empresarial também varia, tem os pessoal que acha que a nuvem resolve tudo e tem backup sincronizado o dia todo, consome upload da 8 as 18h, tem o pessoal que usa voip e não precisa alta banda mas precisa ping minúsculo pro voip ser usável, e tem a maioria, que usa só facebook, webmail, e 2 ou 3 páginas comuns abertas, tráfego pequeno.

Se usar MK pra gerenciar os clientes pode ver o quanto de tráfego agregado cada um somou, cansei de ver coisa tipo fulano consumiu 100MB na semana, ciclano consumiu 700MB na mesma semana, beltrano consumiu 4GB na mesma semana, outro fulano nem conectou a semana toda, outro ciclano consumiu 10GB e agora está consumindo tudo o que pode. Como se tira a média se tem gente que nem conecta e outros que usam tudo o que tem pra usar? Descontar os extremos (Excessões) e tirar a média acho que é o melhor jeito.

30 CPE's com TRAFEGO, que seja 1Mbps cada, já vai ser demais pra um Rocket como AP, é muita fila pra ela gerenciar. Mas ter 30 clientes (Cada um numa CPE) com planos de 1 a 5Mbps não é tão ruim, porque na prática só pouco mais da metade vai ter um tráfego mínimo, e só 4 ou 5 vão ter tráfego meio alto, é fácil ter trafego total circulando tipo 15 a 20Mbps tendo conectados uns 50 clientes de 1 a 5Mbps num servidor (Ligado em vários AP's), a média de consumo por cliente é baixa.

Via de regra ou você coloca muitos clientes, ou coloca muita conexão num AP, digamos um Rocket M5 da vida, ou vende 40Mbps (Pra 10 clientes simultaneos) ou vende 40 pacotes de conexão pra usuário comum (Que mal vão consumir 10Mbps). Conforme o perfil dos clientes, e tipo de instalação (CPE de 45° em cima de telhado cheio de reflexo, Airgrid misturado com soluções de dupla polarização, zona de fresnel desrespeitada) é possível ter conexão ruim com números muito menores, não dá pra fazer regra, só falar em média.

[dmagno]

Entendi Rubem.

Mas só para confirmar, quando você cita "30 CPE's com TRAFEGO, que seja 1Mbps cada, já vai ser demais pra um Rocket como AP, é muita fila pra ela gerenciar." Você está se referindo a este Rocket AP fazendo papel de roteador ou de ponte?

Este meu AP ele está como ponte, ou seja, somente deixa passar o tráfego. PPPoE server, rotas e demais serviços estão atrás dele.

[nelsonjrvoz]

Me referi a cobertura de sinal e não de capacidade!! Sei muito bem que uma basestation com Rocket m5 não aguenta 80 conexões, um exemplo!! Mais o que acontece é que já tenho clientes esperando e então essa é a solução até terminar de vez minha rede!! Quando chegar a 20 Clientes nela, obviamente irei ampliar meu POP..

Obrigado pelas respostas...

[nelsonjrvoz]

Você não quer atender a cidade toda com apenas uma setorial + rádio né?

Para começar atendendo alguna clientes que já estão me aguardando sim!! Obviamente que quando chegar a 20 clientes ou mais um pouco, estarei ampliando!! Antes mesmo de chegar aos 20... Obrigado pela resposta amigo!!

[rubem]

Entendi Rubem.

Mas só para confirmar, quando você cita "30 CPE's com TRAFEGO, que seja 1Mbps cada, já vai ser demais pra um Rocket como AP, é muita fila pra ela gerenciar." Você está se referindo a este Rocket AP fazendo papel de roteador ou de ponte?

Este meu AP ele está como ponte, ou seja, somente deixa passar o tráfego. PPPoE server, rotas e demais serviços estão atrás dele.

Como bridge mesmo não tem tanta capacidade.

O chipset do Rocket é um AR7240, o mesmo chipset de um monte de radionhos de mesa de R$ 100, modelos que ficam um lixo como AP de uns 20 notebooks a 2,4GHz.

O problema é que mesmo como bridge o chipset de RF sofre, é um AR9280, é tecnologia de 2007, tem dele em plaquinha mini-pcie de notebook de R$ 1000.
Essa geração de chipset usa mini-cache de 4 ou 8KB, no estilo FIFO, se tem dado na fila, o primeiro a sair será o primeiro que entrou (First in, first out), é fila indiana comum, sem prioridade, se o AR7240 mandou na ordem "errada" azar. Se comunicar com o AR7240 é tranquilo, é barramento pcie entre eles. O problema é que o RX do chipset também tem esse bus operando com palavras de 32b e mini-cache de 4 ou 8KB, se muito dado chegar (Muita CPE respondendo, seja pacote de sincronia ou pacote do usuário) eles não caberão na fila, os últimos serão descartados (Imagina que o chipset está processando as respostas enquanto os pedidos ainda chegam). Esse chipset manda pro AR7240 tudo que é dado, RSSI, aviso de pacote perdido ou ok, detecções de erros, latência, fora dados dos cabeçalhos de wifi (Que vão além do cabeçalho layer3 de ethernet). Alias, ele informa até o consumo dele mesmo! Ele tem uns 6 passos de consumo, e informa pro AR7240 quanto ele está consumindo, serve pro AR7240 tentar reduzir isso via GPIO quando eles são usados em soluções portáteis tipo notebooks, tablets, ou sistemas embarcados onde precisa economia de energia.

Enfim, mesmo em bridge o AR9280 trabalha pra caramba quando tem muita gente conectada (Ou muita banda passando). Já o AR7240 fica mais tranquilo em bridge e só trabalha pesado em roteamento, quem faz o roteamento é ele e não o AR9280 (Que sempre será só uma bridge).

Pro AR9280 trabalhar mais tranquilo não tem jeito, tem que pendurar menos clientes (CPE's), ter instalações caprichadas pra não perder muitos pacotes (O AR9280 informa pro AR7240 que o pacote foi perdido, mas o pacote fica nesse mini-cache de 4 ou 8KB, exceto em TDMA onde a fila é de outra forma e o pacote enviado desocupa o lugar se for grande (Pacote de sincronia e cia não)), instalações sem ruído, sem zona de fresnel meia-boca, sem reflexos de parede, e... não ter muito tráfego pro AR9280 passar também facilita a vida dele.

Nos Rocket AC se não me engano é um chipset só, já é produto da Atheros fundida na Qualcomm, QCA98xx se não me engano. Mas... mesmo nesses chipsets que tem ambas as funções a coisa internamente é separada, tem os mesmos blocos no diagrama mas ao invez de ter 2 invólucros separados a parte de RF foi trazida pro mesmo chipset que a CPU:



Ou seja, usar um produto com chipset único desse em bridge de qualquer forma não desafoga a parte de RF, só desafoga a CPU.
(E as CPU's evoluiram muito, de um Nanostation5 de 150MHz de 2003, pra 720MHz num NanoBeam AC, a coisa melhorou muito, porque cada vez precisa mais capacidade de processamento pros milhares de pacotes pequenos e conexões semi-abertas de hoje (Em 2003 só p2p tinha conexão semi-aberta, hoje toda página na web tem, todo messenger tem, e por aí vai, o uso de banda não cresceu tanto mas o numero de pacotes e conexões por segundo que cada usuário faz cresceu horrores, quem sofre com isso são os chipsets, precisam agregar e desagregar frames, montar pacotes quebrados e as vezes esperar partes perdidas serem reenviadas, ah se tudo fosse simples como um download em instância única a 1Mbps!)

[dmagno]

Muito bom o seu texto Rubem!

Atendo atualmente a clientes via rede Wireless, e sempre estive em busca de números que me alertassem quanto a aproximação de um possível nível de saturamento de rádios (ubnt) e RouterBoards, seja em relação ao número de clientes, e/ou banda e/ou PPS.

Por exemplo, considerando uma região real em específico que atendo atualmente, que assim está desenhada:

Backbone Internet (Meu data-center) -> Back Haul (ptp Intelbras APC5M+) -> Torre

Na torre, possuo 4 Rocekts com paineis setoriais fechando 360°, além de 4 NanosBeam fechando ptp com alguns clientes mais distantes. Todos estes rádios estão ligados localmente a uma RB1100, que oferece o serviço de PPPoE, com autenticação via Radius no meu Data-Center e IP de Internet válido para cada usuário PPPoE.

Todos esses equipamentos tem seus respectivos gráficos sendo gerados via MRTG.

Mas eu olhando para os gráficos, me falta sensibilidade (números de alerta) que eu interprete como sendo um possível problema de saturamento. Por isso fiz aquela argumentação sobre o número 30 de clientes PPPoE por Rocket M5 acima.

Estou atrás destes números, mesmo que medianos, somente para que eu tenha um ponto de partida:

Rockets M5:
Limite de CPEs: x
Limite de Usuários PPPoE: x
Limite de banda: x
Limite de PPS: x

RB1100:
Limite de Usuários PPPoE: x
Limite de PPS: x

PBE-M5-300:
Limite de Usuários PPPoE: x
Limite de banda: x
Limite de PPS: x

Desta forma, poderia agir de forma preventiva, sendo alertado via Nagios.

Hoje, de forma geral, estes são alguns números desta torre:

Clientes PPPoE: 215
Banda: Picos de 75MB down/15MB Up.
PPS: Picos de 14.000 (up + down) -> esta foi a razão de eu ter adicionado um novo fabricante na minha rede wireless (Intelbras no Back Haul). Já tive experiências práticas ruins nos Rockets M5 com números próximos aos 9/10K PPS (up + down).

[rubem]

Sobre um numero diferente de CPE's e clientes PPPoE por AP eu vou ficar devendo, nunca ví uso onde a CPE não fosse o autenticador PPPoE.

(Uma CPE por cliente, autenticação feita pela CPE, logo, uma sessão pppoe por CPE)

E tenho visto reclamação com poucos usuários e gente feliz com muitos, então repasso o que já ví:

Rocket M5
CPEs: 20 a 40 simultaneos
Limite de banda: 20 a 40Mbps em PTMP
Limite de PPS: 8Kpps em PTP ótimo, 5Kpps em PTP ruim, 5Kpps em PTMP (Não ví ptmp com trafego maior).

RB1100
300 usuários PPPoE num e CPU estrangulada, 450 noutro e com CPU abaixo dos 50%.
Mas a AH x2 é pra ir pra casa dos 600-800 usuários pppoe.

PBE-M5-300 só ví em PTP (Ou cliente comum de internet), 10Kpps em PTP bom passando 80Mbps foi o que testei, mas tem quem diga que vai muito além. Não ponho a mão no fogo por ela, não é um grande hardware poderoso pro meu gosto.

Também não ví o Rocket operando bem depois dos 8Kpps, é um hardware meio velho e pobre pra isso (Pro meu gosto), mas tem quem diga que usa com mais de 15Kpps, talvez em PTP curto com sinal altíssimo dê sim, não posso afirmar mais do que já medi.

E o fator instalação pesa muito, aqui do lado numa cidade um colega trocou Rocket M5 por Rocket AC e igual tem desempenho meia-boca com uns 20-25 simultaneos de 1 a 5Mbps, porque faz muita instalação porca com CPE baixa demais, a maior capacidade de processamento do Rocket AC não fez nenhuma diferença porque o gargalo da coisa são os pacotes perdidos por problemas físicos.

[dmagno]

Sobre um numero diferente de CPE's e clientes PPPoE por AP eu vou ficar devendo, nunca ví uso onde a CPE não fosse o autenticador PPPoE.

Mas existe alguma razão para ser assim? Aqui todos os meus clientes fazem a conexão PPPoE, seja no próprio PC ou em um roteador.

Todos os meus clientes recebem endereço IP válido, não faço NAT.

A maioria dos meus clientes estão em condomínios verticais (prédios) então coloco um rádio no terraço do prédio e todos ali abaixo do rádio são atendidos via cabo ethernet.

Também nos condomínios horizontais (de casa) fecho um ptp para aquele condomínio, e na lan do rádio cliente do ptp eu ligo rádios setoriais (normalmente NS5, interno ao condomínio) e cada casa tem uma CPE (NanoBeam) fechando enlace para esse AP interno ao condomínio.

E o fator instalação pesa muito, aqui do lado numa cidade um colega trocou Rocket M5 por Rocket AC e igual tem desempenho meia-boca com uns 20-25 simultaneos de 1 a 5Mbps, porque faz muita instalação porca com CPE baixa demais, a maior capacidade de processamento do Rocket AC não fez nenhuma diferença porque o gargalo da coisa são os pacotes perdidos por problemas físicos.

Bem interessante isso. Até hoje eu não consegui achar um parâmetro (ou conjunto deles) que me desse uma boa referência de alinhamento de rádios, isso falando de Ubnt, somente trabalho com eles.

Então tenho enlaces com um CCQ baixo mas bomthoughtput, com CCQ em 100% mas praticamente inavegável, nível de sinal bom (-55) mas com thoughtput péssimo, nível de sinal alto (-75/80) e com thoughtput elevado. Também a mesma relação (inversa) com ranges de frequências poluídos e sem poluição, e por aí vai. Enfim, ainda não encontrei uma combinação de sinais que me garantisse: este enlace terá um ótimo thoughput, sem mesmo testa-lo antes.

[rubem]

Sobre a autenticação na CPE, em cliente doméstico ou empresarial não faz o menor sentido colocar a autenticação no PC (Ah o MALDITO hotspot), porque ele pode ter mais de um roteador wifi (Ou trocar, os baratos pifam todo ano), pode ter desktop ou notebook com problema no wifi (Ou que não conecta na encriptação default do roteador e o cliente não sabe mudar), pode ter TV pra plugar (E elas raramente tem discador PPPoE), enfim, é só questão de tirar a necessidade daquele produto velho e ridículo de senhorinha de 70 anos que é o desktop ou notebook, e pra não escravizar o cliente (Ou tratar ele como burro incompetente por não poder fazer algo tão simplório quanto trocar um roteador porque o provedor não passa os dados de autenticação pro cliente (Ou pior, coloca senha no roteador DO cliente e não passa pra ele).
Em condomínios não sei como isso funcionaria, mas pra cliente isolado se você tratar ele como burro e castrar o acesso a tudo ele vai fazer coisas de burro tipo resetar roteador e etc, já onde você entrega o cabo ethernet pronto pra usar internet (Com autenticação na CPE, ou num roteador interno), e explica que daquele cabo pra frente (PC, outro roteador, TV, voip phone) é responsabilidade dele, dá muito menos dor-de-cabeça.
(E nesses casos é bom vender pro cliente roteador com WPS e que já venha de fábrica com um pin configurado escrito em etiqueta debaixo do roteador, insiste pra que ele use do jeito que veio (Porque colocar nome em rede é um prato cheio pra malandro, assim se sabe quando o inquilino está em casa, ou de quem é o apto, ou o nome do morador/filho (Sequestro simulado, já dá o nome do filho...), enfim, não vejo NENHUM motivo pra não usar o SSID original dos AP's, se o cliente tiver problemas ele reseta e conecta sem dificuldades, é um mundo muito mais tranquilo)


Throughput varia muito conforme reflexos de sinal, SNR, e o ruído indicado não se refere ao uso do canal, pode ter um cliente ou AP na vizinhança usando o canal e como são sinais legítimos eles não aparecem como ruído (E se for cliente não adianta escanear SSID que não aparece nada no canal, tem que ver isso por uso do canal ignorando se é ruído ou sinais legítimos de wifi, nos UBNT é o Airview, em MK é Channel Usage, Frequency Usage, ou Spectral Scan conforme o modo/versão/produto), os reflexos das costas e laterais (Paredes! Antena do lado de parede é um erro terrível) tem efeito pior com grandes bandas, pra coisa pouca tipo 1 ou 2Mbps pra 1 cliente não tem problema, mas hora que o tráfego aumenta o numero de pacotes refletidos e captados de volta aumenta e por isso aumenta ainda mais o numero de pacotes enviados (Tem que reenviar os perdidos e os novos), que só aumenta o numero de refletidos captados de volta, e assim tudo só piora.
Faço muito PTP da cidade pra fazendas, na cidade é bem comum ter uso baixo em canal que incomoda, tem que testar 2 ou 3 canais de baixo uso até chegar num onde dá throughput bom, mas no campo não há ruído, em PTP de fazenda pra fazenda qualquer coisa serve, o único problema é zona de fresnel e reflexos.

(E as vezes fazem torres com cantoneiras largas (Amadorismo), mas tão largas que lá no fim do mundo onde nenhum SSID se escaneia, aparece coisa tipo ruído -85dBm, oras, é impossível isso! Aí você vai e põe a antena uns metros ACIMA da torre mal-feita, ou faz uma estrutura lateral pra colocar a antena mais longe da torre, e o ruído milagrosamente some, porque não era ruído mas sim só reflexo dele mesmo na torre! Em casas também sempre ví isso, antena com telhado ou parede nas costas dando throughput péssimo, ou então com calha de aço na frente e abaixo da antena, num angulo perfeito pra pegar reflexo em cheio, as vezes é mecher a antena uns 50cm de lugar e resolve)

Throughput também depende do tipo de pacote, trafego de internet vai ter pacote de tudo que é tamanho, mas os testadores de throughput dos roteadores é meio porco e usa pacote de tamanho fixo (Só 64B, ou só 512B, ou só 1400B), no mundo real isso nunca existe então o trafego real nunca baterá com o throughput de medidor. Eu faço muito PTP pra empresa (Fazendas são empresas...), trafego de rede interna corre solto, serviços do Windows futricando a rede atrás de novos dispositivos gera muito tráfego por isso evito bridge a todo custo, mas onde não dá é fácil ver trafego esporádico mesmo sem nada aberto nos desktops ou notebooks (Desplugado de internet, digamos), e fazendo teste de trafego de um micro ao outro, o trafego de um 3º pro 4º dá uma leve oscilada na velocidade dos primeiros, tipo, micro 1 e 2 trocam um arquivo de 500MB a 10Mbps, no mesmo PTP o micro 3 manda uma requisição besta de snmp pro micro 4, rajadinha de 50Kbps, mas... o trafego do 1 pro 2 oscilada caindo por uns instantes pra uns 9Mbps! Porque o pacote pequeno tomou tempo de processamento pra montar tudo exatamente como um pacote grande tomaria, trafegar um pacote de 200B toma o mesmo tempo e processamento que um pacote no limite do tamanho, de uns 1480B, e obviamente com pacotes maiores o throughput será maior.

Em firmware que exibe o trafego em PPS é fácil ver o numero enorme de pacotes e o tráfego pequeno, culpa de softwares tipo skype, whatsapp, p2p mal configurados, antivírus e ferramentas de segurança inúteis, adwares instalados na forma de complementos ou serviços (E o usuário nem nota), problemas que a 10 anos atrás não tinha (Só messengers tinha pacotes pequenos e constantes). Há uma economia de trafego por cliente fazendo isso, mas quem se ferra é o provedor, são os concentradores e PTP's que se lascam pra levar milhares de pacotes com tráfego de apenas centenas de bytes, pra minimizar esse problema dá pra fazer vlan e rotear totalmente o transporte, mas não resolve tudo.

[dmagno]

Boa noite amigos do Under Linux, Estou com uma dúvida: Tenho um município pequeno para atender, apenas Oito Mil habitantes.. 01 Km de Largura e 2,49 Km de comprimento..

Nelson, me desculpe por ter alugado o seu post!

Rubem,

A visão que tinha sobre entregar a responsabilidade da conexão PPPoE diretamente ao usuário final é justamente ao contrário da sua. Penso que desta forma eu dou independência a ele (usuário) a fazer o que bem entender com sua conexão. Ou seja, atendo desde os usuários mais leigos, onde uma simples configuração em um roteador wireless caseiro já resolve tudo, desde a aquele usuário mais avançado, que pretende colocar o seu endereço IP válido em uma RouterBoard e realizar redirecionamento de portas para poder assistir as suas câmeras de segurança residenciais do trabalho, por exemplo. E isso sem a minha intervenção, já que não tenho nada configurado por lá, ao contrário se eu configurasse a CPE com PPPoE, Nat e etc. Teria que ter a minha intervenção (realizar o redirecionamento de portas, no exemplo citado das câmeras) gerando mais demanda para mim e menos autonomia ao usuário.

Ou estamos falando de coisas diferente?

"(E as vezes fazem torres com cantoneiras largas (Amadorismo), mas tão largas que lá no fim do mundo onde nenhum SSID se escaneia, aparece coisa tipo ruído -85dBm, oras, é impossível isso! Aí você vai e põe a antena uns metros ACIMA da torre mal-feita, ou faz uma estrutura lateral pra colocar a antena mais longe da torre, e o ruído milagrosamente some"

Você teria uma noção de medida do que seria um cantoneira larga?

Eu aqui costumo utilizar polimontes, que são justamente para afastar a antena da torre, mas segundo sua informação, por xemplo, se a haste deste polimonte (onde é fixado a antena), for também muito larga, então o problema continuaria, correto?

Para mim o objetivo destes polimontes seria para poder otimizar o número de rádios em uma cantoneira da torre (poder usar mais rádios no mesmo espaço) mas pela sua citação, me parece que a coisa vai além disso.

Uma shield (escudo) na antena setorial resolveria esse problema?

[mathcardoso]

Muito bom o seu texto Rubem!

Atendo atualmente a clientes via rede Wireless, e sempre estive em busca de números que me alertassem quanto a aproximação de um possível nível de saturamento de rádios (ubnt) e RouterBoards, seja em relação ao número de clientes, e/ou banda e/ou PPS.

Por exemplo, considerando uma região real em específico que atendo atualmente, que assim está desenhada:

Backbone Internet (Meu data-center) -> Back Haul (ptp Intelbras APC5M+) -> Torre

Na torre, possuo 4 Rocekts com paineis setoriais fechando 360°, além de 4 NanosBeam fechando ptp com alguns clientes mais distantes. Todos estes rádios estão ligados localmente a uma RB1100, que oferece o serviço de PPPoE, com autenticação via Radius no meu Data-Center e IP de Internet válido para cada usuário PPPoE.

Todos esses equipamentos tem seus respectivos gráficos sendo gerados via MRTG.

Mas eu olhando para os gráficos, me falta sensibilidade (números de alerta) que eu interprete como sendo um possível problema de saturamento. Por isso fiz aquela argumentação sobre o número 30 de clientes PPPoE por Rocket M5 acima.

Estou atrás destes números, mesmo que medianos, somente para que eu tenha um ponto de partida:

Rockets M5:
Limite de CPEs: x
Limite de Usuários PPPoE: x
Limite de banda: x
Limite de PPS: x

RB1100:
Limite de Usuários PPPoE: x
Limite de PPS: x

PBE-M5-300:
Limite de Usuários PPPoE: x
Limite de banda: x
Limite de PPS: x

Desta forma, poderia agir de forma preventiva, sendo alertado via Nagios.

Hoje, de forma geral, estes são alguns números desta torre:

Clientes PPPoE: 215
Banda: Picos de 75MB down/15MB Up.
PPS: Picos de 14.000 (up + down) -> esta foi a razão de eu ter adicionado um novo fabricante na minha rede wireless (Intelbras no Back Haul). Já tive experiências práticas ruins nos Rockets M5 com números próximos aos 9/10K PPS (up + down).

Uso de uma 1100 com 250 clientes

[rubem]

Nelson, me desculpe por ter alugado o seu post!

Rubem,

A visão que tinha sobre entregar a responsabilidade da conexão PPPoE diretamente ao usuário final é justamente ao contrário da sua. Penso que desta forma eu dou independência a ele (usuário) a fazer o que bem entender com sua conexão. Ou seja, atendo desde os usuários mais leigos, onde uma simples configuração em um roteador wireless caseiro já resolve tudo, desde a aquele usuário mais avançado, que pretende colocar o seu endereço IP válido em uma RouterBoard e realizar redirecionamento de portas para poder assistir as suas câmeras de segurança residenciais do trabalho, por exemplo. E isso sem a minha intervenção, já que não tenho nada configurado por lá, ao contrário se eu configurasse a CPE com PPPoE, Nat e etc. Teria que ter a minha intervenção (realizar o redirecionamento de portas, no exemplo citado das câmeras) gerando mais demanda para mim e menos autonomia ao usuário.

Ou estamos falando de coisas diferente?

"(E as vezes fazem torres com cantoneiras largas (Amadorismo), mas tão largas que lá no fim do mundo onde nenhum SSID se escaneia, aparece coisa tipo ruído -85dBm, oras, é impossível isso! Aí você vai e põe a antena uns metros ACIMA da torre mal-feita, ou faz uma estrutura lateral pra colocar a antena mais longe da torre, e o ruído milagrosamente some"

Você teria uma noção de medida do que seria um cantoneira larga?

Eu aqui costumo utilizar polimontes, que são justamente para afastar a antena da torre, mas segundo sua informação, por xemplo, se a haste deste polimonte (onde é fixado a antena), for também muito larga, então o problema continuaria, correto?

Para mim o objetivo destes polimontes seria para poder otimizar o número de rádios em uma cantoneira da torre (poder usar mais rádios no mesmo espaço) mas pela sua citação, me parece que a coisa vai além disso.

Uma shield (escudo) na antena setorial resolveria esse problema?

Ah sim, se você entrega IP público pro cliente aí a coisa muda.
Acho que pra cada provedor via rádio com AS tem uns 20 entregando IP interno, aí de qualquer forma esses redirecionamentos precisam ser feitos no servidor e balance do provedor (E com a CPE fazendo a autenticação, usando roteador wifi depois dele como bridge na casa do cliente, pode acessar remotamente a CPE e redirecionar as portas necessárias sem precisar visita).


Sobre cantoneiras largas em torres, imagina chegar e encontrar uma estrutura de uns 25cm de largura, com cantoneira de umas 2 ou 2,5", vira quase isso aqui mas visto pela lateral:
https://under-linux.org/attachment.p...1&d=1391283789
São 10 a 15cm de aço reto, refletindo em cheio de volta pra antena!
(Na imagem isso é a emenda dos gomos, sem problemas, o problema é estrutura triangular ou quadrada com cantoneiras largas)

Tubo redondo não é um problemão porque é redondo, reflete de forma convexa, o sinal se perde pra todo lado, mas em superfície plana a reflexão é direta, se chega em 90° reflete em 90°.
Seria o caso de uma antena colocada a 90° dessa parede:
http://img.olx.com.br/images/14/142505091462742.jpg
Tá numa distancia razoável então talvez não atrapalhe PTP curto (Com ack-timeout pequeno).

Eu tive problema por cagada minha mesmo, se colocar um disco mais ou menos nessa posição do disco aqui no meio:
https://upload.wikimedia.org/wikiped...reccionais.jpg
Nanobridge se bem me lembro. Mas estava até mais perto da parede, na pressa do cliente deixei baixo e quase 1 palmo com as costas pra parede, a uns 20cm, funcionou o basicão pra internet via rádio do momento só pra emitir NFE, era pra ser provisório mas como ficou bom na internet lerda de uns 600Kbps acabei deixando por esquecimento, hora que teve mais equipamento na empresa aí os problemas surgiram, ping de 20 a 100ms (Em 5Km com visada linda) e 1/4 perdidos, foi só erguer a mesma antena uns 2m acima da parede que o ruído sumiu e tudo se resolveu.

Esses reflexos em torre dependem do angulo e tipo de superfície, tubo incomoda pouco (Imagine se eles fossem espelhados e você colocasse lampadas ao invés de antenas), e se as costas da antena não estão a exatos 90° de uma grande superfície há pouco incômodo.

Shield ajuda, como eles ficam perto da antena o reflexo volta em picosegundos, tá no tempo que o chipset ignora pacotes, o problema é o reflexo ocorrer mais longe e o pacote voltar em alguns microsegundos, aí o chipset precisa perder tempo analisando pra ver que é pacote dele mesmo, esse tempo desperdiça processador.

Shield pra antena lateral nem sempre é tão necessário porque se você seta um canal em uso, digamos 5735MHz, em largura de 20MHz, o chipset aplica um filtro passa-faixa que atenua uns mais de 30dBm abaixo de uns 5720MHz e acima de uns 5750MHz (Atenua uns 20dBm no começo do canal vizinho, que começa (Nesse exemplo) em 5745MHz, por isso não é bom usar canais vizinhos em antenas vizinhas, e sim deixar um espaçamento de pelo menos 20MHz), ou seja, se do lado ninguém emitir numa frequência não-atenuada pelo circuito, não tem muito problema, teria que ser numa potência bem alta pra incomodar (E se a relação frente-costas de um disco for só 20dBm, ele manda muita potência pras costas, colocar 2 dessas de costas, uma a 180° da outra, sem blindagem extra, em canal vizinho (Sem espaço vazio entre os canais em uso), é o pior tiro no pé que se pode dar.

E se olhar o diagrama de irradiação das antenas, as vezes tem emissão com ganho razoavel não exatamente nas costas, mas digamos a 140° (A partir da frente), aqui um exemplo:
http://2.bp.blogspot.com/-IXg0WpS09s...ra+G2BCX.3.bmp
Pra cima das costas tem um lóbulo emitindo com ganho de quase 2dBi, é ganho e não atenuação. Se o radio está com 20dBm, nesse ponto ele vai emitir com quase 22dBm EIRP, ou seja, pra cima dessa antena nas costas dela (Onde pode ter outra antena no outro lado da torre, 2m acima) vai ter tanto sinal quanto haveria se colocasse alí um NS Loco a 9dBm de potência virado pra cima! Se as antenas nessa posição estiverem em canais distantes não tem problema, mas quem usa 40MHz tem um espectro meio estreito pra trabalhar, sempre vai ter um canal do lado, e a emissão de bigode fora da faixa atinge uns 2 ou 3MHz fora da faixa (Adentrando o canal vizinho), assim como a atenuação no canal vizinho só é grande uns 4 ou 5MHz pra fora do canal atual, ou seja, o mixer, misturador e ADC pegam um pouco de pacotes do canal vizinho (Eles são descartados, mas estão lá no ADC estragando a qualidade de sinais baixos) e o radio no canal vizinho emite algumas porcarias no canal do rádio, é sinal baixo mas se o SNR não for excelente você perde pacotes por conta disso, umas portadoras estarão comprometidas, se estiverem ilegíveis você precisa reenviar o pacote inteiro só por culpa de 1 das 50 ou 60 portadoras prejudicada lá na beirada do canal.

[dmagno]

Ah sim, se você entrega IP público pro cliente aí a coisa muda.
Acho que pra cada provedor via rádio com AS tem uns 20 entregando IP interno, aí de qualquer forma esses redirecionamentos precisam ser feitos no servidor e balance do provedor (E com a CPE fazendo a autenticação, usando roteador wifi depois dele como bridge na casa do cliente, pode acessar remotamente a CPE e redirecionar as portas necessárias sem precisar visita).


Sobre cantoneiras largas em torres, imagina chegar e encontrar uma estrutura de uns 25cm de largura, com cantoneira de umas 2 ou 2,5", vira quase isso aqui mas visto pela lateral:
https://under-linux.org/attachment.p...1&d=1391283789
São 10 a 15cm de aço reto, refletindo em cheio de volta pra antena!
(Na imagem isso é a emenda dos gomos, sem problemas, o problema é estrutura triangular ou quadrada com cantoneiras largas)

Tubo redondo não é um problemão porque é redondo, reflete de forma convexa, o sinal se perde pra todo lado, mas em superfície plana a reflexão é direta, se chega em 90° reflete em 90°.
Seria o caso de uma antena colocada a 90° dessa parede:
http://img.olx.com.br/images/14/142505091462742.jpg
Tá numa distancia razoável então talvez não atrapalhe PTP curto (Com ack-timeout pequeno).

Eu tive problema por cagada minha mesmo, se colocar um disco mais ou menos nessa posição do disco aqui no meio:
https://upload.wikimedia.org/wikiped...reccionais.jpg
Nanobridge se bem me lembro. Mas estava até mais perto da parede, na pressa do cliente deixei baixo e quase 1 palmo com as costas pra parede, a uns 20cm, funcionou o basicão pra internet via rádio do momento só pra emitir NFE, era pra ser provisório mas como ficou bom na internet lerda de uns 600Kbps acabei deixando por esquecimento, hora que teve mais equipamento na empresa aí os problemas surgiram, ping de 20 a 100ms (Em 5Km com visada linda) e 1/4 perdidos, foi só erguer a mesma antena uns 2m acima da parede que o ruído sumiu e tudo se resolveu.

Esses reflexos em torre dependem do angulo e tipo de superfície, tubo incomoda pouco (Imagine se eles fossem espelhados e você colocasse lampadas ao invés de antenas), e se as costas da antena não estão a exatos 90° de uma grande superfície há pouco incômodo.

Shield ajuda, como eles ficam perto da antena o reflexo volta em picosegundos, tá no tempo que o chipset ignora pacotes, o problema é o reflexo ocorrer mais longe e o pacote voltar em alguns microsegundos, aí o chipset precisa perder tempo analisando pra ver que é pacote dele mesmo, esse tempo desperdiça processador.

Shield pra antena lateral nem sempre é tão necessário porque se você seta um canal em uso, digamos 5735MHz, em largura de 20MHz, o chipset aplica um filtro passa-faixa que atenua uns mais de 30dBm abaixo de uns 5720MHz e acima de uns 5750MHz (Atenua uns 20dBm no começo do canal vizinho, que começa (Nesse exemplo) em 5745MHz, por isso não é bom usar canais vizinhos em antenas vizinhas, e sim deixar um espaçamento de pelo menos 20MHz), ou seja, se do lado ninguém emitir numa frequência não-atenuada pelo circuito, não tem muito problema, teria que ser numa potência bem alta pra incomodar (E se a relação frente-costas de um disco for só 20dBm, ele manda muita potência pras costas, colocar 2 dessas de costas, uma a 180° da outra, sem blindagem extra, em canal vizinho (Sem espaço vazio entre os canais em uso), é o pior tiro no pé que se pode dar.

E se olhar o diagrama de irradiação das antenas, as vezes tem emissão com ganho razoavel não exatamente nas costas, mas digamos a 140° (A partir da frente), aqui um exemplo:
http://2.bp.blogspot.com/-IXg0WpS09s...ra+G2BCX.3.bmp
Pra cima das costas tem um lóbulo emitindo com ganho de quase 2dBi, é ganho e não atenuação. Se o radio está com 20dBm, nesse ponto ele vai emitir com quase 22dBm EIRP, ou seja, pra cima dessa antena nas costas dela (Onde pode ter outra antena no outro lado da torre, 2m acima) vai ter tanto sinal quanto haveria se colocasse alí um NS Loco a 9dBm de potência virado pra cima! Se as antenas nessa posição estiverem em canais distantes não tem problema, mas quem usa 40MHz tem um espectro meio estreito pra trabalhar, sempre vai ter um canal do lado, e a emissão de bigode fora da faixa atinge uns 2 ou 3MHz fora da faixa (Adentrando o canal vizinho), assim como a atenuação no canal vizinho só é grande uns 4 ou 5MHz pra fora do canal atual, ou seja, o mixer, misturador e ADC pegam um pouco de pacotes do canal vizinho (Eles são descartados, mas estão lá no ADC estragando a qualidade de sinais baixos) e o radio no canal vizinho emite algumas porcarias no canal do rádio, é sinal baixo mas se o SNR não for excelente você perde pacotes por conta disso, umas portadoras estarão comprometidas, se estiverem ilegíveis você precisa reenviar o pacote inteiro só por culpa de 1 das 50 ou 60 portadoras prejudicada lá na beirada do canal.

Rubem, não querendo abusar mas já abusando, você poderia me dar uma força também no tópico abaixo?

Não tem relação com rádio, agora é com fibra!

https://under-linux.org/showthread.php?t=180077&page=4