Versteht irgendjemand wirklich, wie die HFSC-Planung in Linux/BSD funktioniert?

Question 1

Das Lesen der Artikel über HFSC und seine Verwandten ist kein guter Weg, um es zu verstehen. Das Hauptziel des HFSC-Artikels besteht darin, einen strengen mathematischen Beweis seiner Behauptungen zu liefern, nicht darin, zu erklären, wie es funktioniert. Tatsächlich kann man nicht allein aus dem HFSC-Artikel verstehen, wie es funktioniert; man muss auch die Artikel lesen, auf die es sich bezieht. Wenn Sie ein Problem mit der Behauptung oder ihren Beweisen haben, ist es möglicherweise eine gute Idee, die Autoren der Artikel zu kontaktieren, andernfalls bezweifle ich, dass sie daran interessiert sein werden, von Ihnen zu hören.

Ich habe eineTutorial für HFSC. Lesen Sie es, wenn meine Erklärungen unten nicht klar sind.

Wozu brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2 haben alle eine Link-Share von 128 kbit/s (keine Echtzeitkurve für beide), dann bekommt jeder von ihnen 128 kbit/s, wenn die Wurzel 512 kbit/s zu verteilen hat (und A und B sind natürlich beide 256 kbit/s), richtig? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit/s geben? Wozu wäre das gut? Um diesen beiden eine höhere Priorität zu geben? Laut Originalpapier kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende, darum geht es ja schließlich bei HFSC. Indem ich beiden Klassen eine Kurve von [256 kbit/s 20 ms 128 kbit/s] gebe, haben beide automatisch die doppelte Priorität als A2 und B2 (bekommen im Durchschnitt trotzdem nur 128 kbit/s)

Die Echtzeitkurve und die Link-Sharing-Kurve werden auf unterschiedliche Weise ausgewertet. Die Echtzeitkurve berücksichtigt, was eine Klasse während ihrer gesamten Geschichte getan hat. Dies muss sie tun, um eine genaue Bandbreiten- und Latenzzuweisung zu gewährleisten. Der Nachteil ist nicht das, was die meisten Leute intuitiv alsgerecht. Wenn sich eine Klasse in Echtzeit Bandbreite leiht, die sonst niemand braucht, wird sie bestraft, wenn jemand anderes sie später zurückhaben will. Das bedeutet, dass eine Klasse unter der Echtzeitgarantie für einen langen Zeitraum keine Bandbreite bekommen kann, weil sie sie früher genutzt hat, als sie niemand wollte.

Die gemeinsame Nutzung von Links ist fair, da sie eine Klasse nicht für die Nutzung freier Bandbreite bestraft. Dies bedeutet jedoch, dass sie keine starken Latenzgarantien bieten kann.

Die Trennung der Link-Freigabe von der Bereitstellung von Latenzgarantien ist das Neue, was HFSC auf den Tisch bringt, und das Dokument sagt dies gleich im ersten Satz:In diesem Artikel untersuchen wir hierarchische Modelle und Algorithmen zur Ressourcenverwaltung, die sowohl Link-Sharing als auch garantierte Echtzeitdienste mit entkoppelter Verzögerung (Priorität) und Bandbreitenzuweisung unterstützen. Das Schlüsselwort in diesem Satz ist „entkoppelt“. Übersetzt heißt das, dass Sie sagen sollen, wie viel ungenutzte Bandbreite mit ls geteilt werden soll, und angeben sollen, welche Echtzeitgarantien (auch Latenzgarantien genannt) mit rt erforderlich sind. Die beiden sind orthogonal.

Zählt die Echtzeitbandbreite zur Link-Share-Bandbreite?

Ja. Im HFSC-Dokument wird die Bandbreite anhand dessen definiert, was die Klasse gesendet hat, seit es zu einem Rückstand gekommen ist (d. h. Pakete, die darauf warten, gesendet zu werden). Der einzige Unterschied zwischen rt und ls besteht darin, dass rt von jedem Zeitpunkt an, an dem es zu einem Rückstand gekommen ist, nach vorne schaut und die niedrigste garantierte Bandbreite aus diesem Satz berechnet, während Link Sharing nur vom letzten Zeitpunkt an schaut, an dem es zu einem Rückstand gekommen ist. rt berücksichtigt also mehr Bytes als ls, aber jedes Byte, das ls berücksichtigt, wird auch von rt berücksichtigt.

Wird die Obergrenzenkurve auch auf Echtzeit angewendet, nur auf Link-Share oder vielleicht auf beides?

Die Obergrenze verhindert nicht, dass Pakete gesendet werden, um die Echtzeitbedingung zu erfüllen. Pakete, die unter der Echtzeitbedingung gesendet werden, zählen dennoch zur Obergrenze und können daher ein Paket verzögern, das in Zukunft unter der Link-Sharing-Bedingung gesendet wird. Dies ist ein weiterer Unterschied zwischen Echtzeit und Link-Sharing.

Angenommen, A2 und B2 sind beide 128 kbit/s. Macht es einen Unterschied, ob A1 und B1 nur 128 kbit/s Link-Share oder 64 kbit/s Echtzeit und 128 kbit/s Link-Share sind, und wenn ja, welchen Unterschied?

Ja, es macht einen Unterschied. Wie oben erklärt, sind die Latenzen bei Verwendung von Echtzeit garantiert, aber die Verbindung wird nicht fair geteilt (und insbesondere könnte die Klasse unter Bandbreitenmangel leiden) und die Obergrenzen werden nicht durchgesetzt. Wenn Sie Link Share verwenden, ist die Latenz nicht garantiert, aber Link Sharing ist fair, es besteht kein Risiko von Bandbreitenmangel und die Obergrenze wird durchgesetzt. Echtzeit wird immer vor Link Share geprüft, dies bedeutet jedoch nicht unbedingt, dass Link Share ignoriert wird. Das liegt daran, dass Pakete anders gezählt werden. Da der Verlauf in Echtzeit berücksichtigt wird, muss ein Paket möglicherweise nicht die Echtzeitgarantie erfüllen (weil eins aus dem Verlauf gezählt wird), es ist jedoch erforderlich, um Link Share zu erfüllen, da es das historische Paket ignoriert.

Wenn ich die separate Echtzeitkurve verwende, um die Prioritäten von Klassen zu erhöhen, warum brauche ich dann überhaupt „Kurven“? Warum ist Echtzeit kein fester Wert und Link-Share auch kein fester Wert? Warum sind beide Kurven? Die Notwendigkeit von Kurven ist im Originalpapier klar, da es nur ein Attribut dieser Art pro Klasse gibt. Aber wozu brauche ich jetzt, wo ich drei Attribute habe (Echtzeit, Link-Share und Obergrenze), immer noch Kurven für jedes? Warum sollte ich wollen, dass die Kurvenform (nicht die durchschnittliche Bandbreite, sondern ihre Steigungen) für Echtzeit- und Link-Share-Verkehr unterschiedlich ist?

