Est-ce que quelqu'un comprend vraiment comment fonctionne l'ordonnancement HFSC dans Linux/BSD ?

Lire les articles sur le HFSC et ses cousins n'est pas un bon moyen de le comprendre. L'objectif premier de l'article sur HFSC est de fournir une preuve mathématique rigoureuse de ses affirmations, et non d'expliquer son fonctionnement. En effet, vous ne pouvez pas comprendre comment cela fonctionne à partir du document HFSC seul, vous devez également lire les documents auxquels il fait référence. Si vous avez un problème avec les affirmations ou leurs preuves, il serait bon de contacter les auteurs des articles, sinon je doute qu'ils souhaitent vous entendre.

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 A1, A2, B1, B2 sont tous des liens partagés à 128 kbit/s (pas de courbe en temps réel pour chacun d'eux), chacun d'eux recevra 128 kbit/s si la racine a 512 kbit/s à distribuer (et 512 kbit/s à distribuer (et A et B sont tous 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 avec 128 kbit/s ? À quoi cela servirait-il ? Pour donner à ces deux-là une priorité plus élevée ? Selon l'article original, je peux leur donner une priorité plus élevée en utilisant une courbe. une courbe, c'est le but de HFSC après tout. En donnant aux deux classes une courbe de [256kbit/s 20ms 128kbit/s], les deux classes ont deux fois la priorité que A2 et B2 automatiquement (qui ne reçoivent toujours que 128 kbit/s en moyenne). en moyenne)

La courbe de temps réel et la courbe de partage de liens sont évaluées de manière différente. La courbe de temps réel prend en compte ce qu'une classe a fait tout au long de son histoire. Elle doit le faire pour fournir une allocation précise de la bande passante et de la latence. L'inconvénient est qu'elle n'est pas ce que la plupart des gens considèrent intuitivement comme étant équitable . En temps réel, si une classe emprunte de la bande passante lorsque 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 de temps réel, une classe peut ne pas avoir de bande passante pendant une longue période parce qu'elle l'a utilisée plus tôt, lorsque personne n'en voulait.

Le partage de liens est équitable, dans la mesure où il ne pénalise pas une classe pour avoir utilisé la bande passante disponible. Cependant, cela signifie qu'il ne peut pas fournir de fortes garanties de latence.

La séparation entre le partage des liens et les garanties de latence est la nouveauté apportée par HFSC, et le document le dit dès sa première phrase : Dans cet article, nous étudions des modèles et des algorithmes de gestion des ressources hiérarchiques qui prennent en charge à la fois le partage des liens et les services garantis en temps réel avec une allocation découplée des délais (priorité) et de la bande passante. Le mot clé dans cette phrase est "découplé". Traduit, cela signifie que vous êtes censé 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 est-elle prise en compte 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 qu'elle est en attente (c'est-à-dire qu'elle a des paquets en attente d'être envoyés). La seule différence entre rt et ls est que rt regarde vers l'avant à partir de chaque fois que la classe est devenue arriérée et calcule la bande passante garantie la plus basse à partir de cet ensemble, alors que le partage de lien regarde seulement à partir de la dernière fois que la classe est devenue arriérée. Ainsi, rt prend plus d'octets en considération que ls, mais chaque octet pris en compte par ls l'est également par rt.

La courbe de limite supérieure s'applique-t-elle aussi au temps réel, mais seulement au partage de liens ? ou peut-être aux deux ?

La limite supérieure n'empêche pas l'envoi de paquets pour satisfaire la condition en temps réel. Les paquets envoyés sous la condition de temps réel comptent toujours dans la limite supérieure, et peuvent donc retarder un paquet envoyé sous la condition de partage de lien dans le futur. C'est une autre différence entre le temps réel et le partage de lien.

En supposant que A2 et B2 sont tous deux à 128 kbit/s, cela fait-il une différence si A1 et B1 sont à 128 kbit/s en partage de lien uniquement, ou à 64 kbit/s en temps réel et à 128 kbit/s en partage de lien. 128 kbit/s en temps réel et 128 kbit/s en partage de lien, 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 pas de 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. Puisque l'historique est considéré par le temps réel, un paquet peut ne pas être nécessaire pour satisfaire la garantie du temps réel (à cause d'un paquet compté inclus dans l'historique) mais 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 de classes, pourquoi aurais-je besoin de "courbes" ? Pourquoi le temps réel n'est-il pas une valeur et le partage de liens n'est-il pas également une valeur plate ? Pourquoi les deux sont des courbes ? La nécessité de courbes est clair dans l'article original, car il n'y a qu'un seul attribut de ce ki. attribut de ce type par classe. Mais maintenant, avec trois attributs (temps réel, partage de liens et limite supérieure), pourquoi ai-je encore besoin de de courbes pour chacun d'eux ? Pourquoi aurais-je besoin de la forme des courbes (pas de moyenne bande passante moyenne, mais leurs pentes) soit différente pour le temps réel et la limite supérieure. le trafic de partage de liens ?

La courbe des contrôles en temps réel vous permet d'échanger une latence faible pour une classe de trafic particulière (par exemple la VOIP) contre une latence faible pour d'autres classes de trafic (par exemple le courrier électronique). En décidant 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, mais la bande passante allouée par la courbe de temps réel. Ainsi, si nous avons des paquets VOIP et email de la même longueur, et que le paquet VOIP a une courbe convexe qui lui donne une augmentation de 10 fois par rapport à la courbe concave pour l'email, alors 10 paquets VOIP seront envoyés avant le premier paquet email. Mais cela ne se produit que pendant la durée de la rafale, qui devrait être au maximum le temps qu'il faut pour envoyer quelques paquets - c'est-à-dire quelques milli secondes. Par la suite, la courbe de la 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 être le cas). Le résultat net de tout ceci est de s'assurer que les deux premiers paquets de la VOIP sont envoyés plus rapidement que tout le reste, donnant ainsi à la VOIP une faible latence au détriment de la latence élevée du courrier électronique.

Comme je l'ai dit précédemment, parce que le partage de liens ne tient pas compte de 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 de partage de lien fournira toujours une augmentation de latence à son trafic. Ce n'est simplement pas garanti. C'est très bien pour la plupart des choses, comme le trafic web par e-mail.

D'après le peu de documentation disponible, la courbe en temps réel temps réel sont totalement ignorées pour les classes internes (classe A et B), elles sont uniquement appliquées aux classes feuilles (A1, A2, B1, B2). Si cela est vrai, pourquoi la configuration de l'échantillon ALTQ HFSC (rechercher dans 3.3 Sample configuration) fixe des courbes en temps réel sur les classes internes et prétend que celles-ci fixent le taux garanti de ces classes internes ? N'est-ce pas complètement inutile ? (note : pshare définit la courbe de partage de liens dans ALTQ et grate la courbe en temps réel ; vous pouvez le voir dans le paragraphe ci-dessus. 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, quel qu'il soit. Je ne peux pas vous dire pourquoi ALTQ pense manifestement que c'est le cas.

Selon certains didacticiels, la somme de toutes les courbes en temps réel ne peut être plus élevée 80% de la vitesse de la ligne, d'autres disent qu'elle ne doit pas dépasser 70% de la de la vitesse de la ligne. Lequel des deux a raison ou les deux ont-ils 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 presque certainement pas les satisfaire avec la liaison que vous utilisez. Vous avez besoin d'une liaison plus rapide.

La seule façon dont quelqu'un pourrait penser à spécifier que 80% du trafic devrait être en temps réel est de considérer le temps réel comme une priorité. Oui, afin de fournir des garanties de latence, vous augmentez en effet la priorité de certains paquets. Mais cela ne devrait être que pour quelques millisecondes. C'est tout ce qu'un lien peut supporter tout en offrant des garanties de latence.

Il y a très peu de trafic qui nécessite des garanties de latence. La VOIP en est une, NTP une autre. Le reste devrait être fait avec le partage de liens. Si vous voulez que le web soit rapide, vous le rendez rapide en lui allouant la plupart de la capacité des liens. Ce partage es garantis à long terme. Si vous voulez que la latence soit faible (en moyenne), donnez-lui une courbe convexe sous le partage de liens.

Un tutoriel a dit que vous devez oublier toute la théorie. Peu importe comment les choses fonctionnent réellement (planificateurs et distribution de la bande passante), imaginez les trois courbes selon le "modèle mental simplifié" suivant : le temps réel est la bande passante garantie que cette classe obtiendra toujours. le link-share est la bande passante que cette classe veut obtenir pour être pleinement satisfaite, mais la satisfaction ne peut être garantie. Dans le cas où il y a bande passante excédentaire, la classe peut même se voir offrir plus de bande passante que nécessaire pour être satisfaite. nécessaire pour être satisfaite, mais elle ne peut jamais utiliser plus que ce que la la limite supérieure. Pour que tout cela fonctionne, la somme de toutes les bandes passantes en temps réel ne doit pas être supérieure à la limite supérieure. bande passante en temps réel ne doit pas être supérieure à xx% de la vitesse de la ligne (voir la question ci-dessus), le pourcentage varie). Question : Est-ce plus ou moins précis ou une ou une incompréhension totale de la HSFC ?

