¿Alguien entiende realmente cómo funciona la programación HFSC en Linux/BSD?

Question 1

Leer los artículos sobre HFSC y sus primos no es una buena manera de entenderlo. El objetivo principal del artículo del HFSC es proporcionar una prueba matemática rigurosa de sus afirmaciones, sin explicar cómo funciona. De hecho, no se puede entender cómo funciona solo con el documento HFSC, sino que también se deben leer los documentos a los que hace referencia. Si tiene algún problema con el reclamo o sus pruebas, entonces podría ser una buena idea comunicarse con los autores de los artículos; de lo contrario, dudo que estén interesados en saber de usted.

he escrito untutorial para HFSC. Léelo si mis explicaciones a continuación no son claras.

¿Para qué necesito una curva en tiempo real? Suponiendo que A1, A2, B1, B2 son todos enlaces compartidos de 128 kbit/s (sin curva en tiempo real para ninguno de los dos), entonces cada uno de ellos obtendrá 128 kbit/s si la raíz tiene 512 kbit/s para distribuir (y A y B son ambos de 256 kbit/s, por supuesto), ¿verdad? ¿Por qué debería darle además a A1 y B1 una curva en tiempo real con 128 kbit/s? ¿Para qué sería bueno esto? ¿Para darles a esos dos una mayor prioridad? Según el artículo original, puedo darles una mayor prioridad utilizando una curva; después de todo, de eso se trata HFSC. Al darle a ambas clases una curva de [256 kbit/s 20 ms 128 kbit/s], ambas tienen el doble de prioridad que A2 y B2 automáticamente (aún obteniendo solo 128 kbit/s en promedio)

La curva en tiempo real y la curva de intercambio de enlaces se evalúan de diferentes maneras. La curva en tiempo real tiene en cuenta lo que ha hecho una clase a lo largo de toda su historia. Debe hacerlo para proporcionar una asignación precisa de ancho de banda y latencia. La desventaja es que no es lo que la mayoría de la gente intuitivamente considerajusto. En tiempo real, si una clase toma prestado ancho de banda cuando nadie más lo quiere, se penaliza cuando alguien más lo quiere recuperar más tarde. Esto significa que, bajo la garantía de tiempo real, una clase no puede obtener ancho de banda durante un período prolongado porque lo usó antes, cuando nadie lo quería.

El intercambio de enlaces es justo, ya que no penaliza a una clase por utilizar ancho de banda adicional. Sin embargo, esto significa que no puede ofrecer garantías sólidas de latencia.

La separación entre compartir enlaces y proporcionar garantías de latencia es lo nuevo que aporta HFSC, y el documento lo dice en su frase inicial:En este artículo, estudiamos modelos y algoritmos de gestión de recursos jerárquicos que admiten tanto el intercambio de enlaces como servicios garantizados en tiempo real con retardo desacoplado (prioridad) y asignación de ancho de banda. La palabra clave en esa oración está desacoplada. Traducido, significa que se espera que usted diga cómo se compartirá el ancho de banda no utilizado con ls y especifique qué garantías en tiempo real (también conocidas como garantías de latencia) se necesitan con rt. Los dos son ortogonales.

¿El ancho de banda en tiempo real cuenta para el ancho de banda de enlace compartido?

Sí. En el documento de HFSC, definen el ancho de banda en términos de lo que la clase ha enviado desde que la clase se atrasó (es decir, tiene paquetes en espera de ser enviados). La única diferencia entre rt y ls es que rt mira hacia adelante cada vez que la clase se atrasó y calcula el ancho de banda más bajo garantizado de ese conjunto, mientras que el intercambio de enlaces solo mira desde la última vez que la clase se atrasó. Entonces, rt toma en consideración más bytes que ls, pero cada byte que ls considera también lo considera rt.

¿La curva de límite superior también se aplica al tiempo real, solo para compartir enlaces, o tal vez para ambos?

El límite superior no impide que se envíen paquetes para satisfacer la condición de tiempo real. Los paquetes enviados bajo la condición de tiempo real todavía cuentan para el límite superior y, por lo tanto, pueden retrasar un paquete que se envía bajo la condición de enlace compartido en el futuro. Esta es otra diferencia entre tiempo real y uso compartido de enlaces.

Suponiendo que A2 y B2 son ambos de 128 kbit/s, ¿hay alguna diferencia si A1 y B1 tienen un enlace compartido de 128 kbit/s solamente, o 64 kbit/s en tiempo real y un enlace compartido de 128 kbit/s, y si es así? , ¿Qué diferencia?

Sí, hace la diferencia. Como se explicó anteriormente, si usa tiempo real, las latencias están garantizadas pero el enlace no se comparte de manera justa (y en particular la clase podría sufrir falta de ancho de banda) y los límites superiores no se aplican. Si utiliza el enlace compartido, la latencia no está garantizada, pero el intercambio de enlaces es justo, no hay riesgo de inanición y se aplica un límite superior. El tiempo real siempre se verifica antes de compartir el enlace; sin embargo, esto no significa necesariamente que se ignorará el enlace compartido. Esto se debe a que los paquetes se cuentan de manera diferente. Dado que el historial se considera en tiempo real, es posible que un paquete no sea necesario para cumplir con la garantía de tiempo real (debido a que uno se incluye en el historial), pero sí es necesario para satisfacer el vínculo compartido porque ignora el paquete histórico.

Si uso la curva separada en tiempo real para aumentar las prioridades de las clases, ¿por qué necesitaría "curvas"? ¿Por qué el tiempo real no es un valor fijo y el enlace compartido también es un valor fijo? ¿Por qué son ambas curvas? La necesidad de curvas queda clara en el artículo original, porque sólo hay un atributo de ese tipo por clase. Pero ahora, al tener tres atributos (tiempo real, enlace compartido y límite superior), ¿para qué sigo necesitando curvas en cada uno? ¿Por qué querría que la forma de las curvas (no el ancho de banda promedio, sino sus pendientes) fuera diferente para el tráfico en tiempo real y de enlace compartido?

