9.2.2. Filtro Token Bucket
O algoritmo Token Bucket Filter (TBF) – ou seja, Filtro Balde de Moeda – é uma qdisc simples que somente repassa pacotes que chegam a certa taxa que não está excedendo alguma taxa definida administrativamente, mas com a possibilidade de permitir rajadas curtas acima dessa taxa.
O TBF é muito preciso e amigável a rede e ao processador. Ele deve ser sua primeira escolha se você simplesmente deseja deixar mais lenta à interface!
A implementação TBF consiste de um buffer (balde), constantemente preenchido por alguns pedaços virtuais de informação chamada de fichas, a uma taxa específica (taxa de ficha). O parâmetro mais importante do balde é o seu tamanho, que é o número de fichas que ele pode armazenar.
Cada ficha que chega coleta um pacote entrante da fila de dados e cada ficha é então removida do balde. Associando esse algoritmo com os dois fluxos – ficha e dados, dá-nos três possíveis cenários:
• Os dados chegam a TBF a uma taxa que é igual à taxa de fichas entrantes. Nesse caso cada pacote entrante possui sua ficha correspondente e o mesmo é repassado a fila sem atraso.
• Os dados chegam a TBF a uma taxa que é menor que a taxa de ficha. Somente uma parte das fichas são removidas na saída de cada pacote de dados que é enviado a fila, assim as fichas acumulam, até o tamanho do balde. As fichas não usadas podem então ser usadas para enviar os dados a uma velocidade que pode exceder a taxa de ficha padrão, nesse caso ocorre rajadas curtas de dados.
• Os dados chegam a TBF a uma taxa maior que a taxa de ficha. Isso significa que o balde tão logo ficará sem fichas, o que fará com que o TBF se estrangule momentaneamente. Isso é chamado de ‘situação overlimit’. Se pacotes continuarem entrando, então os mesmos começarão a ser descartados.
O último cenário é muito importante, porque ele permite regular administrativamente a banda disponível para os dados que estão passando pelo filtro.
A acumulação de fichas permite uma rajada curta de dados acima do limite a ser ainda repassado sem perda, mas qualquer sobrecarga duradoura causará aos pacotes serem constantemente atrasados, e então descartados.
Favor observe que na implementação real, as fichas correspondem a bytes, e não a pacotes.
9.2.2.1. Parâmetros & Uso
Muito provavelmente ainda que você não precise alterá-los, o TBF possui algumas opções disponíveis que são configuráveis. Os primeiros parâmetros que estão sempre disponíveis:
limit or latency
A opção limit é o número de bytes que pode ser enfileirado que estão esperando por fichas ficarem disponíveis. Você pode especificar ele de outra forma definindo o parâmetro latency, que especifica a quantidade de tempo máxima que um pacote pode ficar no TBF. O último parâmetro leva em consideração o tamanho do balde, a taxa e a possibilidade do peakrate - taxa de pico - (se for configurado)
burst/buffer/maxburst
Tamanho do balde, em bytes. Essa é a quantidade máxima de bytes que as fichas podem ficar disponíveis de forma instantânea. Em geral, ajustes com taxas mais largas exigem um buffer maior. Para 10mbit/s nas placas Intel, você precisará de um buffer com pelo menos 10kbyte se você deseja alcançar sua taxa configurada!
Se o seu buffer for bastante pequeno, os pacotes podem ser descartados porque mais fichas chegam por tique de relógio que pode ser suportado no balde.
mpu
Um pacote dimensionado com zero não usa banda zero. Na Ethernet, nenhum pacote usa menos de 64 bytes. A Unidade Mínima de Pacote (Minimum Packet Unit) determina o uso mínimo do token para um pacote.
rate
A velocidade que pode ser ajustável. Veja os comentários acima a respeito desses limites!
Se o balde contiver tokens e for permitido esvaziar então, por padrão, executa com velocidade infinita. Se isso for inaceitável, use os seguintes parâmetros:
peakrate
Se fichas estiverem disponíveis, e pacotes chegarem, elas são enviadas imediatamente por padrão, em velocidade clara por assim falar. Isso pode não ser o que você deseja, especialmente se você tiver um balde espaçoso.
A taxa de pico pode ser usada para especificar quão rapidamente ao balde é permitido ser esvaziado. Se tudo for certo, isso é alcançado liberando um pacote, e então espera justamente o tamanho suficiente, e libera o próximo. Nós calculamos nossa espera assim nós enviamos justamente na taxa de pico.
Contudo, devido à resolução padrão do relógio UNIX de 10ms, com pacotes médios de 10.000 bits, estamos limitados a 1mbit/s de taxa de pico!
mtu/minburst
O parâmetro peakrate de 1mbit/s não é muito útil se sua taxa regular for maior do que essa. Um valor de peakrate mais alto é possível enviando mais pacotes por tique de relógio, o que efetivamente significa que nós criamos um segundo balde!
Esse segundo balde é padronizado para ser um balde simples, o que não é um balde em hipótese algum.
Para calcular o valor máximo possível de peakrate, multiplique por 100 o mtu configurado (ou mais precisamente, HZ, que é 100 em placas Intel, 1024 em placas Alpha).
9.2.2.2. Configuração Exemplo
Uma configuração simples, mas *muito* útil é:
# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540
Certo, mas por que é útil? Porque caso você tenha um dispositivo de rede com uma fila grande, como um modem ASDL ou Cable Modem, e você o informa a respeito de um dispositivo rápido, como uma interface Ethernet, você descobrirá que fazer upload destruirá completamente a interatividade.
Isso porque fazer upload vai encher a fila do modem, que muito provavelmente é *imensa* porque isso ajuda realmente alcançar boa taxa de transmissão de dados no upload. Mas isso não é o que você deseja, você deseja ter a fila nem tão grande assim de sorte que a interatividade continue e que você possa ainda continuar a fazer outras coisas enquanto transmite dados.
A linha acima deixará o envio lento a uma taxa que não vai se apossar de uma fila no modem – a fila estará no Linux, onde podemos controlá-la a um tamanho limitado.
Altere o valor 220kbit de modo a refletir a velocidade *real* do seu uplink, diminua por um pequeno percentual. Se você possui um modem realmente rápido, aumente ‘burst’ um pouco.
Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl
Thomas Graf (Autor de Seção)
tgraf@suug.ch
Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx
Remco van Mook (Autor de Seção)
remco@virtu.nl
Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com
Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com
Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl
Pedro Larroy (Autor de Seção)
piotr@member.fsf.org
Nenhum comentário:
Postar um comentário