C'est une bonne description de la limite supérieure. Bien que la description du partage de liens soit strictement exacte, elle est trompeuse. S'il est vrai que le partage de lien ne donne pas de garanties de latence comme le fait le temps réel, il fait un meilleur travail pour donner à la classe sa bande passante que ses concurrents, comme CBQ et HTB. Donc, en disant que le partage de lien "ne fournit pas de garanties", il le tient à un standard plus élevé que tout autre planificateur peut fournir.

La description de Real Time est à la fois précise et tellement trompeuse que je la qualifierais de fausse. Comme son nom l'indique, le but du temps réel n'est pas de garantir une bande passante. Il s'agit de fournir une latence garantie, c'est-à-dire que le paquet est envoyé MAINTENANT, et non pas dans un délai aléatoire dépendant de l'utilisation de la liaison. 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. Il pourrait l'être 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 dépasser son délai de latence du temps qu'il faut pour envoyer un paquet MTU. (Si cela se produit, ce sera parce que c'était un paquet MTU que le partage de lien a inséré pendant que le temps réel gardait le lien inactif au cas où il s'agissait d'un paquet donné avec un délai court qui devait être envoyé immédiatement. C'est encore une autre différence entre le partage de lien et le temps réel. Afin de fournir ses garanties, le temps réel peut délibérément garder la ligne inactive même s'il y a des paquets à envoyer, fournissant ainsi une utilisation du lien inférieure à 100%. Le partage de lien utilise toujours 100% de la capacité disponible du lien. 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 strictes est que le délai est limité. Ainsi, si vous essayez d'offrir une garantie de latence de 20 ms sur un lien de 1Mbit/sec, et que le partage de lien envoie des paquets de taille MTU (1500 octets), vous savez que l'envoi d'un de ces paquets prendra 12 ms. Ainsi, si vous dites en temps réel que vous voulez 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ù se trouve la hiérarchisation dans dans ce modèle ? Par exemple, chaque classe pourrait avoir une bande passante en temps réel (garantie), une bande passante de partage de lien (non garantie) et peut-être une limite supérieure, mais certaines classes ont des besoins plus prioritaires que d'autres. d'autres classes. Dans ce cas, je dois quand même établir des priorités d'une manière ou d'une autre, même parmi le trafic en temps réel de ces classes. Dois-je établir la priorité en fonction de la pente des courbes ? Et si oui, quelle courbe ? La courbe en temps réel ? La courbe de partage de liens de courbe de partage de liens ? La courbe de la limite supérieure ? Toutes ces courbes ? Est-ce que je leur donnerais à toutes la même pente ou une pente différente pour chacune d'entre elles et comment trouver la bonne pente ?

Il n'existe pas de modèle de hiérarchisation des priorités. Sérieusement. Si vous voulez donner des priorités absolues au trafic, utilisez le pfifo. C'est à cela qu'il sert. Mais attention, si vous donnez au trafic web la priorité absolue sur le trafic de messagerie, cela signifie que le trafic web saturera le lien et que les paquets de messagerie ne passeront pas, du tout . Toutes vos connexions de courrier électronique meurent alors.

En réalité, personne ne souhaite une telle hiérarchisation des priorités. Ce qu'ils veulent, c'est ce que le HFSC leur fournit. Si vous avez vraiment un trafic en temps réel, HFSC le fournit. Mais ce ne sera pas tout. Pour le reste, HFSC vous permet de dire "sur un lien congestionné, allouez 90% au web et laissez le courrier électronique s'écouler à 10%, et oh envoyez rapidement le paquet DNS bizarre mais ne laissez pas quelqu'un me faire un DOS avec".