Qual o cálculo de conexões simultâneas nos modelos AC para Pt-MPt ?

Pessoal já li aqui neste fórum matérias mais antigas sobre as capacidades de conexões simultâneas nos APs. De certo o mais próximo que li foi sobre os UniFi. Um link que tb foi postado para ajudar nesta questão foi este aqui :
http://lucianofranz.blogspot.com.br/...bem-em-um.html

O X do problema é que aparenta não haver uma fórmula mais prática de se calcular estes números, dai a dúvida, ou seja, de fato não existe uma formula ? Mesmo que levemos em conta algumas variáveis ? Tipo interferência, distância, throughput do usuário, clima etc..

O que é verificado até o momento é que a potencia dos rádios e antenas, seu poder de processamento e memória são fatores constantes para este cálculo, mas, como disse até hoje nunca vi nenhum rabisco de formula para fazer este calculo.

Dito isso, valeria provocar até o UBNT-Chadi para que estas informações pudessem ser colocadas mesmo que dentro de um cenário predeterminado e dai incluir alguns campos variáveis que podem influenciar a qtde de conexões simultâneas para que todos os provedores pudessem calcular estes números com base na alimentação destes dados.

Logo a questão prática desta thread é :

Quantas conexões simultâneas um LiteBeam AC AP comportaria com velocidades de 3 mbps, onde a CPE seria um LiteBeam AC tb.

Quantas conexões simultâneas um Rocket AC com Setorial AC-60 comportaria com velocidades de 3 mbps, onde a CPE seria um LiteBeam AC ou NanoBeam AC tb.

Se puder colocar isso numa fórmula para que possamos fazer um jogo entre qtde de usuários vs. throughput e delinear quais fatores podem influir na variação dos resultados vai ser uma informação bem bacana.

A dica é que poderia ser uma variação do http://airlink.ubnt.com/#/ onde o provedor pudesse criar seu sitesurvey e de acordo com as variáveis que lançar o site calcular as informações que são importantes na relação Pt - MPt.

Vlwww e sigamos.

Com tanto chipset diferente, e firmware diferente, o que vale pra um modelo com um firmware não vale pro mesmo modelo com outro firmware, imagina trocando de equipamento no comparativo.

Em PTP é mais fácil ver isso, em 2012 você usa equipamento de 2012, digamos um Airgrid, e interliga 2 pontos, alinha, testa, retesta, realinha, e consegue x throughput. Em 2016 um lado queima numa chuva, você troca por um PowerBeam da vida, nem alinha direito, e... mesmo usando só 1 polarização você tem 1,5x de throughput! Uma diferença de 50% a mais no throughput conforme o equipamento (Falando no uso do mesmo mesmo canal, mesma largura de canal, mesmo nível de sinal).

Em PTMP o AP está trocando pacotes com todos os clientes, se 1 cliente tem sinal baixo e perde 20% dos dados, ele vai ter que reenviar na primeira vez 20% a mais de dados, nesse reenvio vai perder 20% e mais ter que enviar de novo 20% de 20%, e assim vai, 1 cliente toma um tempo ENORME se for um cliente com perda de pacotes (Quase sempre causado por sinal baixo graças a zona de Fresnel parcial, dificilmente é culpa de sinal baixo causado por distância. O comportamento muda conforme o motivo do sinal baixo, obstrução na zona de Fresnel detona a qualidade de conexão, sinal baixo por distância grande piora bem menos o throughput), tempo que poderia estar sendo usado pra trocar dados com outros clientes.

A estação/cliente só troca dados com 1 contraparte, o AP, a estação então pode receber sinais levemente piores, mas o que o AP recebe tem que ser totalmente legível, e muito anteneiro leigo cai na besteira de apenas olhar nível de sinal no cliente, sendo que o RX no cliente só precisa ler os dados de 1 contraparte, quem mais interessa que seja alto o suficiente é o RX na torre, porque esse tem duzias de sinais chegando quase juntos, um sinal baixo demais perde pacotes e um sinal alto demais afeta a legibilidade dos sinais baixos, ideal é ter todos os clientes chegando com nível suficiente pro data rate escolhido (Uns 20dBm acima da sensibilidade do data rate, sensibilidade que é informada pra CADA data rate nos bons datasheets) e num nível similar, o rádio dos clientes tem ajuste de potência pra isso, cliente próximo talvez fique em -2 ou 2dBm de potência, enquanto cliente distante precisa se esgoelar a 22dBm, como cada cliente tem distância diferente a lógica diz que cada um deve ter potência diferente, já que a queda de sinal existe conforme a distância (E é bem simples calcular a queda que existe pra cada distância em campo aberto, com a primeira zona de Fresnel limpa)