La curva para controles en tiempo real le permite intercambiar una latencia estricta para una clase de tráfico en particular (por ejemplo, VOIP) por una latencia deficiente para otras clases de tráfico (por ejemplo, correo electrónico). Al decidir qué paquete enviar bajo la restricción de tiempo real, HFSC elige el que completará el envío primero. Sin embargo, no utiliza el ancho de banda del enlace para calcular esto, sino el ancho de banda asignado por la curva de tiempo real. Por lo tanto, si tenemos paquetes VOIP y de correo electrónico de la misma longitud, y el paquete VOIP tiene una curva convexa que aumenta 10 veces la curva cóncava del correo electrónico, entonces se enviarán 10 paquetes VOIP antes del primer paquete de correo electrónico. Pero esto sólo ocurre durante el tiempo de ráfaga, que debería ser como máximo el tiempo que se tarda en enviar algunos paquetes, es decir, milisegundos. A partir de entonces, la curva VOIP debería aplanarse, y VOIP no recibirá ningún impulso futuro a menos que retroceda por un tiempo (lo cual, dado que VOIP es una aplicación de bajo ancho de banda, debería hacerlo). El resultado neto de todo esto es garantizar que los primeros paquetes VOIP se envíen más rápido que cualquier otra cosa, lo que brinda a VOIP una latencia baja a expensas de que el correo electrónico tenga una latencia alta.

Como dije antes, debido a que el enlace compartido no analiza el historial, no puede ofrecer garantías de latencia. Una garantía sólida es lo que se necesita para el tráfico en tiempo real como VOIP. Sin embargo, en promedio, una curva convexa compartida de enlace seguirá proporcionando un aumento de latencia a su tráfico. Simplemente no está garantizado. Eso está bien para la mayoría de las cosas, como el tráfico web a través del correo electrónico.

Según la poca documentación disponible, los valores de la curva en tiempo real se ignoran totalmente para las clases internas (clases A y B), solo se aplican a las clases de hoja (A1, A2, B1, B2). Si eso es cierto, ¿por qué la configuración de muestra ALTQ HFSC (busque 3.3 Configuración de muestra) establece curvas en tiempo real en clases internas y afirma que establecen la tasa garantizada de esas clases internas? ¿No es eso completamente inútil? (nota: pshare establece la curva de enlace compartido en ALTQ y ralla la curva en tiempo real; puede ver esto en el párrafo encima de la configuración de muestra).

La documentación es correcta. La jerarquía (y por tanto los nodos internos) no tiene ningún efecto en el cálculo del tiempo real. No puedo decirle por qué ALTQ evidentemente piensa que sí.

Algunos tutoriales dicen que la suma de todas las curvas en tiempo real no puede ser superior al 80% de la velocidad de la línea, otros dicen que no debe ser superior al 70% de la velocidad de la línea. ¿Cuál tiene razón o quizás ambos estén equivocados?

Ambos están equivocados. Si el 70% o el 80% de su tráfico tiene requisitos de latencia estrictos que deben especificarse en tiempo real, la realidad es que es casi seguro que no podrá satisfacerlos con el enlace que está utilizando. Necesitas un enlace más rápido.

La única forma en que alguien podría pensar que especificar que el 80% del tráfico debería ser en tiempo real es si considerara el tiempo real como un impulso prioritario. Sí, para brindar garantías de latencia, de hecho está aumentando la prioridad de algunos paquetes. Pero sólo debería ser por milisegundos. Eso es todo lo que un enlace puede afrontar y seguir ofreciendo garantías de latencia.

Hay muy poco tráfico que necesite garantías de latencia. VOIP es una, NTP otra. El resto debería hacerse compartiendo enlaces. Si desea que la web sea rápida, puede hacerlo asignándole la mayor parte de la capacidad de enlaces. esa parteesgarantizado a largo plazo. Si desea que tenga una latencia baja (en promedio), déle una curva convexa al compartir enlaces.

Un tutorial decía que olvidarás toda la teoría. No importa cómo funcionen realmente las cosas (programadores y distribución del ancho de banda), imagine las tres curvas según el siguiente "modelo mental simplificado": el tiempo real es el ancho de banda garantizado que esta clase siempre obtendrá. link-share es el ancho de banda que esta clase quiere que esté completamente satisfecho, pero no se puede garantizar la satisfacción. En caso de que haya un exceso de ancho de banda, es posible que a la clase incluso se le ofrezca más ancho de banda del necesario para estar satisfecha, pero es posible que nunca use más del límite superior indicado. Para que todo esto funcione, la suma de todos los anchos de banda en tiempo real no puede ser superior al xx% de la velocidad de la línea (consulte la pregunta anterior, el porcentaje varía). Pregunta: ¿Es esto más o menos exacto o se trata de un malentendido total del HSFC?

Es una buena descripción del límite superior. Si bien la descripción del enlace compartido es estrictamente precisa, es engañosa. Si bien es cierto que el intercambio de enlaces no ofrece garantías de latencia estrictas como lo hace el tiempo real, hace un mejor trabajo al darle a la clase su ancho de banda su asignación que sus competidores, como CBQ y HTB. Entonces, al decir que el enlace compartido "no ofrece garantías", lo mantiene en un estándar más alto que el que cualquier otro programador puede ofrecer.

La descripción en tiempo real logra ser precisa, pero tan engañosa que la llamaría incorrecta. Como su nombre lo indica, el propósito del tiempo real no es brindar ancho de banda garantizado. Su objetivo es proporcionar latencia garantizada, es decir, el paquete se envía AHORA, no una cantidad de tiempo aleatoria después, dependiendo de cómo se utilice el enlace. La mayor parte del tráfico no necesita latencia garantizada.

Dicho esto, el tiempo real tampoco ofrece garantías de latencia perfecta. Podría, si el enlace no fuera administrado también por enlace compartido, pero la mayoría de los usuarios quieren la flexibilidad adicional de tener ambos y no es gratis. El tiempo real puede no cumplir con su fecha límite de latencia en el tiempo que lleva enviar un paquete MTU. (Si sucede, será porque se introdujo un enlace de paquete MTU mientras se mantenía el enlace inactivo en tiempo real en caso de que se le entregara un paquete con una fecha límite corta que tuviera que enviarse de inmediato. Esta es otra diferencia más entre el enlace compartido y en tiempo real, para brindar sus garantías, el tiempo real puede mantener deliberadamente la línea inactiva aunque haya paquetes para enviar, siempre que la utilización del enlace sea inferior al 100 % y siempre utilice el 100 % de la capacidad disponible. , se puede decir que "preserva el trabajo".)

