Página 2 de 2 PrimeiroPrimeiro 12
+ Responder ao Tópico



  1. Rubem, de novo obrigado pela resposta.

    Vi sua colocação sobre as redes mesh e de fato não tenho ainda como fazer um debate sobre, já que iremos testar ainda e estamos seguindo algumas diretrizes das comunidades que atuam com open-wrt.
    Na Argentina por exemplo existem indicadores de que em 10 hops eles conseguem ainda transito de 5 Mbps com qualidade, mas, isso veio através de relatos, logo, estamos fazendo uma experiência e dai ao verificar os problemas partir pro mão na massa.

    Outro ponto importante é que a mesh ficará assim :
    1 - eles se interligarão por 5.8 Ghz;
    2 - O usuário em sua residência poderá acessar o wifi em 2.4 Ghz, ou seja, não é sinal aberto para todos é só pro usuário, que se desejar poderá puxar um cabo de rede vindo deste TPLink para outro AP dentro de sua casa e até desabilitar o 2.4 do TPLink ou ainda colocar tudo como 5.8 Ghz já que o modelo que estamos usando tem antenas dualband

    Compreendi que o uso do AC vai ser bacana se todos estiverem com -60 dBm pra baixo e iremos levar isso em consideração. Da mesma forma iremos fazer Traffic Shapping para conteúdos mais pesados e não tenho dúvidas que a guerra mesmo vai ser com streaming e VOD, mas, iremos equalizar isso com cache e o resto é informar a galera para o bom uso da rede até se começar a migrar pra fibra ou cabeamento UTP blindado.

    No item 2 vc fala se for usar AC em MCS9 caberá muito mais. Eu vi a tabela e fiquei confuso pq a parte azul que se relaciona com o AC só tem em sua grande maioria com canal de 80Mhz e pra Pt-MPt acho que ele só usará até 40 Mhz não ? Ou o VHT MCS Index é exatamente a relação de MCS que está na coluna do padrão N tb ?

    Sei que é complexo delimitar número de conexões simultâneas e muito provavelmente só se colocando o cenário posto na prática pra poder ter este indicador e dai testar estas variações para ver o impacto que ela terá nesta relação de qtde de usuários simultâneos.

    De qq forma obrigado pelas dicas e se quiser podemos fechar o tópico, salvo se houver como desenhar uma tabela da forma como o post do luciano franz fez e que possa ser publicada para deixar aqui no post, ou seja, seguinte cenário :

    No Chutômetro :-)

    Cenários de SUPERPOP :

    Cenário 1
    ERBs : LiteBeam AC AP 16 dBi
    CPE : LiteBeam AC até 23 dBi ou NanoBeam AC

    802.11ac..................30 Mbps.............15Mbps download x 15Mbps de Upload


    Isso dá 30Mbps com compartilhamento de 4x1 são 120 Mbps vendidos ou:

    - 56 clientes de 2048Kbps cada um em cada painel setorial (SuperPOP)

    - 28 clientes de 4096Kbps cada um em cada painel setorial (SuperPOP)


    Cenário 2
    ERBs : Rocket M5 AC com Setorial AC 21 dBi 60º
    CPE : LiteBeam AC até 23 dBi ou NanoBeam AC

    802.11ac..................50 Mbps.............25Mbps download x 25Mbps de Upload


    Isso dá 50Mbps com compartilhamento de 4x1 são 200 Mbps vendidos ou:

    - 80 clientes de 2048Kbps cada um em cada painel setorial (SuperPOP)

    - 50 clientes de 4096Kbps cada um em cada painel setorial (SuperPOP)


    Como condicionante para se chegar a estes cenários propostos os sinais das CPEs devem estar abaixo de -60 dBm.
    * Dai o que mais devemos colocar como condicionantes ? Heavy Users ?

  2. O que mexi com mesh foi só na faculdade, o problema era mais ou menos assim: Enfileira 5 nós, em situação normal no último nó consegue throughput X, sem ninguém nos nós intermediários consumindo nada de mais, mas... se alguém no primeiro nó consome toda a banda que conseguir (Na época era com 802.11G, consumo de uns 10Mbps) no último nó a banda disponível cai pra 0,01X.

    Quem estava nos nós iniciais tinha ping melhor, e mais banda disponível, no último nó só tinha ping baixo e velocidade boa se nos nós centrais não tinha ninguém usando. Mas eram tempos de chipset RTL8186, roteadores com 8MB de Ram, isso deve ter melhor, só não acredito que ainda não haja essa desequalização entre quem está perto e quem está longe do nó inicial.

    Sobre a falta de MCS9 em 20MHz (Com 1, 2 ou 4 chains), o problema é que num coding rate onde você usa 5/6 (Cinco sextos) dos 64 pontos de ums MCS7 na constelação (64 amostras numa transformada de Fourier) você está usando 83% deles com dados transmitidos, sobram 17% (1/6, um sexto) pra usar em dados de retransmissão. O problema com MCS9 em AC em 20MHz é que são 256 pontos (256QAM), 256 amostras numa transformada, qualquer sinal minimamente mais baixo que devia já torna ilegível uns 25 pontos da borda, 25 de 256 é quase 10% de amostras ilegíveis, e... um coding rate 5/6 tem só 17% de amostras pra usar pra retransmissão, então em uma situação praticamente normal você já começaria com só 7% de margem de reenvio.

    Com 40MHz ainda é 256QAM, mas tem o dobro de portadoras, com um sinal um pouco ruim você terá as portadoras da borda com alguns erros, o numero de erros será igual em 20MHz, mas o numero PERCENTUAL cai de 10% pra 5%, ou seja, você tem agora uma margem de amostras que não estão enviando dados (E pode ser usada pra reenvio do que foi perdido, ou de sincronia) de 12%.

    Um 512QAM também teria esse problema até em 40MHz, é muito ponto,

    Com MCS8 em AC o coding rate é 3/4, isso dá 75% enviando dado legítimo, e 25% enviando nada, ou retransmissão. Se por sinal baixo perder a legibilidade dos pontos da borda (E eles são os primeiros a perder), dos 25% se comer 10% ainda sobra 15%, margem suficiente pra reenviar pacotes.

    Um MCS9 em 20MHz, se existisse, seria assim: Ia permitir uns 86Mbps de data rate, mas... com uma mísera queda de sinal, digamos com sinal -55dBm, essa margem de apenas 7% das amostras podendo reenviar dado perdido, ia obrigar o rádio a usar algumas das 83% das amostras pra reenviar dado perdido, com -50dBm você teria digamos 40Mbps de throughput, mas com -55dBm teria tanto reenvio em usando amostra que não devia ser usada pra isso, que o throughput cairia pra uns 20Mbps!

    O que EU gostaria é que existisse um MCS com 256QAM e um coding rate de 1/2, seria um data rate de uns 50Mbps, mas teria METADE das amostras ociosas, poderia ter um perda gigante de pacotes que teria como reenviar eles sem afetar o throughput principal. Mas... o usuário usa viseira de burro, só enxerga velocidade máxima (Conseguível em bancada ou laboratório), não pagaria por um equipamento dualchain que fale em data rate de 100Mbps em 20MHz.


    Sobre fazer uma tabela sobre quanto cada modo consegue entregar, essa idéia não faz sentido porque cada modo tem VÁRIAS larguras de canais, várias modulações e coding rates.

    Não faz sentido falar "Em A se entrega 9Mbps agregado". Provavelmente isso se refere a 64QAM em A, que é o data rate de 54M.
    Mas... o data rate de 48M terá numeros BEM DIFERENTES!
    E o data rate de 36M terá números AINDA mais diferentes!

    Pra ter todos os clientes usando o maior data rate do modo você precisa todos com sinal bem alto, digamos -55dBm pra A e N. Quem tem isso? Será que 0,1% dos provedores do Brasil conseguem isso?

    Se você consegue, com equipamentos acessíveis nos clientes (CPE de R$ 250 pra cliente próximo, e de R$ 450 pra cliente distante) equalizar todos apenas em -65dBm, faz mais sentido usar 24M em A, ou MCS12 em N (78M). E aí, a tabela fala em 54M em A, e MCS7 ou MCS15 em N, pra que serve uma tabela que fala nos MAIORES data rates no modo?

    Por isso prefiro falar em data rate: Em 16QAM (Seja A ou N, seja em 10, 20, 30 ou 40MHz de largura de canal) conte com 30% do data rate. Com 64QAM conte com uns 35% do data rate.

    Se tiver CCQ ruins nos clientes, conte com um agregado que equivale em 16QAM a uns 20% do data rate, e em 64QAM a uns 25% dele.

    Bem mais simples, se vai usar um data rate de 78M, conte com um agregado em PTMP de uns 23Mbps. Se tiver clientes com CCQ baixo, conte com uns 14Mbps. Falo logo em 30 e 20% porque a coisa mais rara de se ver é cliente chegando com sinal suficiente pra usar 64QAM.

    (E tem quem use 64QAM com sinal baixos tipo -60dBm e seja feliz justo porque 1/6 das amostras em 64QAM é usada pra reenviar dado perdido, se tiver perda de 20%, 17% sairá dos pontos sem uso, e só 3% usará pontos que podiam estar enviando pacotes novos. Mas isso só funciona quando tem tráfego baixo, hora que 4 ou 5 clientes resolverem consumir 24x7 os 10Mbps que tem liberados, essa rede com -60dBm em MCS7 vira um lixo, enquanto se estivesse usando MCS5 a banda seria limitada mais cedo mas não teria aquelas situações de todos os CCQ caindo, e o ping de cliente com sinal bom ficando uma porcaria tipo 50ms até o concentrador. Data rate alto com sinal baixo só funciona enquanto o tráfego é baixo, enquanto o coding rate suporta o envio e reenvio sem afetar o throughput agregado, mas hora que o numero de amostras ociosas for todo usado, aí degenera toda a rede de uma hora pra outra)


    A informação nos setups sobre o data rate está aí pra isso, facilitar a conta, se é PTP conte com cerca de metade (1/2) do data rate informado, se for PTMP bom conte com 1/3, se for PTMP meia boca conte com 1/4. Se falar em MCS13 em 20MHz, 104Mbps de data rate, arredonda pra 100 pra facilitar a conta, 1/2, 1/3 e 1/4, é fácil fazer a conta de cabeça.

    O problema é que não adianta "querer" um throughput agregado em 50Mbps em PTMP, tem que CONSEGUIR ele, tem que ter todos os clientes com zona de Fresnel limpa, com sinal suficiente, com ack-timeout adequado, enfim, tem que FAZER a qualidade, e ela se faz nas instalações dos clientes, não em configuração na torre. Se um cliente tem uma folha de coqueiro na frente, não adianta mexer em configuração na torre se o problema é a folha do coqueiro. E... no geral o que mais tem é plantas e construções na zona de Fresnel rumo aos clientes, então se quer ser realista, conte com um limite de tráfego agregado que equivalha a 20% do data rate que usar, recomendo sempre usar 16QAM, seja 10, 20 ou 30MHz de largura de canal, em dupla polarização ou simples, falamos de data rates de 13Mbps (MCS3 em 10MHz, pol. simples) até 117Mbps (MCS12 em 30MHz, em polarização dupla), com sinais tipo -68dBm dá pra ter CCQ de 98-99% em todos os clientes, é bem mais simples conseguir todos os clientes com -60 a -68dBm, do que conseguir todos entre -50 e -56dBm pra usar MCS7 ou MCS15.

    (Ou pior, conseguir entre -45 e -52dBm pra usar MCS9 em AC em 40MHz. Olha a diferença, entre -45 e -68dBm são 23dbm de diferença, entre uma CPE de 13dBi de R$ 250 e uma CPE de 27dBi de R$ 800 tem só 14dBi de diferença, daria só 14dBm de diferença de sinal mesmo com investimento R$ 550 mais alto! Conseguir sinal tão alto pra AC em cliente de 300 a 3000m é coisa pra poucos, um residencial padronizado sem nada na frente, uma cidade muito plana e sem arvores nem construções altas, e principalmente, clientes que aceitem pagar R$ 600 por uma CPE (Pra cliente a 2 ou 3km do provedor, só com PBE 5AC mesmo))

    Fora que o normal pra 94% dos provedores é ir misturando pol. simples com pol. dupla, NS Loco M5 em cliente até 1km, e Airgrid nos clientes mais distantes, com essa mistura não tem como saber que tráfego agregado você consegue, afinal tem diferentes data rates em uso, daria pra estimar com base no percentual, se tem 10 clientes com MCS12 (78M), e 10 com MCS4 (39M), 30% de 78 é 23M, 30% de 39M é 11M, 23+11=34, e 34/2 = 17Mbps de tráfego agregado conseguível em tese. Se vender planos de 10Mbps pra esses clientes, eles saturam esses 17Mbps fácil, e quem vai sofrer primeiro com isso é o usuário de Airgrid, com data rate de 39M ele só vai trafegar 10Mbps se o AP estiver meio que dando sopa, sem mais nenhum heavy user conectado. Num PTP com data rate de 39M você consegue até mais de 20Mbps half porque cada rádio só cuida de 1 contraparte, mas em PTMP o AP está respondendo pra uma dezena de rádios, o intervalo de tempo pra emissão de cada pacote (Somando até o GI) é de uns 4ms (Com GI de 0,4 ou 0,8ms), um cliente de alto consumo vai ter pacotes o suficiente pra encher esse tempo todo, em 1s cabem só 250 pacotes desse, então por segundo um AP consegue atender no máximo 250 pedidos. Se forem pacotes pequenos, digamos 1200 bytes, leva 1,6ms ou menos, aí é outra estória, mas um heavy user vai de fato comer todos os 4ms se uso do AP que tem direito (Vai usar todo o intervale de transmissão que ele tem direito ao iniciar cada sessão de transmissão, intervalo do padrão IEEE, não estou falando do enfileiramento que TDMA faz, isso é outra coisa, isso otimiza a fila mas ainda pode ter cliente fominha tomando tempo de outros clientes). 4ms com 64QAM transmite mais dados que 4ms de 16QAM, por isso quem quer vender pacote maior obrigatoriamente tem que usar data rate maior, e dar seus pulos pra ter sinal suficiente pra isso (Quem quiser se meter a vender pizza pra mim tem que fazer uma pizza sensacional, senão vou chamar de burro incompetente. Não dá pra se propor a vender o que não dá conta de entregar, não tem como entregar 10Mbps pra 40 clientes com NS Loco M5 a 1km da torre, não tem sinal suficiente pra data rate alto o suficiente, e meter Airgrid em cliente assim também não dá, teria que fazer a porquice de ocupar 40MHz do espectro (Tem dupla polarização no mundo pra que?)sendo que com 20MHz e pol. dupla se consegue o mesmo, muda o preço do rádio, mas quem quer banda mais alta tem que pagar o preço disso, e o preço deve ser no bolso, o preço não pode ser o uso idiota de uma largura de 40 ou 80MHz em local onde é possível resolver a coisa usando só 20MHz de largura.






Tópicos Similares

  1. Relato de uso do Controle de Conexões Simultâneas (CONNLIMIT)
    Por roneyeduardo no fórum Servidores de Rede
    Respostas: 18
    Último Post: 13-11-2006, 09:38
  2. Método MAXCONN para limitar conexões simultaneas no SQUID
    Por robinsonsilva no fórum Servidores de Rede
    Respostas: 3
    Último Post: 05-10-2006, 15:03
  3. Limite de conexões simultanes no mk por IP
    Por tecnic no fórum Redes
    Respostas: 2
    Último Post: 17-07-2006, 10:19
  4. Conexões Simultâneas no Mikrotik!!!
    Por _AGM_ no fórum Redes
    Respostas: 22
    Último Post: 17-07-2006, 09:54
  5. Habilitando log de conexoes abortadas no MySQL 3.23.54
    Por Daniels no fórum Servidores de Rede
    Respostas: 0
    Último Post: 27-05-2005, 14:57

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L