Detalhes

Categoria: Como fazer configurações

Atualização: Terça, 21 Abril 2009 18:16

Autor: vovó Vicki

Acessos: 12147

Filtro Balde de Token

O Token Bucket Filter (TBF) - Filtro Balde de Token - é uma qdisc simples que só passa pacotes que chegam numa taxa que não ultrapassa uma taxa determinada administrativamente, mas com a possibilidade de permitir rompimentos curtos quando houver excessos.

O TBF é muito preciso e não sobrecarrega nem a rede e nem o processador. Deveria ser a sua primeira escolha se você quiser tornar uma interface mais lenta!

A implementação do TBF consiste num buffer (o balde - bucket) que é constantemente preenchido com alguns pedaços de informação virtual chamados de tokens, numa taxa específica (a token rate). O parâmetro mais importante do balde é o seu tamanho, que é o número de tokens que ele pode armazenar.

Cada um dos tokens que chega pega um pacote de dados entrante na fila de dados e depois é deletado do balde. A associação deste algoritmo com os dois fluxos (o de tokens e o de dados) pode resultar em três cenários diferentes:

• Os dados chegam no TBF numa taxa igual à taxa de tokens entrantes. Neste caso, cada pacote entrante possui seu token correspondente e passa pela fila sem qualquer retardo (delay).
• Os dados chegam no TBF numa taxa que é menor que a taxa dos tokens. Apenas uma parte dos tokens são deletados quando cada um dos pacotes de dados sair da fila de modo que os tokens se acumulam e acabam lotando o balde. Os tokens que não foram usados podem ser usados para enviar dados numa velocidade que ultrapassa a taxa de token padrão, ou seja, ocorre uma rápida explosão de dados.
• Os dados chegam no TBF numa taxa maior do que a taxa de tokens. Isto significa que o balde se esvazia rapidamente, o que faz com que o TBF fique estrangulado por um tempo. Esta é a chamada "situação acima do limite" (overlimit situation). Se os pacotes continuam entrando, eles começam a ser descartados.

O último cenário é muito importante porque permite modelar administrativamente a largura de banda disponível para atender os dados que passam pelo filtro.

O acúmulo de tokens permite que uma explosão rápida de dados acima do limite faça com que passem sem perdas, mas um excesso de carga prolongado causa atrasos persistentes nos pacotes e estes acabam sendo descartados.

É importante saber que na implementação atual do TBF, os tokens correspondem a bytes e não a pacotes.

Normalmente a configuração do TBF não precisa ser alterada, mas, mesmo assim, esta possibilidade é oferecida através dos seus parâmetros:

• limit ou latency: Limit (limite) é o número de bytes que podem entrar na fila para esperar até que haja tokens disponíveis. Pode-se especificar isto "ao contrário" alterando o parâmetro latency (latência), o qual especifica o tempo máximo que um pacote pode ficar no TBF. Este cálculo leva em consideração o tamanho do balde, a taxa e, se estiver especificada, a taxa de pico (peakrate).
• burst/buffer/maxburst: Tamanho do balde em bytes. Esta é a quantidade máxima de bytes para os quais deve haver tokens disponíveis instantaneamente. Em geral, taxas mais altas requerem um buffer maior. Para 10mbit/s em processadores Intel será preciso um buffer de, no mínimo, 10kbyte para suportar a taxa configurada!
  Se o buffer for muito pequeno, os pacotes podem ser descartados porque chegam mais tokens do que cabem no buffer por ciclo de timer.
• mpu: Um pacote de tamanho zero também usa largura de banda. Para uma Ethernet, nenhum pacote usa menos do que 64 bytes. A Minimum Packet Unit - Unidade de Pacote Mínima determina a utilização de token mínima para um pacote.
• rate: O acelerador. Veja os comentários acima sobre limites!

Se o balde contiver tokens e tiver permissão para ser esvaziado, ele faz isto numa velocidade infinita por default. Se isto não for aceitável, use os seguintes parâmetros:

• peakrate (taxa de pico): Se chegarem pacotes e houver tokens disponíveis, por default os pacotes são despachados instantaneamente - por assim dizer, na "velocidade da luz". Isto pode não ser o que você deseja, especialmente se o balde for grande.
  A taxa de pico pode ser usada para especificar a velocidade permitida de esvaziamento do balde. Se fizermos tudo de acordo com o manual, isto pode ser obtido liberando um pacote e depois esperar um certo tempo para liberar o seguinte. Se calculamos as esperas, então é só enviar na taxa de pico.
  Entretanto, devido à resolução default de 10ms do timer no Unix, com pacotes de 10.000 bits em média estaremos limitados a uma taxa de pico de 1mbit/s!
• mtu/minburst: A taxa de pico de 1mbit/s não serve para muita coisa se a taxa normal for mais alta. Uma taxa de pico mais alta torna possível despachar mais pacotes por ciclo do timer (timertick), o que, na realidade, significa a criação de um segundo balde!
  O segundo balde serve para apenas um pacote, o que não chega a ser um balde.
  Para calcular a taxa de pico mais alta possível, multiplique a mtu configurada por 100 (ou, mais corretamente, HZ, que é 100 no Intel e 1024 no Alpha).

Exemplo de configuração

Uma configuração *muito* simples mas muito útil é:

# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540

Muito bem, porque isto é útil? Se você tiver um dispositivo de rede com uma fila grande (por exemplo um modem DSL ou modem a cabo) e quiser "falar" com ele através de um dispositivo rápido (uma interface Ethernet, por exemplo), vai descobrir que o upload destrói toda a interatividade.

Isto acontece porque o upload vai entupir a fila do modem. Esta fila provavelmente é gigantesca para permitir um bom fluxo de dados para o upload. Mas não é isto o que queremos, o que desejamos é uma fila menor para preservar a interatividade e poder realizar outras tarefas enquanto enviamos dados.

A linha acima diminui a velocidade de envio para uma taxa que não aciona a fila no modem - a fila estará no Linux, onde podemos controlá-la limitando seu tamanho.

Altere a velocidade efetiva do seu uplink para 220kbit menos uma pequena porcentagem. Se você tiver um modem realmente rápido, aumente um pouco o 'burst'.