Die Kurve für Echtzeitsteuerungen ermöglicht es Ihnen, eine geringe Latenz für eine bestimmte Verkehrsklasse (z. B. VOIP) gegen eine geringe Latenz für andere Verkehrsklassen (z. B. E-Mail) einzutauschen. Bei der Entscheidung, welches Paket unter der Echtzeitbeschränkung gesendet werden soll, wählt HFSC das Paket aus, das zuerst vollständig gesendet wird. Zur Berechnung wird jedoch nicht die Bandbreite der Verbindung verwendet, sondern die von der Echtzeitkurve zugewiesene Bandbreite. Wenn wir also VOIP- und E-Mail-Pakete gleicher Länge haben und das VOIP-Paket eine konvexe Kurve hat, die eine 10-fache Steigerung gegenüber der konkaven Kurve für E-Mail ergibt, werden 10 VOIP-Pakete vor dem ersten E-Mail-Paket gesendet. Dies geschieht jedoch nur für die Burst-Zeit, die höchstens der Zeit entsprechen sollte, die zum Senden einiger Pakete benötigt wird – also Millisekunden. Danach sollte die VOIP-Kurve abflachen, und VOIP wird keine weitere Steigerung erfahren, es sei denn, es lässt für eine Weile nach (was es sollte, da VOIP eine Anwendung mit geringer Bandbreite ist). Das Nettoergebnis von all dem besteht darin, dass die ersten paar VOIP-Pakete schneller gesendet werden als alles andere, wodurch VOIP eine geringe Latenz aufweist, auf Kosten einer hohen Latenz bei E-Mails.

Wie ich bereits sagte, kann Link Share keine Latenzgarantien geben, da es nicht auf den Verlauf achtet. Für Echtzeitverkehr wie VoIP ist eine absolut zuverlässige Garantie erforderlich. Im Durchschnitt sorgt eine konvexe Link-Share-Kurve jedoch immer noch für eine Latenzsteigerung des Datenverkehrs. Es ist einfach nicht garantiert. Für die meisten Dinge ist das in Ordnung, beispielsweise für Webverkehr über E-Mail.

Laut der wenigen verfügbaren Dokumentation werden Echtzeitkurvenwerte für innere Klassen (Klasse A und B) völlig ignoriert und nur auf Blattklassen (A1, A2, B1, B2) angewendet. Wenn das stimmt, warum legt die ALTQ HFSC-Beispielkonfiguration (suchen Sie nach 3.3 Beispielkonfiguration) dann Echtzeitkurven für innere Klassen fest und behauptet, dass diese die garantierte Rate dieser inneren Klassen festlegen? Ist das nicht völlig sinnlos? (Hinweis: pshare legt die Link-Share-Kurve in ALTQ fest und gleitet die Echtzeitkurve; Sie können dies im Absatz über der Beispielkonfiguration sehen).

Die Dokumentation ist korrekt. Die Hierarchie (und damit die inneren Knoten) hat keinerlei Einfluss auf die Berechnung der Echtzeit. Ich kann Ihnen nicht sagen, warum ALTQ offensichtlich denkt, dass dies der Fall ist.

In einigen Tutorials heißt es, die Summe aller Echtzeitkurven dürfe nicht höher als 80% der Leitungsgeschwindigkeit sein, in anderen Tutorials heißt es, sie dürfe nicht höher als 70% der Leitungsgeschwindigkeit sein. Welches davon ist richtig oder liegen vielleicht beide falsch?

Beides ist falsch. Wenn 70 % oder 80 % Ihres Datenverkehrs strenge Latenzanforderungen haben, die in Echtzeit angegeben werden müssen, können Sie diese mit der von Ihnen verwendeten Verbindung mit ziemlicher Sicherheit nicht erfüllen. Sie benötigen eine schnellere Verbindung.

Die einzige Möglichkeit, auf die Idee zu kommen, dass 80 % des Datenverkehrs in Echtzeit erfolgen sollten, besteht darin, Echtzeit als Prioritätssteigerung zu betrachten. Ja, um Latenzgarantien bereitzustellen, erhöhen Sie tatsächlich die Priorität einiger Pakete. Dies sollte jedoch nur für Millisekunden erfolgen. Das ist alles, was eine Verbindung bewältigen kann und trotzdem die Latenzgarantien bietet.

Es gibt sehr wenig Verkehr, der Latenzgarantien benötigt. VOIP ist eine davon, NTP eine andere. Der Rest sollte alles über Link-Sharing erledigt werden. Wenn Sie möchten, dass das Web schnell ist, machen Sie es schnell, indem Sie ihm den Großteil der Link-Kapazität zuweisen. Diese FreigabeIstlangfristig garantiert. Wenn Sie eine niedrige Latenz (im Durchschnitt) wünschen, geben Sie ihm eine konvexe Kurve unter Link-Sharing.

In einem Tutorial hieß es, Sie sollten die ganze Theorie vergessen. Unabhängig davon, wie die Dinge wirklich funktionieren (Scheduler und Bandbreitenverteilung), stellen Sie sich die drei Kurven gemäß dem folgenden „vereinfachten Gedankenmodell“ vor: Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhält. Link-Share ist die Bandbreite, die diese Klasse vollständig erreichen möchte, aber die Erfüllung kann nicht garantiert werden. Falls es überschüssige Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite angeboten, als zur Erfüllung erforderlich ist, aber sie darf nie mehr verwenden, als die Obergrenze vorgibt. Damit all dies funktioniert, darf die Summe aller Echtzeitbandbreiten nicht über xx % der Leitungsgeschwindigkeit liegen (siehe Frage oben, der Prozentsatz variiert). Frage: Ist dies mehr oder weniger genau oder ein völliges Missverständnis von HSFC?

Dies ist eine gute Beschreibung der Obergrenze. Die Beschreibung von Link Share ist zwar genau richtig, aber irreführend. Es stimmt zwar, dass Link Share keine Garantien für die harte Latenz bietet wie Echtzeit, aber es ist besser darin, der Klasse seine Bandbreite zuzuweisen als seine Konkurrenten wie CBQ und HTB. Wenn man also sagt, dass Link Share „keine Garantien bietet“, legt man einen höheren Standard an, als ihn jeder andere Scheduler bieten kann.

Die Beschreibung von Echtzeit ist zwar genau, aber so irreführend, dass ich sie für falsch halte. Wie der Name schon sagt, besteht der Zweck von Echtzeit nicht darin, eine garantierte Bandbreite bereitzustellen. Es geht darum, eine garantierte Latenz bereitzustellen – d. h. das Paket wird JETZT gesendet und nicht zu einem beliebigen Zeitpunkt später, je nachdem, wie die Verbindung verwendet wird. Der meiste Datenverkehr benötigt keine garantierte Latenz.