La razón por la que se puede decir que el tiempo real ofrece estrictas garantías de latencia es que el retraso es limitado. Entonces, si está intentando ofrecer una garantía de latencia de 20 ms en un enlace de 1 Mbit/s y el enlace compartido envía paquetes de tamaño MTU (1500 bytes), sabrá que uno de esos paquetes tardará 12 ms en enviarse. Por lo tanto, si dice en tiempo real que desea una latencia de 8 ms, aún puede cumplir con el plazo de 20 ms, con absoluta garantía.

Y si el supuesto anterior es realmente exacto, ¿dónde está la priorización en ese modelo? Por ejemplo, cada clase puede tener un ancho de banda en tiempo real (garantizado), un ancho de banda de enlace compartido (no garantizado) y tal vez un límite superior, pero aún así algunas clases tienen necesidades de mayor prioridad que otras clases. En ese caso todavía debo priorizar de alguna manera, incluso entre el tráfico en tiempo real de esas clases. ¿Priorizaría por la pendiente de las curvas? Y si es así, ¿qué curva? ¿La curva en tiempo real? ¿La curva de enlace compartido? ¿La curva del límite superior? ¿Todos ellos? ¿Les daría a todos la misma pendiente o a cada uno diferente y cómo saber la pendiente correcta?

No existe un modelo de priorización. En serio. Si desea darle al tráfico prioridades absolutas, use pfifo. Esto es para lo que sirve. Pero también tenga en cuenta que si le da al tráfico web prioridad absoluta sobre el tráfico de correo electrónico, eso significa permitir que el tráfico web sature el enlace y, por lo tanto, no lleguen paquetes de correo electrónico.en absoluto. Entonces todas tus conexiones de correo electrónico mueren.

En realidad, nadie quiere ese tipo de priorización. Lo que quieren es lo que proporciona HFSC. Si realmente tiene tráfico en tiempo real, HFSC lo proporciona. Pero será todo. Por lo demás, HFSC le permite decir "en un enlace congestionado, asigne el 90% a la web y deje que el correo electrónico fluya al 10% y, oh, envíe algún paquete DNS rápidamente, pero no permita que nadie me envíe un DOS".

Answer

Leer los artículos sobre HFSC y sus primos no es una buena manera de entenderlo. El objetivo principal del artículo del HFSC es proporcionar una prueba matemática rigurosa de sus afirmaciones, sin explicar cómo funciona. De hecho, no se puede entender cómo funciona solo con el documento HFSC, sino que también se deben leer los documentos a los que hace referencia. Si tiene algún problema con el reclamo o sus pruebas, entonces podría ser una buena idea comunicarse con los autores de los artículos; de lo contrario, dudo que estén interesados en saber de usted.

he escrito untutorial para HFSC. Léelo si mis explicaciones a continuación no son claras.

¿Para qué necesito una curva en tiempo real? Suponiendo que A1, A2, B1, B2 son todos enlaces compartidos de 128 kbit/s (sin curva en tiempo real para ninguno de los dos), entonces cada uno de ellos obtendrá 128 kbit/s si la raíz tiene 512 kbit/s para distribuir (y A y B son ambos de 256 kbit/s, por supuesto), ¿verdad? ¿Por qué debería darle además a A1 y B1 una curva en tiempo real con 128 kbit/s? ¿Para qué sería bueno esto? ¿Para darles a esos dos una mayor prioridad? Según el artículo original, puedo darles una mayor prioridad utilizando una curva; después de todo, de eso se trata HFSC. Al darle a ambas clases una curva de [256 kbit/s 20 ms 128 kbit/s], ambas tienen el doble de prioridad que A2 y B2 automáticamente (aún obteniendo solo 128 kbit/s en promedio)

La curva en tiempo real y la curva de intercambio de enlaces se evalúan de diferentes maneras. La curva en tiempo real tiene en cuenta lo que ha hecho una clase a lo largo de toda su historia. Debe hacerlo para proporcionar una asignación precisa de ancho de banda y latencia. La desventaja es que no es lo que la mayoría de la gente intuitivamente considerajusto. En tiempo real, si una clase toma prestado ancho de banda cuando nadie más lo quiere, se penaliza cuando alguien más lo quiere recuperar más tarde. Esto significa que, bajo la garantía de tiempo real, una clase no puede obtener ancho de banda durante un período prolongado porque lo usó antes, cuando nadie lo quería.

El intercambio de enlaces es justo, ya que no penaliza a una clase por utilizar ancho de banda adicional. Sin embargo, esto significa que no puede ofrecer garantías sólidas de latencia.

La separación entre compartir enlaces y proporcionar garantías de latencia es lo nuevo que aporta HFSC, y el documento lo dice en su frase inicial:En este artículo, estudiamos modelos y algoritmos de gestión de recursos jerárquicos que admiten tanto el intercambio de enlaces como servicios garantizados en tiempo real con retardo desacoplado (prioridad) y asignación de ancho de banda. La palabra clave en esa oración está desacoplada. Traducido, significa que se espera que usted diga cómo se compartirá el ancho de banda no utilizado con ls y especifique qué garantías en tiempo real (también conocidas como garantías de latencia) se necesitan con rt. Los dos son ortogonales.

¿El ancho de banda en tiempo real cuenta para el ancho de banda de enlace compartido?

Sí. En el documento de HFSC, definen el ancho de banda en términos de lo que la clase ha enviado desde que la clase se atrasó (es decir, tiene paquetes en espera de ser enviados). La única diferencia entre rt y ls es que rt mira hacia adelante cada vez que la clase se atrasó y calcula el ancho de banda más bajo garantizado de ese conjunto, mientras que el intercambio de enlaces solo mira desde la última vez que la clase se atrasó. Entonces, rt toma en consideración más bytes que ls, pero cada byte que ls considera también lo considera rt.

¿La curva de límite superior también se aplica al tiempo real, solo para compartir enlaces, o tal vez para ambos?

