Solution 1 :
Lire les articles sur HFSC et ses cousins n'est pas une bonne façon de le comprendre. L'objectif principal du document HFSC est de fournir une preuve mathématique rigoureuse de ses affirmations, sans expliquer son fonctionnement. En effet, vous ne pouvez pas comprendre comment cela fonctionne à partir du seul document HFSC, vous devez également lire les documents auxquels il fait référence. Si vous avez un problème avec l'affirmation ou leurs preuves, contacter les auteurs des articles peut être une bonne idée, sinon je doute qu'ils soient intéressés à avoir de vos nouvelles.
J'ai écrit un tutoriel pour HFSC. Lisez-le si mes explications ci-dessous ne sont pas claires.
Pourquoi ai-je besoin d'une courbe en temps réel ? En supposant que A1, A2, B1, B2 sont tous à 128 kbit/s en partage de liaison (pas de courbe en temps réel pour l'un ou l'autre), alors chacun d'eux obtiendra 128 kbit/s si la racine a 512 kbit/s à distribuer (et A et B sont tous les deux à 256 kbit/s bien sûr), n'est-ce pas ? Pourquoi donnerais-je en plus à A1 et B1 une courbe en temps réel à 128 kbit/s ? À quoi cela servirait-il ? Pour donner à ces deux une priorité plus élevée? Selon le document original, je peux leur donner une priorité plus élevée en utilisant une courbe, c'est ce qu'est HFSC après tout. En donnant aux deux classes une courbe de [256kbit/s 20ms 128kbit/s] les deux ont automatiquement deux fois la priorité que A2 et B2 (en n'obtenant toujours que 128 kbit/s en moyenne)
La courbe temps réel et la courbe de partage de liens sont évaluées de différentes manières. La courbe en temps réel tient compte de ce qu'une classe a fait tout au long de son histoire. Il doit le faire pour fournir une allocation précise de la bande passante et de la latence. L'inconvénient n'est pas ce que la plupart des gens considèrent intuitivement comme juste . En temps réel, si une classe emprunte de la bande passante alors que personne d'autre n'en veut, elle est pénalisée lorsque quelqu'un d'autre veut la récupérer plus tard. Cela signifie que dans le cadre de la garantie en temps réel, une classe ne peut obtenir aucune bande passante pendant une longue période car elle l'a utilisée plus tôt, alors que personne n'en voulait.
Le partage de lien est équitable, en ce sens qu'il ne pénalise pas une classe pour l'utilisation de la bande passante disponible. Cependant, cela signifie qu'il ne peut pas fournir de garanties de latence solides.
La séparation du partage de lien de la fourniture de garanties de latence est la nouvelle chose que HFSC apporte à la table, et le document le dit dans sa phrase d'ouverture : Dans ce document, nous étudions des modèles et des algorithmes de gestion des ressources hiérarchiques qui prennent en charge à la partage et services en temps réel garantis avec délai découplé (priorité) et allocation de bande passante. Le mot clé de cette phrase est découplé. Traduit, cela signifie que vous devez dire comment la bande passante inutilisée doit être partagée avec ls, et spécifier quelles garanties en temps réel (alias garanties de latence) sont nécessaires avec rt. Les deux sont orthogonaux.
La bande passante en temps réel compte-t-elle dans la bande passante de partage de lien ?
Oui. Dans le document HFSC, ils définissent la bande passante en termes de ce que la classe a envoyé depuis que la classe est devenue en attente (c'est-à-dire que des paquets attendent d'être envoyés). La seule différence entre rt et ls est que rt attend à partir de chaque moment où la classe est devenue en attente et calcule la bande passante garantie la plus faible à partir de cet ensemble, alors que le partage de liens ne regarde qu'à partir de la dernière fois que la classe est devenue en attente. Ainsi, rt prend en compte plus d'octets que ls, mais chaque octet pris en compte par ls est également pris en compte par rt.
La courbe de limite supérieure s'applique-t-elle également au temps réel, uniquement au partage de lien, ou peut-être aux deux ?
La limite supérieure n'empêche pas l'envoi de paquets pour satisfaire la condition de temps réel. Les paquets envoyés dans la condition de temps réel comptent toujours pour la limite supérieure, et peuvent donc bien retarder l'envoi d'un paquet dans la condition de partage de liaison à l'avenir. C'est une autre différence entre le temps réel et le partage de lien.
En supposant que A2 et B2 sont tous les deux à 128 kbit/s, cela fait-il une différence si A1 et B1 sont en partage de liaison à 128 kbit/s uniquement, ou en temps réel à 64 kbit/s et en partage de liaison à 128 kbit/s, et si oui, quelle différence ?
Oui, cela fait une différence. Comme expliqué ci-dessus si vous utilisez le temps réel, les latences sont garanties mais le lien n'est pas partagé équitablement (et en particulier la classe pourrait souffrir d'un manque de bande passante), et les limites supérieures ne sont pas appliquées. Si vous utilisez le partage de lien, la latence n'est pas garantie, mais le partage de lien est équitable, il n'y a aucun risque de famine et la limite supérieure est appliquée. Le temps réel est toujours vérifié avant le partage de lien, mais cela ne signifie pas nécessairement que le partage de lien sera ignoré. C'est parce que les paquets sont comptés différemment. Étant donné que l'historique est considéré en temps réel, un paquet peut ne pas être nécessaire pour respecter la garantie en temps réel (à cause d'un compté inclus dans l'historique), mais il est nécessaire pour satisfaire le partage de lien car il ignore le paquet historique.
Si j'utilise la courbe en temps réel séparée pour augmenter les priorités des classes, pourquoi aurais-je besoin de "courbes" ? Pourquoi le temps réel n'est-il pas une valeur fixe et le partage de liens est-il également une valeur fixe ? Pourquoi les deux courbes? Le besoin de courbes est clair dans l'article original, car il n'y a qu'un seul attribut de ce type par classe. Mais maintenant, ayant trois attributs (temps réel, partage de lien et limite supérieure), pourquoi ai-je encore besoin de courbes sur chacun d'eux ? Pourquoi voudrais-je que la forme des courbes (pas la bande passante moyenne, mais leurs pentes) soit différente pour le trafic en temps réel et en partage de liens ?
La courbe des contrôles en temps réel vous permet d'échanger une latence étroite pour une classe de trafic particulière (par exemple, VOIP) contre une latence faible pour d'autres classes de trafic (par exemple, les e-mails). Lorsqu'il décide quel paquet envoyer sous la contrainte de temps réel, HFSC choisit celui qui terminera l'envoi en premier. Cependant, il n'utilise pas la bande passante du lien pour calculer cela, il utilise la bande passante allouée par la courbe en temps réel. Ainsi, si nous avons des paquets VOIP et e-mail de la même longueur, et que le paquet VOIP a une courbe convexe qui donne si une augmentation de 10 fois par rapport à la courbe concave pour l'e-mail, alors 10 paquets VOIP seront envoyés avant le premier paquet e-mail. Mais cela ne se produit que pour le temps de rafale, qui devrait être au maximum le temps qu'il faut pour envoyer quelques paquets - c'est-à-dire des millisecondes. Par la suite, la courbe VOIP devrait s'aplatir et la VOIP n'obtiendra aucune augmentation future à moins qu'elle ne recule pendant un certain temps (ce qui, étant donné que la VOIP est une application à faible bande passante, devrait le faire). Le résultat net de tout cela est de s'assurer que ces deux premiers paquets VOIP sont envoyés plus rapidement que toute autre chose, donnant ainsi une faible latence VOIP au détriment de la latence élevée des e-mails.
Comme je l'ai dit plus tôt, parce que le partage de liens ne regarde pas l'historique, il ne peut pas donner de garanties de latence. Une garantie solide comme le roc est ce qui est nécessaire pour le trafic en temps réel comme la VOIP. Cependant, en moyenne, une courbe convexe partagée par lien fournira toujours une augmentation de la latence à son trafic. Ce n'est tout simplement pas garanti. C'est suffisant pour la plupart des choses, comme le trafic Web par e-mail.
D'après le peu de documentation disponible, les valeurs de courbes en temps réel sont totalement ignorées pour les classes internes (classes A et B), elles ne sont appliquées qu'aux classes feuilles (A1, A2, B1, B2). Si tel est le cas, pourquoi l'exemple de configuration ALTQ HFSC (recherchez 3.3 Exemple de configuration) définit-il des courbes en temps réel sur les classes internes et prétend que celles-ci définissent le taux garanti de ces classes internes ? N'est-ce pas complètement inutile ? (Remarque :pshare définit la courbe de partage de liens dans ALTQ et grille la courbe en temps réel ; vous pouvez le voir dans le paragraphe au-dessus de l'exemple de configuration).
La documentation est correcte. La hiérarchie (et donc les nœuds internes) n'a aucun effet sur le calcul du temps réel. Je ne peux pas vous dire pourquoi ALTQ pense évidemment que c'est le cas.
Certains tutoriels disent que la somme de toutes les courbes en temps réel ne peut pas être supérieure à 80 % de la vitesse de la ligne, d'autres disent qu'elle ne doit pas être supérieure à 70 % de la vitesse de la ligne. Lequel a raison ou les deux ont peut-être tort ?
Les deux ont tort. Si 70 % ou 80 % de votre trafic a des exigences de latence strictes qui doivent être spécifiées en temps réel, la réalité est que vous ne pouvez certainement pas les satisfaire avec le lien que vous utilisez. Vous avez besoin d'un lien plus rapide.
La seule façon dont quelqu'un pourrait penser que spécifier 80 % du trafic devrait être en temps réel, c'est s'il utilisait le temps réel comme un boost prioritaire. Oui, afin de fournir des garanties de latence, vous augmentez en fait la priorité de certains paquets. Mais cela ne devrait durer que quelques millisecondes. C'est tout ce qu'un lien peut supporter tout en offrant les garanties de latence.
Il y a très peu de trafic nécessitant des garanties de latence. VOIP en est une, NTP en est une autre. Le reste devrait être fait avec le partage de lien. Si vous voulez que le Web soit rapide, vous le rendez rapide en lui allouant la majeure partie de la capacité des liens. Cette part est garantie sur le long terme. Si vous voulez qu'il ait une faible latence (en moyenne), donnez-lui une courbe convexe sous le partage de lien.
Un tutoriel a dit que vous oublierez toute la théorie. Peu importe comment les choses fonctionnent vraiment (ordonnanceurs et distribution de bande passante), imaginez les trois courbes selon le "modèle d'esprit simplifié" suivant :le temps réel est la bande passante garantie que cette classe obtiendra toujours. le partage de liens est la bande passante que cette classe veut devenir pleinement satisfait, mais la satisfaction ne peut être garantie. En cas de bande passante excessive, la classe peut même se voir offrir plus de bande passante que nécessaire pour être satisfaite, mais elle ne peut jamais utiliser plus que la limite supérieure indiquée. Pour que tout cela fonctionne, la somme de toutes les bandes passantes en temps réel ne doit pas dépasser xx % de la vitesse de la ligne (voir la question ci-dessus, le pourcentage varie). Question :Est-ce plus ou moins exact ou une incompréhension totale de HSFC ?
C'est une bonne limite supérieure de description. Bien que la description du partage de lien soit strictement exacte, elle est trompeuse. Bien qu'il soit vrai que le partage de liens ne donne pas les garanties de latence dure comme le fait le temps réel, il fait un meilleur travail pour donner à la classe sa bande passante son allocation que ses concurrents, comme CBQ et HTB. Donc, en disant que le partage de lien "ne fournit pas de garanties", il le maintient à un niveau supérieur à celui que tout autre planificateur peut fournir.
La description en temps réel parvient à être à la fois précise, mais si trompeuse que je dirais que c'est faux. Comme son nom l'indique, le but du temps réel n'est pas de donner une bande passante garantie. Il s'agit de fournir une latence garantie - c'est-à-dire que le paquet est envoyé MAINTENANT, et non un laps de temps aléatoire plus tard en fonction de la manière dont le lien est utilisé. La plupart du trafic n'a pas besoin d'une latence garantie.
Cela dit, le temps réel ne garantit pas non plus une latence parfaite. Cela pourrait, si le lien n'était pas également géré par le partage de lien, mais la plupart des utilisateurs veulent la flexibilité supplémentaire d'avoir les deux et cela n'est pas gratuit. Le temps réel peut manquer son délai de latence par le temps qu'il faut pour envoyer un paquet MTU. (Si cela se produit, ce sera parce qu'il s'agit d'un partage de lien de paquet MTU qui s'est faufilé en temps réel en gardant le lien inactif au cas où il recevait un paquet avec un court délai qui devait être envoyé immédiatement. C'est encore une autre différence entre le partage de lien et temps réel. Afin de fournir ses garanties, le temps réel peut délibérément maintenir la ligne inactive même s'il y a des paquets à envoyer, fournissant ainsi moins de 100 % d'utilisation du lien. Le partage de lien utilise toujours 100 % de la capacité disponible des liens. Contrairement au temps réel , on peut dire qu'il "préserve le travail".)
La raison pour laquelle on peut dire que le temps réel offre des garanties de latence dure est que le délai est limité. Donc, si vous essayez d'offrir une garantie de latence de 20 ms sur une liaison de 1 Mbit/s et que le partage de liens envoie des paquets de taille MTU (1 500 octets), vous savez que l'envoi de l'un de ces paquets prendra 12 ms. Ainsi, si vous indiquez en temps réel que vous souhaitez une latence de 8 ms, vous pouvez toujours respecter le délai de 20 ms - avec une garantie absolue.
Et si l'hypothèse ci-dessus est vraiment exacte, où est la priorisation dans ce modèle ? Par exemple. chaque classe peut avoir une bande passante en temps réel (garantie), une bande passante de partage de liens (non garantie) et peut-être une limite supérieure, mais certaines classes ont toujours des besoins plus prioritaires que d'autres classes. Dans ce cas, je dois toujours prioriser d'une manière ou d'une autre, même parmi le trafic en temps réel de ces classes. Aurais-je la priorité par la pente des courbes ? Et si oui, quelle courbe ? La courbe en temps réel ? La courbe de partage de liens ? La courbe limite supérieure ? Tous? Est-ce que je leur donnerais à tous la même pente ou à chacun une pente différente et comment trouver la bonne pente ?
Il n'y a pas de modèle de priorisation. Sérieusement. Si vous voulez donner au trafic des priorités absolues, utilisez pfifo. C'est pour ça. Mais sachez également que si vous donnez au trafic Web une priorité absolue sur le trafic de messagerie, cela signifie laisser le trafic Web saturer le lien et donc aucun paquet de messagerie ne passer, du tout . Toutes vos connexions e-mail meurent alors.
En réalité, personne ne veut ce genre de priorisation. Ce qu'ils veulent, c'est ce que HFSC fournit. Si vous avez réellement du trafic en temps réel, HFSC le fournit. Mais ce sera tout. Pour le reste, HFSC vous permet de dire "sur un lien encombré, allouez 90 % au Web et laissez le courrier électronique s'écouler à 10 %, et oh envoyez rapidement le paquet DNS impair mais ne laissez personne me DOS avec." /P>
Solution 2 :
Vous pouvez définir les courbes avec des noms différents :
- rt, courbe en temps réel, garantie bande passante/délai.
- ls, courbe de partage de lien, partage de bande passante/délai (basé sur la configuration des feuilles voisines)
- ul, courbe limite supérieure, bande passante/délai maximum qu'elle peut atteindre.
Pourquoi ai-je besoin d'une courbe en temps réel ? En supposant que A1, A2, B1, B2 sont tous à 128 kbit/s en partage de liaison (pas de courbe en temps réel pour l'un ou l'autre), alors chacun d'eux obtiendra 128 kbit/s si la racine a 512 kbit/s à distribuer (et A et B sont tous les deux à 256 kbit/s bien sûr), n'est-ce pas ? Pourquoi donnerais-je en plus à A1 et B1 une courbe en temps réel à 128 kbit/s ? À quoi cela servirait-il ? Pour donner à ces deux une priorité plus élevée? Selon le document original, je peux leur donner une priorité plus élevée en utilisant une courbe, c'est ce qu'est HFSC après tout. En donnant aux deux classes une courbe de [256kbit/s 20ms 128kbit/s] les deux ont automatiquement deux fois la priorité que A2 et B2 (en n'obtenant toujours que 128 kbit/s en moyenne)
Lorsque vous créez une définition dans HFSC avec des taux uniquement, il définit automatiquement 'dmax' sur 0. Ce qui signifie essentiellement qu'il ne tient pas compte du retard. Une bonne configuration HFSC doit inclure à la fois la bande passante ET les limites de délai que vous souhaitez utiliser pour votre classe, sinon l'algorithme ne peut pas déterminer exactement la priorité qu'une classe doit obtenir.
Chaque fois que vous donnez la priorité à des paquets, d'autres paquets devront être diminués en priorité. Sur la base des valeurs 'dmax' et 'rate', toutes les classes seront multiplexées à l'aide de minuteries virtuelles. Reportez-vous à tc-hfsc(7) pour plus d'informations.
La bande passante en temps réel compte-t-elle dans la bande passante de partage de lien ? si A1 et B1 n'ont tous les deux que 64kbit/s de bande passante en temps réel et 64kbit/slink-share, cela signifie-t-il qu'une fois qu'ils sont servis à 64kbit/s en temps réel, leur exigence de partage de lien est également satisfaite (ils peuvent obtenir un excès de bande passante, mais ignorons cela une seconde) ou cela signifie-t-il qu'ils obtiennent 64 kbit/s supplémentaires via le partage de lien ? Ainsi, chaque classe a-t-elle une "exigence" de bande passante en temps réel plus lien-partage ? Ouune classe a-t-elle seulement une exigence supérieure à la courbe en temps réel si la courbe de partage de liens est supérieure à la courbe en temps réel (l'exigence actuelle de partage de liens est égale à l'exigence de partage de liens spécifiée moins la bande passante en temps réel déjà fournie à cette classe) ?
Si le flux ne dépasse pas les limites de la définition de partage de liens de la classe, la courbe en temps réel n'est jamais utilisée. Définir une courbe en temps réel dans ce cas permet par exemple :de garantir un certain 'dmax'.
Si vos définitions de partage de liens sont sans faille, vous n'auriez pas besoin de courbes en temps réel. Vous pourriez simplement définir des courbes de service (sc), mais cela rendrait votre configuration plus difficile.
La courbe de limite supérieure s'applique-t-elle également au temps réel, uniquement au partage de liens, ou peut-être aux deux ? Certains tutoriels disent d'une manière, d'autres disent l'autre. Certains prétendent même que la limite supérieure est le maximum pour la bande passante en temps réel + la bande passante de partage de liens ? Quelle est la vérité ?
La courbe de limite supérieure de votre classe est appliquée uniquement au partage de lien, lorsque vous définissez une courbe de limite supérieure, vous DEVEZ définir une courbe de partage de lien. Cependant, la courbe limite supérieure des classes parentes est toujours appliquée.
En supposant que A2 et B2 sont tous les deux à 128 kbit/s, cela fait-il une différence si A1 et B1 sont en partage de liaison à 128 kbit/s uniquement, ou en temps réel à 64 kbit/s et en partage de liaison à 128 kbit/s, et si oui, quelle différence ?
Il y a une légère différence, si par ex. A2 =0 kbit/s et B2 =256 kbit/s. Alors le temps virtuel pour A2 sera à son maximum. Chaque fois que des paquets sont classés en A2, ils seront instantanément traités. Cependant, la courbe en temps réel de B2 garantira toujours qu'il est capable de transmettre au moins 64 kbit/s
Si j'utilise la courbe en temps réel séparée pour augmenter les priorités des classes, pourquoi aurais-je besoin de "courbes" ? Pourquoi le temps réel n'est-il pas une valeur fixe et le partage de liens est-il également une valeur fixe ? Pourquoi les deux courbes? Le besoin de courbes est clair dans l'article original, car il n'y a qu'un seul attribut de ce type par classe. Mais maintenant, ayant trois attributs (temps réel, partage de lien et limite supérieure), pourquoi ai-je encore besoin de courbes sur chacun d'eux ? Pourquoi voudrais-je que la forme des courbes (pas la bande passante moyenne, mais leurs pentes) soit différente pour le trafic en temps réel et en partage de liens ?
Les courbes en temps réel ne partagent pas le trafic entre les feuilles voisines, contrairement aux courbes de partage de liens.
D'après le peu de documentation disponible, les valeurs de courbes en temps réel sont totalement ignorées pour les classes internes (classes A et B), elles ne sont appliquées qu'aux classes feuilles (A1, A2, B1, B2). Si tel est le cas, pourquoi l'exemple de configuration ALTQ HFSC (recherchez 3.3 Exemple de configuration) définit-il des courbes en temps réel sur les classes internes et prétend que celles-ci définissent le taux garanti de ces classes internes ? N'est-ce pas complètement inutile ? (Remarque :pshare définit la courbe de partage de liens dans ALTQ et grille la courbe en temps réel ; vous pouvez le voir dans le paragraphe au-dessus de l'exemple de configuration).
Il est vrai que les courbes en temps réel sont ignorées pour les classes internes, elles ne sont appliquées qu'aux classes feuilles. Cependant, les courbes en temps réel définies sur ces classes internes sont prises en compte pour les calculs sur les classes feuilles.
Certains tutoriels disent que la somme de toutes les courbes en temps réel ne peut pas être supérieure à 80 % de la vitesse de la ligne, d'autres disent qu'elle ne doit pas être supérieure à 70 % de la vitesse de la ligne. Lequel a raison ou les deux ont peut-être tort ?
Ce qu'ils veulent dire, c'est :vous ne pouvez pas donner la priorité à tout le trafic... Chaque fois que vous donnez la priorité à des paquets, les autres paquets devront être moins prioritaires. Si vous sur-garantissez, l'algorithme devient inutile. Définissez les classes qui gagnent en priorité et définissez les classes qui peuvent en souffrir.
Un tutoriel a dit que vous oublierez toute la théorie. Peu importe comment les choses fonctionnent réellement (ordonnanceurs et répartition de la bande passante), imaginez les trois courbes selon le "modèle d'esprit simplifié" suivant :le temps réel est la bande passante garantie que cette classe obtiendra toujours. le partage de liens est la bande passante que cette classe veut devenir pleinement satisfait, mais la satisfaction ne peut être garantie. En cas d'excès de bande passante, la classe peut même se voir offrir plus de bande passante que nécessaire pour être satisfaite, mais elle ne peut jamais utiliser plus que la limite supérieure indiquée. Pour que tout cela fonctionne, la somme de toutes les bandes passantes en temps réel ne doit pas dépasser xx % de la vitesse de la ligne (voir la question ci-dessus, le pourcentage varie). Question :Est-ce plus ou moins exact ou une incompréhension totale de HSFC ?
C'est exact.
Et si l'hypothèse ci-dessus est vraiment exacte, où est la priorisation dans ce modèle ? Par exemple. chaque classe peut avoir une bande passante en temps réel (garantie), une bande passante de partage de liens (non garantie) et peut-être une limite supérieure, mais certaines classes ont toujours des besoins plus prioritaires que d'autres classes. Dans ce cas, je dois toujours prioriser d'une manière ou d'une autre, même parmi le trafic en temps réel de ces classes. Aurais-je la priorité par la pente des courbes ? Et si oui, quelle courbe ? La courbe en temps réel ? La courbe de partage de liens ? La courbe limite supérieure ? Tous? Est-ce que je leur donnerais à tous la même pente ou à chacun une pente différente et comment trouver la bonne pente ?
La différence entre par ex. HFSC et HTB est que HFSC vous permettra de définir exactement le niveau de priorité que vous souhaitez lui attribuer. Pour ce faire, définissez des limites minimales et maximales avec la valeur 'dmax'.
Solution 3 :
Enfin un guide qui semble expliquer la plupart des incohérences et aussi en quoi l'implémentation actuelle est différente de l'article d'origine :
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
Selon ce guide, de nombreux autres guides et messages de forum sur HFSC sont totalement absurdes ; cela montre à quel point HFSC est compliqué, car de nombreuses personnes qui semblent être des experts et prétendent avoir parfaitement compris HFSC, n'ont en fait qu'une connaissance partielle et font de fausses déclarations basées sur une mauvaise compréhension du concept et de la façon dont tous ces paramètres jouent ensemble.
Je pense que je vais enfin abandonner le HFSC. Si vous parvenez à configurer correctement votre HFSC, il s'agit peut-être de la meilleure QoS que vous puissiez obtenir, mais les chances que vous vous trompiez complètement sont bien plus élevées que les chances que vous réussissiez.