Sobre o Token Bucket do CAnopy

Cenário:

1 AP Advantage e 1 SM Tradicional (Ambos hardware novo e habilitado o hardware scheduling) (teste em bancada)


Problema:

Ao transmitir arquivos grandes (1GB) durante o início da transmissão a velocidade de transmissão fica na velocidade topo informada no link test (rajada), passado um certo tempo o algorítimo de Token Bucket passa a limitar a banda nos valores definidos na configuração do rádio, até esse ponto nenhuma novidade, o problema q o algorítimo de Token Bucket desse rádio é ruim pois para controlar a banda ele oscila demasiadamente a velocidade, fazendo q determinados momentos ele usa a taxa máxima e outros momentos reduz drasticamente(praticamente para de transmitir) para conseguir atingir a média da velocidade. Tentei mexer no tamanho do Burst Allocation para tentar casar com o tamanho da velocidade configurada como se recomenda no manual mas mesmo assim a oscilação continua ocorrendo.

Existe alguma coisa que possa ser feita para melhorar isso ?

Neto,

com relação à configuração do MIR, há 2 parametros:
- sustained rate
- burst

o sustained rate vai definir a taxa média de consumo do rádio (máxima). A função do burst é permitir que o rádio possa transmitir a taxas superiores ao MIR para uma quantidade de bits (esta é a interpretação do burst - um volume, e não taxa).
Quando o balde está cheio, e há largura de banda disponivel, o radio pode transmitir a taxas superiores até esvaziar o balde. Daí passaria ao valor do sustained (caso haja banda disponivel).

Se vc programar o burts igual ao sustained, o radio não deveria transmitir a taxas superiores que o sustained (não haveris burst).

Fora destes parâmetros, haveria que considerar que o protocolo de tx do Canopy revalida as solicitações de tx a cada 8 frames ethernet, para estar sempre priorizando as transmissões e controloando o as taxas programas de MIR para cada SM (para respeitá-las).

Haveria ainda o impacto dos mecanismos de ACK dos protocolos como FTP, por exemplo.

abraços,
Daniel

Olá Daniel…

To começando a entender agora

Mas os 2 parametros existem tanto para Downlink e UpLink e tbm existem tanto no SM como no AP.

Eu fui no SM e coloquei o Burst igual ao sustained (3500 de burst e 3500 de sustained) e reparei q no upload funcionou corretamente ficou sempre a 3,5Mb/s a transferencia de um arquivo de 2GB, só q no download não funcionou, ficando a 11Mb/s nos primeiros minutos e depois comecou a oscilar bruscamente gerando aquela situação chata descrita.

Não deveria ficar tbm a 3,5Mb/s o download já q no SM está setado o uplink e downlink no mesmo valor 3500 (Burst e sustained) ?

Corrigindo meu ultimo post:

Reparamos que a alteração do bust e sustained no SM não tem efeito. Quem tem efeito é a porcentagem do Downlink data do AP (75%). Consequentemente 25% para upload dando 3,5mb/s (sendo percebemos que ele considera o AP como 14mb).

Neto,

Para que os parâmetros de config de largura de banda do SM sejam usados, é preciso programar no AP o “Config Source” = SM.
Caso contrário, são usados os parâmetros do AP ou do BAM.

[]s
Daniel

Daniel, muito obrigado pela ajuda

Acabei de configurar "Config Source = SM"

Agora sim comecou a fazer sentido os parametros sustained e burst !!!

Coloquei o burst e sustained iguais (3500) e a média foi mesmo de 3500kbps , só que eu achava que se o burst e o sustained fossem iguais aquele comportamento de a transferencia não ir constantemente iria parar, mesmo assim eu percebo pausas pequenas na transferencia como se fosse de “socos”.

Daniel eu te pergunto agora… esse comportamento procede ? será q se eu usar o bam não haveria esse mesmo comportamento ?

Neto,

A configuração dos parametros e MIR pode ser feita no AP, no BAM e no SM.
O comportamento é exatamente igual.

Note que os parametros de MIR definem a taxa média (que deve ser medida a longo do tempo). Desta forma, podem ocorrer momentos onde se transmitem muitos dados, e outros periodos de “silencio” - mas a média deve ficar igual à programada nos parametros MIR.

[]s
Daniel