Allerdings gibt Echtzeit auch keine perfekten Latenzgarantien. Das könnte es, wenn die Verbindung nicht auch von Link Share verwaltet würde, aber die meisten Benutzer möchten die zusätzliche Flexibilität, die beides mit sich bringt, und das ist nicht umsonst. Echtzeit kann seine Latenzfrist um die Zeit verfehlen, die zum Senden eines MTU-Pakets benötigt wird. (Wenn das passiert, liegt es daran, dass Link Share ein MTU-Paket eingeschmuggelt hat, während Echtzeit die Verbindung im Leerlauf hielt, falls ein Paket mit kurzer Frist empfangen wurde, das sofort gesendet werden musste. Dies ist ein weiterer Unterschied zwischen Link Share und Echtzeit. Um seine Garantien zu bieten, kann Echtzeit die Leitung absichtlich im Leerlauf halten, obwohl Pakete zu senden sind, und so eine Verbindungsauslastung von weniger als 100 % bieten. Link Share nutzt immer 100 % der verfügbaren Kapazität der Verbindung. Im Gegensatz zu Echtzeit kann man sagen, dass es „arbeitserhaltend“ ist.)

Der Grund, warum man sagen kann, dass Real Time feste Latenzgarantien bietet, ist, dass die Verzögerung begrenzt ist. Wenn Sie also versuchen, eine Latenzgarantie von 20 ms für eine 1-Mbit/s-Verbindung anzubieten und Link Share Pakete mit MTU-Größe (1500 Byte) sendet, wissen Sie, dass eines dieser Pakete 12 ms zum Senden benötigt. Wenn Sie Real Time also mitteilen, dass Sie eine Latenz von 8 ms wünschen, können Sie die Frist von 20 ms trotzdem einhalten – mit absoluter Garantie.

Und wenn die obige Annahme wirklich zutrifft, wo ist dann die Priorisierung in diesem Modell? Beispielsweise könnte jede Klasse eine Echtzeitbandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und vielleicht eine Obergrenze haben, aber dennoch haben einige Klassen höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich trotzdem irgendwie priorisieren, sogar unter dem Echtzeitverkehr dieser Klassen. Würde ich nach der Steigung der Kurven priorisieren? Und wenn ja, welche Kurve? Die Echtzeitkurve? Die Link-Share-Kurve? Die Obergrenzenkurve? Alle? Würde ich allen die gleiche Steigung zuweisen oder jeder eine andere, und wie finde ich die richtige Steigung heraus?

Es gibt kein Priorisierungsmodell. Im Ernst. Wenn Sie dem Datenverkehr absolute Priorität einräumen möchten, verwenden Sie pfifo. Dafür ist es gedacht. Aber seien Sie sich auch bewusst: Wenn Sie dem Web-Datenverkehr absolute Priorität vor dem E-Mail-Datenverkehr einräumen, bedeutet das, dass der Web-Datenverkehr die Verbindung überlastet und somit keine E-Mail-Pakete durchkommen.überhaupt. Alle Ihre E-Mail-Verbindungen werden dann unterbrochen.

In Wirklichkeit will niemand diese Art der Priorisierung. Was sie wollen, ist das, was HFSC bietet. Wenn Sie tatsächlich Echtzeitverkehr haben, bietet HFSC das. Aber das ist alles. Im Übrigen können Sie mit HFSC sagen: „Bei einer überlasteten Verbindung 90 % dem Web zuweisen und E-Mails mit 10 % durchsickern lassen, und oh, das eine oder andere DNS-Paket schnell senden, aber nicht zulassen, dass mich jemand damit unter Beschuss nimmt.“

Answer

Das Lesen der Artikel über HFSC und seine Verwandten ist kein guter Weg, um es zu verstehen. Das Hauptziel des HFSC-Artikels besteht darin, einen strengen mathematischen Beweis seiner Behauptungen zu liefern, nicht darin, zu erklären, wie es funktioniert. Tatsächlich kann man nicht allein aus dem HFSC-Artikel verstehen, wie es funktioniert; man muss auch die Artikel lesen, auf die es sich bezieht. Wenn Sie ein Problem mit der Behauptung oder ihren Beweisen haben, ist es möglicherweise eine gute Idee, die Autoren der Artikel zu kontaktieren, andernfalls bezweifle ich, dass sie daran interessiert sein werden, von Ihnen zu hören.

Ich habe eineTutorial für HFSC. Lesen Sie es, wenn meine Erklärungen unten nicht klar sind.

Wozu brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2 haben alle eine Link-Share von 128 kbit/s (keine Echtzeitkurve für beide), dann bekommt jeder von ihnen 128 kbit/s, wenn die Wurzel 512 kbit/s zu verteilen hat (und A und B sind natürlich beide 256 kbit/s), richtig? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit/s geben? Wozu wäre das gut? Um diesen beiden eine höhere Priorität zu geben? Laut Originalpapier kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende, darum geht es ja schließlich bei HFSC. Indem ich beiden Klassen eine Kurve von [256 kbit/s 20 ms 128 kbit/s] gebe, haben beide automatisch die doppelte Priorität als A2 und B2 (bekommen im Durchschnitt trotzdem nur 128 kbit/s)

Die Echtzeitkurve und die Link-Sharing-Kurve werden auf unterschiedliche Weise ausgewertet. Die Echtzeitkurve berücksichtigt, was eine Klasse während ihrer gesamten Geschichte getan hat. Dies muss sie tun, um eine genaue Bandbreiten- und Latenzzuweisung zu gewährleisten. Der Nachteil ist nicht das, was die meisten Leute intuitiv alsgerecht. Wenn sich eine Klasse in Echtzeit Bandbreite leiht, die sonst niemand braucht, wird sie bestraft, wenn jemand anderes sie später zurückhaben will. Das bedeutet, dass eine Klasse unter der Echtzeitgarantie für einen langen Zeitraum keine Bandbreite bekommen kann, weil sie sie früher genutzt hat, als sie niemand wollte.

Die gemeinsame Nutzung von Links ist fair, da sie eine Klasse nicht für die Nutzung freier Bandbreite bestraft. Dies bedeutet jedoch, dass sie keine starken Latenzgarantien bieten kann.

Die Trennung der Link-Freigabe von der Bereitstellung von Latenzgarantien ist das Neue, was HFSC auf den Tisch bringt, und das Dokument sagt dies gleich im ersten Satz:In diesem Artikel untersuchen wir hierarchische Modelle und Algorithmen zur Ressourcenverwaltung, die sowohl Link-Sharing als auch garantierte Echtzeitdienste mit entkoppelter Verzögerung (Priorität) und Bandbreitenzuweisung unterstützen. Das Schlüsselwort in diesem Satz ist „entkoppelt“. Übersetzt heißt das, dass Sie sagen sollen, wie viel ungenutzte Bandbreite mit ls geteilt werden soll, und angeben sollen, welche Echtzeitgarantien (auch Latenzgarantien genannt) mit rt erforderlich sind. Die beiden sind orthogonal.

Zählt die Echtzeitbandbreite zur Link-Share-Bandbreite?

Ja. Im HFSC-Dokument wird die Bandbreite anhand dessen definiert, was die Klasse gesendet hat, seit es zu einem Rückstand gekommen ist (d. h. Pakete, die darauf warten, gesendet zu werden). Der einzige Unterschied zwischen rt und ls besteht darin, dass rt von jedem Zeitpunkt an, an dem es zu einem Rückstand gekommen ist, nach vorne schaut und die niedrigste garantierte Bandbreite aus diesem Satz berechnet, während Link Sharing nur vom letzten Zeitpunkt an schaut, an dem es zu einem Rückstand gekommen ist. rt berücksichtigt also mehr Bytes als ls, aber jedes Byte, das ls berücksichtigt, wird auch von rt berücksichtigt.

