Kpps??

[gabrielest]

Pessoal,
Boa noite, uma pergunta de leigo:

Estava olhando as conf.. das RBS no site da MK atras dos PPS máximo teórico que cada hardware suporta pra saber qual o limite dele, na procura deparei-me com a unidade Kpps, o que seria?? seria aquele valor x x 1000??, por exemplo na sxt lite 5 na primeira opção diz 148.0 Kpps a 97.1MB, a 64 byte o que traduzindo significa dizer que a capacidade máxima teórica dela é a transmissão de 148.000 pacotes de 64 byte a 97Mb correto?

[rubem]

Isso, pacotes por segundo, se o pacote for de 64B, 148 mil deles dão em 97MB/s.
Pacote de 64B é praticamente o mínimo, ninguem mantém conexão hoje apenas com pacotes pequenos, coisa tipo voip e whatssapp até usam pacotes de 32B as vezes, mas se somar o cabeçalho completo (Incluindo encriptação e CRC) o tamanho aumenta.
O problema dessa medida é que se você aumenta o tamanho dos pacotes o troughput não aumenta no mesmo nível, é uma medida importante saber quantos pacotes pequenos o hardware trafega porque existem pacotes pequenos, se você depender apenas de agregação pra formar pacotes grandes e trafega-los você terá atraso, se o processamento da etapa de RF for lento não vai dar conta de muitos pacotes e os pacotes pequenos ocuparão tanto o hardware quanto pacotes grandes, de modo que o troughput final não será grande.

Quando você aumenta o tamanho dos pacotes, chegando aos 1500B, ou talvez usando jumbo frames, com pacotes de 2000B ou 4000B, você cai no gargalo do trafego nas portadoras, cada portadora trafega um numero X de dados úteis, porque perde-se tempo verificando se está livre pra transmitir, perde-se tempo enviando dados tipo canal, nivel de sinal, esses dados pra manter a conexão, de modo que não tem como ter 148 mil pacotes de 1500B, com pacotes grandes a capacidade será a de trafego nas portadoras, e não mais o potencial de processamento da etapa de RF.
(E os padrões IEEE tem portadoras fixas, em 802.11G terá 54Mbps, seja em pacotes grandes ou pequenos. Em 802.11N tem mais portadoras, de modo que se consegue 65 ou 72Mbps com a mesma largura que 802.11G tem 54Mbps)

Na vida real você tem pacotes de varios tamanhos, pequenos e grandes, por isso esses testes de troughput as vezes enganam, você tem 140Mbps em teste, mas na vida real mas passa de 90Mbps. Porque na hora de agregar pacotes, ou de lidar com tamanhos diferentes, a etapa de RF trabalha mais, digo, gasta mais tempo processando cada pacote, saber lidar com muitos pacotes pequenos significa que eles não ocuparão o mesmo tempo de processamento que pacotes grandes.

[brunocemeru]

Caramba,parabéns é pouco para sua explicação.
Vlw mesmo.

[gabrielest]

OBrigado Rubens, Muito esclarecedor

Lendo sua resposta porém veio-me uma dúvida... acaso isso teria a ver com o MTU ou com o agragation/frames?? e, caso sim, esxiste uma equalização "conveniente"?

[rubem]

A maioria dos hardware funciona melhor com pacotes pequenos, já que tudo é quebrado em partes pequenas, pacote grande tem mais chance de ser perdido porque se uma parte for perdida isso inutiliza o todo, por isso você tem a possibilidade de configurar um MTU menor, digamos 1000 B, ou talvez 500 B se usar apenas protocolos leves (Voip, chat de texto). Alias, pode notar que em cliente de sinal muito ruim o ping a -64 é uma maravilha, mas -l 1400 dá erro, quanto menor o pacote melhor ele trafega em ambiente ruim. O que a maioria dos usuarios domesticos e soho usa (web) tem que usar pacotes grandes, senão o provimento de internet apenas pra IRC e VOIP seria extremamente facil, 32Kbps com pacotes de 128B se consegue em 20 Km com um par de NS.

A agregação pega pacotes de nível similar, com mac's diferentes como origem e destino, e junta numa rajada só de envio, não sei como anda as compatibilidades, hoje falam em pacotes de 4 e 8KB, que são agregados em pacotões de 64KB. O problema é que tem CRC e tal, se 1 desses pacotes de 4KB (1500B de dados do usuario, e mais todos os cabeçalhos adicionais, tipo dmac=012345.678900 smac=012345.678900 typelen=0800) der erro tem que reenviar o de 64KB todo, então em lugar de sinal ruim (Teste com pacote de 64B não serve) é bom evitar agregação, senão vai acelerar 45 ou 60 pacotes um pouco, mas atrasar bastante outros 15 ou 30 por deu erro devido a variação de sinal.

A "perda" de tempo em wifi com troca de dados entre cliente e torre é tão grande que quando você aumenta o GI de 400ns pra 800ns (Ou seja, DOBRA o tempo de transmissão de pacotes do clientes) o datarate cresce apenas 10-15%! O resto do tempo (Outros 400 ou 600nS, não lembro agora) são gastos estabelecendo a conexão e dando detalhes de nível de sinal e cia. Onde o sinal varia (Principalmente zona de fresnel parcialmente obstruída) a variação ou mudança de reflexos é tão rapida que ocorre em menos de 400nS, as vezes a conexão cai então varia em menos de 200nS, que é o tempo inicial pra estabelecer conexão (Note, nS, não mS! 400nS são 0,4mS, ou 0,0004 segundos).

Não tem um MTU exato pra usar, conforme o tipo de encriptação ou autenticação que usar o cabeçalho aumenta e a area útil do pacote diminui, de maneira geral Windows usa o maior pacotes possível pra tudo, LAN raramente tem problema com isso. Agregação... acelera a conexão quando tem sinal suficiente, ela faz mais sentido em PTP, mas tem que ser um bom PTP, nada de 2 NS a 5Km. Em cliente não muda muito, não é tão comum em SO normal ter pacotes de mesmo nível e tamanho pra gerar um agregado grande e isso fazer tanta diferença, ativo ou desativado no cliente não vai pesar muito pra torre, porque ter que lidar com milhares de pacotes pequenos também usa processamento, não é tipo lidar com 2 ou 3 pacotes grandões mas ocupa ambos ocupam algum processamento. Num PTP você tem mais pacotes similares (Muitos clientes navegando gerando pacotes similares) e faz mais efeito.

[gabrielest]

Novamente obrigado pelos esclarecimentos.

[1929]

@technorte, será que você não se enganou ao escrever -81dbm? Se for isso é sinal muito ruim.

[1929]

Ah... eu tinha me atentado só para esta parte da tua escrita...

"peguei um cliente com sinal -81 pq eu estou montando o repetidor bem proximo dele,".

Agora entendi que era provisório.