Bonjour,
Je termine la traduction de la dernière version de cet HOWTO. Je n'arrive pas à trouver de traductions satisfaisantes pour certains passages que je vous soumet :
* Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously. In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer if you want to reach your configured rate! If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
* Classification can be performed using filters. A filter contains a number of conditions which if matched, make the filter match.
* When the kernel decides that it needs to extract packets to send to the interface, the root qdisc 1: gets a dequeue request, which is passed to 1:1, which is in turn passed to 10:, 11: and 12:, which each query their siblings, and try to dequeue() from them. In this case, the kernel needs to walk the entire tree, because only 12:2 contains a packet.
* As mentioned before, CBQ needs to throttle in case of overlimit. The ideal solution is to do so for exactly the calculated idle time, and pass 1 packet. However, Unix kernels generally have a hard time scheduling events shorter than 10ms, so it is better to throttle for a longer period, and then pass minburst packets in one go, and then sleep minburst times longer. The time to wait is called the offtime. Higher values of minburst lead to more accurate shaping in the long term, but to bigger bursts at millisecond timescales.
* As your HTB configuration gets more complex, your configuration scales well. With CBQ it is already complex even in simple cases!
Je sais que le texte est un peu long, mais je vous demande un peu d'indulgence !!
Merci de votre aide,
Laurent Foucher
Afficher les réponses par date
* Laurent Foucher foucher@gch.iut-tlse3.fr (20020127 20:14):
- Size of the bucket, in bytes. This is the maximum amount of bytes that
tokens can be available for instantaneously. In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer if you want to reach your configured rate! If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
Taille du { seau, réserve, tampon }, en octets. C'est la quantité maximale en octets pour laquelle on disposera de jetons en meme temps. En général, des taux de limitation { mettre ce que tu as traduit pour shaping } plus importants nécessitent un tampon plus grand. Pour 10 Mbit/s sur plateforme Intel, vous avez besoin d'un tampon d'au moins 10 kilo-octets si vous voulez atteindre la limitation configurée ! Si votre tampon est trop petit, les paquets pourront etre { rejetés, balancés } car il arrive plus de jetons par tic d'horloge que ne peut en contenir le tampon.
- Classification can be performed using filters. A filter contains a
number of conditions which if matched, make the filter match.
On peut faire de la classification à l'aide de filtres. Un filtre contient un certain nombre de conditions qui font correspondre le filtre si ces conditions correspondent.
- When the kernel decides that it needs to extract packets to send to
the interface, the root qdisc 1: gets a dequeue request, which is passed to 1:1, which is in turn passed to 10:, 11: and 12:, which each query their siblings, and try to dequeue() from them. In this case, the kernel needs to walk the entire tree, because only 12:2 contains a packet.
Quand le noyau décide qu'il veut extraire des paquets à envoyer à l'interface, le qdisc racine 1: reçoit une demande de { défilage, déqueuage, ? } qui est passée à 1:1, qui à son tour la passe à 10:, 11: et 12:, chacune à son tour demandent à leurs soeurs { siblings ? }, et essaient d'obtenir un défilage (dequeue()). Dans ce cas, le noyau doit traverser l'arbre entier, car seul 12:2 contient un paquet.
- As mentioned before, CBQ needs to throttle in case of overlimit. The
ideal solution is to do so for exactly the calculated idle time, and pass 1 packet. However, Unix kernels generally have a hard time scheduling events shorter than 10ms, so it is better to throttle for a longer period, and then pass minburst packets in one go, and then sleep minburst times longer. The time to wait is called the offtime. Higher values of minburst lead to more accurate shaping in the long term, but to bigger bursts at millisecond timescales.
Comme nous l'avons déjà indiqué, CBQ doit limiter en cas de dépassement. La solution idéale est de le faire pendant exactement le temps mort calculé, et de passer un paquet. Cependant, les noyaux Unix ont généralement du mal à prévoir des événements plus courts que 10 ms, et il est donc mieux de limiter pendant une période plus longue, puis d'envoyer minburst paquets d'un seul coup, puis de dormir minburst fois d'autant. Le temps d'attente s'appelle offtime { trad ? }. Des valeurs plus grandes de minburst tendent à améliorer le controle de flux à long terme, mais à des pointes de trafic plus élevées à des échelles de temps de l'ordre de la milliseconde.
- As your HTB configuration gets more complex, your configuration scales
well. With CBQ it is already complex even in simple cases!
Au fur et à mesure que votre configuration HTB se complexifie, votre configuration s'adapte bien. Avec CBQ, elle est déjà complexe meme dans les cas simples !
HTH olive