Wird die Obergrenzenkurve auch auf Echtzeit angewendet, nur auf Link-Share oder vielleicht auf beides?

Die Obergrenze verhindert nicht, dass Pakete gesendet werden, um die Echtzeitbedingung zu erfüllen. Pakete, die unter der Echtzeitbedingung gesendet werden, zählen dennoch zur Obergrenze und können daher ein Paket verzögern, das in Zukunft unter der Link-Sharing-Bedingung gesendet wird. Dies ist ein weiterer Unterschied zwischen Echtzeit und Link-Sharing.

Angenommen, A2 und B2 sind beide 128 kbit/s. Macht es einen Unterschied, ob A1 und B1 nur 128 kbit/s Link-Share oder 64 kbit/s Echtzeit und 128 kbit/s Link-Share sind, und wenn ja, welchen Unterschied?

Ja, es macht einen Unterschied. Wie oben erklärt, sind die Latenzen bei Verwendung von Echtzeit garantiert, aber die Verbindung wird nicht fair geteilt (und insbesondere könnte die Klasse unter Bandbreitenmangel leiden) und die Obergrenzen werden nicht durchgesetzt. Wenn Sie Link Share verwenden, ist die Latenz nicht garantiert, aber Link Sharing ist fair, es besteht kein Risiko von Bandbreitenmangel und die Obergrenze wird durchgesetzt. Echtzeit wird immer vor Link Share geprüft, dies bedeutet jedoch nicht unbedingt, dass Link Share ignoriert wird. Das liegt daran, dass Pakete anders gezählt werden. Da der Verlauf in Echtzeit berücksichtigt wird, muss ein Paket möglicherweise nicht die Echtzeitgarantie erfüllen (weil eins aus dem Verlauf gezählt wird), es ist jedoch erforderlich, um Link Share zu erfüllen, da es das historische Paket ignoriert.

Wenn ich die separate Echtzeitkurve verwende, um die Prioritäten von Klassen zu erhöhen, warum brauche ich dann überhaupt „Kurven“? Warum ist Echtzeit kein fester Wert und Link-Share auch kein fester Wert? Warum sind beide Kurven? Die Notwendigkeit von Kurven ist im Originalpapier klar, da es nur ein Attribut dieser Art pro Klasse gibt. Aber wozu brauche ich jetzt, wo ich drei Attribute habe (Echtzeit, Link-Share und Obergrenze), immer noch Kurven für jedes? Warum sollte ich wollen, dass die Kurvenform (nicht die durchschnittliche Bandbreite, sondern ihre Steigungen) für Echtzeit- und Link-Share-Verkehr unterschiedlich ist?

Die Kurve für Echtzeitsteuerungen ermöglicht es Ihnen, eine geringe Latenz für eine bestimmte Verkehrsklasse (z. B. VOIP) gegen eine geringe Latenz für andere Verkehrsklassen (z. B. E-Mail) einzutauschen. Bei der Entscheidung, welches Paket unter der Echtzeitbeschränkung gesendet werden soll, wählt HFSC das Paket aus, das zuerst vollständig gesendet wird. Zur Berechnung wird jedoch nicht die Bandbreite der Verbindung verwendet, sondern die von der Echtzeitkurve zugewiesene Bandbreite. Wenn wir also VOIP- und E-Mail-Pakete gleicher Länge haben und das VOIP-Paket eine konvexe Kurve hat, die eine 10-fache Steigerung gegenüber der konkaven Kurve für E-Mail ergibt, werden 10 VOIP-Pakete vor dem ersten E-Mail-Paket gesendet. Dies geschieht jedoch nur für die Burst-Zeit, die höchstens der Zeit entsprechen sollte, die zum Senden einiger Pakete benötigt wird – also Millisekunden. Danach sollte die VOIP-Kurve abflachen, und VOIP wird keine weitere Steigerung erfahren, es sei denn, es lässt für eine Weile nach (was es sollte, da VOIP eine Anwendung mit geringer Bandbreite ist). Das Nettoergebnis von all dem besteht darin, dass die ersten paar VOIP-Pakete schneller gesendet werden als alles andere, wodurch VOIP eine geringe Latenz aufweist, auf Kosten einer hohen Latenz bei E-Mails.

Wie ich bereits sagte, kann Link Share keine Latenzgarantien geben, da es nicht auf den Verlauf achtet. Für Echtzeitverkehr wie VoIP ist eine absolut zuverlässige Garantie erforderlich. Im Durchschnitt sorgt eine konvexe Link-Share-Kurve jedoch immer noch für eine Latenzsteigerung des Datenverkehrs. Es ist einfach nicht garantiert. Für die meisten Dinge ist das in Ordnung, beispielsweise für Webverkehr über E-Mail.

Laut der wenigen verfügbaren Dokumentation werden Echtzeitkurvenwerte für innere Klassen (Klasse A und B) völlig ignoriert und nur auf Blattklassen (A1, A2, B1, B2) angewendet. Wenn das stimmt, warum legt die ALTQ HFSC-Beispielkonfiguration (suchen Sie nach 3.3 Beispielkonfiguration) dann Echtzeitkurven für innere Klassen fest und behauptet, dass diese die garantierte Rate dieser inneren Klassen festlegen? Ist das nicht völlig sinnlos? (Hinweis: pshare legt die Link-Share-Kurve in ALTQ fest und gleitet die Echtzeitkurve; Sie können dies im Absatz über der Beispielkonfiguration sehen).

Die Dokumentation ist korrekt. Die Hierarchie (und damit die inneren Knoten) hat keinerlei Einfluss auf die Berechnung der Echtzeit. Ich kann Ihnen nicht sagen, warum ALTQ offensichtlich denkt, dass dies der Fall ist.

In einigen Tutorials heißt es, die Summe aller Echtzeitkurven dürfe nicht höher als 80% der Leitungsgeschwindigkeit sein, in anderen Tutorials heißt es, sie dürfe nicht höher als 70% der Leitungsgeschwindigkeit sein. Welches davon ist richtig oder liegen vielleicht beide falsch?

Beides ist falsch. Wenn 70 % oder 80 % Ihres Datenverkehrs strenge Latenzanforderungen haben, die in Echtzeit angegeben werden müssen, können Sie diese mit der von Ihnen verwendeten Verbindung mit ziemlicher Sicherheit nicht erfüllen. Sie benötigen eine schnellere Verbindung.

Die einzige Möglichkeit, auf die Idee zu kommen, dass 80 % des Datenverkehrs in Echtzeit erfolgen sollten, besteht darin, Echtzeit als Prioritätssteigerung zu betrachten. Ja, um Latenzgarantien bereitzustellen, erhöhen Sie tatsächlich die Priorität einiger Pakete. Dies sollte jedoch nur für Millisekunden erfolgen. Das ist alles, was eine Verbindung bewältigen kann und trotzdem die Latenzgarantien bietet.