Vários fatores podem ser calculados, mas nesse caso a coisa tem que ser testada e não calculada, porque depende da capacidade de processamento de todos os hardwares envolvidos (E um software ruim (Firmware com bug) detona o desempenho de um bom hardware), e das condições físicas entre o AP e cada cliente.



Se é pra falar em mundo teórico, num mundo irreal onde não há reflexo nenhum (Ou pelo menos onde a 2ª e 3ª zona de Fresnel (200 e 300%) estão limpas), onde não há ruído, onde todos os clientes chegam com sinal equalizado e 20dBm acima da sensibilidade do data rate, num PTP se usar 16QAM você consegue em throughput half-duplex uns 60% do data rate, ou seja, se o data rate (Que varia conforme a largura do canal) é de 100Mbps, o throughput seria de 60Mbps.

Ainda nesse mundo irreal, que não existe, se mudar isso pra um PTMP, com 20 clientes de baixo tráfego, o tráfego agregado de RX não será de 60Mbps porque tem 20 estações trocando pacotes, há perda de tempo em cada um, muito mais pacote de sincronia, nesse caso o tráfego agregado vai ficar nuns 50% do data rate (50Mbps, no exemplo de um data rate de 100Mbps).

Mas isso é com 16QAM! Com 64QAM se usar o coding rate de 5/6 o throughput vai chegar perto de 70% do data rate (Valor nominal). Com BPSK, QPSK e modulações menores, a sensibilidade do data rate fica perto do limiar de sensibilidade do chipset como um todo, a legibilidade percentual parece que não melhora, não lembro de ver um throughput de 60% do data rate com QPSK.

Na prática terá ruído, terá sinal refletindo no chão ou parede lateral (Não existe "a zona de Fresnel", existe a primeira zona de Fresnel, ou 100% da zona de Fresnel, existe a segunda, a terceiro, a quarta, em cada uma ainda há reflexo, fora da primeira GERALMENTE são tão pequenos que são desprezíveis. Mas geralmente é diferente de sempre), ou pelo menos umas das polarizações de pelo menos 1 dos clientes terá atenuação por zona de Fresnel obstruída, de modo que conseguir em PTMP um throughput agregado de 40% do data rate é impossível, se conseguir 30% se dê por satisfeito! E convenhamos que hoje temos equipamentos pra muita coisa, um MCS12 a 20MHz tem data rate de 78Mbps, em PTMP decente dá pra contar com 20Mbps agregado, e uns 20 clientes de 5Mbps cada vão ficar mais ou menos nisso.

Quem quer vender plano maior, e pra muito cliente (E eu não vejo motivo pra ir muito além dos 5 ou 10Mbps, pra uso doméstico isso roda filmes realtime tranquilo, não precisa mais que isso, povão pede mais que isso mas é porque quer dividir com vizinho ou usar p2p, se tem conexão de qualidade pra uso de streaming (Netflix e cia) não vejo motivos pra usar p2p (Eu uso porque nem um vídeo a 240p eu consigo assistir no Youtube sem engasgos)) tem que partir pra MCS15, em 30MHz dá pra contar com uns 50Mbps agregado, mas veja que MCS15 exige sinal muito alto, 20dBm acima da sensibilidade pro data rate significa sinal acima de -54dBm, e seria isso em TODOS os chains de TODOS os clientes, nada de ter um a chain0/chain1 -54/-62dBm. Ou partir pra AC mesmo, mas aí também precisa ainda mais sinal, falamos em ter sinal na casa dos -50dBm em todos os chains de todos os clientes, isso é perfeitamente possível na teoria, mas na prática as cidades ão cagadas e não planejadas, tem relevo variando, casas de diversas alturas, arvores de diversas variedades e alturas, tem mil obstáculos na zona de Fresnel, eu duvido muito que num ambiente urbano típico alguém consiga colocar 20 clientes entre 200 a 1500m, numa setorial de 60°, com todos tendo sinal de pelo menos -50dbm em todos os chains, duvido MUITO. Conseguir isso com -60dBm já é tarefa pra loteamentos novos onde só tem casas nanicas e padronizadas (Pombais) sem árvore nenhuma, enfim, situação que não existe na grande maioria dos 5573 municípios do Brasil.


