Versteht jemand wirklich, wie die HFSC-Planung unter Linux / BSD funktioniert?

Ich habe das Original SIGCOMM '97 PostScript-Papier über HFSC gelesen , es ist sehr technisch, aber ich verstehe das Grundkonzept. Anstelle einer linearen Servicekurve (wie bei so ziemlich jedem anderen Scheduling-Algorithmus) können Sie eine konvexe oder konkave Servicekurve angeben und so Bandbreite und Verzögerung entkoppeln. Obwohl in diesem Artikel die Art der verwendeten Planungsalgorithmen erwähnt wird (Echtzeit und Link-Share), wird immer nur EINE Kurve pro Planungsklasse erwähnt (die Entkopplung erfolgt durch Angabe dieser Kurve, dafür wird nur eine Kurve benötigt) ).

Jetzt wurde HFSC für BSD (OpenBSD, FreeBSD usw.) mit dem ALTQ-Scheduling-Framework und Linux mit dem TC-Scheduling-Framework (Teil von iproute2) implementiert . Beide Implementierungen fügten zwei zusätzliche Servicekurven hinzu, die NICHT im Originalpapier enthalten waren! Eine Echtzeit-Servicekurve und eine Obergrenzen-Servicekurve. Bitte beachten Sie auch hier, dass das Originalpapier zwei Planungsalgorithmen (Echtzeit und Link-Share) erwähnt, in diesem Papier jedoch beide mit einer einzigen Servicekurve arbeiten. Es hat nie zwei unabhängige Servicekurven für eine gegeben, wie Sie sie derzeit in BSD und Linux finden.

Schlimmer noch, einige Versionen von ALTQ scheinen HSFC eine zusätzliche Warteschlangenpriorität hinzuzufügen (im Originalpapier gibt es auch keine Priorität). Ich habe mehrere BSD-HowTos gefunden, die diese Prioritätseinstellung erwähnen (obwohl die Manpage der neuesten ALTQ-Version keinen solchen Parameter für HSFC kennt, existiert sie offiziell nicht einmal).

Dies alles macht die HFSC-Planung noch komplexer als der im Originalartikel beschriebene Algorithmus, und im Internet gibt es unzählige Tutorials, die sich oft widersprechen, wobei eines das Gegenteil des anderen behauptet. Dies ist wahrscheinlich der Hauptgrund, warum niemand wirklich zu verstehen scheint, wie die HFSC-Planung wirklich funktioniert. Bevor ich meine Fragen stellen kann, benötigen wir ein Beispielsetup. Ich werde ein sehr einfaches verwenden, wie im Bild unten zu sehen:

Alternativtext http://f.imagehost.org/0177/hfsc-test-setup.png

Hier sind einige Fragen, die ich nicht beantworten kann, weil sich die Tutorials widersprechen:

1. Wofür brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2 sind alle 128 kbit / s Link-Share (keine Echtzeitkurve für eine), dann erhält jede von diesen 128 kbit / s, wenn die Wurzel 512 kbit / s zu verteilen hat (und A und B sind natürlich beide 256 kbit / s, oder? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit / s geben? Wofür wäre das gut? Um diesen beiden eine höhere Priorität einzuräumen? Laut Originalpapier kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende , darum geht es doch bei HFSC. Wenn Sie beiden Klassen eine Kurve von [256 kbit / s, 20 ms, 128 kbit / s] zuweisen, haben beide automatisch die doppelte Priorität als A2 und B2 (im Durchschnitt immer noch nur 128 kbit / s).

2. Zählt die Echtzeitbandbreite zur Link-Share-Bandbreite? Wenn z. B. A1 und B1 beide nur eine Link-Share-Bandbreite von 64 kbit / s in Echtzeit und 64 kbit / s in Echtzeit haben, ist möglicherweise auch ihre Link-Share-Anforderung erfüllt Erhalten Sie überschüssige Bandbreite, aber lassen Sie uns das für eine Sekunde ignorieren) oder bedeutet das, dass sie weitere 64 kbit / s über Link-Share erhalten? Hat also jede Klasse einen "Bandbreitenbedarf" von Echtzeit plus Link-Share? Oder hat eine Klasse nur dann eine höhere Anforderung als die Echtzeitkurve, wenn die Link-Share-Kurve höher ist als die Echtzeitkurve (die aktuelle Link-Share-Anforderung entspricht der angegebenen Link-Share-Anforderung abzüglich der dafür bereits bereitgestellten Echtzeitbandbreite) Klasse)?

