J'ai lu de nombreuses fois sur le filtre de seau à jetons de Linux (tbf) et je ne comprends toujours pas comment calculer les paramètres burstet latency, honte à moi :(

Je suppose qu'une latence raisonnable est d'environ 50 ms. OK, mais quelle valeur doit prendre l'éclatement?

La page de manuel indique:

Ce dernier calcul prend en compte la taille du godet, le débit et éventuellement le débit de crête (si défini). Ces deux paramètres s'excluent mutuellement.

Alors, comment la latence est-elle liée au bucket et au filtre? Existe-t-il une formule pour le calculer? Ou est-ce simplement une question de "OK, X octets de rafale et Y secondes de latence sont bons pour moi"?

A partir de la page de manuel, la seule contrainte burstest qu'elle doit être suffisamment élevée pour autoriser votre taux configuré: elle doit être au moins taux / HZ. HZ est un paramètre de configuration du noyau; vous pouvez comprendre ce que c'est sur votre système en vérifiant la configuration de votre noyau. Par exemple, sur Debian, vous pouvez:

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

donc HZ sur mon système est de 250. Pour atteindre un taux de 10 Mbps, il me faudrait donc burstau moins 10 000 000 bits / sec ÷ 250 Hz = 40 000 bits = 5000 octets. (Notez que la valeur la plus élevée dans la page de manuel date de quand HZ = 100 était la valeur par défaut).

Mais au-delà, burstc'est aussi un outil politique. Il configure la mesure dans laquelle vous pouvez utiliser moins de bande passante maintenant pour la "sauvegarder" pour une utilisation future. Une chose courante ici est que vous souhaiterez peut-être autoriser les petits téléchargements (par exemple, une page Web) à aller très vite, tout en limitant les gros téléchargements. Pour ce faire, augmentez burstla taille que vous considérez comme un petit téléchargement. (Cependant, vous passiez souvent à un qdisc de classe comme htb, vous pouvez donc segmenter les différents types de trafic.)

Donc: vous configurez la rafale pour qu'elle soit au moins suffisamment grande pour atteindre le résultat souhaité rate. Au-delà, vous pouvez l'augmenter encore, en fonction de ce que vous essayez de réaliser.

Modèle conceptuel d'un filtre de seau à jetons

Un "seau" est un objet métaphorique. Ses principales propriétés sont qu'il peut contenir des jetons et que le nombre de jetons qu'il peut contenir est limité - si vous essayez d'en ajouter plus, il "déborde" et les jetons supplémentaires sont perdus (tout comme essayer de mettre trop d'eau dans un seau réel). La taille du seau est appelée burst.

Afin de transmettre réellement un paquet sur le réseau, ce paquet doit obtenir des jetons égaux à sa taille en octets ou mpu(selon la valeur la plus élevée).

Il existe (ou peut exister) une ligne (file d'attente) de paquets en attente de jetons. Cela se produit lorsque le compartiment est vide ou qu'il a moins de jetons que la taille du paquet. Il n'y a que peu d'espace sur le trottoir devant le godet, et la quantité d'espace (en octets) est définie directement par limit. Alternativement, il peut être défini indirectement avec latency(dans un monde idéal, le calcul serait rate× latency).

Lorsque le noyau veut envoyer un paquet hors de l'interface filtrée, il tente de placer le paquet à la fin de la ligne. S'il n'y a pas de place sur le trottoir, c'est dommage pour le paquet, car à la fin du trottoir se trouve une fosse sans fond, et le noyau laisse tomber le paquet.

La dernière pièce est une machine à fabriquer des jetons qui ajoute rate/ HZjetons au seau à chaque tick. (C'est pourquoi votre seau doit être au moins aussi grand, sinon certains des jetons nouvellement créés seront immédiatement jetés).

Une autre réponse pour compléter celle de Derobert.

Tout d'abord sur les processeurs Intel modernes, le manuel est obsolète. Les processeurs modernes ont des minuteries haute résolution, et Linux moderne est moins tick - ce qui signifie littéralement qu'il n'y a pas de tics de minuterie. Ainsi, tous ces commentaires faisant des seaux assez grands pour contenir les jetons dans un seul minuteur ne sont pas pertinents. En fait, l'analogie du bucket n'était là que pour aider l'utilisateur à comprendre l'interaction entre la granularité du minuteur et la vitesse d'envoi. Maintenant que Linux a des minuteries nanosecondes sur du matériel moderne, il perd son utilité.

Pour TBF, le paramètre de rafale est le nombre d'octets qui peuvent être envoyés à une vitesse illimitée avant que la limitation de débit (spécifiée par le débit ) ne se déclenche. .

Par exemple, disons que votre paramètre de rafale tbf est de 10K octets, et votre paramètre de débit tbf est de 2K octets / seconde, et que vous êtes actuellement limité en débit (c'est-à-dire que la rafale est épuisée, vous êtes donc limité à l'envoi à 2kbps). Si vous réduisez volontairement la vitesse d'envoi à 1Kbps pendant 10 secondes, vous accumulez à nouveau votre allocation de rafale de 10K octets (= (2000 [octets / sec] - 1000 [octets / sec]) * 10 sec). Le maintenir en dessous de 1kbps pendant plus de 10sec n'aurait aucun effet car tbf ne permet pas que vous ne soyez pas autorisé à accumuler plus que le paramètre burst .

Si vous arrêtez complètement de dépenser, vous récupérerez votre allocation de rafale en 5 secondes (= 100000 [octets] / 2000 [octets / sec]).

Vous n'avez pas besoin de récupérer toute votre allocation de rafale pour l'utiliser, vous pouvez en utiliser autant que vous en avez accumulé.

Une autre façon de voir les choses est la suivante: vous êtes autorisé à envoyer des octets de rafale à une vitesse illimitée, par la suite votre vitesse moyenne à long terme ne pourra jamais dépasser le taux . Cependant, comme il s'agit d'une moyenne à long terme, si vous descendez en dessous du taux, vous êtes autorisé à rattraper votre retard en envoyant à pleine vitesse - mais même alors, vous n'êtes autorisé à envoyer à plein régime que pour au plus des octets de rafale (et si cela ne le fait pas) vous permettent de rattraper votre retard).

L'autre ride est que TBF a deux de ces limiteurs de débit, et votre trafic doit passer par les deux. Dans le second, le paramètre de rafale est appelé mtu et, et le débit est appelé débit de crête . Vous êtes censé utiliser ce second pour limiter la vitesse à laquelle le premier peut envoyer ses rafales. L'utilisation de cette seconde option est facultative et si vous ne l'utilisez pas, les rafales sont envoyées à la vitesse de l'appareil.

Enfin, tbf a un paramètre limite . Si le programme envoie de manière persistante plus rapidement que rate , les paquets s'accumuleront dans la file d'attente. Il n'y a pas de mémoire infinie du noyau, donc limit indique combien d'octets peuvent s'accumuler avant que le noyau ne commence à éliminer les paquets.