Tamanho do bucket em tbf

Question

Eu li muitas vezes sobre filtro de token bucket do Linux (tbf) e ainda não • Entendo completamente como devo calcular os parâmetros burst e latency , que vergonha para mim: (

Suponho que uma latência razoável seja de cerca de 50 ms. OK, mas que valor deve estourar?

A manpage diz:

The latter calculation takes into account the size of the bucket, the rate and possibly the peakrate (if set). These two parameters are mutually exclusive.

Então, como a latência está relacionada ao bucket e ao filtro? Existe uma fórmula para calcular isso? Ou é simplesmente uma questão de "OK, X bytes de burst e Y segundos de latência é bom para mim"?

    

Answer 1

Na página de manual, a única restrição em burst é que ela deve ser alta o suficiente para permitir sua taxa configurada: ela deve ter pelo menos taxa / HZ. HZ é um parâmetro de configuração do kernel; você pode descobrir o que está no seu sistema verificando a configuração do seu kernel. Por exemplo, no Debian, você pode:

$ egrep '^CONFIG_HZ_[0-9]+' /boot/config-'uname -r'
CONFIG_HZ_250=y

então HZ no meu sistema é 250. Para atingir uma taxa de 10mbps, eu precisaria de um burst de pelo menos 10.000.000 bits / seg ~ 250 Hz = 40.000 bits = 5000 bytes. (Observe que o valor mais alto na página man é de quando HZ = 100 era o padrão).

Mas além disso, burst também é uma ferramenta política. Ele configura até que ponto você pode usar menos largura de banda agora para "salvá-lo" para uso futuro. Uma coisa comum aqui é que você pode querer permitir que pequenos downloads (digamos, uma página da web) sejam muito rápidos, ao mesmo tempo em que estrangulam grandes downloads. Você faz isso aumentando burst para o tamanho que você considera um pequeno download. (No entanto, você costuma alternar para um qdisc de classe como o htb, para poder segmentar os diferentes tipos de tráfego.)

Então: você configura o burst para ser pelo menos grande o suficiente para atingir o rate desejado. Além disso, você pode aumentá-lo ainda mais, dependendo do que você está tentando alcançar.

Modelo Conceitual de um Filtro de Caçamba Token

Um"balde" é um objeto metafórico. Suas principais propriedades são que ele pode conter tokens e que o número de tokens que ele pode conter é limitado - se você tentar adicionar mais, ele "transborda" e os tokens extras são perdidos (assim como tentar colocar muita água em um balde real). O tamanho do depósito é chamado burst .

Para realmente transmitir um pacote para a rede, esse pacote deve obter tokens iguais ao tamanho em bytes ou mpu (o que for maior).

Existe (ou pode ser) uma linha (fila) de pacotes esperando por tokens. Isso ocorre quando o bucket está vazio ou, alternativamente, tem menos tokens do que o tamanho do pacote. Há muito espaço na calçada em frente ao balde e a quantidade de espaço (em bytes) é definida diretamente por limit . Alternativamente, pode ser definido indiretamente com latency (em um mundo ideal, o cálculo seria rate × latency ).

Quando o kernel deseja enviar um pacote pela interface filtrada, ele tenta colocar o pacote no final da linha. Se não há espaço na calçada, isso é uma pena para o pacote, porque no final da calçada há um poço sem fundo, e o kernel deixa cair o pacote.

A peça final é uma máquina de geração de tokens que adiciona rate / HZ tokens ao bloco a cada tick. (É por isso que seu balde deve ser pelo menos tão grande, caso contrário, alguns dos tokens recém-cunhados serão imediatamente descartados).

    

Answer 2

Outra resposta para complementar a derobert.

Em primeiro lugar no CPU Intel moderno, o manual está desatualizado. Os processadores modernos têm timers de alta resolução, e o Linux moderno tem menos ticks - literalmente significando que não há pulsos de timer. Assim, todos os comentários que fazem baldes grandes o suficiente para manter os tokens em um cronômetro são irrelevantes. Na verdade, a analogia do bucket estava lá apenas para ajudar o usuário a entender a interação entre a granularidade do timer e a velocidade de envio. Agora que o Linux possui timers de nanossegundos no hardware moderno, ele perde sua utilidade.

Para TBF, o parâmetro burst é o número de bytes que podem ser enviados a uma velocidade ilimitada antes que a limitação de taxa (especificada por taxa ) seja ativada. chutado a única maneira de explodir novamente é limitar o seu envio para abaixo dessa taxa.

Por exemplo, digamos que seu parâmetro tbf burst é de 10K bytes, e seu parâmetro tbf rate é de 2K bytes / segundo, e você está limitado atualmente (isto é, o explosão está esgotada, então você está limitado a enviar a 2kbps). Se você voluntariamente reduziu a velocidade de envio para 1Kbps por 10 segundos, você iria acumular sua reserva de 10k bytes novamente (= (2000 [bytes / s] - 1000 [bytes / s]) * 10 s). Mantê-lo abaixo de 1kbps por mais de 10sec não teria efeito porque o tbf não permite que você não tenha permissão para acumular mais do que o parâmetro burst .

Se você parasse de gastar inteiramente, você receberia o seu limite de burst novamente em 5sec (= 100000 [bytes] / 2000 [bytes / s]).

Você não precisa obter todo o seu limite de burst para usá-lo, você pode usar o máximo que acumulou.

Outra maneira de ver isso é: você tem permissão para enviar burst bytes a uma velocidade ilimitada; depois disso, sua velocidade média de longo prazo nunca pode exceder taxa . No entanto, como é uma média de longo prazo, se você cair abaixo de taxa , poderá subir o número enviando a toda velocidade - mas, mesmo assim, só é permitido enviá-lo por no máximo > burst bytes (e se isso não permitir que você o alcance, você não pode).

A outra ruga é TBF tem dois destes limitadores de taxa, e seu tráfego tem que passar por ambos. No segundo, o parâmetro burst é chamado de mtu e a taxa é chamada de taxa de pico . Você deve usar este segundo para limitar a velocidade na qual o primeiro pode enviar suas rajadas. Usar este segundo é opcional, e se você não usá-lo, as rajadas são enviadas na velocidade do dispositivo.

Finalmente, tbf tem um parâmetro limite . Se o programa enviar persistentemente mais rápido que taxa , os pacotes serão acumulados na fila. Não há memória infinita do kernel, então limit diz quantos bytes podem ser construídos antes que o kernel inicie o descarte de pacotes.