3. Wird die obere Grenzkurve auch auf Echtzeit angewendet, nur auf Link-Share oder vielleicht auf beide? Einige Tutorials sagen den einen Weg, andere den anderen. Einige behaupten sogar, die Obergrenze sei das Maximum für Echtzeitbandbreite + Link-Share-Bandbreite? Was ist die Wahrheit?

4. Angenommen, A2 und B2 sind beide 128 kbit / s, macht es keinen 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 , welcher Unterschied?

5. Warum brauche ich überhaupt "Kurven", wenn ich die separate Echtzeitkurve verwende, um die Prioritäten von Klassen zu erhöhen? Warum ist Echtzeit kein Pauschalwert und Link-Sharing auch ein Pauschalwert? Warum sind beide Kurven? Die Notwendigkeit von Kurven ist im Originalpapier klar, da es nur ein Attribut dieser Art pro Klasse gibt. Aber jetzt, mit drei Attributen (Echtzeit, Link-Freigabe und Obergrenze), wofür benötige ich noch Kurven für jedes Attribut? Warum soll ich die Kurven Form (nicht die durchschnittliche Bandbreite, aber ihre Pisten) , anders zu sein für die Echtzeit und Link-Sharing - Verkehr?

6. Gemäß der wenigen verfügbaren Dokumentation werden Echtzeitkurvenwerte für innere Klassen (Klasse A und B) vollständig ignoriert. Sie gelten nur für Blattklassen (A1, A2, B1, B2). Wenn dies zutrifft, warum legt die ALTQ HFSC-Beispielkonfiguration (Suche nach 3.3-Beispielkonfiguration ) 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 berechnet die Echtzeitkurve. Sie können dies im Abschnitt über der Beispielkonfiguration sehen.)

7. Einige Tutorials sagen, dass die Summe aller Echtzeitkurven nicht höher als 80% der Liniengeschwindigkeit sein darf, andere sagen, dass sie nicht höher als 70% der Liniengeschwindigkeit sein darf. Welches ist richtig oder sind sie vielleicht beide falsch?

8. Ein Tutorial sagte, Sie sollen die ganze Theorie vergessen. Unabhängig davon, wie die Dinge wirklich funktionieren (Planer und Bandbreitenverteilung), stellen Sie sich die drei Kurven nach dem folgenden "vereinfachten Denkmodell" vor: Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhält. Link-Share ist die Bandbreite, mit der diese Klasse vollständig zufrieden sein möchte, aber die Zufriedenheit kann nicht garantiert werden. Falls es zu viel Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite angeboten, als sie benötigt, um zufrieden zu sein, aber sie darf niemals mehr als die angegebene Obergrenze verwenden. Damit dies funktioniert, darf die Summe aller Echtzeit-Bandbreiten nicht über xx% der Leitungsgeschwindigkeit liegen (siehe Frage oben, der Prozentsatz variiert). Frage: Ist das mehr oder weniger genau oder ein totales Missverständnis von HSFC?

9. Und wenn die obige Annahme wirklich zutreffend ist, wo befindet sich die Priorisierung in diesem Modell? Beispielsweise hat jede Klasse möglicherweise eine Echtzeitbandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und möglicherweise eine Obergrenze. Einige Klassen haben jedoch höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich immer noch Prioritäten setzen, selbst im Echtzeitverkehr dieser Klassen. Würde ich nach der Steigung der Kurven priorisieren? Und wenn ja, welche Kurve? Die Echtzeitkurve? Die Link-Share-Kurve? Die obere Grenzkurve? Alle von ihnen? Würde ich allen die gleiche oder eine andere Steigung geben und wie finde ich die richtige Steigung heraus?

Ich habe immer noch nicht die Hoffnung verloren, dass es zumindest eine Hand voll Menschen auf dieser Welt gibt, die HFSC wirklich verstanden haben und in der Lage sind, all diese Fragen genau zu beantworten. Und das zu tun, ohne sich in den Antworten zu widersprechen, wäre wirklich nett ;-)