Es gibt sehr wenig Verkehr, der Latenzgarantien benötigt. VOIP ist eine davon, NTP eine andere. Der Rest sollte alles über Link-Sharing erledigt werden. Wenn Sie möchten, dass das Web schnell ist, machen Sie es schnell, indem Sie ihm den Großteil der Link-Kapazität zuweisen. Diese FreigabeIstlangfristig garantiert. Wenn Sie eine niedrige Latenz (im Durchschnitt) wünschen, geben Sie ihm eine konvexe Kurve unter Link-Sharing.

In einem Tutorial hieß es, Sie sollten die ganze Theorie vergessen. Unabhängig davon, wie die Dinge wirklich funktionieren (Scheduler und Bandbreitenverteilung), stellen Sie sich die drei Kurven gemäß dem folgenden „vereinfachten Gedankenmodell“ vor: Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhält. Link-Share ist die Bandbreite, die diese Klasse vollständig erreichen möchte, aber die Erfüllung kann nicht garantiert werden. Falls es überschüssige Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite angeboten, als zur Erfüllung erforderlich ist, aber sie darf nie mehr verwenden, als die Obergrenze vorgibt. Damit all dies funktioniert, darf die Summe aller Echtzeitbandbreiten nicht über xx % der Leitungsgeschwindigkeit liegen (siehe Frage oben, der Prozentsatz variiert). Frage: Ist dies mehr oder weniger genau oder ein völliges Missverständnis von HSFC?

Dies ist eine gute Beschreibung der Obergrenze. Die Beschreibung von Link Share ist zwar genau richtig, aber irreführend. Es stimmt zwar, dass Link Share keine Garantien für die harte Latenz bietet wie Echtzeit, aber es ist besser darin, der Klasse seine Bandbreite zuzuweisen als seine Konkurrenten wie CBQ und HTB. Wenn man also sagt, dass Link Share „keine Garantien bietet“, legt man einen höheren Standard an, als ihn jeder andere Scheduler bieten kann.

Die Beschreibung von Echtzeit ist zwar genau, aber so irreführend, dass ich sie für falsch halte. Wie der Name schon sagt, besteht der Zweck von Echtzeit nicht darin, eine garantierte Bandbreite bereitzustellen. Es geht darum, eine garantierte Latenz bereitzustellen – d. h. das Paket wird JETZT gesendet und nicht zu einem beliebigen Zeitpunkt später, je nachdem, wie die Verbindung verwendet wird. Der meiste Datenverkehr benötigt keine garantierte Latenz.

Allerdings gibt Echtzeit auch keine perfekten Latenzgarantien. Das könnte es, wenn die Verbindung nicht auch von Link Share verwaltet würde, aber die meisten Benutzer möchten die zusätzliche Flexibilität, die beides mit sich bringt, und das ist nicht umsonst. Echtzeit kann seine Latenzfrist um die Zeit verfehlen, die zum Senden eines MTU-Pakets benötigt wird. (Wenn das passiert, liegt es daran, dass Link Share ein MTU-Paket eingeschmuggelt hat, während Echtzeit die Verbindung im Leerlauf hielt, falls ein Paket mit kurzer Frist empfangen wurde, das sofort gesendet werden musste. Dies ist ein weiterer Unterschied zwischen Link Share und Echtzeit. Um seine Garantien zu bieten, kann Echtzeit die Leitung absichtlich im Leerlauf halten, obwohl Pakete zu senden sind, und so eine Verbindungsauslastung von weniger als 100 % bieten. Link Share nutzt immer 100 % der verfügbaren Kapazität der Verbindung. Im Gegensatz zu Echtzeit kann man sagen, dass es „arbeitserhaltend“ ist.)

Der Grund, warum man sagen kann, dass Real Time feste Latenzgarantien bietet, ist, dass die Verzögerung begrenzt ist. Wenn Sie also versuchen, eine Latenzgarantie von 20 ms für eine 1-Mbit/s-Verbindung anzubieten und Link Share Pakete mit MTU-Größe (1500 Byte) sendet, wissen Sie, dass eines dieser Pakete 12 ms zum Senden benötigt. Wenn Sie Real Time also mitteilen, dass Sie eine Latenz von 8 ms wünschen, können Sie die Frist von 20 ms trotzdem einhalten – mit absoluter Garantie.

Und wenn die obige Annahme wirklich zutrifft, wo ist dann die Priorisierung in diesem Modell? Beispielsweise könnte jede Klasse eine Echtzeitbandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und vielleicht eine Obergrenze haben, aber dennoch haben einige Klassen höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich trotzdem irgendwie priorisieren, sogar unter dem Echtzeitverkehr dieser Klassen. Würde ich nach der Steigung der Kurven priorisieren? Und wenn ja, welche Kurve? Die Echtzeitkurve? Die Link-Share-Kurve? Die Obergrenzenkurve? Alle? Würde ich allen die gleiche Steigung zuweisen oder jeder eine andere, und wie finde ich die richtige Steigung heraus?

Es gibt kein Priorisierungsmodell. Im Ernst. Wenn Sie dem Datenverkehr absolute Priorität einräumen möchten, verwenden Sie pfifo. Dafür ist es gedacht. Aber seien Sie sich auch bewusst: Wenn Sie dem Web-Datenverkehr absolute Priorität vor dem E-Mail-Datenverkehr einräumen, bedeutet das, dass der Web-Datenverkehr die Verbindung überlastet und somit keine E-Mail-Pakete durchkommen.überhaupt. Alle Ihre E-Mail-Verbindungen werden dann unterbrochen.

In Wirklichkeit will niemand diese Art der Priorisierung. Was sie wollen, ist das, was HFSC bietet. Wenn Sie tatsächlich Echtzeitverkehr haben, bietet HFSC das. Aber das ist alles. Im Übrigen können Sie mit HFSC sagen: „Bei einer überlasteten Verbindung 90 % dem Web zuweisen und E-Mails mit 10 % durchsickern lassen, und oh, das eine oder andere DNS-Paket schnell senden, aber nicht zulassen, dass mich jemand damit unter Beschuss nimmt.“

Question 2

Sie könnten die Kurven mit unterschiedlichen Namen definieren:

rt, Echtzeitkurve, Bandbreiten-/Verzögerungsgarantie.
ls, Link-Share-Kurve, Bandbreiten-/Verzögerungs-Sharing (basierend auf der Konfiguration benachbarter Blätter)
ul, Obergrenzkurve, maximale Bandbreite/Verzögerung, die erreicht werden kann.

Wozu brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2 haben alle eine Link-Share von 128 kbit/s (keine Echtzeitkurve für beide), dann bekommt jeder von ihnen 128 kbit/s, wenn die Wurzel 512 kbit/s zu verteilen hat (und A und B sind natürlich beide 256 kbit/s), richtig? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit/s geben? Wozu wäre das gut? Um diesen beiden eine höhere Priorität zu geben? Laut Originalpapier kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende, darum geht es ja schließlich bei HFSC. Indem ich beiden Klassen eine Kurve von [256 kbit/s 20 ms 128 kbit/s] gebe, haben beide automatisch die doppelte Priorität als A2 und B2 (bekommen im Durchschnitt trotzdem nur 128 kbit/s)