El límite superior no impide que se envíen paquetes para satisfacer la condición de tiempo real. Los paquetes enviados bajo la condición de tiempo real todavía cuentan para el límite superior y, por lo tanto, pueden retrasar un paquete que se envía bajo la condición de enlace compartido en el futuro. Esta es otra diferencia entre tiempo real y uso compartido de enlaces.

Suponiendo que A2 y B2 son ambos de 128 kbit/s, ¿hay alguna diferencia si A1 y B1 tienen un enlace compartido de 128 kbit/s solamente, o 64 kbit/s en tiempo real y un enlace compartido de 128 kbit/s, y si es así? , ¿Qué diferencia?

Sí, hace la diferencia. Como se explicó anteriormente, si usa tiempo real, las latencias están garantizadas pero el enlace no se comparte de manera justa (y en particular la clase podría sufrir falta de ancho de banda) y los límites superiores no se aplican. Si utiliza el enlace compartido, la latencia no está garantizada, pero el intercambio de enlaces es justo, no hay riesgo de inanición y se aplica un límite superior. El tiempo real siempre se verifica antes de compartir el enlace; sin embargo, esto no significa necesariamente que se ignorará el enlace compartido. Esto se debe a que los paquetes se cuentan de manera diferente. Dado que el historial se considera en tiempo real, es posible que un paquete no sea necesario para cumplir con la garantía de tiempo real (debido a que uno se incluye en el historial), pero sí es necesario para satisfacer el vínculo compartido porque ignora el paquete histórico.

Si uso la curva separada en tiempo real para aumentar las prioridades de las clases, ¿por qué necesitaría "curvas"? ¿Por qué el tiempo real no es un valor fijo y el enlace compartido también es un valor fijo? ¿Por qué son ambas curvas? La necesidad de curvas queda clara en el artículo original, porque sólo hay un atributo de ese tipo por clase. Pero ahora, al tener tres atributos (tiempo real, enlace compartido y límite superior), ¿para qué sigo necesitando curvas en cada uno? ¿Por qué querría que la forma de las curvas (no el ancho de banda promedio, sino sus pendientes) fuera diferente para el tráfico en tiempo real y de enlace compartido?

La curva para controles en tiempo real le permite intercambiar una latencia estricta para una clase de tráfico en particular (por ejemplo, VOIP) por una latencia deficiente para otras clases de tráfico (por ejemplo, correo electrónico). Al decidir qué paquete enviar bajo la restricción de tiempo real, HFSC elige el que completará el envío primero. Sin embargo, no utiliza el ancho de banda del enlace para calcular esto, sino el ancho de banda asignado por la curva de tiempo real. Por lo tanto, si tenemos paquetes VOIP y de correo electrónico de la misma longitud, y el paquete VOIP tiene una curva convexa que aumenta 10 veces la curva cóncava del correo electrónico, entonces se enviarán 10 paquetes VOIP antes del primer paquete de correo electrónico. Pero esto sólo ocurre durante el tiempo de ráfaga, que debería ser como máximo el tiempo que se tarda en enviar algunos paquetes, es decir, milisegundos. A partir de entonces, la curva VOIP debería aplanarse, y VOIP no recibirá ningún impulso futuro a menos que retroceda por un tiempo (lo cual, dado que VOIP es una aplicación de bajo ancho de banda, debería hacerlo). El resultado neto de todo esto es garantizar que los primeros paquetes VOIP se envíen más rápido que cualquier otra cosa, lo que brinda a VOIP una latencia baja a expensas de que el correo electrónico tenga una latencia alta.

Como dije antes, debido a que el enlace compartido no analiza el historial, no puede ofrecer garantías de latencia. Una garantía sólida es lo que se necesita para el tráfico en tiempo real como VOIP. Sin embargo, en promedio, una curva convexa compartida de enlace seguirá proporcionando un aumento de latencia a su tráfico. Simplemente no está garantizado. Eso está bien para la mayoría de las cosas, como el tráfico web a través del correo electrónico.

Según la poca documentación disponible, los valores de la curva en tiempo real se ignoran totalmente para las clases internas (clases A y B), solo se aplican a las clases de hoja (A1, A2, B1, B2). Si eso es cierto, ¿por qué la configuración de muestra ALTQ HFSC (busque 3.3 Configuración de muestra) establece curvas en tiempo real en clases internas y afirma que establecen la tasa garantizada de esas clases internas? ¿No es eso completamente inútil? (nota: pshare establece la curva de enlace compartido en ALTQ y ralla la curva en tiempo real; puede ver esto en el párrafo encima de la configuración de muestra).

La documentación es correcta. La jerarquía (y por tanto los nodos internos) no tiene ningún efecto en el cálculo del tiempo real. No puedo decirle por qué ALTQ evidentemente piensa que sí.

Algunos tutoriales dicen que la suma de todas las curvas en tiempo real no puede ser superior al 80% de la velocidad de la línea, otros dicen que no debe ser superior al 70% de la velocidad de la línea. ¿Cuál tiene razón o quizás ambos estén equivocados?

Ambos están equivocados. Si el 70% o el 80% de su tráfico tiene requisitos de latencia estrictos que deben especificarse en tiempo real, la realidad es que es casi seguro que no podrá satisfacerlos con el enlace que está utilizando. Necesitas un enlace más rápido.

La única forma en que alguien podría pensar que especificar que el 80% del tráfico debería ser en tiempo real es si considerara el tiempo real como un impulso prioritario. Sí, para brindar garantías de latencia, de hecho está aumentando la prioridad de algunos paquetes. Pero sólo debería ser por milisegundos. Eso es todo lo que un enlace puede afrontar y seguir ofreciendo garantías de latencia.

Hay muy poco tráfico que necesite garantías de latencia. VOIP es una, NTP otra. El resto debería hacerse compartiendo enlaces. Si desea que la web sea rápida, puede hacerlo asignándole la mayor parte de la capacidad de enlaces. esa parteesgarantizado a largo plazo. Si desea que tenga una latencia baja (en promedio), déle una curva convexa al compartir enlaces.