Das Lesen der Zeitungen über HFSC und seine Cousins ​​ist kein guter Weg, dies zu verstehen. Das Hauptziel des HFSC-Papiers ist es, einen strengen mathematischen Beweis für seine Behauptungen zu liefern und nicht zu erklären, wie es funktioniert. In der Tat können Sie anhand des HFSC-Papiers allein nicht verstehen, wie es funktioniert. Sie müssen auch die Papiere lesen, auf die es verweist. Wenn Sie ein Problem mit der Behauptung oder ihren Nachweisen haben, ist es möglicherweise eine gute Idee, sich an die Verfasser der Beiträge zu wenden, da sie sonst zweifelsohne daran interessiert sind, von Ihnen zu hören.

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

Wofür brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2 sind alle 128 kbit / s Link-Share (keine Echtzeitkurve für eine), dann erhält jede von diesen 128 kbit / s, wenn die Wurzel 512 kbit / s zu verteilen hat (und A und B sind natürlich beide 256 kbit / s, oder? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit / s geben? Wofür wäre das gut? Um diesen beiden eine höhere Priorität einzuräumen? Laut Originalpapier kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende, darum geht es doch bei HFSC. Wenn Sie beiden Klassen eine Kurve von [256 kbit / s, 20 ms, 128 kbit / s] zuweisen, haben beide automatisch die doppelte Priorität als A2 und B2 (im Durchschnitt immer noch nur 128 kbit / s).

Die Echtzeitkurve und die Link-Sharing-Kurve werden auf unterschiedliche Weise ausgewertet. Die Echtzeitkurve berücksichtigt, was eine Klasse in ihrer gesamten Geschichte getan hat. Dies muss erfolgen, um eine genaue Zuordnung von Bandbreite und Latenz zu gewährleisten. Der Nachteil ist, dass es nicht das ist, was die meisten Menschen intuitiv als fair ansehen . Wenn eine Klasse in Echtzeit Bandbreite ausleiht, wenn niemand dies wünscht, wird dies bestraft, wenn jemand anderes es später wieder wünscht. Dies bedeutet, dass eine Klasse unter der Echtzeitgarantie für einen langen Zeitraum keine Bandbreite erhalten kann, da sie diese früher verwendet hat, als niemand dies wollte.

Die gemeinsame Nutzung von Links ist insofern fair, als sie eine Klasse nicht für die Nutzung der freien Bandbreite benachteiligt. Dies bedeutet jedoch, dass es keine starken Latenzgarantien geben kann.

Die Trennung von Link-Sharing von der Bereitstellung von Latenzgarantien ist das Neue, was HFSC auf den Tisch bringt, und das Papier sagt dies im ersten Satz: In diesem Papier untersuchen wir hierarchische Ressourcenmanagementmodelle und -algorithmen, die sowohl Link-Sharing als auch Garantien unterstützen Echtzeitdienste mit entkoppelter Verzögerung (Priorität) und Bandbreitenzuweisung. Das Schlüsselwort in diesem Satz ist entkoppelt. Übersetzt bedeutet dies, dass Sie erwarten, dass Sie angeben, wie nicht genutzte Bandbreite mit ls geteilt werden soll, und angeben, welche Echtzeitgarantien (auch Latenzgarantien genannt) mit rt benötigt werden. Die beiden sind orthogonal.

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

Ja. Im HFSC-Papier definieren sie die Bandbreite in Bezug auf das, was die Klasse gesendet hat, seit die Klasse einen Rückstand aufweist (dh Pakete warten darauf, gesendet zu werden). Der einzige Unterschied zwischen "rt" und "ls" besteht darin, dass "rt" jedes Mal nach vorn schaut, wenn die Klasse überlastet wurde, und die niedrigste garantierte Bandbreite aus dieser Menge berechnet, während "link sharing" nur nach dem letzten Mal aussieht, als die Klasse überlastet wurde. Rt berücksichtigt also mehr Bytes als ls, aber jedes Byte, das ls berücksichtigt, wird auch von rt berücksichtigt.

Wird die obere Grenzkurve auch auf Echtzeit angewendet, nur auf Link-Share oder vielleicht auf beide?

Die Obergrenze verhindert nicht, dass Pakete gesendet werden, um die Echtzeitbedingung zu erfüllen. Unter der Echtzeitbedingung gesendete Pakete zählen immer noch bis zur Obergrenze und können daher ein Paket, das unter der Bedingung der gemeinsamen Nutzung von Verbindungen gesendet wird, in Zukunft verzögern. Dies ist ein weiterer Unterschied zwischen Echtzeit- und Link-Freigabe.

Angenommen, A2 und B2 sind beide 128 kbit / s, macht es keinen 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 , welcher Unterschied?

Ja, das macht einen Unterschied. Wie oben erläutert, werden bei Verwendung von Echtzeit die Latenzen garantiert, aber die Verbindung wird nicht fair geteilt (und insbesondere die Klasse kann unter Bandbreitenmangel leiden), und die Obergrenzen werden nicht durchgesetzt. Wenn Sie die Linkfreigabe verwenden, ist die Latenz nicht garantiert, aber die Linkfreigabe ist fair, es besteht keine Gefahr des Ausfalls und die Obergrenze wird durchgesetzt. Die Echtzeit wird immer vor der Linkfreigabe überprüft, dies bedeutet jedoch nicht, dass die Linkfreigabe ignoriert wird. Das liegt daran, dass Pakete unterschiedlich gezählt werden. Da die Historie in Echtzeit betrachtet wird, wird ein Paket möglicherweise nicht benötigt, um die Echtzeitgarantie zu erfüllen (da eines aus der Historie gezählt wird), sondern um die Link-Freigabe zu erfüllen, da das historische Paket ignoriert wird.

Warum brauche ich überhaupt "Kurven", wenn ich die separate Echtzeitkurve verwende, um die Prioritäten von Klassen zu erhöhen? Warum ist Echtzeit kein Pauschalwert und Link-Sharing auch ein Pauschalwert? Warum sind beide Kurven? Die Notwendigkeit von Kurven ist im Originalpapier klar, da es nur ein Attribut dieser Art pro Klasse gibt. Aber jetzt, mit drei Attributen (Echtzeit, Link-Freigabe und Obergrenze), wofür benötige ich noch Kurven für jedes Attribut? Warum sollte die Kurvenform (nicht die durchschnittliche Bandbreite, sondern die Steigung) für Echtzeit- und Link-Share-Verkehr unterschiedlich sein?

Mit der Kurve für die Echtzeitsteuerung können Sie die enge Latenz für eine bestimmte Verkehrsklasse (z. B. VOIP) gegen eine geringe Latenz für andere Verkehrsklassen (z. B. E-Mail) austauschen. Bei der Entscheidung, welches Paket unter der Echtzeitbeschränkung gesendet werden soll, wählt HFSC das Paket, das zuerst gesendet wird. Es wird jedoch nicht die Bandbreite der Verbindung verwendet, um dies zu berechnen, sondern die von der Echtzeitkurve zugewiesene Bandbreite. Wenn wir also VOIP- und E-Mail-Pakete mit der gleichen Länge haben und das VOIP-Paket eine konvexe Kurve hat, die einen 10-fachen Anstieg 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 einige Millisekunden betragen sollte, um ein paar Pakete zu senden. Danach sollte die VOIP-Kurve abflachen, und VOIP wird keinen zukünftigen Schub bekommen, es sei denn, es wird für eine Weile zurückgesetzt (was angesichts der Tatsache, dass VOIP eine Anwendung mit geringer Bandbreite ist, es sollte). Das Endergebnis ist, dass die ersten beiden VOIP-Pakete schneller als alles andere gesendet werden, wodurch die VOIP-Latenz auf Kosten einer hohen E-Mail-Latenz verringert wird.

Wie ich bereits sagte, kann die Linkfreigabe keine Latenzgarantien geben, da sie den Verlauf nicht berücksichtigt. Eine absolut solide Garantie ist das, was für Echtzeitverkehr wie VOIP benötigt wird. Im Durchschnitt sorgt eine Link-Shared-Convex-Kurve jedoch weiterhin für eine Erhöhung der Latenz für den Datenverkehr. Es ist nur nicht garantiert. Das ist für die meisten Dinge in Ordnung, wie zum Beispiel den Web-Verkehr über E-Mail.

Gemäß der wenigen verfügbaren Dokumentation werden Echtzeitkurvenwerte für innere Klassen (Klasse A und B) vollständig ignoriert. Sie gelten nur für Blattklassen (A1, A2, B1, B2). Wenn dies zutrifft, warum legt die ALTQ HFSC-Beispielkonfiguration (Suche nach 3.3-Beispielkonfiguration) 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 berechnet die Echtzeitkurve. Sie können dies im Abschnitt ü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 offenbar glaubt, dass dies der Fall ist.

Einige Tutorials sagen, dass die Summe aller Echtzeitkurven nicht höher als 80% der Liniengeschwindigkeit sein darf, andere sagen, dass sie nicht höher als 70% der Liniengeschwindigkeit sein darf. Welches ist richtig oder sind sie vielleicht beide falsch?

Beides ist falsch. Wenn 70% oder 80% Ihres Traffics 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. Du brauchst einen schnelleren Link.

Die einzige Möglichkeit, 80% des Datenverkehrs in Echtzeit anzugeben, besteht darin, Echtzeit als Prioritätsschub zu verwenden. Ja, um Latenzgarantien zu bieten, erhöhen Sie tatsächlich die Priorität einiger Pakete. Es sollte aber nur für Millisekunden sein. Das ist alles, was ein Link bewältigen kann und dennoch die Latenzgarantien bietet.

Es gibt sehr wenig Verkehr, für den Latenzgarantien erforderlich sind. VOIP ist eins, NTP ein anderes. Der Rest sollte mit Link-Sharing erledigt werden. Wenn das Web schnell sein soll, können Sie es schnell machen, indem Sie ihm den größten Teil der Linkkapazität zuweisen. Dieser Anteil ist langfristig garantiert. Wenn Sie möchten, dass die Latenz (im Durchschnitt) niedrig ist, geben Sie ihr unter Link-Sharing eine konvexe Kurve.

Ein Tutorial sagte, Sie sollen die ganze Theorie vergessen. Unabhängig davon, wie die Dinge wirklich funktionieren (Planer und Bandbreitenverteilung), stellen Sie sich die drei Kurven nach dem folgenden "vereinfachten Denkmodell" vor: Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhält. Link-Share ist die Bandbreite, mit der diese Klasse vollständig zufrieden sein möchte, aber die Zufriedenheit kann nicht garantiert werden. Falls es zu viel Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite angeboten, als sie benötigt, um zufrieden zu sein, aber sie darf niemals mehr als die angegebene Obergrenze verwenden. Damit dies funktioniert, darf die Summe aller Echtzeit-Bandbreiten nicht über xx% der Leitungsgeschwindigkeit liegen (siehe Frage oben, der Prozentsatz variiert). Frage: Ist das mehr oder weniger genau oder ein totales Missverständnis von HSFC?

Es ist eine gute Beschreibungsobergrenze. Die Beschreibung der Linkfreigabe ist zwar genau, aber irreführend. Während die echte Linkfreigabe nicht die Garantie für die harte Latenz bietet, wie dies in Echtzeit der Fall ist, kann sie der Klasse die Bandbreite besser zuweisen als ihre Konkurrenten wie CBQ und HTB. Wenn Sie also sagen, dass die Linkfreigabe "keine Garantien bietet", entspricht dies einem höheren Standard, den jeder andere Scheduler bieten kann.

Die Beschreibung in Echtzeit ist zwar korrekt, aber so irreführend, dass ich es falsch nennen würde. Wie der Name andeutet, besteht der Zweck von Echtzeit darin, keine garantierte Bandbreite bereitzustellen. Dies soll eine garantierte Latenz gewährleisten, dh, das Paket wird JETZT gesendet, und nicht eine zufällige Zeitspanne später, je nachdem, wie die Verbindung verwendet wird. Der meiste Verkehr benötigt keine garantierte Latenz.

Allerdings bietet Echtzeit auch keine perfekten Latenzgarantien. Dies könnte auch der Fall sein, wenn der Link nicht auch über die Linkfreigabe verwaltet wird, aber die meisten Benutzer möchten die zusätzliche Flexibilität, beides zu haben, und dies ist nicht kostenlos. In Echtzeit kann die Latenzfrist um die Zeit überschritten werden, die zum Senden eines MTU-Pakets erforderlich ist. (Wenn dies passiert, liegt es daran, dass sich eine MTU-Paket-Link-Freigabe eingeschlichen hat, während die Verbindung in Echtzeit im Leerlauf war, falls ihr ein Paket mit einer kurzen Frist zugewiesen wurde, das sofort gesendet werden musste. Dies ist ein weiterer Unterschied zwischen der Link-Freigabe und Echtzeit. Um seine Garantien zu gewährleisten, kann Echtzeit die Leitung absichtlich im Leerlauf halten, obwohl zu sendende Pakete vorhanden sind, vorausgesetzt, dass die Verbindungsauslastung weniger als 100% beträgt. Die Verbindungsfreigabe verwendet immer 100% der verfügbaren Verbindungskapazität. Im Gegensatz zu Echtzeit ,

Der Grund, warum Echtzeit eine Garantie für hohe Latenz bietet, ist die begrenzte Verzögerung. Wenn Sie also versuchen, eine 20-ms-Latenzgarantie für eine 1-Mbit / s-Verbindung anzubieten und die Verbindungsfreigabe MTU-Pakete (1500 Byte) sendet, wissen Sie, dass eines dieser Pakete 12 ms zum Senden benötigt. Wenn Sie also in Echtzeit angeben, 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 zutreffend ist, wo liegt die Priorisierung in diesem Modell? Beispielsweise hat jede Klasse möglicherweise eine Echtzeitbandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und möglicherweise eine Obergrenze, aber dennoch haben einige Klassen höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich immer noch Prioritäten setzen, selbst im Echtzeitverkehr dieser Klassen. Würde ich nach der Steigung der Kurven priorisieren? Und wenn ja, welche Kurve? Die Echtzeitkurve? Die Link-Share-Kurve? Die obere Grenzkurve? Alle von ihnen? Würde ich allen die gleiche oder eine andere Steigung geben und wie finde ich die richtige Steigung heraus?

Es gibt kein Priorisierungsmodell. Ernst. Wenn Sie dem Verkehr absolute Prioritäten zuweisen möchten, verwenden Sie pfifo. Dafür ist es da. Aber Vorsicht auch , dass , wenn Sie Web - Traffic absoluten Vorrang vor E - Mail - Verkehr geben, dass Mittel im Stich gelassen Web - Traffic auf den Link sättigen und somit keine E - Mail - Pakete bekommen durch, überhaupt . Alle Ihre E-Mail-Verbindungen sterben dann.

In Wirklichkeit will niemand eine solche Priorisierung. Was sie wollen, ist das, was HFSC bietet. Wenn Sie tatsächlich Echtzeitverkehr haben, bietet HFSC dies an. Aber es wird alles Zeug sein. Im Übrigen können Sie mit HFSC sagen: "Ordnen Sie auf einem überlasteten Link 90% dem Web zu und lassen Sie E-Mails mit 10% weiterlaufen. Oh, senden Sie das ungerade DNS-Paket schnell, aber lassen Sie mich nicht von jemandem DOS."

Sie können die Kurven mit verschiedenen Namen definieren:

• RT, Echtzeitkurve, Bandbreiten- / Verzögerungsgarantie.
• ls, Link-Share-Kurve, Bandbreiten- / Delay-Sharing (basierend auf der Konfiguration der Nachbarblätter)
• ul, obere Grenzkurve, maximale Bandbreite / Verzögerung, die erreicht werden kann.

Wofür brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2 sind alle 128 kbit / s Link-Share (keine Echtzeitkurve für eine), dann erhält jede von diesen 128 kbit / s, wenn die Wurzel 512 kbit / s zu verteilen hat (und A und B sind natürlich beide 256 kbit / s, oder? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit / s geben? Wofür wäre das gut? Um diesen beiden eine höhere Priorität einzuräumen? Laut Originalpapier kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende, darum geht es doch bei HFSC. Wenn Sie beiden Klassen eine Kurve von [256 kbit / s, 20 ms, 128 kbit / s] zuweisen, haben beide automatisch die doppelte Priorität als A2 und B2 (im Durchschnitt immer noch nur 128 kbit / s).

Wenn Sie eine Definition in HFSC nur mit Raten vornehmen, wird "dmax" automatisch auf 0 gesetzt. Dies bedeutet im Grunde, dass die Verzögerung nicht berücksichtigt wird. Eine gute HFSC-Konfiguration sollte sowohl Bandbreite als auch 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.

Wann immer Sie Paketen Priorität einräumen, müssen andere Pakete eine geringere Priorität erhalten. Basierend auf den Werten 'dmax' und 'rate' werden alle Klassen mit virtuellen Timern gemultiplext. Weitere Informationen finden Sie unter tc-hfsc (7).

Zählt die Echtzeitbandbreite zur Link-Share-Bandbreite? Wenn z. B. A1 und B1 beide nur eine Link-Share-Bandbreite von 64 kbit / s in Echtzeit und 64 kbit / s in Echtzeit haben, ist möglicherweise auch ihre Link-Share-Anforderung erfüllt Erhalten Sie überschüssige Bandbreite, aber lassen Sie uns das für eine Sekunde ignorieren) oder bedeutet das, dass sie weitere 64 kbit / s über Link-Share erhalten? Hat also jede Klasse einen "Bandbreitenbedarf" von Echtzeit plus Link-Share? Oder hat eine Klasse nur dann eine höhere Anforderung als die Echtzeitkurve, wenn die Link-Share-Kurve höher ist als die Echtzeitkurve (die aktuelle Link-Share-Anforderung entspricht der angegebenen Link-Share-Anforderung abzüglich der dafür bereits bereitgestellten Echtzeitbandbreite) Klasse)?

Wenn der Datenfluss die Grenzen der Link-Share-Definition der Klasse nicht überschreitet, wird die Echtzeitkurve niemals verwendet. Wenn Sie in diesem Fall eine Echtzeitkurve definieren, können Sie z. B .: einen bestimmten "dmax" garantieren.

Wenn Ihre Link-Share-Definitionen fehlerfrei sind, benötigen Sie keine Echtzeitkurven. Sie könnten lediglich Servicekurven (sc) definieren, dies würde Ihre Konfiguration jedoch erschweren.

Wird die obere Grenzkurve auch auf Echtzeit angewendet, nur auf Link-Share oder vielleicht auf beide? Einige Tutorials sagen den einen Weg, andere den anderen. Einige behaupten sogar, die Obergrenze sei das Maximum für Echtzeitbandbreite + Link-Share-Bandbreite? Was ist die Wahrheit?

Die obere Grenzkurve Ihrer Klasse wird nur auf Link-Share angewendet. Wenn Sie eine obere Grenzkurve definieren, MÜSSEN Sie eine Link-Share-Kurve definieren. Die obere Grenzkurve der Elternklassen wird jedoch weiterhin angewendet.

Angenommen, A2 und B2 sind beide 128 kbit / s, macht es keinen 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 , welcher Unterschied?

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

Warum brauche ich überhaupt "Kurven", wenn ich die separate Echtzeitkurve verwende, um die Prioritäten von Klassen zu erhöhen? Warum ist Echtzeit kein Pauschalwert und Link-Sharing auch ein Pauschalwert? Warum sind beide Kurven? Die Notwendigkeit von Kurven ist im Originalpapier klar, da es nur ein Attribut dieser Art pro Klasse gibt. Aber jetzt, mit drei Attributen (Echtzeit, Link-Freigabe und Obergrenze), wofür benötige ich noch Kurven für jedes Attribut? Warum sollte die Kurvenform (nicht die durchschnittliche Bandbreite, sondern die Steigung) für Echtzeit- und Link-Share-Verkehr unterschiedlich sein?

Echtzeitkurven teilen den Datenverkehr nicht zwischen Nachbarn, Link-Share-Kurven jedoch.

Gemäß der wenigen verfügbaren Dokumentation werden Echtzeitkurvenwerte für innere Klassen (Klasse A und B) vollständig ignoriert. Sie gelten nur für Blattklassen (A1, A2, B1, B2). Wenn dies zutrifft, warum legt die ALTQ HFSC-Beispielkonfiguration (Suche nach 3.3-Beispielkonfiguration) 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 berechnet die Echtzeitkurve. Sie können dies im Abschnitt über der Beispielkonfiguration sehen.)