Pra PTP é mais simples, calcule o sinal teórico (Digamos aqui), e conte com throughput que equivale a cerca de 50 a 60% do maior data rate que tiver sinal suficiente (Varia conforme distância e sensibilidade do rádio, esse site acima aplica a margem mínima, 12dBm acima da sensibilidade até 2km, e de fato na roça, sem ruído, 12dBm de margem tá ótimo, em ambiente urbano geralmente precisa ficar acima de 14 ou 15dBm. Eu falo 20dBm porque existe chuva (Atenuação de 0,5dB por km, as vezes), neblina, poeira, torre chacoalhando e afetando alinhamento, enfim, tem diversos fatores que fazem o sinal real variar 4 ou 5dBm, e 5dBm acima de 15dBm é 20dBm).
Pra PTMP não é tão simples porque cada cliente tem consumo diferenciado, meu p2p consome 300kbps 24h por dia, sem parar nem com blackout, outros clientes vão ter rajadas de 50 a 200kbps porque só usam whatsapp, outro fica no xvideos a tarde toda por isso tem 1h de consumo na casa dos 2Mbps, outra resolve assistir novela pela internet (Como se não existisse sinal de tv via satélite chegando em 100% do país, contra uma cobertura de talvez 2% do território (8,5 milhões de km²) com cobertura de internet) justo as 20h que é o horário de pico, e consome 1h de 2Mbps... enfim, se todos os clientes tivessem consumo constante, seria só contar com throughput agregado na casa dos 40% do data rate em uso. Quem tem câmera de segurança assim pode contar com tráfego muito maior, cada câmera envia 24x7 um streaming de 2Mbps, se usar MCS12 em 20MHz pode contar com tráfego de 30Mbps, 15 câmeras com tráfego perene, nunca passando de 2Mbps, aí funciona lindamente. Se vender planos de 2Mbps pra 15 clientes num sistema desse você vai estar subutilizando ele, se tem 15 clientes com sinal suficiente pra MCS12 pode vender planos de 5Mbps, o tráfego agregado nunca vai chegar em 30Mbps, e se forem 15 clientes típicos não terão muitos pacotes por segundo a ponto de saturar a capacidade de processamento do AP.