Un tutorial decía que olvidarás toda la teoría. No importa cómo funcionen realmente las cosas (programadores y distribución del ancho de banda), imagine las tres curvas según el siguiente "modelo mental simplificado": el tiempo real es el ancho de banda garantizado que esta clase siempre obtendrá. link-share es el ancho de banda que esta clase quiere que esté completamente satisfecho, pero no se puede garantizar la satisfacción. En caso de que haya un exceso de ancho de banda, es posible que a la clase incluso se le ofrezca más ancho de banda del necesario para estar satisfecha, pero es posible que nunca use más del límite superior indicado. Para que todo esto funcione, la suma de todos los anchos de banda en tiempo real no puede ser superior al xx% de la velocidad de la línea (consulte la pregunta anterior, el porcentaje varía). Pregunta: ¿Es esto más o menos exacto o se trata de un malentendido total del HSFC?

Es una buena descripción del límite superior. Si bien la descripción del enlace compartido es estrictamente precisa, es engañosa. Si bien es cierto que el intercambio de enlaces no ofrece garantías de latencia estrictas como lo hace el tiempo real, hace un mejor trabajo al darle a la clase su ancho de banda su asignación que sus competidores, como CBQ y HTB. Entonces, al decir que el enlace compartido "no ofrece garantías", lo mantiene en un estándar más alto que el que cualquier otro programador puede ofrecer.

La descripción en tiempo real logra ser precisa, pero tan engañosa que la llamaría incorrecta. Como su nombre lo indica, el propósito del tiempo real no es brindar ancho de banda garantizado. Su objetivo es proporcionar latencia garantizada, es decir, el paquete se envía AHORA, no una cantidad de tiempo aleatoria después, dependiendo de cómo se utilice el enlace. La mayor parte del tráfico no necesita latencia garantizada.

Dicho esto, el tiempo real tampoco ofrece garantías de latencia perfecta. Podría, si el enlace no fuera administrado también por enlace compartido, pero la mayoría de los usuarios quieren la flexibilidad adicional de tener ambos y no es gratis. El tiempo real puede no cumplir con su fecha límite de latencia en el tiempo que lleva enviar un paquete MTU. (Si sucede, será porque se introdujo un enlace de paquete MTU mientras se mantenía el enlace inactivo en tiempo real en caso de que se le entregara un paquete con una fecha límite corta que tuviera que enviarse de inmediato. Esta es otra diferencia más entre el enlace compartido y en tiempo real, para brindar sus garantías, el tiempo real puede mantener deliberadamente la línea inactiva aunque haya paquetes para enviar, siempre que la utilización del enlace sea inferior al 100 % y siempre utilice el 100 % de la capacidad disponible. , se puede decir que "preserva el trabajo".)

La razón por la que se puede decir que el tiempo real ofrece estrictas garantías de latencia es que el retraso es limitado. Entonces, si está intentando ofrecer una garantía de latencia de 20 ms en un enlace de 1 Mbit/s y el enlace compartido envía paquetes de tamaño MTU (1500 bytes), sabrá que uno de esos paquetes tardará 12 ms en enviarse. Por lo tanto, si dice en tiempo real que desea una latencia de 8 ms, aún puede cumplir con el plazo de 20 ms, con absoluta garantía.

Y si el supuesto anterior es realmente exacto, ¿dónde está la priorización en ese modelo? Por ejemplo, cada clase puede tener un ancho de banda en tiempo real (garantizado), un ancho de banda de enlace compartido (no garantizado) y tal vez un límite superior, pero aún así algunas clases tienen necesidades de mayor prioridad que otras clases. En ese caso todavía debo priorizar de alguna manera, incluso entre el tráfico en tiempo real de esas clases. ¿Priorizaría por la pendiente de las curvas? Y si es así, ¿qué curva? ¿La curva en tiempo real? ¿La curva de enlace compartido? ¿La curva del límite superior? ¿Todos ellos? ¿Les daría a todos la misma pendiente o a cada uno diferente y cómo saber la pendiente correcta?

No existe un modelo de priorización. En serio. Si desea darle al tráfico prioridades absolutas, use pfifo. Esto es para lo que sirve. Pero también tenga en cuenta que si le da al tráfico web prioridad absoluta sobre el tráfico de correo electrónico, eso significa permitir que el tráfico web sature el enlace y, por lo tanto, no lleguen paquetes de correo electrónico.en absoluto. Entonces todas tus conexiones de correo electrónico mueren.

En realidad, nadie quiere ese tipo de priorización. Lo que quieren es lo que proporciona HFSC. Si realmente tiene tráfico en tiempo real, HFSC lo proporciona. Pero será todo. Por lo demás, HFSC le permite decir "en un enlace congestionado, asigne el 90% a la web y deje que el correo electrónico fluya al 10% y, oh, envíe algún paquete DNS rápidamente, pero no permita que nadie me envíe un DOS".

Question 2

Podrías definir las curvas con diferentes nombres:

rt, curva en tiempo real, garantía de ancho de banda/retardo.
ls, curva de enlace compartido, ancho de banda/retraso compartido (basado en la configuración de las hojas vecinas)
ul, curva de límite superior, ancho de banda/retardo máximo que puede alcanzar.

¿Para qué necesito una curva en tiempo real? Suponiendo que A1, A2, B1, B2 son todos enlaces compartidos de 128 kbit/s (sin curva en tiempo real para ninguno de los dos), entonces cada uno de ellos obtendrá 128 kbit/s si la raíz tiene 512 kbit/s para distribuir (y A y B son ambos de 256 kbit/s, por supuesto), ¿verdad? ¿Por qué debería darle además a A1 y B1 una curva en tiempo real con 128 kbit/s? ¿Para qué sería bueno esto? ¿Para darles a esos dos una mayor prioridad? Según el artículo original, puedo darles una mayor prioridad utilizando una curva; después de todo, de eso se trata HFSC. Al darle a ambas clases una curva de [256 kbit/s 20 ms 128 kbit/s], ambas tienen el doble de prioridad que A2 y B2 automáticamente (aún obteniendo solo 128 kbit/s en promedio)

