Agregation no firmware ubiquiti

Olá amigos, venho mais uma vez se alguém poderia comentar ou falar algo sobre a opção "agreation" nos firmware ubiquiti, no qual são limitados a 32 frames e 65535 bytes, após o lançamento da atualização 6.0 da ubnt, essa opção é desabilitado, sendo necessário habilitar manualmente "pelo menos só prestei atenção agora" rsrs.

Pois bem, a meu ver, pelo menos eu acreditava ser, que com essa opção ativada, eu teria melhor qualidade e capacidade na largura de banda nos meus APs. Com essa dúvida fui no forum da ubiquiti atrás de uma resposta para essa dúvida, alguns dizem que ao aumentar os bytes no qual o valor padrão é 50000, posso ter mais banda e estabilidade no ping desde que as CPEs estejam com sinal bom e para aquelas que estiverem com sinal ruin, terei problemas. Não foi muito claro. o link é esse
https://community.ubnt.com/t5/airOS-...ty/td-p/264579

Se os amigos puderem comentar algo, agradeço muito, aproveito e deixo aqui o convite para os especialistas com quem aprendo muito comentar algo sobre o assunto.
@rubem @fhayashi @ab5x2
@emilidani @1929 @JonasMT

@alextaws,

Não vou conseguir opinar nesse ponto. rsrs. É que só fiz PTP e o tráfego que tenho não chega nem perto de engargalar eles.

Mas em "teoria", agregação de pacotes tem um trade-off

Se você consolida quadros para enviar em um burst, você consegue enviar mais dados mais rapidamente. Motivo é que há menor quantidade de interrupções no processo.

Em contra partida, se você compartilha essa conexão, a concorrência precisa esperar o término dessa transmissão para ter sua janela, ou seja, pode aumentar a latência.

"Acho" que em links tipo backbone a agregação pode ser uma baita mão na roda mas em PTMP pode impactar aumentando a latência. Por outro lado, se abaixar demais, também pode reduzir muito a banda e aumentar o processamento. Bom, essa parte aqui é especulação, como disse, nunca usei PTMP.

Eu coloquei um par de PTP que tenho aqui com o novo firmware para testar. Indo bem até agora. Vi que na configuração tem a opção de alterar o aggregation frames mas não dá opção de mudar o tamanho do frame.

Anexo 65689

É exatamente isso, só junta mais pacotes num único burst.

Mas em PTMP você terá um burst por cliente então é difícil ter ganho real.

Mas tem que ver que agrega quase o pacote todo (Economiza só uma parte do cabeçalho), gera um burst longo. O problema é que quando o sinal não é suficiente (Margem entre sinal e sensibilidade do data rate) o começo de um pacote e as portadoras do meio podem sair mais legíveis que as portadoras da borda ou que momentos de variação de sinal (Por causa de ripple no VRM que alimenta o amplificador, digamos), de modo que você precisa enviar as vezes até mais dados.

Num pacote normal a conexão perde muito tempo com preambulo, que é transmitido em data rate baixo e altamente legível, então num burst curto com amplificador com poucos dados ele não aquece nem satura, não dá tempo de aquecer. Mas com burst longo ele pode aquecer e o final da transmissão ter distorção percentual maior que o começo.

Enfim, tem que testar, onde o sinal varia (E não confie no nível de sinal exibido, aquilo é a MÉDIA) ao longo da largura do canal, ou ao longo do tempo por causa de temperatura do amplificador ou ripple do VRM que o alimenta, uma agregação enorme vai gerar perdas percentuais maiores que uma agregação pequena. Num mundo perfeito o espectro é limpo e o amplificador está sempre frio, nesse mundo quando maior a agregação maior o throughput sem aumentar delay.

A MK permite você escolher 2 tipos de agregação, agregando com a parte do MAC de serviço (MSDU) ou com a parte de pacote (MPDU), digamos:
Anexo 65690