Es ist richtig, 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 die Berechnungen für die Blattklassen berücksichtigt.

Einige Tutorials sagen, dass die Summe aller Echtzeitkurven nicht höher als 80% der Liniengeschwindigkeit sein darf, andere sagen, dass sie nicht höher als 70% der Liniengeschwindigkeit sein darf. Welches ist richtig oder sind sie vielleicht beide falsch?

Was sie bedeuten ist: Sie können nicht allen Verkehr priorisieren ... Immer wenn Sie Paketen Priorität geben, müssen andere Pakete in der Priorität verringert werden. Wenn Sie zu viel garantieren, wird der Algorithmus sinnlos. Definieren Sie eine Klasse, die Prioritäten erhält, und definieren Sie Klassen, die möglicherweise darunter leiden.

Ein Tutorial sagte, Sie sollen die ganze Theorie vergessen. Unabhängig davon, wie die Dinge wirklich funktionieren (Planer und Bandbreitenverteilung), stellen Sie sich die drei Kurven nach dem folgenden "vereinfachten Denkmodell" vor: Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhält. Link-Share ist die Bandbreite, mit der diese Klasse vollständig zufrieden sein möchte, aber die Zufriedenheit kann nicht garantiert werden. Falls es zu viel Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite angeboten, als sie benötigt, um zufrieden zu sein, aber sie darf niemals mehr als die angegebene Obergrenze verwenden. Damit dies funktioniert, darf die Summe aller Echtzeit-Bandbreiten nicht über xx% der Leitungsgeschwindigkeit liegen (siehe Frage oben, der Prozentsatz variiert). Frage: Ist das mehr oder weniger genau oder ein totales Missverständnis von HSFC?

