He leído muchas veces sobre el filtro de cubo de token de Linux (tbf) y todavía no entiendo completamente cómo debo calcular los parámetros bursty latency, lástima :(

Supongo que una latencia razonable es de alrededor de 50 ms. Bien, pero ¿qué valor debería tomar la explosión?

La página del manual dice:

El último cálculo tiene en cuenta el tamaño del depósito, la tasa y posiblemente la tasa máxima (si se establece). Estos dos parámetros son mutuamente excluyentes.

Entonces, ¿cómo se relaciona la latencia con el depósito y el filtro? ¿Hay una fórmula para calcularlo? ¿O es simplemente una cuestión de "OK, X bytes de ráfaga e Y segundos de latencia son buenos para mí"?

Desde la página de manual, la única restricción burstes que debe ser lo suficientemente alta como para permitir su velocidad configurada: debe ser al menos velocidad / HZ. HZ es un parámetro de configuración del núcleo; puede averiguar qué es en su sistema verificando la configuración de su núcleo. Por ejemplo, en Debian, puedes:

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

entonces HZ en mi sistema es 250. Para alcanzar una velocidad de 10mbps, necesitaría burstpor lo menos 10,000,000 bits / seg ÷ 250 Hz = 40,000 bits = 5000 bytes. (Tenga en cuenta que el valor más alto en la página de manual es de cuando HZ = 100 era el valor predeterminado).

Pero más allá de esto, bursttambién es una herramienta política. Configura hasta qué punto puede usar menos ancho de banda ahora para "guardarlo" para uso futuro. Una cosa común aquí es que es posible que desee permitir que las descargas pequeñas (por ejemplo, una página web) vayan muy rápido, al tiempo que aceleran las descargas grandes. Para ello, aumenta burstal tamaño que considera una descarga pequeña. (Sin embargo, a menudo cambia a un qdisc con clase como htb, por lo que puede segmentar los diferentes tipos de tráfico).

Entonces: configura la ráfaga para que sea al menos lo suficientemente grande como para lograr lo deseado rate. Más allá de eso, puede aumentarlo aún más, dependiendo de lo que esté tratando de lograr.

Modelo conceptual de un filtro de cubo de fichas

Un "cubo" es un objeto metafórico. Sus propiedades clave son que puede contener tokens y que la cantidad de tokens que puede contener es limitada: si intenta agregar más, se "desborda" y se pierden los tokens adicionales (al igual que tratar de poner demasiada agua en un cubo real). Se llama el tamaño del cubo burst.

Para transmitir realmente un paquete a la red, ese paquete debe obtener tokens iguales a su tamaño en bytes o mpu(el que sea mayor).

Hay (o puede haber) una línea (cola) de paquetes esperando tokens. Esto ocurre cuando el depósito está vacío o, alternativamente, tiene menos tokens que el tamaño del paquete. Solo hay mucho espacio en la acera frente al cubo, y la cantidad de espacio (en bytes) se establece directamente por limit. Alternativamente, se puede establecer indirectamente con latency(en un mundo ideal, el cálculo sería rate× latency).

Cuando el núcleo quiere enviar un paquete desde la interfaz filtrada, intenta colocar el paquete al final de la línea. Si no hay espacio en la acera, es desafortunado para el paquete, porque al final de la acera hay un pozo sin fondo, y el grano deja caer el paquete.

La pieza final es una máquina de hacer fichas que agrega rate/ HZfichas al cubo cada vez que se marca. (Esta es la razón por la cual su cubo debe ser al menos tan grande, de lo contrario, algunas de las fichas recién acuñadas se descartarán inmediatamente).

Otra respuesta para complementar la derobert.

En primer lugar, en las CPU Intel modernas, el manual está desactualizado. Las CPU modernas tienen temporizadores de alta resolución, y Linux moderno es menos tick, literalmente significa que no hay tics de temporizador. Por lo tanto, todos esos comentarios que hacen que los cubos sean lo suficientemente grandes como para contener los tokens en un temporizador son irrelevantes. De hecho, la analogía del cubo solo estaba allí para ayudar al usuario a comprender la interacción entre la granularidad del temporizador y la velocidad de envío. Ahora que Linux tiene temporizadores de nanosegundos en hardware moderno, pierde su utilidad.

Para TBF, el parámetro de ráfaga es el número de bytes que se pueden enviar a velocidad ilimitada antes de que entre en vigencia la limitación de velocidad (especificada por la velocidad ). Una vez que la limitación de velocidad ha comenzado, la única forma de estallar nuevamente es limitar su envío a una velocidad inferior a esa velocidad. .

Por ejemplo, supongamos que su parámetro de ráfaga de tbf es de 10K bytes, y su parámetro de velocidad de tbf es de 2K bytes / segundo, y actualmente tiene una velocidad limitada (es decir, la ráfaga está agotada, por lo que está limitado a enviar a 2kbps). Si reduce voluntariamente la velocidad a la que envía a 1 Kbps durante 10 segundos, acumularía de nuevo su asignación de ráfaga de 10 K bytes (= (2000 [bytes / seg] - 1000 [bytes / seg]) * 10 seg). Mantenerlo por debajo de 1 kbps durante más de 10 segundos no tendría ningún efecto porque tbf no permite que no se le permita acumular más que el parámetro de ráfaga .

Si dejara de gastar por completo, volvería a recuperar su asignación de ráfaga en 5 segundos (= 100000 [bytes] / 2000 [bytes / seg]).

No tiene que recuperar todo su subsidio de ráfaga para usarlo, puede usar tanto como haya acumulado.

Otra forma de ver esto es: se le permite enviar bytes de ráfaga a velocidad ilimitada, a partir de entonces su velocidad promedio a largo plazo nunca puede exceder la velocidad . Sin embargo, debido a que es un promedio a largo plazo, si cae por debajo de la velocidad , se le permite ponerse al día enviando a toda velocidad, pero incluso así solo se le permite enviar al máximo para la mayoría de los bytes de ráfaga (y si eso no funciona te permite ponerte al día no puedes).

La otra arruina es que TBF tiene dos de estos limitadores de velocidad, y su tráfico tiene que pasar por ambos. En el segundo, el parámetro de ráfaga se llama mtu y, y la tasa se llama tasa de pico . Se supone que debes usar este segundo para limitar la velocidad a la que el primero puede enviar sus ráfagas. Usar este segundo es opcional, y si no lo usa, las ráfagas se envían a la velocidad del dispositivo.

Finalmente, tbf tiene un parámetro límite . Si el programa envía persistentemente más rápido que la velocidad , entonces los paquetes se acumularán en la cola. No hay memoria de kernel infinita, entonces limit dice cuántos bytes pueden acumularse antes de que el kernel comience a descartar paquetes.