O desempenho também vai depender do cenário exato, num mundo da fantasia com sinal suficiente, com espectro limpo, com hardware 1000% estável, tudo é lindo. No mundo real é tudo pior, o espectro OFDM é planejado pra ser assim:
Anexo 65691
Variação máxima de 3dBm dentro da largura do canal. Mas... em PTP mais distante é normal medir digamos isso:
Anexo 65694
ou
http://imgur.com/2ivbD

Tem mais de 20dBm de variação nalguns pontos do canal, digo, comparando 2 pontos diferentes (Isso ignorando os maiores picos, que são as portadoras de guarda, que não tem dados úteis). Em PTP distante a média pode ser ok, mas quanto maior a distância mais os objetos na 2ª ou 3ª zona de Fresnel (Ou seja, 200 ou 300% da zona de Fresnel) começam a refletir de modo que cheguem com leve atraso, batendo certinho na contra-fase de um dado, inutiliza só uns bits e essa parte do pacote pode ser reenviada (E num data rate chamado "3/4" (MCS12 e MCS14, digamso) você tem 3/4 do pacote com dados novos, o resto tem repetição ou dado irrelevante, se perder parte desse 1/4 não precisa reenviar essa parte (É tipo um ônibus de 40 lugares mas ele levar só 30 pessoas, se cair uma bigorna gigante no fundo dos ônibus acertando os 10 últimos bancos vazios, você não perde nenhum passageiro, afetou 10 posições mas não tinha dado útil nelas). Enfim, a variação ao longo do canal e do tempo é fato, então um burst mais longo nem sempre resulta em throughput maior, poucas vezes vai diminuir o throughput, mas vai comer mais processamento do chipset de RF, então se testar e o throughput não mudar, deixa desativado pra evitar processamento extra a toa do chipset (E evitar ainda mais calor no coitado do amplificador que raramente tem dissipador).

:rock:

O básico parece simples mas a utilização prática tem muuuuita coisa.

@fhayashi @rubem

Pensava ser algo simples, mais esse pequena opção tem muito conteúdo a ser explorado.

rubem, em rede PTMP. então eu habilitando a "agregação de pacotes" aumentando para 65535 bytes, posso ter throphout maior, mais os demais clientes ao fazer novas requisições podem ter latência alto, desde que o primeiro pacote solicitado seja pequeno, se for grande, tipo como um video do youtube posso ter problemas de latência e lentidão? sem contar o processamento que aumenta do RF.

Uma vez ativei essa opção em uma das setoriais da minha rede, deixando o padrão de 50000, o resultado que tive foi um aumento de banda, e sem reclamação do cliente. Situação que antes de habilitar, eu tinha problemas de ping alto e navegação lenta, após habilitar, melhorou a conexão dos clientes.

Não deveria aumentar muito a latência não, seria mais questão de instabilidade, onde sem agregação perde digamos 5% dos pacotes passaria a perder 10% com agregação nos horários quentes e tal. Onde não perde nada não tem como perder um percentual maior.

Quando você tem um throughput servidor>cliente maior que a banda limitada dele (Plano de digamos 5Mbps, usando data rate de 78Mbps), na real o AP não está trafegando tudo o que consegue rumo aos clientes, geralmente o gargalo é mais no número de pacotes por segundo do que no tráfego (Bytes por segundo). Se o AP num dado momento só está trocando dados com 1 cliente (Porque não tem pacote na fila destinado aos demais) o ping e jitter rumo a esse cliente serão melhores, independente de ser um grande vídeo no Youtube ou ser uma mísera rádio online de 64kbps. O cenário onde isso não faz tanta diferença é onde tem vários clientes com tráfego simultâneo, e/ou onde tem perda de pacotes significativa (Por zona de Fresnel comprometida).

@rubem
recomendaria eu usar desativado ou ativado essa opção?

Em PTP eu testo. Se não fizer diferença eu deixo desativado.

Em PTMP acho que só testaria se fosse rede com muito tráfego (Planos alto), porque em planos pequenos (<5Mbps) deve mudar 5% no ping, e reduzir 5% dos 2ms de uma rede boa não faz diferença mensurável.