Cuando realiza una definición en HFSC solo con tasas, automáticamente establece 'dmax' en 0. Lo que básicamente significa que no tiene en cuenta el retraso. Una buena configuración de HFSC debe incluir tanto el ancho de banda como los límites de retardo que desea utilizar para su clase; de lo contrario, el algoritmo no puede determinar exactamente cuánta prioridad debe tener una clase.

Siempre que le dé prioridad a los paquetes, se deberá disminuir la prioridad de otros paquetes. Según los valores 'dmax' y 'rate', todas las clases se multiplexarán mediante temporizadores virtuales. Consulte tc-hfsc(7) para obtener más información.

¿El ancho de banda en tiempo real cuenta para el ancho de banda de enlace compartido? Por ejemplo, si A1 y B1 solo tienen 64 kbit/s en tiempo real y 64 kbit/s de ancho de banda de enlace compartido, ¿eso significa que una vez que reciben 64 kbit/s en tiempo real, su requisito de enlace compartido también se satisface (es posible que obtienen exceso de ancho de banda, pero ignoremos eso por un segundo) ¿o eso significa que obtienen otros 64 kbit/s a través del enlace compartido? Entonces, ¿cada clase tiene un "requisito" de ancho de banda de tiempo real más enlace compartido? ¿O una clase solo tiene un requisito más alto que la curva de tiempo real si la curva de enlace compartido es mayor que la curva de tiempo real (el requisito de enlace compartido actual es igual al requisito de enlace compartido especificado menos el ancho de banda en tiempo real ya proporcionado a esta curva? clase)?

Si el flujo no supera los límites de la definición de enlace compartido de la clase, entonces nunca se utiliza la curva en tiempo real. Definir una curva en tiempo real en este caso le permite, por ejemplo: garantizar un determinado 'dmax'.

Si sus definiciones de enlaces compartidos son perfectas, entonces no necesitaría curvas en tiempo real. Podría simplemente definir curvas de servicio (sc), pero eso haría que su configuración trabajara más.

¿La curva de límite superior también se aplica al tiempo real, solo para compartir enlaces, o tal vez para ambos? Algunos tutoriales dicen de una manera, otros dicen de otra. ¿Algunos incluso afirman que el límite superior es el máximo para ancho de banda en tiempo real + ancho de banda de enlace compartido? ¿Cuál es la verdad?

La curva de límite superior de su clase se aplica solo a los enlaces compartidos; cuando define una curva de límite superior, DEBE definir una curva de enlaces compartidos. Sin embargo, todavía se aplica la curva de límite superior de las clases principales.

Suponiendo que A2 y B2 son ambos de 128 kbit/s, ¿hay alguna diferencia si A1 y B1 tienen un enlace compartido de 128 kbit/s solamente, o 64 kbit/s en tiempo real y un enlace compartido de 128 kbit/s, y si es así? , ¿Qué diferencia?

Hay una ligera diferencia si, por ejemplo, A2 = 0 kbits/s y B2 = 256 kbits/s. Entonces el tiempo virtual para A2 será máximo. Siempre que los paquetes se clasifiquen en A2, se procesarán instantáneamente. Sin embargo, la curva en tiempo real de B2 seguirá garantizando que sea capaz de transmitir al menos 64 kbit/s.

Si uso la curva separada en tiempo real para aumentar las prioridades de las clases, ¿por qué necesitaría "curvas"? ¿Por qué el tiempo real no es un valor fijo y el enlace compartido también es un valor fijo? ¿Por qué son ambas curvas? La necesidad de curvas queda clara en el artículo original, porque sólo hay un atributo de ese tipo por clase. Pero ahora, al tener tres atributos (tiempo real, enlace compartido y límite superior), ¿para qué sigo necesitando curvas en cada uno? ¿Por qué querría que la forma de las curvas (no el ancho de banda promedio, sino sus pendientes) fuera diferente para el tráfico en tiempo real y de enlace compartido?

Las curvas en tiempo real no comparten el tráfico entre hojas vecinas, pero las curvas de enlaces compartidos sí lo hacen.

Según la poca documentación disponible, los valores de la curva en tiempo real se ignoran totalmente para las clases internas (clases A y B), solo se aplican a las clases de hoja (A1, A2, B1, B2). Si eso es cierto, ¿por qué la configuración de muestra ALTQ HFSC (busque 3.3 Configuración de muestra) establece curvas en tiempo real en clases internas y afirma que establecen la tasa garantizada de esas clases internas? ¿No es eso completamente inútil? (nota: pshare establece la curva de enlace compartido en ALTQ y ralla la curva en tiempo real; puede ver esto en el párrafo encima de la configuración de muestra).

Es cierto que las curvas en tiempo real se ignoran para las clases internas, solo se aplican a las clases hoja. Sin embargo, las curvas en tiempo real definidas en esas clases internas se tienen en cuenta para los cálculos de las clases de hojas.

Algunos tutoriales dicen que la suma de todas las curvas en tiempo real no puede ser superior al 80% de la velocidad de la línea, otros dicen que no debe ser superior al 70% de la velocidad de la línea. ¿Cuál tiene razón o quizás ambos estén equivocados?

Lo que quieren decir es: no se puede priorizar todo el tráfico... Siempre que le dé prioridad a los paquetes, habrá que disminuir la prioridad de otros paquetes. Si garantiza demasiado, el algoritmo deja de tener sentido. Defina las clases que obtienen prioridad y defina las clases que pueden verse afectadas.

Un tutorial decía que olvidarás toda la teoría. No importa cómo funcionen realmente las cosas (programadores y distribución del ancho de banda), imagine las tres curvas según el siguiente "modelo mental simplificado": el tiempo real es el ancho de banda garantizado que esta clase siempre obtendrá. link-share es el ancho de banda que esta clase quiere que esté completamente satisfecho, pero no se puede garantizar la satisfacción. En caso de que haya un exceso de ancho de banda, es posible que a la clase incluso se le ofrezca más ancho de banda del necesario para estar satisfecha, pero es posible que nunca use más del límite superior indicado. Para que todo esto funcione, la suma de todos los anchos de banda en tiempo real no puede ser superior al xx% de la velocidad de la línea (consulte la pregunta anterior, el porcentaje varía). Pregunta: ¿Es esto más o menos exacto o se trata de un malentendido total del HSFC?

