Solución 1:
Leer los artículos sobre HFSC y sus primos no es una buena manera de entenderlo. El objetivo principal del documento HFSC es proporcionar una prueba matemática rigurosa de sus afirmaciones, sin explicar cómo funciona. De hecho, no puede entender cómo funciona solo con el documento HFSC, también debe leer los documentos a los que hace referencia. Si tiene algún problema con el reclamo o sus pruebas, puede ser una buena idea ponerse en contacto con los autores de los artículos; de lo contrario, dudo que estén interesados en saber de usted.
He escrito un tutorial para HFSC. Léalo 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), ¿no? ¿Por qué le daría adicionalmente 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 prioridad más alta? De acuerdo con el artículo original, puedo darles una prioridad más alta usando una curva, después de todo, de eso se trata HFSC. Al dar a ambas clases una curva de [256kbit/s 20ms 128kbit/s], ambas tienen el doble de prioridad que A2 y B2 automáticamente (todavía solo obtienen un promedio de 128 kbit/hijo)
La curva de tiempo real y la curva de enlaces compartidos se evalúan de diferentes maneras. La curva de tiempo real tiene en cuenta lo que ha hecho una clase a lo largo de toda su historia. Debe hacer eso 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 piensa intuitivamente como justo . 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 más tarde. Esto significa que, bajo la garantía de tiempo real, una clase no puede obtener ancho de banda durante un largo período porque lo usó antes, cuando nadie lo quería.
El uso compartido de enlaces es justo, ya que no penaliza a una clase por usar ancho de banda adicional. Sin embargo, esto significa que no puede proporcionar fuertes garantías de latencia.
La separación entre el uso compartido de enlaces y la provisión de garantías de latencia es lo nuevo que HFSC trae a la mesa, y el documento lo dice en su oración inicial:En este documento, estudiamos modelos de gestión de recursos jerárquicos y algoritmos que admiten ambos enlaces:compartir y 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 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 HFSC, definen el ancho de banda en términos de lo que la clase ha enviado desde que la clase se ha atrasado (es decir, tiene paquetes esperando para 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 garantizado más bajo de ese conjunto, mientras que el enlace compartido solo mira desde la última vez que la clase se atrasó. Así que rt toma en consideración más bytes que ls, pero cada byte que ls considera también es considerado por rt.
¿La curva de límite superior también se aplica en tiempo real, solo para compartir mediante enlace, 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 aún 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 enlace compartido.
Suponiendo que A2 y B2 son ambos de 128 kbit/s, ¿hay alguna diferencia si A1 y B1 son solo de enlace compartido de 128 kbit/s, o de 64 kbit/s en tiempo real y de enlace compartido de 128 kbit/s? diferencia?
Sí, hace la diferencia. Como se explicó anteriormente, si usa el tiempo real, las latencias están garantizadas pero el enlace no se comparte de manera justa (y en particular, la clase podría sufrir escasez de ancho de banda), y los límites superiores no se aplican. Si usa el enlace compartido, la latencia no está garantizada, pero el enlace compartido es justo, no hay riesgo de inanición y se aplica un límite superior. El tiempo real siempre se verifica antes de compartir mediante enlace, sin embargo, esto no significa necesariamente que se ignorará el uso compartido de enlace. Eso es porque los paquetes se cuentan de manera diferente. Dado que el historial se considera en tiempo real, es posible que no se necesite un paquete para cumplir con la garantía en tiempo real (debido a que se incluye uno del historial), pero se necesita para satisfacer el uso compartido de enlaces porque ignora el paquete histórico.
Si uso la curva en tiempo real separada 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é ambas curvas? La necesidad de curvas es clara en el documento original, porque solo 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 enlaces compartidos?
La curva para los controles en tiempo real le permite intercambiar una latencia estrecha para una clase de tráfico en particular (p. ej., VOIP) por una latencia deficiente para otras clases de tráfico (p. ej., 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 usa el ancho de banda del enlace para calcular esto, usa el ancho de banda asignado por la curva de tiempo real. Por lo tanto, si tenemos paquetes de VOIP y de correo electrónico de la misma longitud, y el paquete de VOIP tiene una curva convexa que aumenta 10 veces la curva cóncava del correo electrónico, se enviarán 10 paquetes de VOIP antes que el primer paquete de correo electrónico. Pero esto solo sucede durante el tiempo de ráfaga, que debería ser como máximo el tiempo que lleva enviar algunos paquetes, es decir, milisegundos. A partir de entonces, la curva de VOIP debería aplanarse, y VOIP no obtendrá un 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). El resultado neto de todo esto es garantizar que esos primeros paquetes de VOIP se envíen más rápido que cualquier otra cosa, lo que le otorga a VOIP una latencia baja a expensas de que el correo electrónico obtenga 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 como una roca es lo que se necesita para el tráfico en tiempo real como VOIP. Sin embargo, en promedio, una curva convexa compartida por enlace aún proporcionará 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 por correo electrónico.
De acuerdo con la poca documentación disponible, los valores de las curvas en tiempo real se ignoran totalmente para las clases internas (clase A y B), solo se aplican a las clases 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 las 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 anterior a la configuración de muestra).
La documentación es correcta. La jerarquía (y, por lo tanto, los nodos internos) no tiene ningún efecto sobre el cálculo del tiempo real. No puedo decirte 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 es el correcto o tal vez ambos están equivocados?
Ambos están equivocados. Si el 70% o el 80% de su tráfico tiene requisitos estrictos de latencia que deben especificarse en tiempo real, la realidad es que es casi seguro que no puede satisfacerlos con el enlace que está utilizando. Necesitas un enlace más rápido.
La única forma en que alguien podría pensar en especificar que el 80 % del tráfico debería ser en tiempo real es si tuvieran el tiempo real como un impulso prioritario. Sí, para proporcionar garantías de latencia, de hecho está aumentando la prioridad de algunos paquetes. Pero solo debe ser por milisegundos. Eso es todo lo que puede hacer frente a un enlace y aún así proporcionar las garantías de latencia.
Hay muy poco tráfico que necesita garantías de latencia. VOIP es uno, NTP otro. El resto debe hacerse con el uso compartido de enlaces. Si desea que la web sea rápida, la hace rápida al asignarle la mayor parte de la capacidad de los enlaces. Ese recurso compartido es garantizado a largo plazo. Si desea que tenga una latencia baja (en promedio), dele una curva convexa en el uso compartido de 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 de acuerdo con el siguiente "modelo mental simplificado":tiempo real es el ancho de banda garantizado que esta clase siempre obtendrá. enlace compartido es el ancho de banda que esta clase quiere estar completamente satisfecho, pero la satisfacción no se puede garantizar. En caso de que haya un exceso de ancho de banda, es posible que a la clase se le ofrezca más ancho de banda del necesario para quedar satisfecha, pero es posible que nunca use más de lo que dice el límite superior. Para que todo esto funcione, la suma de todos los anchos de banda en tiempo real no puede estar por encima del 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 un malentendido total de 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 enlace compartido no brinda las garantías de latencia estrictas como lo hace el tiempo real, hace un mejor trabajo al darle a la clase su asignación de ancho de banda 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 cualquier otro programador puede proporcionar.
La descripción del 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. Es para proporcionar una latencia garantizada, es decir, el paquete se envía AHORA, no una cantidad de tiempo aleatoria después, dependiendo de cómo se use el enlace. La mayoría del tráfico no necesita latencia garantizada.
Dicho esto, el tiempo real tampoco ofrece garantías de latencia perfectas. 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 perder su fecha límite de latencia por el tiempo que se tarda en enviar un paquete MTU. (Si sucede, será porque era un enlace compartido de paquete MTU que se coló en tiempo real manteniendo el enlace inactivo en caso de que se le diera un paquete con un plazo corto que tenía que enviarse de inmediato. Esta es otra diferencia entre el enlace compartido y tiempo real. Para proporcionar sus garantías, el tiempo real puede mantener deliberadamente la línea inactiva incluso si hay paquetes para enviar, por lo que proporciona menos del 100 % de utilización del enlace. El uso compartido del enlace siempre utiliza el 100 % de la capacidad disponible de los enlaces. A diferencia del tiempo real , se puede decir que es "preservación del trabajo".)
La razón por la que se puede decir que el tiempo real ofrece garantías estrictas de latencia es que la demora es limitada. Por lo tanto, si intenta ofrecer una garantía de latencia de 20 ms en un enlace de 1 Mbit/seg, y el enlace compartido está enviando paquetes de tamaño MTU (1500 bytes), sabe que uno de esos paquetes tardará 12 ms en enviarse. Por lo tanto, si le dice en tiempo real que desea una latencia de 8 ms, aún puede cumplir con el plazo de 20 ms, con una garantía absoluta.
Y si la suposición anterior es realmente precisa, ¿dónde está la priorización en ese modelo? P.ej. cada clase puede tener un ancho de banda en tiempo real (garantizado), un ancho de banda de enlace compartido (no garantizado) y quizás un límite superior, pero aun 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í, ¿cuál curva? ¿La curva en tiempo real? ¿La curva de enlaces compartidos? ¿La curva del límite superior? ¿Todos ellos? ¿Les daría a todos la misma pendiente o a cada uno una diferente y cómo encontrar la pendiente correcta?
No hay un modelo de priorización. En serio. Si desea dar prioridad absoluta al tráfico, utilice pfifo. Esto es para lo que sirve. Pero también tenga en cuenta que si le da al tráfico web una 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 pase ningún paquete de correo electrónico, en absoluto. . Todas sus conexiones de correo electrónico mueren.
En realidad, nadie quiere ese tipo de priorización. Lo que quieren es lo que ofrece HFSC. Si realmente tiene tráfico en tiempo real, HFSC lo proporciona. Pero serán cosas todas. 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 el paquete de DNS extraño rápidamente, pero no deje que alguien me DOS con él".
Solución 2:
Podrías definir las curvas con diferentes nombres:
- rt, curva en tiempo real, ancho de banda/garantía de retraso.
- 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 máximo/retraso 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), ¿no? ¿Por qué le daría adicionalmente 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 prioridad más alta? De acuerdo con el artículo original, puedo darles una prioridad más alta usando una curva, después de todo, de eso se trata HFSC. Al dar a ambas clases una curva de [256kbit/s 20ms 128kbit/s], ambas tienen el doble de prioridad que A2 y B2 automáticamente (todavía solo obtienen un promedio de 128 kbit/hijo)
Cuando realiza una definición en HFSC solo con tarifas, establece automáticamente 'dmax' en 0. Lo que básicamente significa que no tiene en cuenta la demora. Una buena configuración de HFSC debe incluir tanto el ancho de banda como los límites de retardo que desea usar para su clase; de lo contrario, el algoritmo no puede calcular exactamente cuánta prioridad debe tener una clase.
Cada vez que le dé prioridad a los paquetes, la prioridad de otros paquetes tendrá que disminuir. En función de 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? si tanto A1 como B1 solo tienen un ancho de banda de 64 kbit/s en tiempo real y 64 kbit/slink-share, ¿eso significa que una vez que reciben 64 kbit/s en tiempo real, su requisito de link-share también se cumple (es posible que obtengan un exceso de ancho de banda, pero ignoremos eso por un segundo) o ¿eso significa que obtienen otros 64 kbit/s a través de un 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 en tiempo real si la curva de enlace compartido es más alta que la curva en tiempo real (el requisito actual de enlace compartido es igual al requisito de enlace compartido especificado menos el ancho de banda en tiempo real ya proporcionado a esta clase)?
Si el flujo no supera los límites de la definición de enlace compartido de la clase, la curva en tiempo real nunca se usa. Definir una curva en tiempo real en este caso le permite, por ejemplo:garantizar un cierto 'dmax'.
Si sus definiciones de enlaces compartidos son impecables, entonces no necesitará curvas en tiempo real. Podría simplemente definir las 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 en tiempo real, solo para compartir enlaces, o tal vez para ambos? Algunos tutoriales dicen de una manera, otros dicen de otra manera. ¿Algunos incluso afirman que el límite superior es el máximo para el 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 al enlace compartido, cuando define una curva de límite superior, DEBE definir una curva de enlace compartido. 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 son solo de enlace compartido de 128 kbit/s, o de 64 kbit/s en tiempo real y de enlace compartido de 128 kbit/s? diferencia?
Hay una ligera diferencia, si p. A2 =0 kbits/s y B2 =256 kbits/s. Entonces el tiempo virtual para A2 estará en su máximo. Siempre que los paquetes se clasifiquen en A2, se procesarán instantáneamente. Sin embargo, la curva en tiempo real de B2 aún garantizará que pueda transmitir al menos 64 kbit/s
Si uso la curva de tiempo real separada 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é ambas curvas? La necesidad de curvas es clara en el documento original, porque solo 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 enlaces compartidos?
Las curvas en tiempo real no comparten el tráfico entre hojas vecinas, las curvas de enlace compartido sí lo hacen.
De acuerdo con la poca documentación disponible, los valores de las curvas en tiempo real se ignoran totalmente para las clases internas (clase A y B), solo se aplican a las clases 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 las 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 anterior a 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 en 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 es el correcto o tal vez ambos están equivocados?
Lo que quieren decir es:no se puede priorizar todo el tráfico... Cada vez que se da prioridad a los paquetes, se tendrá que disminuir la prioridad de otros paquetes. Si garantiza en exceso, el algoritmo se vuelve inútil. Defina la clase que gana prioridad y defina las clases que pueden sufrir.
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 de acuerdo con el siguiente "modelo mental simplificado":tiempo real es el ancho de banda garantizado que esta clase siempre obtendrá. enlace compartido es el ancho de banda que esta clase quiere estar completamente satisfecho, pero la satisfacción no se puede garantizar. En caso de que haya un exceso de ancho de banda, es posible que a la clase se le ofrezca más ancho de banda del necesario para quedar satisfecha, pero es posible que nunca use más de lo que dice el límite superior. Para que todo esto funcione, la suma de todos los anchos de banda en tiempo real no puede estar por encima del 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 un malentendido total de HSFC?
Esto es correcto.
Y si la suposición anterior es realmente precisa, ¿dónde está la priorización en ese modelo? P.ej. cada clase puede tener un ancho de banda en tiempo real (garantizado), un ancho de banda de enlace compartido (no garantizado) y quizás un límite superior, pero aun 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í, ¿cuál curva? ¿La curva en tiempo real? ¿La curva de enlaces compartidos? ¿La curva del límite superior? ¿Todos ellos? ¿Les daría a todos la misma pendiente o a cada uno una diferente y cómo encontrar la pendiente correcta?
La diferencia entre, p. HFSC y HTB es que HFSC le permitirá definir exactamente cuánta prioridad desea que tenga. Esto se hace definiendo límites mínimos y máximos con el valor 'dmax'.
Solución 3:
Finalmente, una guía que parece explicar la mayoría de las inconsistencias y también cómo la implementación actual es diferente del artículo original:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
De acuerdo con esta guía, muchas otras guías y publicaciones en foros sobre HFSC no tienen sentido; simplemente muestra lo complicado que es HFSC, ya que muchas personas que parecen ser expertos y pretenden haber entendido completamente HFSC, de hecho solo tienen un conocimiento parcial y hacen declaraciones falsas basadas en la incomprensión del concepto y cómo todas esas configuraciones juegan juntas.
Creo que finalmente renunciaré a HFSC. Si puede configurar correctamente su HFSC, puede ser la mejor QoS que pueda obtener, pero las posibilidades de que se equivoque por completo son mucho mayores que las posibilidades de éxito.