(Se usar coisa velha tipo Rocket M5 versão XM, isso é um hardware básico, chipset altamente barato, satura com 10 ou 15kpps em PTP (E em 2010 quando isso foi lançado não tinha WhatsApp em milhões de smartphones, tinham mais pacotes grandes, hoje são milhares de pacotes pequeno, chipset velho satura pela quantia de pacote e não pelo throughput), é duzias de vezes pior que uma RB912 da vida, que ainda NEM É UM HARDWARE DE ALTA CAPACIDADE! É só olhar os chipsets usados, muita RB e equipto UBNT tem os mesmos chipsets de roteadores de mesa de R$ 100, são produtos muuuuuito inferiores a um rádio licenciado, que tem um processador PowerPC de R$ 200, um chipset ethernet avulso, um chipset de RF pra cada chain, uma memória maior e mais rápida, uma Rom muito mais rápida (Troca HDD por SSD num notebook barato e você entenderá o poder da velocidade da Rom (Local onde fica armazenado o sistema operacional) no desempenho de um equipamento!), enfim, esses rádios são mais poderosos que o desktop de muita gente, enquanto umas RB's e rádios UBNT são tão poderosos quanto um roteador de mesa de R$ 150 ou um receptor de TV digital, não dá pra esperar grandes maravilhas de hardware básico, um hardware de alta capacidade num PTP half-duplex com sinal baixo não consegue throughput muito maior, a diferença vem quando compara os cenários típicos, espectro altamente poluído, sinal variando e refletindo nas bordas da zona de Fresnel, e no caso de um AP proprietário, as estações enviando diversos pedidos de pacotes praticamente ao mesmo tempo (Experimenta conversar com 10 CRIANÇAS ao mesmo tempo, cada uma com um assunto, pra ver o trabalho que dá ser o AP de 10 estações, elas raramente conseguem respeitar a vez, ou responder direito))

Obrigado Rubem pela resposta, de certo irei montar um diagrama com os parâmetros que vc colocou.

Quero somente aproveitar a devolutiva para pontuar algumas colocações.

1 - Pelo que entendi então no caso de termos APs nas ERBs em padrão AC usando Rockets M5 AC com Setoriais AC 16 dBi de 60º, e em condições minimamente ideais conseguiremos colocar pelo menos uns 15 usuários com 5 Mbps ? Sendo caso 2 Mbps (suficiente para atender VOD) vc acha que consegue se colocar uns 40 usuários ? De certo de acordo com a prática quanto mais usuários, mais problemas podem afetar a performance do throughput, mas a base de cálculo, mesmo que irreal, é garantir este ambiente o mais próximo do ideal.
2 - Uma dúvida, esta colocação sobre 15 usuários com 5 Mbps em ambiente ideal é com os equipos Rocket M5 AC e Setorial AC ou para o LiteBeam AC AP ? Acho que a diferença entre os dois (em relação ao radio) está só na qtde de Memória certo ? ou o processador tb é mais possante ?
3 - Dentro da pergunta prática e objetiva que coloquei, vale então especificar mais o cenário que estamos querendo implementar, ou seja :
a) A ideia é colocar CPE AC casadas com TPLinks WDR 4300 (dual band com OpenWrt) que estarão ampliando a rede mesh, ou seja, usuários com melhores condições de enlace com a ERB ficará como gateway de uma parte da rede em malha ao mesmo tempo que serve ao seu respectivo usuário.
b) Cada TPLink na rede em malha tb poderá servir a usuários via cabo UTP CAT5 blindado em suas proximidades, evitando sobrecarregar a rede wifi. Eles irão fazer os enlaces entre si em 5.8 Ghz e distribuir em 2.4 Ghz.

Ontem tinha lido um post do Chadi dizendo que consegue 80 Mbps (Throughput total) em um AP em Pt-MPt acho que com 40 usuários. Só não me lembro em qual AP foi, enfim, suas dicas foram bacanas e irei esmiuçá-las na tentativa de desenhar um modelo, mesmo que dentro de condições ideais difíceis de se alcançar.

Quanto as novas colocações se tiver mais dicas, agradeço desde já.

Vlwww

1 - 40 usuários acho exagero. Um hardware mais básico vai ter desempenho ruim lá pelos 30 a 40 usuários até mesmo se usar planos tipo 256kbps, o limite nesse caso é pela troca de dados de sincronia e cia, não pelo tráfego agregado em si. Mas depende do perfil do cliente, 40 CPE's ligadas sem tráfego dá quase na mesma que 5 CPE's com tráfego.

2 - 15 usuários de 5Mbps vão consumir talvez picos de 30Mbps, dá pra colocar muito mais gente se usar AC. E é besteira usar AC com sinais ruins tipo -60dBm, só faz sentido usar AC se usar MCS8 ou MCS9 (Não confundir com MCS8 e 9 de N, veja a diferença em www.mcsindex.com , esses 2 MCS de AC são diferentes dos de N com mesmo nome), porque MCS4 em AC, numa antena de dupla-polarização, é exatamente MCS12 em N. Enfim, se usar AC de fato (MCS9, digamos), em 20MHz dá pra contar com uns 60 ou 70Mbps de throughput agregado.