Esto es correcto.

Y si el supuesto anterior es realmente exacto, ¿dónde está la priorización en ese modelo? Por ejemplo, cada clase puede tener un ancho de banda en tiempo real (garantizado), un ancho de banda de enlace compartido (no garantizado) y tal vez un límite superior, pero aún así algunas clases tienen necesidades de mayor prioridad que otras clases. En ese caso todavía debo priorizar de alguna manera, incluso entre el tráfico en tiempo real de esas clases. ¿Priorizaría por la pendiente de las curvas? Y si es así, ¿qué curva? ¿La curva en tiempo real? ¿La curva de enlace compartido? ¿La curva del límite superior? ¿Todos ellos? ¿Les daría a todos la misma pendiente o a cada uno diferente y cómo saber la pendiente correcta?

La diferencia entre, por ejemplo, HFSC y HTB es que HFSC le permitirá definir exactamente cuánta prioridad desea que tenga. Para ello, defina límites mínimos y máximos con el valor 'dmax'.

Answer

Podrías definir las curvas con diferentes nombres:

rt, curva en tiempo real, garantía de ancho de banda/retardo.
ls, curva de enlace compartido, ancho de banda/retraso compartido (basado en la configuración de las hojas vecinas)
ul, curva de límite superior, ancho de banda/retardo máximo que puede alcanzar.

¿Para qué necesito una curva en tiempo real? Suponiendo que A1, A2, B1, B2 son todos enlaces compartidos de 128 kbit/s (sin curva en tiempo real para ninguno de los dos), entonces cada uno de ellos obtendrá 128 kbit/s si la raíz tiene 512 kbit/s para distribuir (y A y B son ambos de 256 kbit/s, por supuesto), ¿verdad? ¿Por qué debería darle además a A1 y B1 una curva en tiempo real con 128 kbit/s? ¿Para qué sería bueno esto? ¿Para darles a esos dos una mayor prioridad? Según el artículo original, puedo darles una mayor prioridad utilizando una curva; después de todo, de eso se trata HFSC. Al darle a ambas clases una curva de [256 kbit/s 20 ms 128 kbit/s], ambas tienen el doble de prioridad que A2 y B2 automáticamente (aún obteniendo solo 128 kbit/s en promedio)

Cuando realiza una definición en HFSC solo con tasas, automáticamente establece 'dmax' en 0. Lo que básicamente significa que no tiene en cuenta el retraso. Una buena configuración de HFSC debe incluir tanto el ancho de banda como los límites de retardo que desea utilizar para su clase; de lo contrario, el algoritmo no puede determinar exactamente cuánta prioridad debe tener una clase.

Siempre que le dé prioridad a los paquetes, se deberá disminuir la prioridad de otros paquetes. Según los valores 'dmax' y 'rate', todas las clases se multiplexarán mediante temporizadores virtuales. Consulte tc-hfsc(7) para obtener más información.

¿El ancho de banda en tiempo real cuenta para el ancho de banda de enlace compartido? Por ejemplo, si A1 y B1 solo tienen 64 kbit/s en tiempo real y 64 kbit/s de ancho de banda de enlace compartido, ¿eso significa que una vez que reciben 64 kbit/s en tiempo real, su requisito de enlace compartido también se satisface (es posible que obtienen exceso de ancho de banda, pero ignoremos eso por un segundo) ¿o eso significa que obtienen otros 64 kbit/s a través del enlace compartido? Entonces, ¿cada clase tiene un "requisito" de ancho de banda de tiempo real más enlace compartido? ¿O una clase solo tiene un requisito más alto que la curva de tiempo real si la curva de enlace compartido es mayor que la curva de tiempo real (el requisito de enlace compartido actual es igual al requisito de enlace compartido especificado menos el ancho de banda en tiempo real ya proporcionado a esta curva? clase)?

Si el flujo no supera los límites de la definición de enlace compartido de la clase, entonces nunca se utiliza la curva en tiempo real. Definir una curva en tiempo real en este caso le permite, por ejemplo: garantizar un determinado 'dmax'.

Si sus definiciones de enlaces compartidos son perfectas, entonces no necesitaría curvas en tiempo real. Podría simplemente definir curvas de servicio (sc), pero eso haría que su configuración trabajara más.

¿La curva de límite superior también se aplica al tiempo real, solo para compartir enlaces, o tal vez para ambos? Algunos tutoriales dicen de una manera, otros dicen de otra. ¿Algunos incluso afirman que el límite superior es el máximo para ancho de banda en tiempo real + ancho de banda de enlace compartido? ¿Cuál es la verdad?

La curva de límite superior de su clase se aplica solo a los enlaces compartidos; cuando define una curva de límite superior, DEBE definir una curva de enlaces compartidos. Sin embargo, todavía se aplica la curva de límite superior de las clases principales.

Suponiendo que A2 y B2 son ambos de 128 kbit/s, ¿hay alguna diferencia si A1 y B1 tienen un enlace compartido de 128 kbit/s solamente, o 64 kbit/s en tiempo real y un enlace compartido de 128 kbit/s, y si es así? , ¿Qué diferencia?

Hay una ligera diferencia si, por ejemplo, A2 = 0 kbits/s y B2 = 256 kbits/s. Entonces el tiempo virtual para A2 será máximo. Siempre que los paquetes se clasifiquen en A2, se procesarán instantáneamente. Sin embargo, la curva en tiempo real de B2 seguirá garantizando que sea capaz de transmitir al menos 64 kbit/s.

Si uso la curva separada en tiempo real para aumentar las prioridades de las clases, ¿por qué necesitaría "curvas"? ¿Por qué el tiempo real no es un valor fijo y el enlace compartido también es un valor fijo? ¿Por qué son ambas curvas? La necesidad de curvas queda clara en el artículo original, porque sólo hay un atributo de ese tipo por clase. Pero ahora, al tener tres atributos (tiempo real, enlace compartido y límite superior), ¿para qué sigo necesitando curvas en cada uno? ¿Por qué querría que la forma de las curvas (no el ancho de banda promedio, sino sus pendientes) fuera diferente para el tráfico en tiempo real y de enlace compartido?

