150Mbps (Procura usar maiúsculas e minúsculas pra todo mundo ter certeza do que está falando) é data rate, não é throughput. Em wifi o throughput fica lá pela metade do data rate, ou seja, se usar um data rates de 150Mbps, o throughput real fica lá pelos 75Mbps (Arredondando pra facilitar).
Mas 150Mbps é data rate com canal de 40MHz. Se usar canal de 20MHz o maior data rate em N, com polarização simples, é 72Mbps. O throughput fica nuns 35Mbps então.
Em rede você não manda "72Mbps por 0,1 segundos", você manda um PACOTE. O MTU do roteador é 1500 bytes, então pra abrir uma página da web de 1MB (1024kB, ou 1048576 bytes) serão uns 699 pacotes (1048576 / 1500 = 699). Esse pacote será transmitido usando uma modulação no esquema OFDM, são os data rates. Em N os data rates são:
www.mcsindex.com
Digamos que o roteador está configurado pra usar o maior data rate, MCS7, em 20MHz de largura, com tempo de guarda/espera longo, é o data rate de 65Mbps.
CADA pacote vai ser transmitido em MCS7. O roteador pega o pacote de 1500 bytes, acrescenta um cabeçalho de 8 bytes no começo, e envia o pacote pro notebook. O roteador NÃO transmite outro pacote enquanto o notebook não responder o checksum correto do pacote.
O checksum é uma soma dos bits que gera um número, o rádio que transmite soma e chega num resultado, o notebook soma o pacote que recebeu e chega num resultado, o notebook envia esse checksum pro rádio, e o RÁDIO é que diz se o numero bate. O número pode não bater até se um (UM!) bit for lido errado. Digamos que o cálculo de uma rajada de bits gera um checksum pequeno assim:
http://www.analog.com/library/analog..._BB_FIG_02.jpg
O rádio envia pacote, recebe resposta, envia outro pacote, recebe resposta, mais um pacote, recebe resposta errada... ops, precisa reenviar esse pacote.
Por conta dos erros no envio do pacote, ou erros no envio DO CHECKSUM, wifi raramente tem na prática metade do data rate como throughput. É comum em roteador doméstico PORCAMENTE configurado pra 40MHz, usando MCS7, mal e mal trafegar 15Mbps (Ao invés dos 70-80Mbps que o data rate permitiria em condições ideais) porque tem coisas tipo paredes no meio, a LEGIBILIDADE do sinal é muito comprometida quando tem obstáculos no meio, ocorre distorção no esquema de modulação e se perde muita informação no meio dos pacotes, o sistema tem que reenviar 2 ou 3 vezes o mesmo dado até que ele chegue direito. Isso toma tempo, por isso na medição de velocidade por segundo a taxa cai (Leva digamos 1,2 segundos pra transmitir 1MB, ao invés de 0,1 segundo).
Usando N, temos 64 portadoras, cada uma com uns 300kHz de largura, elas não ocupam uniformamente o canal de 20MHz de largura (Se usar canal de 40MHz terá 128 portadoras, o dobro de dados pro chipset analisar, gasta mais processamento pra analisar mais dados), digamos que fica assim:
http://rfmw.em.keysight.com/wireless...0explained.png
Quando você olha no Airview (Analisador de espectro) dos rádios Ubiquiti novos o canal aparece assim:
http://i.imgur.com/lo2jj.png
Dá pra ver nessa imagem que algumas portadoras tem sinal tipo -53dBm, enquanto as primeiras na esquerda parecem ter -56dBm. Por isso é bom não ser bobo e acreditar em bobeiras tipo "Tem sinal bom", o nível de sinal exibido pelo setup do equipamento exibe média, a coisa é mais complicada que ter 12dBm de sinal acima da sensibilidade, é bom ter FOLGA, ter 20dBm de margem porque eventualmente umas portadoras estarão só 14 ou 15dBm acima da margem. Precaução nunca causa problemas.
Por meio de séries de Fourier (Ou transformadas de Fourier? Enfim, um cálculo matemático simples pra um computador, complicado pra gente) esse monte de bits enviados por cada portadora é juntado e forma um diagrama de constelação OFDM. MCS3 e MCS4 usam um esquema de modulçai de 16 pontos, por isso 16QAM, os dados das 64 portadoras vai formar esses 16 pontos no diagrama:
http://docplayer.com.br/docs-images/...mages/37-0.png
Quando o nível de sinal é baixo (SNR ruim, ou muito perto da sensibilidade que o rádio informa pra aquele data rate) a definição dessas posições fica ruim, na imagem acima você define com precisão onde cada pontinho está, digo, a qual quadrante ele percente. Mas... com sinal ruim fica assim:
http://www.intechopen.com/source/htm...edia/fig10.png
Um moooonte dos pontos estão fora de um quadrante, o rádio não tem como adivinhar onde ele vai, esse pontos são bits que talvez serão lidos com erro, isso vai gerar erro num pacote todo, vai ter que reenviar pacote, por isso não só cai o throughput, o ping também aumenta (As vezes dá ping de 10ms quando o sinal está baixo, e do lado do roteador dá 0,3ms (Linux exibe o ping abaixo de 1ms, o Windows só exibe 1ms pra cima). Um ping de 10ms é um pacote enviado e reenviado DUZIAS de vezes até ser enviado direito!
Enfim, cada cliente vai ter uma pequena variação no throughput REAL que consome. Com múltiplos clientes conectados o cliente que perde pacotes vai tomar mais tempo do rádio que o cliente que NÃO perde pacotes. Então na teoria um data rate de 26Mbps, teria um throughput de uns 13Mbps pra dividir por 10 clientes. Mas na prática isso não funciona, porque 1 cliente com sinal pior vai tomar mais tempo que os outros, é comum mesmo com todos os clientes com CCQ de 98-99% o throughput ficar em uns 2/3 disso, ou seja, ao invés de 13Mbps em MCS3, uns 8Mbps agregado. Se tiver 1 cliente com CCQ de 90%, e esse cliente estiver trafegando muitos pacotes, ele vai ficar reenviando pacotes perdidos (CCQ de 90% é fruto de muita coisa sendo perdida) aos montes, vai tomar muito tempo que poderia estar sendo gasto com outros clientes, nessa situação talvez o thrpughput agregado (Soma do que todos juntos conseguem consumir) mal passe dos 5Mbps, simplesmente porque o cliente de CCQ ruim perde TANTO, mas TANTO pacote, que não sobra muito tempo pro rádio trocar dados com os clientes com CCQ de 100%.
Não vale a pena ficar calculando throughput previsto, as pessoas não navegam o tempo todo, pega 10 clientes e veja a média de consumo, se forem 10 clientes de 2Mbps provavelmente o tráfego total vai variar de 1 a 12Mbps, sendo 1Mbps de madrugada, e uns 12Mbps lá pelas 20h quando vários estiverem ao mesmo tempo vendo vídeo idiota no facebook (Ou pior, um gameplay inútil no YT...). Vai ter um ou outro clientes com rajadas de alto consumo a cada tempo, na soma total o tráfego é sempre bem baixo.
Um Rocket M5 da vida pode ter 30 CPE's conectadas, provavelmente 7 ou 8 delas não terão NINGUÉM navegando, 7 ou 8 terão rajadas de tráfego baixo só de um smartphone, 7 ou 8 terão rajadas de alto consumo conforme navega ou gira uma página, e só menos de meia duzia terão consumo constante (Rodando p2p ou algum gerenciador de downloads). Se tiver muito pirralho adolescente como cliente, e eles consumirem muito download, ou assistirem muitos vídeos em bitrate alto, 1 desses clientes consome o mesmo que 10 clientes pacatos que só usam internet no smartphone, só pro WhatsApp e Facebook. Não tem como ter certeza de qual será o tráfego somado de todos os 30 clientes conectados, tem que estimar uma média e ver se o data rate em uso no Rocket dá conta de entregar esse tráfego agregado (Lembra, o throughput máximo conseguível fica em cerca de metade do data rate, mas em PTMP geralmente se consegue só 2/3 do throughput máximo conseguível. Se usar 40MHz (Pra que poluir tanto? Usa 20MHz e polarização dupla, poxa!), em polarização dupla (Polarização simples é coisa pra internet de 2009, tipo 1Mbps) o maior data rate é de uns 300Mbps, o thrpughput num PTP excelente ficaria nuns 150Mbps half, e em PTMP com sinais perfeitos então uns 100Mbps pra dividir em 30 clientes. Mas... PTMP perfeito em provedor brasileiro é raro, a maioria faz cagada em instalação com zona de Fresnel parcial, ou tem sinais baixo (MCS15 (300Mbps) exige sinal ótimo tipo -50dBm, DUVIDO que 0,1% dos provedores do Brasil tenham 30 clientes com sinal tão bom), com instalação típica não conte nem com 50Mpbs num caso desse.
Mas o típo de sinal que tem em provedor via rádio geralmente dá só pra MCS3 ou 4 (Ou MCS11 e 12 pra quem vive nessa década, com polarização dupla), são data rates MUITO mais baixos, MCS12 em 20MHz é 78Mbps, dá pra contar com uns 20Mbps agregado se tiver rede boa (Se fosse um PTP dava pra extrair 40Mbps half), e 30 clientes PAGANTES de 5Mbps provavelmente consumirão picos de uns 25Mbps, seria bom num caso de MCS12 pra 30 pagantes limitar lá pelos 3Mbps por cliente (Porque sempre tem os pirralhos que consomem tudo o que podem o dia todo, não sabem configurar nada e deixam clientes p2p usando toda a banda disponível). Planos de 3Mbps pra cima só dá pra arriscar com dupla-polarização, ou se tiver só uma duzia de clientes por setorial, ou se tiver só clientes bem pacatos que pagam 5Mbps mas só consomem em smartphone, com bobeiros tipo WhatsApp e Facebook (No máximo vídeos com resolução lá por 240p).
30 CPE's conectadas num AP comum pesam um pouco, pra manter a conexão ativa uns pacotes são trocados ("Anda tá aí?" "Tô"), mas hora que há digamos um Windows ligado nessa CPE o peso aumenta, o Windows dá um ping rumo a um IP da Microsoft pra mostrar do lado do relógio se tem acesso a internet (Esse ping é trafego), os inúteis antivírus e atualizadores diversos vivem perguntando via web se tem atualização, o Windows vive fuçando na rede em busca de novos dispositivos (Pra exibir automaticamente novas impressoras ou novos computadores, já que a MS diz que todo usuário é tão tapado que não sabe procurar sozinho), se a CPE estiver em bridge esses serviços de scan na rede vão pela rede wifi e só acabam lá no concentrador (Servidor PPPoE, provavelmente), enfim, é um ambiente onde cada uma das 30 CPE tem tráfego, é tráfego pequeno mas são alguns pequenos pacotes por segundo, já pesa bem mais. Mas o que pesa MUITO é se os 30 clientes estiverem navegando, usando whatsapp ou facebook, enfim, estiverem consumindo internet de verdade. Serão milhares de pacotes por segundo pra CADA cliente, cada pacote tem o checksum respondido, se em média perde 1 a cada 100 pacotes isso dá um número de reenvios enorme, ocorre um gargalo na rede wifi não pelo throughput agregado, mas pelo enorme número de pacotes pequenos passando, o throughput agregado pode ficar em 5Mbps pra 30 clientes de 2Mbps cada, mas a rede ser um lixo, porque 500 pacotes por segundo de cada cliente, cada pacote com 300 bytes, gera 15 mil pacotes, pro AP receber, enviar o ok, e... sempre terá que reenviar algum pacote com erro, um roteador que em PTP dá conta de 15 mil pacotes por segundo (15kpps) não vai conseguir o mesmo num PTMP com 30 clientes, porque num PTP ele envia e recebe numa cadência perfeita, enquanto recebe o checksum ele já monta o outro pacote, enquanto envia um pacote já vai calculando o checksum do outro, e assim vai. Mas em PTMP você tá lá enviando e recebendo tudo certo, aí chega a vez de enviar pra um cliente, enviar, e... pééééé... não chega resposta, envia de novo, e chega um checksum errado, envia de novo, e agora sim chegou certo, essa pequena perda de tempo tira tempo que poderia ter sido gasto enviando dados pra outro cliente, essa demora em outro pacote (Que ficou mais tempo na fila) piora a rede desse outro cliente no fim das contas.
30 AP's perfeitos, com 100% de CCQ, é coisa mais rara do mundo, mas se fosse um cenário desse aí sim daria pra sonhar em ter digamos 30Mbps agregado usando MCS12 a 20MHz, atendendo 30 a 35 clientes simultâneos em planos de 3 a 5Mbps cada. Na maioria dos provedores corta todos esses números pela metade.