Wenn Sie in HFSC eine Definition nur mit Raten vornehmen, wird „dmax“ automatisch auf 0 gesetzt. Das bedeutet im Grunde, dass die Verzögerung nicht berücksichtigt wird. Eine gute HFSC-Konfiguration sollte sowohl die Bandbreite als auch die Verzögerungsgrenzen enthalten, die Sie für Ihre Klasse verwenden möchten, da der Algorithmus sonst nicht genau herausfinden kann, wie viel Priorität eine Klasse erhalten soll.

Wenn Sie Paketen Priorität einräumen, muss die Priorität anderer Pakete verringert werden. Basierend auf den Werten „dmax“ und „rate“ werden alle Klassen mithilfe virtueller Timer gemultiplext. Weitere Informationen finden Sie in tc-hfsc(7).

Zählt die Echtzeitbandbreite zur Link-Share-Bandbreite? Wenn z. B. A1 und B1 beide nur 64 kbit/s Echtzeit- und 64 kbit/s Link-Share-Bandbreite haben, bedeutet das, dass ihr Link-Share-Bedarf ebenfalls erfüllt ist, sobald ihnen 64 kbit/s in Echtzeit zur Verfügung gestellt werden (sie erhalten möglicherweise zusätzliche Bandbreite, aber ignorieren wir das für eine Sekunde) oder bedeutet das, dass sie weitere 64 kbit/s über Link-Share erhalten? Hat also jede Klasse einen Bandbreiten-„Bedarf“ von Echtzeit plus Link-Share? Oder hat eine Klasse nur dann einen höheren Bedarf als die Echtzeitkurve, wenn die Link-Share-Kurve höher ist als die Echtzeitkurve (der aktuelle Link-Share-Bedarf ist gleich dem angegebenen Link-Share-Bedarf abzüglich der Echtzeitbandbreite, die dieser Klasse bereits zur Verfügung gestellt wurde)?

Wenn der Fluss die Grenzen der Link-Share-Definition der Klasse nicht überschreitet, wird die Echtzeitkurve nie verwendet. Durch die Definition einer Echtzeitkurve können Sie in diesem Fall beispielsweise ein bestimmtes „dmax“ garantieren.

Wenn Ihre Link-Share-Definitionen fehlerfrei sind, benötigen Sie keine Echtzeitkurven. Sie könnten einfach Servicekurven (sc) definieren, aber das würde den Konfigurationsaufwand erhöhen.

Gilt die Obergrenzenkurve auch für Echtzeit, nur für Link-Share oder vielleicht für beides? Einige Tutorials sagen das eine, andere das andere. Einige behaupten sogar, die Obergrenze sei das Maximum für Echtzeitbandbreite + Link-Share-Bandbreite? Was ist die Wahrheit?

Die Obergrenzenkurve Ihrer Klasse wird nur auf den Link-Share angewendet. Wenn Sie eine Obergrenzenkurve definieren, MÜSSEN Sie eine Link-Share-Kurve definieren. Die Obergrenzenkurve der übergeordneten Klassen wird jedoch weiterhin angewendet.

Angenommen, A2 und B2 sind beide 128 kbit/s. Macht es einen Unterschied, ob A1 und B1 nur 128 kbit/s Link-Share oder 64 kbit/s Echtzeit und 128 kbit/s Link-Share sind, und wenn ja, welchen Unterschied?

Es gibt einen kleinen Unterschied, wenn z. B. A2 = 0 kbits/s und B2 = 256 kbits/s. Dann ist die virtuelle Zeit für A2 maximal. Wenn Pakete in A2 klassifiziert werden, werden sie sofort verarbeitet. Die Echtzeitkurve von B2 stellt jedoch immer noch sicher, dass mindestens 64 kbit/s übertragen werden können.

Wenn ich die separate Echtzeitkurve verwende, um die Prioritäten von Klassen zu erhöhen, warum brauche ich dann überhaupt „Kurven“? Warum ist Echtzeit kein fester Wert und Link-Share auch kein fester Wert? Warum sind beide Kurven? Die Notwendigkeit von Kurven ist im Originalpapier klar, da es nur ein Attribut dieser Art pro Klasse gibt. Aber wozu brauche ich jetzt, wo ich drei Attribute habe (Echtzeit, Link-Share und Obergrenze), immer noch Kurven für jedes? Warum sollte ich wollen, dass die Kurvenform (nicht die durchschnittliche Bandbreite, sondern ihre Steigungen) für Echtzeit- und Link-Share-Verkehr unterschiedlich ist?

Echtzeitkurven teilen den Datenverkehr zwischen benachbarten Blättern nicht, Link-Share-Kurven tun dies.

Laut der wenigen verfügbaren Dokumentation werden Echtzeitkurvenwerte für innere Klassen (Klasse A und B) völlig ignoriert und nur auf Blattklassen (A1, A2, B1, B2) angewendet. Wenn das stimmt, warum legt die ALTQ HFSC-Beispielkonfiguration (suchen Sie nach 3.3 Beispielkonfiguration) dann Echtzeitkurven für innere Klassen fest und behauptet, dass diese die garantierte Rate dieser inneren Klassen festlegen? Ist das nicht völlig sinnlos? (Hinweis: pshare legt die Link-Share-Kurve in ALTQ fest und gleitet die Echtzeitkurve; Sie können dies im Absatz über der Beispielkonfiguration sehen).

Es stimmt, dass Echtzeitkurven für innere Klassen ignoriert werden, sie werden nur auf Blattklassen angewendet. Die für diese inneren Klassen definierten Echtzeitkurven werden jedoch für Berechnungen für die Blattklassen berücksichtigt.

In einigen Tutorials heißt es, die Summe aller Echtzeitkurven dürfe nicht höher als 80% der Leitungsgeschwindigkeit sein, in anderen Tutorials heißt es, sie dürfe nicht höher als 70% der Leitungsgeschwindigkeit sein. Welches davon ist richtig oder liegen vielleicht beide falsch?

Was sie meinen, ist: Sie können nicht den gesamten Verkehr priorisieren ... Wenn Sie Paketen Priorität einräumen, muss die Priorität anderer Pakete verringert werden. Wenn Sie zu viel garantieren, wird der Algorithmus sinnlos. Definieren Sie Klassen, die Priorität erhalten, und definieren Sie Klassen, die darunter leiden können.

In einem Tutorial hieß es, Sie sollten die ganze Theorie vergessen. Unabhängig davon, wie die Dinge wirklich funktionieren (Scheduler und Bandbreitenverteilung), stellen Sie sich die drei Kurven gemäß dem folgenden „vereinfachten Gedankenmodell“ vor: Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhält. Link-Share ist die Bandbreite, die diese Klasse vollständig erreichen möchte, aber die Erfüllung kann nicht garantiert werden. Falls es überschüssige Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite angeboten, als zur Erfüllung erforderlich ist, aber sie darf nie mehr verwenden, als die Obergrenze vorgibt. Damit all dies funktioniert, darf die Summe aller Echtzeitbandbreiten nicht über xx % der Leitungsgeschwindigkeit liegen (siehe Frage oben, der Prozentsatz variiert). Frage: Ist dies mehr oder weniger genau oder ein völliges Missverständnis von HSFC?