Las curvas en tiempo real no comparten el tráfico entre hojas vecinas, pero las curvas de enlaces compartidos sí lo hacen.

Según la poca documentación disponible, los valores de la curva en tiempo real se ignoran totalmente para las clases internas (clases A y B), solo se aplican a las clases de hoja (A1, A2, B1, B2). Si eso es cierto, ¿por qué la configuración de muestra ALTQ HFSC (busque 3.3 Configuración de muestra) establece curvas en tiempo real en clases internas y afirma que establecen la tasa garantizada de esas clases internas? ¿No es eso completamente inútil? (nota: pshare establece la curva de enlace compartido en ALTQ y ralla la curva en tiempo real; puede ver esto en el párrafo encima de la configuración de muestra).

Es cierto que las curvas en tiempo real se ignoran para las clases internas, solo se aplican a las clases hoja. Sin embargo, las curvas en tiempo real definidas en esas clases internas se tienen en cuenta para los cálculos de las clases de hojas.

Algunos tutoriales dicen que la suma de todas las curvas en tiempo real no puede ser superior al 80% de la velocidad de la línea, otros dicen que no debe ser superior al 70% de la velocidad de la línea. ¿Cuál tiene razón o quizás ambos estén equivocados?

Lo que quieren decir es: no se puede priorizar todo el tráfico... Siempre que le dé prioridad a los paquetes, habrá que disminuir la prioridad de otros paquetes. Si garantiza demasiado, el algoritmo deja de tener sentido. Defina las clases que obtienen prioridad y defina las clases que pueden verse afectadas.

Un tutorial decía que olvidarás toda la teoría. No importa cómo funcionen realmente las cosas (programadores y distribución del ancho de banda), imagine las tres curvas según el siguiente "modelo mental simplificado": el tiempo real es el ancho de banda garantizado que esta clase siempre obtendrá. link-share es el ancho de banda que esta clase quiere que esté completamente satisfecho, pero no se puede garantizar la satisfacción. En caso de que haya un exceso de ancho de banda, es posible que a la clase incluso se le ofrezca más ancho de banda del necesario para estar satisfecha, pero es posible que nunca use más del límite superior indicado. Para que todo esto funcione, la suma de todos los anchos de banda en tiempo real no puede ser superior al xx% de la velocidad de la línea (consulte la pregunta anterior, el porcentaje varía). Pregunta: ¿Es esto más o menos exacto o se trata de un malentendido total del HSFC?

Esto es correcto.

Y si el supuesto anterior es realmente exacto, ¿dónde está la priorización en ese modelo? Por ejemplo, cada clase puede tener un ancho de banda en tiempo real (garantizado), un ancho de banda de enlace compartido (no garantizado) y tal vez un límite superior, pero aún así algunas clases tienen necesidades de mayor prioridad que otras clases. En ese caso todavía debo priorizar de alguna manera, incluso entre el tráfico en tiempo real de esas clases. ¿Priorizaría por la pendiente de las curvas? Y si es así, ¿qué curva? ¿La curva en tiempo real? ¿La curva de enlace compartido? ¿La curva del límite superior? ¿Todos ellos? ¿Les daría a todos la misma pendiente o a cada uno diferente y cómo saber la pendiente correcta?

La diferencia entre, por ejemplo, HFSC y HTB es que HFSC le permitirá definir exactamente cuánta prioridad desea que tenga. Para ello, defina límites mínimos y máximos con el valor 'dmax'.

Question 3

Finalmente, una guía que parece explicar la mayoría de las inconsistencias y también en qué se diferencia la implementación actual del documento original:

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

Según esta guía, muchas otras guías y publicaciones en foros sobre HFSC son totalmente absurdas; simplemente muestra cuán complicado es el HFSC, ya que muchas personas que parecen ser expertos y pretenden comprender completamente el HFSC, en realidad solo tienen un conocimiento parcial y hacen declaraciones falsas basadas en una mala comprensión del concepto y de cómo todos esos entornos interactúan.

Creo que finalmente renunciaré al HFSC. Si puede configurar correctamente su HFSC, puede que sea la mejor QoS que pueda obtener, pero las posibilidades de que cometa un error total son mucho mayores que las posibilidades de que tenga éxito.

Answer

Finalmente, una guía que parece explicar la mayoría de las inconsistencias y también en qué se diferencia la implementación actual del documento original:

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

Según esta guía, muchas otras guías y publicaciones en foros sobre HFSC son totalmente absurdas; simplemente muestra cuán complicado es el HFSC, ya que muchas personas que parecen ser expertos y pretenden comprender completamente el HFSC, en realidad solo tienen un conocimiento parcial y hacen declaraciones falsas basadas en una mala comprensión del concepto y de cómo todos esos entornos interactúan.

Creo que finalmente renunciaré al HFSC. Si puede configurar correctamente su HFSC, puede que sea la mejor QoS que pueda obtener, pero las posibilidades de que cometa un error total son mucho mayores que las posibilidades de que tenga éxito.

Question 4

Si no puede localizar a los autores originales, intentaría lo siguiente:

vaya al árbol de fuentes del kernel de Linux y busque archivos C que implementen el "marco de programación TC"
Mire el encabezado y busque el autor del código.
Envíe un correo electrónico a los programadores del "marco de programación de CT" solicitándoles literatura sobre su implementación.

Intente también consultar otros artículos más recientes que citan este. Es posible que existan artículos más nuevos que sean una continuación de la investigación en esta área y que puedan incluir más información sobre las preguntas que usted hace.

Answer

Si no puede localizar a los autores originales, intentaría lo siguiente:

vaya al árbol de fuentes del kernel de Linux y busque archivos C que implementen el "marco de programación TC"
Mire el encabezado y busque el autor del código.
Envíe un correo electrónico a los programadores del "marco de programación de CT" solicitándoles literatura sobre su implementación.

Intente también consultar otros artículos más recientes que citan este. Es posible que existan artículos más nuevos que sean una continuación de la investigación en esta área y que puedan incluir más información sobre las preguntas que usted hace.

¿Alguien entiende realmente cómo funciona la programación HFSC en Linux/BSD?

Respuesta1

Respuesta2

Respuesta3

Respuesta4

información relacionada