3 - a) Só tive experiências bem ruins com Mesh, de tráfego altamente afetado por um cliente consumindo demais, não sei o que é uma rede Mesh de qualidade, não posso opinar.
3 - b) Pra mim faz mais sentido, mas nem precisa cabeamento UTP, conheça o conceito de micro-células ou micro-setorização, Nanobeam+Omnitik formam uma micro-célula que de fato teria condições de atender uns 20 clientes pagantes de planos tipo 5Mbps (20 pagantes tipicamente significa 10 a 15 CPE's ligadas, mas mal e mal com 7 tendo tráfego).


Com exceção desse último ítens, nos outros falei em clientes simultâneos, e NÃO TEM como estimar que tráfego os clientes terão, eu tenho consumo 24x7 em velocidade baixa (p2p e gerenciador de download bem limitados), lá de vez em quando dou pulos de alto consumo, mas minha mãe e minha irmã ficam o dia todo só no smarthphone, uma rajada de 300kbps de consumo a cada 5 minutos. Mas meu cunhado assiste muita coisa online, se ele resolve usar internet por 1h, é 1h de consumo de toda a banda disponível, e muito adolescente é assim, fica com mil abas do browser abertas, em páginas cheio de firulas com flash gastando banda e processamento, consomem toda a banda disponível pelas 8 ou 10h de uso. Eu olhava muito o consumo dos meus clientes, era normal numa tarde ver 50% do consumo do concentrador vir de 3 clientes com filhos adolescentes, e os outros 50% virem de 40 clientes sem pestes em casa. Mas eu não faria a distribuição por 2,4GHz em hipótese nenhuma, põe um AP em cada cliente senão eles começam a usar smartphone debaixo da cama, dentro de uma lata, e acham que porque está vendo no smartphone um sinal bom, o sinal smartphone>AP é suficiente, eles não entendem a bidirecionalidade do wifi e esmerdalham o desempenho dos AP's 2,4GHz. Vender conexão direta pra placa PCI ou USB com antena externa já é ruim, mas vender conexão direta pra smartphone é coisa pra lugar que não tem nem conexão 2,5G por perto, porque a qualidade fica terrível, é ambiente onde se liberar 300kbps ou 3Mbps pro cliente vai dar na mesma, pela perda gigantes de pacotes criada pelo sinal lixo vindo dos smartphones.

(Alias, por excesso de árvores na vizinhança, e falta de disponibilidade, eu dividia a internet com uma vizinha, reparei que tinha muito consumo de noite, comentei com ela (Achei que ela assistia novela, ia propor puxar uma cabo da minha parabólica até lá, pra diminuir isso) e ela disse que colocava a filha pra assistir desenhos no Youtube porque era horário que não tinha nada infantil na TV, gravei 3 DVD's DL de 8GB cada com desenhos (H265 em 360p cabem centenas de horas nesse espaço, criança não sabe a diferença entre 240p e 720p), entreguei, e nunca mais vi consumo de banda no IP dela de noite, ensinei a abrir VLC pelo playlist, com o playlist no modo shuffle (Pra não ficar repetindo o mesmo vídeo, como minha sobrinha faz no tablet, dá play no mesmo vídeo de 5 minutos umas 5x seguidas), pior é que fui eu que dei a dica de deixar em loop os vídeos da galinha pintadinha no Youtube. Eu achei curioso isso, comecei a perguntar pra cliente o que, e como, eles usavam internet por isso, aí que percebi o gigantesco percentual que só usam pra WhatsApp e Facebook, quem nem ligam pra demora de 5s pra abrir um vídeo 240p. Notei que até o pessoal que faz EAD via internet (Faculdade) tem consumo muito baixo, são poucos minutos de vídeo 360p, o resto é texto, acesso a site da faculdade, é realmente um consumo muito baixo no acumulado (Se o concentrador somar o tráfego total do cliente, fica fácil ver isso, uma duzia consome 1GB cada na semana e o outros 2 ou 3 consomem 20GB)

15 clientes de alto consumo vão dar um tráfego agregado que certamente vai exceder a capacidade do rádio, mas 30 clientes de baixo consumo vão ficar bem longe da capacidade máxima do rádio. Se tiver 30 clientes pacatos conectados num PTMP qualquer, e você chegar em um e fizer um teste de velocidade, tem que dar até mais de 80Mbps se os outros clientes estiverem completamente sem tráfego, mas é uma situação completamente diferente de ter 30 clientes consumindo 3Mbps cada, aí o problema é o tempo gasto com preambulo e cia antes de trocar a parte do pacote com dados tcp/ip do cliente (Antes de cada payload tem um preâmbulo, ele toma tempo de uso do AP). Com 10 ou 15 clientes você chega no limite de througput do data rate fácil, mas na casa dos 40 começa a degradação de qualidade, tem quem metade 50 ou 60 clientes, porque um ping de 6ms não é problema pra cliente doméstico (E 60 clientes domésticos pacatos não consomem muito, tem caso de 50 clientes de 1Mbps consumindo 10Mbps nos picos, com média de 5 ou 6Mbps de noite, e mal e mal 1Mbps de madrugada e manhã), um delay desse do cliente ao provedor não chega nem perto do delay do provedor até o CDN onde o vídeo que ele quer ver no facebook fica hospedado.


Há um limite de tráfego agregado que cada data rate consegue entregar, exceto em casos de pacotes muito grandes pro data rate (Plano de 5Mbps pra data rate de 50Mbps não dá) não tem como saber que tráfego agregado um número X de clientes vai dar, se for cliente pacato dá pra meter 40 simultâneos num AP de fato, sem degenerar rede, mas onde tem uns consumindo demais, talvez com 30 simultâneos já comece a piorar a coisa, e ultimamente como todo mundo usando smartphone ligado 24x7 você tem milhares de pacotes de tráfego baixo, vários pacotes pequenos, ou se tiver muita firula instalada no smartphone (Adwares rodando) várias conexões abertas e semi-abertas, isso gera um numero de pacotes por segundo que na somatória total dos clientes excede a capacidade de processamento de algum dos chipsets do AP, a qualidade cai bem antes de chegar no tráfego agregado que o data rate daria conta.

A UBNT parece que se baseia muito no cliente americano, que no geral tem rede 3G de alta capacidade no smartphone, por isso consome pouco da sua conexão fixa em casa, eles usam muito pouco p2p (Medo justificado!), tem cache ou cdn no Google, Akamai (Facebook) não só nas 48 capitais como em mais umas 200 grandes cidades (No Brasil não tem nada disso em metade dos estados), de modo que esses conteúdos estão a 4 ou 5ms de distância (No brasil talvez a média de distância seria 80ms, porque tem o pessoal de SP a 5ms de distância, mas tem o resto do país a 200-300ms de distância), acessar conteúdo bem próximo permite assistir conteúdo 360p real-time até em link de 1Mbps! Até quem joga acessa servers bem próximos, não é só questão de um jogo consumir só 300kbps, se o server fica distante cada pacote enviado fica no buffer por mais tempo esperando resposta (Checksum), um concentrador de acesso que fica a 200ms da "internet toda" sofre muito mais que um concentrador que fica a 4 ou 5ms de tudo que é site, isso reflete muito nos limites até onde o equipamento pode ir. Vide as conexões via satélite, tem aqueles pings gigantescos (Também, são 36 mil km!), perda alta de pacotes, por isso em pleno 2016 tem satélite quase novo vendendo conexão de 128 ou 256kbps mesmo, e com garantia de 30 ou 40%, por R$ 100 ou 150, o único jeito de baixar custo é limitar velocidade e prioridade (Pra sobrar capacidade de processamento pra quem paga R$ 1 mil por 1Mps com 80% de garantia), não pelo tráfego agregado, mas pelo tempo que cada pacote ficar no buffer esperando checksum voltar. É algo tipo engarrafamento criado em semáforos, se todos percorressem numa velocidade constante, com espaçamento uniforme, seguindo todos o mesmo trajeto, caberiam X mil carros com parada máxima de 1 minuto, mas como cada pacote, digo, carro vai numa velocidade diferente, num trajeto diferente, ocorrem delays de 5 minutos as vezes, até o buffer adiante esvaziar e liberar um espaço pra ele andar um pouco.

Rubem em mais uma aula. Eu fico indignado com o under linux, toda vez que vou qualificar o post de alguém aparece:"Você precisa acrescentar reputação a outros antes de acrescentá-la a rubem novamente."
Ao lado do seu avatar deveria ter um botão para doação via paypal, pois cada post seu equivale a um treinamento avançado para provedor wireless.

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 ?

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.