Ho letto molte volte sul token bucket di filtro di Linux (tbf) e ancora non capisco perfettamente come dovrei calcolare i parametri burste latency, vergogna per me :(

Suppongo che una latenza ragionevole sia di circa 50 ms. OK, ma quale valore dovrebbe prendere il burst?

La manpage dice:

Quest'ultimo calcolo tiene conto della dimensione del bucket, della velocità e, eventualmente, della frequenza di picco (se impostata). Questi due parametri si escludono a vicenda.

Quindi, in che modo la latenza è correlata a bucket e filtro? Esiste una formula per calcolarlo? O è semplicemente una questione di "OK, X byte di burst e Y secondi di latenza mi fanno bene"?

Dalla manpage, l'unico vincolo burstè che deve essere abbastanza alto da consentire la velocità configurata: deve essere almeno rate / HZ. HZ è un parametro di configurazione del kernel; puoi capire di cosa si tratta sul tuo sistema controllando la configurazione del tuo kernel. Ad esempio, su Debian puoi:

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

quindi HZ sul mio sistema è 250. Per raggiungere una velocità di 10 Mbps, avrei quindi bisogno burstdi almeno 10.000.000 bit / sec ÷ 250 Hz = 40.000 bit = 5000 byte. (Notare che il valore più alto nella manpage proviene da quando HZ = 100 era il valore predefinito).

Ma oltre a ciò, burstè anche uno strumento politico. Configura la misura in cui è possibile utilizzare meno larghezza di banda ora per "salvarla" per un utilizzo futuro. Una cosa comune qui è che potresti voler consentire a piccoli download (diciamo, una pagina web) di andare molto velocemente, pur limitando i grandi download. Puoi farlo aumentando burstle dimensioni che consideri un piccolo download. (Tuttavia, passeresti spesso a un qdisc di classe come htb, in modo da poter segmentare i diversi tipi di traffico.)

Quindi: configuri il burst in modo che sia almeno abbastanza grande da ottenere il desiderato rate. Oltre a ciò, puoi aumentarlo ulteriormente, a seconda di ciò che stai cercando di ottenere.

Modello concettuale di un filtro secchio token

Un "secchio" è un oggetto metaforico. Le sue proprietà chiave sono che può contenere token e che il numero di token che può contenere è limitato: se si tenta di aggiungerne altri, "trabocca" e i token extra vengono persi (proprio come se si cercasse di inserire troppa acqua in un secchio reale). Viene chiamata la dimensione del bucket burst.

Per poter effettivamente trasmettere un pacchetto sulla rete, quel pacchetto deve ottenere token uguali alla sua dimensione in byte o mpu(qualunque sia il più grande).

C'è (o può esserci) una linea (coda) di pacchetti in attesa di token. Ciò si verifica quando il bucket è vuoto o, in alternativa, ha meno token rispetto alla dimensione del pacchetto. C'è solo così tanto spazio sul marciapiede davanti al secchio e la quantità di spazio (in byte) viene impostata direttamente da limit. In alternativa, può essere impostato indirettamente con latency(in un mondo ideale, il calcolo sarebbe rate× latency).

Quando il kernel vuole inviare un pacchetto dall'interfaccia filtrata, tenta di posizionare il pacchetto alla fine della riga. Se non c'è spazio sul marciapiede, è un peccato per il pacchetto, perché alla fine del marciapiede c'è una fossa senza fondo e il kernel rilascia il pacchetto.

Il pezzo finale è una macchina per fare token che aggiunge rate/ HZtoken al secchio ad ogni tick. (Ecco perché il tuo bucket deve essere almeno così grande, altrimenti alcuni token appena coniati verranno immediatamente scartati).

Un'altra risposta per completare quella di Derobert.

In primo luogo sulle moderne CPU Intel il manuale non è aggiornato. Le moderne CPU hanno timer ad alta risoluzione e il moderno Linux è meno tick - letteralmente significa che non ci sono tick timer. Pertanto, tutti quei commenti che rendono i bucket abbastanza grandi da contenere i token in un solo timer sono irrilevanti. In effetti, l'analogia del bucket era presente solo per aiutare l'utente a comprendere l'interazione tra la granularità del timer e la velocità di invio. Ora che Linux ha timer a nanosecondi su hardware moderno, perde la sua utilità.

Per TBF il parametro burst è il numero di byte che possono essere inviati a velocità illimitata prima che la limitazione della velocità (specificata dalla velocità ) entri in azione. Una volta che la limitazione della frequenza è stata avviata, l'unico modo per esplodere di nuovo è limitare l'invio al di sotto di tale velocità .

Ad esempio, supponiamo che il parametro burst tbf sia 10 KB byte e che il parametro frequenza tbf sia 2 KB byte / secondo e che attualmente sia a velocità limitata (ovvero che il burst sia esaurito, quindi si è limitati all'invio a 2 kbps). Se riduci volontariamente la velocità che invii a 1Kbps per 10 secondi, accumulerai di nuovo il tuo margine di burst di 10K byte (= (2000 [byte / sec] - 1000 [byte / sec]) * 10 sec). Mantenerlo al di sotto di 1kbps per più di 10 secondi non avrebbe alcun effetto perché tbf non consente di accumulare più del parametro burst .

Se smettessi di spendere del tutto, otterrai di nuovo la tua indennità di scoppio in 5 secondi (= 100000 [byte] / 2000 [byte / sec]).

Non è necessario recuperare tutte le indennità di scoppio per utilizzarlo, è possibile utilizzare quanto accumulato.

Un altro modo di vedere questo è: ti è permesso inviare byte a raffica a velocità illimitata, quindi la tua velocità media a lungo termine non potrà mai superare la velocità . Tuttavia, poiché si tratta di una media a lungo termine, se si scende al di sotto della velocità, è possibile recuperare l'invio a tutta velocità, ma anche in questo caso è consentito inviare a pieno solo per la maggior parte dei byte di scoppio (e in caso contrario permetterti di recuperare il ritardo non puoi).

L'altra ruga è che TBF ha due di questi limitatori di velocità e il tuo traffico deve passare attraverso entrambi. Nel secondo, il parametro burst si chiama mtu e, e la frequenza si chiama peakrate . Dovresti usare questo secondo per limitare la velocità alla quale il primo può inviare i suoi lampi. L'utilizzo di questo secondo è facoltativo e, se non lo si utilizza, le raffiche vengono inviate alla velocità del dispositivo.

Infine, tbf ha un parametro limite . Se il programma invia in modo persistente più veloce della velocità , i pacchetti si accumuleranno nella coda. Non c'è memoria del kernel infinita, quindi il limite indica quanti byte possono accumularsi prima che il kernel inizi a scartare i pacchetti.