Já li várias vezes sobre o filtro de balde de tokens (tbf) do Linux e ainda não entendo completamente como devo calcular os parâmetros burste latency, que vergonha :(

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

A página de manual diz:

O último cálculo leva em consideração o tamanho do balde, a taxa e possivelmente a taxa de pico (se definida). Esses dois parâmetros são mutuamente exclusivos.

Então, como a latência está relacionada ao intervalo e ao filtro? Existe uma fórmula para calculá-lo? Ou é simplesmente uma questão de "OK, X bytes de burst e Y segundos de latência são bons para mim"?

Na página de manual, a única restrição bursté que ela deve ser alta o suficiente para permitir sua taxa configurada: deve ser pelo menos taxa / HZ. HZ é um parâmetro de configuração do kernel; você pode descobrir o que é no seu sistema verificando a configuração do 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, seria necessário, burstno mínimo, 10.000.000 bits / s ~ 250 Hz = 40.000 bits = 5000 bytes. (Observe que o valor mais alto na página de manual é quando HZ = 100 era o padrão).

Mas além disso, bursttambém é uma ferramenta de política. Ele configura até que ponto você pode usar menos largura de banda agora para "salvá-la" para uso futuro. Uma coisa comum aqui é que você pode permitir que pequenos downloads (digamos, uma página da web) sejam muito rápidos, enquanto controla grandes downloads. Você faz isso aumentando bursto tamanho que considera um pequeno download. (Porém, muitas vezes você alterna para um qdisc de classe, como o htb, para segmentar os diferentes tipos de tráfego.)

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

Modelo conceitual de um filtro de bucket de 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 balde é chamado burst.

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

Há (ou pode haver) uma linha (fila) de pacotes aguardando tokens. Isso ocorre quando o balde está vazio ou, em alternativa, possui menos tokens 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. Como alternativa, 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 houver espaço na calçada, isso é lamentável para o pacote, porque no final da calçada há um poço sem fundo, e o kernel deixa o pacote cair.

A peça final é uma máquina de fabricação de tokens que adiciona rate/ HZtokens ao balde a cada carrapato. (É por isso que seu balde deve ter pelo menos esse tamanho, caso contrário, alguns dos tokens recém-criados serão imediatamente descartados).

Outra resposta para complementar a derobert.

Primeiramente, nos modernos processadores Intel, o manual está desatualizado. As CPUs modernas têm timers de alta resolução, e o Linux moderno é menos eficiente - literalmente, o que significa que não há marcações de timer. Portanto, todos os comentários que fazem baldes grandes o suficiente para armazenar os tokens em um cronômetro são irrelevantes. De fato, 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 temporizadores de nanossegundos no hardware moderno, perde sua utilidade.

Para o TBF, o parâmetro burst é o número de bytes que podem ser enviados em velocidade ilimitada antes que a limitação da taxa (especificada pela taxa ) comece. Depois que a limitação da taxa for acionada, a única maneira de estourar novamente é limitar o envio para abaixo dessa taxa .

Por exemplo, digamos que seu parâmetro de burst tbf seja 10K bytes e seu parâmetro de taxa tbf seja 2K bytes / segundo, e você esteja atualmente com uma taxa limitada (por exemplo, o burst está esgotado, portanto, você está limitado a enviar a 2kbps). Se você voluntariamente reduzisse a velocidade que enviava a 1Kbps por 10 segundos, acumularia novamente sua permissão de rajada de 10K bytes (= (2000 [bytes / s] - 1000 [bytes / s]) * 10 s). Mantê-lo abaixo de 1kbps por mais de 10seg não teria efeito porque o tbf não permite que você não acumule mais do que o parâmetro burst .

Se você parasse de gastar completamente, recuperaria sua permissão de rajada novamente em 5seg (= 100000 [bytes] / 2000 [bytes / s]).

Você não precisa recuperar todo o seu subsídio de explosão para usá-lo; pode usar o máximo que acumular.

Outra maneira de analisar isso é: você tem permissão para enviar bytes de rajada a velocidade ilimitada; depois, sua velocidade média de longo prazo nunca poderá exceder a taxa . No entanto, por se tratar de uma média de longo prazo, se você cair abaixo da taxa, poderá atualizar enviando a toda velocidade - mas mesmo assim, você poderá enviar na íntegra apenas no máximo de bytes burst (e se isso não acontecer) permitir que você acompanhe você não pode).

O outro problema é que o TBF possui dois desses limitadores de taxa e seu tráfego precisa passar pelos dois. No segundo, o parâmetro burst é chamado mtu e, e a taxa é denominada taxa de pico . Você deve usar este segundo para limitar a velocidade com que o primeiro pode enviar suas rajadas. O uso deste segundo é opcional e, se você não o usar, as rajadas serão enviadas na velocidade do dispositivo.

Finalmente, tbf possui um parâmetro limite . Se o programa persistentemente enviar mais rápido que a taxa , os pacotes serão acumulados na fila. Não há memória infinita do kernel, portanto, o limite indica quantos bytes podem ser acumulados antes que o kernel comece a descartar pacotes.