Das ist richtig.

Und wenn die obige Annahme wirklich zutrifft, wo ist dann die Priorisierung in diesem Modell? Beispielsweise könnte jede Klasse eine Echtzeitbandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und vielleicht eine Obergrenze haben, aber dennoch haben einige Klassen höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich trotzdem irgendwie priorisieren, sogar unter dem Echtzeitverkehr dieser Klassen. Würde ich nach der Steigung der Kurven priorisieren? Und wenn ja, welche Kurve? Die Echtzeitkurve? Die Link-Share-Kurve? Die Obergrenzenkurve? Alle? Würde ich allen die gleiche Steigung zuweisen oder jeder eine andere, und wie finde ich die richtige Steigung heraus?

Der Unterschied zwischen HFSC und HTB besteht beispielsweise darin, dass Sie bei HFSC genau festlegen können, wie viel Priorität Sie wünschen. Dies erreichen Sie, indem Sie mit dem Wert „dmax“ minimale und maximale Grenzen definieren.

Answer

Sie könnten die Kurven mit unterschiedlichen Namen definieren:

rt, Echtzeitkurve, Bandbreiten-/Verzögerungsgarantie.
ls, Link-Share-Kurve, Bandbreiten-/Verzögerungs-Sharing (basierend auf der Konfiguration benachbarter Blätter)
ul, Obergrenzkurve, maximale Bandbreite/Verzögerung, die erreicht werden kann.

Wozu brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2 haben alle eine Link-Share von 128 kbit/s (keine Echtzeitkurve für beide), dann bekommt jeder von ihnen 128 kbit/s, wenn die Wurzel 512 kbit/s zu verteilen hat (und A und B sind natürlich beide 256 kbit/s), richtig? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit/s geben? Wozu wäre das gut? Um diesen beiden eine höhere Priorität zu geben? Laut Originalpapier kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende, darum geht es ja schließlich bei HFSC. Indem ich beiden Klassen eine Kurve von [256 kbit/s 20 ms 128 kbit/s] gebe, haben beide automatisch die doppelte Priorität als A2 und B2 (bekommen im Durchschnitt trotzdem nur 128 kbit/s)

Wenn Sie in HFSC eine Definition nur mit Raten vornehmen, wird „dmax“ automatisch auf 0 gesetzt. Das bedeutet im Grunde, dass die Verzögerung nicht berücksichtigt wird. Eine gute HFSC-Konfiguration sollte sowohl die Bandbreite als auch die Verzögerungsgrenzen enthalten, die Sie für Ihre Klasse verwenden möchten, da der Algorithmus sonst nicht genau herausfinden kann, wie viel Priorität eine Klasse erhalten soll.

Wenn Sie Paketen Priorität einräumen, muss die Priorität anderer Pakete verringert werden. Basierend auf den Werten „dmax“ und „rate“ werden alle Klassen mithilfe virtueller Timer gemultiplext. Weitere Informationen finden Sie in tc-hfsc(7).

Zählt die Echtzeitbandbreite zur Link-Share-Bandbreite? Wenn z. B. A1 und B1 beide nur 64 kbit/s Echtzeit- und 64 kbit/s Link-Share-Bandbreite haben, bedeutet das, dass ihr Link-Share-Bedarf ebenfalls erfüllt ist, sobald ihnen 64 kbit/s in Echtzeit zur Verfügung gestellt werden (sie erhalten möglicherweise zusätzliche Bandbreite, aber ignorieren wir das für eine Sekunde) oder bedeutet das, dass sie weitere 64 kbit/s über Link-Share erhalten? Hat also jede Klasse einen Bandbreiten-„Bedarf“ von Echtzeit plus Link-Share? Oder hat eine Klasse nur dann einen höheren Bedarf als die Echtzeitkurve, wenn die Link-Share-Kurve höher ist als die Echtzeitkurve (der aktuelle Link-Share-Bedarf ist gleich dem angegebenen Link-Share-Bedarf abzüglich der Echtzeitbandbreite, die dieser Klasse bereits zur Verfügung gestellt wurde)?

Wenn der Fluss die Grenzen der Link-Share-Definition der Klasse nicht überschreitet, wird die Echtzeitkurve nie verwendet. Durch die Definition einer Echtzeitkurve können Sie in diesem Fall beispielsweise ein bestimmtes „dmax“ garantieren.

Wenn Ihre Link-Share-Definitionen fehlerfrei sind, benötigen Sie keine Echtzeitkurven. Sie könnten einfach Servicekurven (sc) definieren, aber das würde den Konfigurationsaufwand erhöhen.

Gilt die Obergrenzenkurve auch für Echtzeit, nur für Link-Share oder vielleicht für beides? Einige Tutorials sagen das eine, andere das andere. Einige behaupten sogar, die Obergrenze sei das Maximum für Echtzeitbandbreite + Link-Share-Bandbreite? Was ist die Wahrheit?

Die Obergrenzenkurve Ihrer Klasse wird nur auf den Link-Share angewendet. Wenn Sie eine Obergrenzenkurve definieren, MÜSSEN Sie eine Link-Share-Kurve definieren. Die Obergrenzenkurve der übergeordneten Klassen wird jedoch weiterhin angewendet.

Angenommen, A2 und B2 sind beide 128 kbit/s. Macht es einen Unterschied, ob A1 und B1 nur 128 kbit/s Link-Share oder 64 kbit/s Echtzeit und 128 kbit/s Link-Share sind, und wenn ja, welchen Unterschied?

Es gibt einen kleinen Unterschied, wenn z. B. A2 = 0 kbits/s und B2 = 256 kbits/s. Dann ist die virtuelle Zeit für A2 maximal. Wenn Pakete in A2 klassifiziert werden, werden sie sofort verarbeitet. Die Echtzeitkurve von B2 stellt jedoch immer noch sicher, dass mindestens 64 kbit/s übertragen werden können.

Wenn ich die separate Echtzeitkurve verwende, um die Prioritäten von Klassen zu erhöhen, warum brauche ich dann überhaupt „Kurven“? Warum ist Echtzeit kein fester Wert und Link-Share auch kein fester Wert? Warum sind beide Kurven? Die Notwendigkeit von Kurven ist im Originalpapier klar, da es nur ein Attribut dieser Art pro Klasse gibt. Aber wozu brauche ich jetzt, wo ich drei Attribute habe (Echtzeit, Link-Share und Obergrenze), immer noch Kurven für jedes? Warum sollte ich wollen, dass die Kurvenform (nicht die durchschnittliche Bandbreite, sondern ihre Steigungen) für Echtzeit- und Link-Share-Verkehr unterschiedlich ist?

Echtzeitkurven teilen den Datenverkehr zwischen benachbarten Blättern nicht, Link-Share-Kurven tun dies.