Das ist richtig.

Und wenn die obige Annahme wirklich zutreffend ist, wo liegt die Priorisierung in diesem Modell? Beispielsweise hat jede Klasse möglicherweise eine Echtzeitbandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und möglicherweise eine Obergrenze, aber dennoch haben einige Klassen höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich immer noch Prioritäten setzen, selbst im Echtzeitverkehr dieser Klassen. Würde ich nach der Steigung der Kurven priorisieren? Und wenn ja, welche Kurve? Die Echtzeitkurve? Die Link-Share-Kurve? Die obere Grenzkurve? Alle von ihnen? Würde ich allen die gleiche oder eine andere Steigung geben und wie finde ich die richtige Steigung heraus?

Der Unterschied zwischen z. B. HFSC und HTB besteht darin, dass Sie mit HFSC genau definieren können, wie viel Priorität Sie möchten. Dazu definieren Sie minimale und maximale Grenzen mit dem Wert 'dmax'.

Zum Schluss ein Leitfaden, der die meisten Inkonsistenzen und auch den Unterschied zwischen der aktuellen Implementierung und dem Originalpapier zu erklären scheint:

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

Laut diesem Leitfaden sind viele andere Leitfäden und Forenbeiträge über HFSC völlig unsinnig. es zeigt nur, wie kompliziert HFSC ist, wie viele Leute, die Experten zu sein scheinen und vortäuschen, HFSC vollständig verstanden zu haben, tatsächlich nur teilweise Bescheid wissen und falsche Aussagen machen, die auf Missverständnissen des Konzepts beruhen und wie all diese Einstellungen zusammenspielen.

Ich denke, ich werde HFSC endlich aufgeben. Wenn Sie Ihr HFSC-Setup richtig einrichten können, ist es möglicherweise die beste QoS, die Sie erhalten können, aber die Chancen, dass Sie völlig durcheinander geraten, sind weit höher als die Chancen, dass Sie erfolgreich sind.

Wenn Sie nicht in der Lage sind, die Originalautoren zu finden, würde ich Folgendes versuchen:

1. Gehe in den Linux Kernel Source Tree und finde C-Dateien, die das "TC Scheduling Framework" implementieren.
2. Schauen Sie sich den Header an und suchen Sie den Autor des Codes.
3. E-Mail-Programmierer des "TC Scheduling Framework" bitten sie um Literatur zu ihrer Implementierung.

Überprüfen Sie auch andere neuere Papiere, die diese zitieren. Möglicherweise gibt es neuere Veröffentlichungen, die die Forschung in diesem Bereich fortsetzen und möglicherweise weitere Informationen zu den von Ihnen gestellten Fragen enthalten.