Laut der wenigen verfügbaren Dokumentation werden Echtzeitkurvenwerte für innere Klassen (Klasse A und B) völlig ignoriert und nur auf Blattklassen (A1, A2, B1, B2) angewendet. Wenn das stimmt, warum legt die ALTQ HFSC-Beispielkonfiguration (suchen Sie nach 3.3 Beispielkonfiguration) dann Echtzeitkurven für innere Klassen fest und behauptet, dass diese die garantierte Rate dieser inneren Klassen festlegen? Ist das nicht völlig sinnlos? (Hinweis: pshare legt die Link-Share-Kurve in ALTQ fest und gleitet die Echtzeitkurve; Sie können dies im Absatz über der Beispielkonfiguration sehen).

Es stimmt, dass Echtzeitkurven für innere Klassen ignoriert werden, sie werden nur auf Blattklassen angewendet. Die für diese inneren Klassen definierten Echtzeitkurven werden jedoch für Berechnungen für die Blattklassen berücksichtigt.

In einigen Tutorials heißt es, die Summe aller Echtzeitkurven dürfe nicht höher als 80% der Leitungsgeschwindigkeit sein, in anderen Tutorials heißt es, sie dürfe nicht höher als 70% der Leitungsgeschwindigkeit sein. Welches davon ist richtig oder liegen vielleicht beide falsch?

Was sie meinen, ist: Sie können nicht den gesamten Verkehr priorisieren ... Wenn Sie Paketen Priorität einräumen, muss die Priorität anderer Pakete verringert werden. Wenn Sie zu viel garantieren, wird der Algorithmus sinnlos. Definieren Sie Klassen, die Priorität erhalten, und definieren Sie Klassen, die darunter leiden können.

In einem Tutorial hieß es, Sie sollten die ganze Theorie vergessen. Unabhängig davon, wie die Dinge wirklich funktionieren (Scheduler und Bandbreitenverteilung), stellen Sie sich die drei Kurven gemäß dem folgenden „vereinfachten Gedankenmodell“ vor: Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhält. Link-Share ist die Bandbreite, die diese Klasse vollständig erreichen möchte, aber die Erfüllung kann nicht garantiert werden. Falls es überschüssige Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite angeboten, als zur Erfüllung erforderlich ist, aber sie darf nie mehr verwenden, als die Obergrenze vorgibt. Damit all dies funktioniert, darf die Summe aller Echtzeitbandbreiten nicht über xx % der Leitungsgeschwindigkeit liegen (siehe Frage oben, der Prozentsatz variiert). Frage: Ist dies mehr oder weniger genau oder ein völliges Missverständnis von HSFC?

Das ist richtig.

Und wenn die obige Annahme wirklich zutrifft, wo ist dann die Priorisierung in diesem Modell? Beispielsweise könnte jede Klasse eine Echtzeitbandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und vielleicht eine Obergrenze haben, aber dennoch haben einige Klassen höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich trotzdem irgendwie priorisieren, sogar unter dem Echtzeitverkehr dieser Klassen. Würde ich nach der Steigung der Kurven priorisieren? Und wenn ja, welche Kurve? Die Echtzeitkurve? Die Link-Share-Kurve? Die Obergrenzenkurve? Alle? Würde ich allen die gleiche Steigung zuweisen oder jeder eine andere, und wie finde ich die richtige Steigung heraus?

Der Unterschied zwischen HFSC und HTB besteht beispielsweise darin, dass Sie bei HFSC genau festlegen können, wie viel Priorität Sie wünschen. Dies erreichen Sie, indem Sie mit dem Wert „dmax“ minimale und maximale Grenzen definieren.

Question 3

Zum Schluss noch eine Anleitung, die die meisten Unstimmigkeiten zu erklären scheint und auch zeigt, wie sich die aktuelle Implementierung vom Originaldokument unterscheidet:

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

Diesem Leitfaden zufolge sind viele andere Leitfäden und Forenbeiträge zu HFSC völliger Unsinn. Dies zeigt nur, wie kompliziert HFSC ist, da viele Leute, die sich als Experten ausgeben und vorgeben, HFSC vollständig zu verstehen, in Wirklichkeit nur über Teilkenntnisse verfügen und falsche Aussagen machen, die auf einem Missverständnis des Konzepts und des Zusammenspiels all dieser Einstellungen beruhen.

Ich glaube, ich werde HFSC endgültig aufgeben. Wenn Sie Ihr HFSC-Setup richtig hinbekommen, ist das vielleicht die beste QoS, die Sie bekommen können, aber die Wahrscheinlichkeit, dass Sie es komplett vermasseln, ist viel höher als die Wahrscheinlichkeit, dass Sie Erfolg haben.

Answer

Zum Schluss noch eine Anleitung, die die meisten Unstimmigkeiten zu erklären scheint und auch zeigt, wie sich die aktuelle Implementierung vom Originaldokument unterscheidet:

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

Diesem Leitfaden zufolge sind viele andere Leitfäden und Forenbeiträge zu HFSC völliger Unsinn. Dies zeigt nur, wie kompliziert HFSC ist, da viele Leute, die sich als Experten ausgeben und vorgeben, HFSC vollständig zu verstehen, in Wirklichkeit nur über Teilkenntnisse verfügen und falsche Aussagen machen, die auf einem Missverständnis des Konzepts und des Zusammenspiels all dieser Einstellungen beruhen.

Ich glaube, ich werde HFSC endgültig aufgeben. Wenn Sie Ihr HFSC-Setup richtig hinbekommen, ist das vielleicht die beste QoS, die Sie bekommen können, aber die Wahrscheinlichkeit, dass Sie es komplett vermasseln, ist viel höher als die Wahrscheinlichkeit, dass Sie Erfolg haben.

Question 4

Wenn Sie die ursprünglichen Autoren nicht erreichen können, würde ich als Nächstes Folgendes versuchen:

Gehen Sie in den Quellcode des Linux-Kernels und suchen Sie nach C-Dateien, die das „TC Scheduling Framework“ implementieren.
Sehen Sie sich die Kopfzeile an und finden Sie den Autor des Codes.
Senden Sie den Programmierern des „TC Scheduling Framework“ eine E-Mail und bitten Sie sie um Literatur zu ihrer Implementierung.

Sehen Sie sich auch andere neuere Arbeiten an, die diese zitieren. Möglicherweise gibt es neuere Arbeiten, die die Forschung auf diesem Gebiet fortführen und möglicherweise mehr Informationen zu Ihren Fragen enthalten.

Answer

Wenn Sie die ursprünglichen Autoren nicht erreichen können, würde ich als Nächstes Folgendes versuchen:

Gehen Sie in den Quellcode des Linux-Kernels und suchen Sie nach C-Dateien, die das „TC Scheduling Framework“ implementieren.
Sehen Sie sich die Kopfzeile an und finden Sie den Autor des Codes.
Senden Sie den Programmierern des „TC Scheduling Framework“ eine E-Mail und bitten Sie sie um Literatur zu ihrer Implementierung.

Sehen Sie sich auch andere neuere Arbeiten an, die diese zitieren. Möglicherweise gibt es neuere Arbeiten, die die Forschung auf diesem Gebiet fortführen und möglicherweise mehr Informationen zu Ihren Fragen enthalten.

Versteht irgendjemand wirklich, wie die HFSC-Planung in Linux/BSD funktioniert?

Antwort1

Antwort2

Antwort3

Antwort4

verwandte Informationen