Frage Hat jemand wirklich verstanden, wie HFSC-Scheduling in Linux / BSD funktioniert?


Ich lese das Original SIGCOMM '97 PostScript-Papier über HFSC, es ist sehr technisch, aber ich verstehe das Grundkonzept. Anstatt eine lineare Servicekurve zu geben (wie bei so ziemlich jedem anderen Scheduling-Algorithmus), können Sie eine konvexe oder konkave Servicekurve angeben und somit Bandbreite und Verzögerung entkoppeln. Auch wenn in diesem Artikel auf die Art der verwendeten Scheduling-Algorithmen (Echtzeit- und Link-Sharing) hingewiesen wird, wird immer nur EINE Kurve pro Scheduling-Klasse 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, etc.) unter Verwendung der ALTQ-Planungsframework und es wurde Linux mit dem implementiert TC-Zeitplanungsrahmen (Teil von iproute2). Beide Implementierungen fügten zwei zusätzliche Servicekurven hinzu NICHT im Originalpapier! Eine Echtzeit-Service-Kurve und eine Service-Kurve für die obere Grenze. Bitte beachten Sie, dass in der Originalarbeit zwei Planungsalgorithmen (Echtzeit- und Link-Sharing) erwähnt werden, aber in diesem Papier beide mit einer einzigen Servicekurve arbeiten. Es gab nie zwei unabhängige Service-Kurven für beide, wie Sie es derzeit in BSD und Linux finden.

Schlimmer noch, einige Versionen von ALTQ scheinen dem HSFC eine zusätzliche Warteschlangenpriorität hinzuzufügen (im Original gibt es keine Priorität). Ich habe mehrere BSD HowTo gefunden, die diese Prioritätseinstellung erwähnen (auch wenn die Manpage der letzten ALTQ-Version keinen solchen Parameter für HSFC kennt, also offiziell gar nicht existiert).

Dies alles macht die HFSC-Planung noch komplexer als der Algorithmus, der in der Originalarbeit beschrieben wird, und es gibt Unmengen an Tutorials im Internet, die sich oft widersprechen, wobei einer das Gegenteil behauptet. Dies ist wahrscheinlich der Hauptgrund, warum niemand wirklich zu verstehen scheint, wie die HFSC-Planung wirklich funktioniert. Bevor ich meine Fragen stellen kann, brauchen wir einen Musteraufbau. Ich werde einen sehr einfachen verwenden, wie in der folgenden Abbildung zu sehen ist:

alt text http://f.imagehost.org/0177/hfs-c-test-setup.png

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

  1. Wozu brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2 sind alle 128 kbit / s Link-Share (keine Echtzeitkurve für beide), dann erhält jeder von ihnen 128 kbit / s, wenn die Wurzel 512 kbit / s zu verteilen hat (und A und B sind beide 256 kbit / s natürlich), oder? Warum würde 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 zu geben? Laut Originalpapier kann ich ihnen eine höhere Priorität geben, indem ich a KurveDas ist es, worum es bei HFSC geht. Indem man beiden Klassen eine Kurve von [256 kbit / s 20 ms 128 kbit / s] gibt, haben beide automatisch die doppelte Priorität als A2 und B2 (immer noch nur 128 kbit / s im Durchschnitt).

  2. Zählt die Echtzeit-Bandbreite zur Link-Share-Bandbreite? Z.B. Wenn A1 und B1 beide nur 64 kbit / s Echtzeit- und 64 kbit / s Link-Share-Bandbreite haben, bedeutet das, dass sobald sie 64 kbit / s über Echtzeit bedient werden, auch ihre Link-Share-Anforderung erfüllt ist (sie könnten es bekommen) überschüssige Bandbreite, aber lassen Sie das für eine Sekunde ignorieren) oder bedeutet das, dass sie weitere 64 kbit / s über Link-Share bekommen? Hat also jede Klasse eine Bandbreiten- "Anforderung" an Echtzeit plus Link-Sharing? Oder hat eine Klasse nur dann eine höhere Anforderung als die Echtzeitkurve, wenn die Link-Share-Kurve höher ist als die Echtzeitkurve (aktuelle Link-Share-Anforderung entspricht der angegebenen Link-Share-Anforderung minus bereits dafür bereitgestellter Echtzeit-Bandbreite) Klasse)?

  3. Wird die obere Grenzkurve auch auf Echtzeit angewendet, nur um eine Verbindung zu teilen oder vielleicht beides? Manche Tutorials sagen einen Weg, andere sagen es anders. Einige behaupten sogar, die Obergrenze sei das Maximum für Echtzeit-Bandbreite + Link-Share-Bandbreite? Was ist die Wahrheit?

  4. Unter der Annahme, dass A2 und B2 beide 128 kbit / s sind, macht es einen Unterschied, ob A1 und B1 nur 128 kbit / s Link-Share oder 64 kbit / s Real-Time und 128 kbit / s Link-Share sind und wenn ja , welcher Unterschied?

  5. Wenn ich die separate Echtzeitkurve verwende, um die Prioritäten der Klassen zu erhöhen, warum würde ich überhaupt "Kurven" brauchen? Warum ist in Echtzeit kein flacher Wert und Link-Share auch ein flacher Wert? Warum sind beide Kurven? Der Bedarf an Kurven ist in der Originalarbeit klar, weil es nur ein Attribut dieser Art pro Klasse gibt. Aber jetzt, mit drei Attributen (Echtzeit, Link-Sharing und Obergrenze), wofür brauche ich noch Kurven auf jedem einzelnen? Warum sollte ich die Kurven wollen? gestalten (nicht durchschnittliche Bandbreite, aber ihre Steigungen) für Echtzeit- und Link-Sharing-Verkehr zu unterscheiden?

  6. Entsprechend der wenigen verfügbaren Dokumentation werden Echtzeitkurvenwerte für innere Klassen (Klasse A und B) vollständig ignoriert, sie werden nur auf Blattklassen (A1, A2, B1, B2) angewendet. Wenn das stimmt, warum tut das? ALTQ HFSC-Beispielkonfiguration (suchen nach 3.3 Beispielkonfiguration) setze Echtzeitkurven auf innere Klassen und behauptet, dass diese die garantierte Rate dieser inneren Klassen setzen? Ist das nicht völlig sinnlos? (Anmerkung: pshare legt die Link-Share-Kurve in ALTQ fest und berichtigt die Echtzeitkurve; Sie können dies im Absatz oberhalb 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 dürfen. Welcher ist richtig oder sind sie beide falsch?

  8. Eine Anleitung besagt, dass Sie die gesamte Theorie vergessen sollten. Egal, wie die Dinge wirklich funktionieren (Scheduler und Bandbreitenverteilung), stellen Sie sich die drei Kurven gemäß dem folgenden "vereinfachten Denkmodell" vor: Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhalten wird. Link-Share ist die Bandbreite, die diese Klasse vollständig zufriedenstellen möchte, aber die Zufriedenheit kann nicht garantiert werden. Falls die Bandbreite zu groß ist, wird der Klasse möglicherweise sogar mehr Bandbreite geboten als nötig, um zufrieden zu werden, aber sie kann niemals mehr als die Obergrenze verwenden. Damit das alles funktioniert, darf die Summe aller Echtzeit-Bandbreiten nicht über xx% der Liniengeschwindigkeit liegen (siehe Frage oben, der Prozentsatz variiert). Frage: Ist das mehr oder weniger korrekt oder ein totales Missverständnis von HSFC?

  9. Und wenn die obige Annahme wirklich richtig ist, wo ist die Priorisierung in diesem Modell? Z.B. Jede Klasse hat möglicherweise eine Echtzeit-Bandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und vielleicht eine Obergrenze, aber dennoch haben einige Klassen eine höhere Priorität als andere Klassen. In diesem Fall muss ich irgendwie priorisieren, sogar 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 Steigung oder eine andere geben und wie finde ich die richtige Steigung?

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


34
2018-01-21 15:01


Ursprung


Blink Blink - Matt Simmons
Viel Glück. Vielleicht solltest du dem Autor der Software schreiben und mit ihnen darüber reden. Ich bin mir sicher, dass sie gerne von jemand anderem hören würden, der sich für ihr Thema interessiert. - Matt Simmons
Diese Frage ist meiner Meinung nach viel zu akademisch und nicht sehr gut geeignet, um hier eine praktische Antwort zu erhalten. Ich stimme Matt zu, dass eine Kommunikation mit dem Autor oder den Autoren die beste Vorgehensweise ist. - joeqwerty
Sie können eine E-Mail an den Autor des Papiers senden? Vielleicht könnte er helfen, den Code durchzusehen? - Matt Simmons
+1 Matt. Mecki, ich vermute die wörtliche Antwort auf deine Frage ist "Nein". - Richard Holloway


Antworten:


Das Lesen der Papiere über HFSC und seine Cousins ​​ist keine gute Möglichkeit, es zu verstehen. Das Hauptziel des HFSC-Papiers ist es, einen strengen mathematischen Beweis seiner Behauptungen zu liefern, nicht zu erklären, wie es funktioniert. In der Tat können Sie nicht verstehen, wie es aus dem HFSC-Papier allein funktioniert, Sie müssen auch die Papiere lesen, auf die es sich bezieht. Wenn Sie ein Problem mit der Behauptung oder ihren Beweisen haben, dann ist es vielleicht eine gute Idee, sich mit den Autoren der Papiere in Verbindung zu setzen, ansonsten bezweifle ich, dass sie daran interessiert sind, von Ihnen zu hören.

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

Wozu brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2   sind alle 128 kbit / s link-share (keine Echtzeitkurve für beide),   dann bekommt jeder von denen 128 kbit / s, wenn die Wurzel 512 kbit / s hat   verteilen (und A und B sind beide 256 kbit / s natürlich), oder? Warum   würde 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 zu geben?   Laut Originalpapier kann ich ihnen eine höhere Priorität geben   eine Kurve, darum geht es bei HFSC. Indem ich beides gebe   Klassen eine Kurve von [256kbit / s 20ms 128kbit / s] haben beide das Doppelte   Priorität als A2 und B2 automatisch (immer noch nur 128 kbit / s   im Durchschnitt)

Die Echtzeitkurve und die Link-Sharing-Kurve werden auf verschiedene Arten ausgewertet. Die Echtzeitkurve berücksichtigt, was eine Klasse während ihrer gesamten Geschichte getan hat. Es muss dies tun, um eine genaue Bandbreite und Latenzzuweisung bereitzustellen. Der Nachteil ist nicht, was die meisten Menschen intuitiv denken Messe. Wenn eine Klasse in Echtzeit Bandbreite ausborgt, wenn niemand sie will, wird sie bestraft, wenn sie später jemand anderes möchte. Das bedeutet, dass eine Klasse unter der Echtzeitgarantie lange Zeit keine Bandbreite erhalten kann, weil sie früher verwendet wurde, als niemand sie wollte.

Die gemeinsame Nutzung von Links ist insofern fair, als dass eine Klasse für die Verwendung von Spare-Bandbreiten nicht benachteiligt wird. Dies bedeutet jedoch, dass es keine starken Latenzgarantien geben kann.

Die Trennung der Link-Sharing von Latenz-Garantien ist das Neue, was HFSC auf den Tisch bringt, und das Papier sagt so viel in seinem Eröffnungssatz: In diesem Artikel untersuchen wir hierarchische Ressourcenverwaltungsmodelle und -algorithmen, die Link-Sharing- und garantierte Echtzeitdienste mit entkoppelter Verzögerung (Priorität) und Bandbreitenzuweisung unterstützen.  Das Schlüsselwort in diesem Satz ist entkoppelt. Übersetzt bedeutet dies, dass Sie sagen sollen, wie ungenutzte Bandbreite mit ls geteilt werden soll, und geben Sie an, welche Echtzeitgarantien (auch Latenzgarantien) bei RT benötigt werden. Die beiden sind orthogonal.

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

Ja. Im HFSC-Papier definieren sie Bandbreite in Bezug auf das, was die Klasse gesendet hat, seit die Klasse sich zurückgemeldet hat (dh, Pakete warten darauf, gesendet zu werden). Der einzige Unterschied zwischen rt und ls besteht darin, dass rt von jedem Zeitpunkt, an dem die Klasse zurückgestuft wird, vorwärts schaut und die niedrigste garantierte Bandbreite aus dieser Menge berechnet, während Link-Sharing nur vom letzten Mal aussieht, an dem die Klasse zurückgestaut wurde. So nimmt rt mehr Bytes in Betracht als ls, aber jedes Byte, das ls berücksichtigt, wird auch von rt berücksichtigt.

Wird die obere Grenzwertkurve auch auf Echtzeit angewendet, nur um eine Verbindung zu teilen,   oder vielleicht zu beiden?

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

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

Ja, es macht einen Unterschied. Wie oben erklärt, wenn Sie Echtzeit verwenden, sind die Latenzen garantiert, aber die Verbindung wird nicht fair geteilt (und insbesondere kann die Klasse einen Mangel an Bandbreite erleiden), und die Obergrenzen werden nicht erzwungen. Wenn Sie die Linkfreigabe verwenden, ist die Latenz nicht garantiert, aber die Linkfreigabe ist fair, es besteht kein Risiko zu verhungern, und die Obergrenze wird erzwungen. 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 (wegen einer in der Historie enthaltenen Zählung), aber es wird benötigt, um die Linkfreigabe zu erfüllen, da es das historische Paket ignoriert.

Wenn ich die separate Echtzeitkurve verwende, um die Prioritäten zu erhöhen   Klassen, warum sollte ich überhaupt Kurven brauchen? Warum ist Echtzeit nicht flach?   Wert und Link-Share auch einen flachen Wert? Warum sind beide Kurven? Die Notwendigkeit   Für Kurven ist in der Originalarbeit klar, weil es nur eine gibt   Attribut dieser Art pro Klasse. Aber jetzt, mit drei Attributen   (Echtzeit, Link-Sharing und Obergrenze) Was für brauche ich noch?   Kurven auf jedem? Warum sollte ich die Kurvenform haben wollen (nicht durchschnittlich   Bandbreite, aber ihre Steigungen) für Echtzeit und anders zu sein   Link-Sharing-Verkehr?

Die Kurve für Echtzeitsteuerungen ermöglicht es Ihnen, eine enge Latenz für eine bestimmte Verkehrsklasse (z. B. VOIP) gegen schlechte Latenz für andere Verkehrsklassen (z. B. E-Mail) zu tauschen. Bei der Entscheidung, welches Paket unter der Echtzeitbedingung gesendet werden soll, wählt HFSC diejenige aus, die das Senden zuerst abschließen wird. Es verwendet jedoch nicht die Bandbreite der Verbindung, um dies zu berechnen, es verwendet die von der Echtzeitkurve zugewiesene Bandbreite. Wenn wir also VOIP- und E-Mail-Pakete der gleichen Länge haben und das VOIP-Paket eine konvexe Kurve hat, die 10-fache Verstärkung über die konkave Kurve für E-Mail gibt, dann werden 10 VOIP-Pakete vor dem ersten E-Mail-Paket gesendet. Dies geschieht jedoch nur für die Burst-Zeit, die höchstens die Zeit sein sollte, die benötigt wird, um ein paar Pakete zu senden - dh Millisekunden. Danach sollte die VOIP-Kurve abgeflacht werden, und VOIP wird keine zukünftige Verstärkung erhalten, wenn es nicht für eine Weile zurückgeht (was, wenn VOIP eine Anwendung mit niedriger Bandbreite ist, sollte es sein). Das Ergebnis all dessen ist, sicherzustellen, dass die ersten paar VOIP-Pakete schneller als alles andere gesendet werden, wodurch VOIP eine niedrige Latenz auf Kosten von E-Mails mit hoher Latenz erhält.

Wie ich bereits sagte, da Link-Share nicht auf Historie schaut, kann es keine Latenzgarantien geben. Eine solide Garantie ist für Echtzeitverkehr wie VOIP erforderlich. Im Durchschnitt liefert eine gemeinsam genutzte konvexe Kurve jedoch immer noch eine Latenzverstärkung für ihren Datenverkehr. Es ist einfach nicht garantiert. Das ist für die meisten Dinge in Ordnung, wie zum Beispiel Web-Traffic über E-Mail.

Entsprechend der wenigen zur Verfügung stehenden Dokumentation, Echtzeitkurve   Werte werden für innere Klassen (Klasse A und B) total ignoriert, sie sind   nur für Blattklassen (A1, A2, B1, B2). Wenn das stimmt, warum   macht die ALTQ HFSC Beispielkonfiguration (Suche nach 3.3 Sample   Konfiguration) setzen Echtzeitkurven auf innere Klassen und behauptet, dass   diese stellen die garantierte Rate dieser inneren Klassen ein? Ist das nicht?   völlig sinnlos? (Hinweis: pshare legt die Link-Share-Kurve in ALTQ fest   und raspeln Sie die Echtzeitkurve; Sie können dies im obigen Absatz sehen   die Beispielkonfiguration).

Die Dokumentation ist korrekt. Die Hierarchie (und damit innere Knoten) hat keinerlei Auswirkung auf die Berechnung von Echtzeit überhaupt. Ich kann Ihnen nicht sagen, warum ALTQ offensichtlich denkt, dass es das tut.

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

Beide sind falsch. Wenn 70% oder 80% Ihres Datenverkehrs harte Latenzanforderungen aufweist, die in Echtzeit angegeben werden müssen, können Sie diese mit dem Link, den Sie verwenden, mit hoher Wahrscheinlichkeit nicht erfüllen. Sie benötigen eine schnellere Verbindung.

Der einzige Weg, wie jemand denken könnte, dass 80% des Datenverkehrs in Echtzeit sein sollte, ist, wenn sie Echtzeit als Prioritätserhöhung nutzen. Ja, um Latenzgarantien zu bieten, erhöhen Sie effektiv die Priorität einiger Pakete. Aber es sollte nur für Millisekunden sein. Das ist alles, was ein Link bewältigen kann und bietet trotzdem die Latenzgarantie.

Es gibt sehr wenig Verkehr, der Latenzgarantien benötigt. VOIP ist einer, NTP ein anderer. Der Rest sollte mit Link-Sharing getan werden. Wenn Sie wollen, dass das Web schnell ist, machen Sie es schnell, indem Sie ihm die meisten Verbindungskapazitäten zuweisen. Dieser Anteil ist garantiert auf lange Sicht. Wenn Sie möchten, dass die Latenz (im Durchschnitt) niedrig ist, geben Sie unter Link-Sharing eine konvexe Kurve ein.

Eine Anleitung besagt, dass Sie die gesamte Theorie vergessen sollten. Egal wie   Dinge funktionieren wirklich (Scheduler und Bandbreitenverteilung), stell dir vor   die drei Kurven nach dem folgenden "vereinfachten Denkmodell":   Echtzeit ist die garantierte Bandbreite, die diese Klasse immer bekommt.   Link-Share ist die Bandbreite, die diese Klasse vollständig erreichen möchte   zufrieden, aber die Zufriedenheit kann nicht garantiert werden. Falls da ist   Übermäßige Bandbreite, könnte der Klasse sogar mehr Bandbreite als angeboten werden   notwendig, um zufrieden zu werden, aber es kann nie mehr als verwenden   Obergrenze sagt. Damit das funktioniert, ist die Summe aller Echtzeit   Bandbreiten dürfen nicht über xx% der Liniengeschwindigkeit liegen (siehe Frage oben,   der Prozentsatz variiert). Frage: Ist das mehr oder weniger genau oder a   totales Missverständnis von HSFC?

Es ist eine gute Beschreibung, obere Grenze. Während die Link-Share-Beschreibung streng korrekt ist, ist sie irreführend. Zwar ist es nicht so, dass Link-Shares die garantierten Latenzzeiten wie in Echtzeit liefert, aber es ist besser, der Klasse ihre Bandbreite zuzuteilen als den Konkurrenten wie CBQ und HTB. Wenn man sagt, dass der Link-Share "keine Garantien bietet", hält er ihn auf einem Standard höher, den jeder andere Scheduler bereitstellen kann.

Die Beschreibung in Echtzeit kann genau sein, aber so irreführend, würde ich es falsch nennen. Wie der Name andeutet, besteht der Zweck der Echtzeit nicht darin, eine garantierte Bandbreite zu geben. Es soll garantierte Latenz bieten - dh das Paket wird JETZT gesendet, nicht eine zufällige Menge an Zeit später, abhängig davon, wie die Verbindung verwendet wird. Der meiste Verkehr benötigt keine garantierte Latenz.

Das heißt, Echtzeit gibt auch keine perfekten Latenzzeiten. Es könnte, wenn der Link nicht auch von Link-Share verwaltet wird, aber die meisten Benutzer wollen die zusätzliche Flexibilität von beiden haben und es ist nicht kostenlos. Echtzeit kann die Latenzzeit bis zum Senden eines MTU-Pakets verfehlen. (Wenn es passiert, wird es sein, weil es ein MTU-Paket war Link-Share eingeschlichen, während in Echtzeit die Verbindung im Leerlauf, wenn es Paket mit einer kurzen Frist, die sofort gesendet werden musste gegeben. Dies ist noch ein weiterer Unterschied zwischen Link-Share In Echtzeit kann die Leitung absichtlich inaktiv gehalten werden, auch wenn Pakete zu senden sind, und somit weniger als 100% der Verbindungsnutzung zur Verfügung stellt.Link-Anteil verwendet immer 100% der verfügbaren Verbindungskapazität Man kann sagen, dass es sich um "Arbeitserhaltung" handelt.)

Der Grund dafür, dass Echtzeit garantiert werden kann, ist die Verzögerung ist begrenzt. Wenn Sie also versuchen, eine Latenzgarantie von 20 ms für eine 1-Mbit / s-Verbindung anzubieten, und eine Verbindungsfreigabe MTU-Pakete (1500 Byte) sendet, wissen Sie, dass eines dieser Pakete 12 ms benötigt, um gesendet zu werden. Wenn Sie also in Echtzeit angeben, dass Sie eine Latenz von 8 ms benötigen, können Sie die 20 ms-Frist einhalten - mit einer absoluten Garantie.

Und wenn obige Annahme wirklich richtig ist, wo ist die Priorisierung in   dieses Modell? Z.B. Jede Klasse kann eine Echtzeit-Bandbreite haben   (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und eine vielleicht an   Obergrenze, aber immer noch einige Klassen haben höhere Priorität als   andere Klassen. In diesem Fall muss ich noch irgendwie priorisieren   unter Echtzeitverkehr dieser Klassen. Würde ich priorisieren durch die   Steigung der Kurven? Und wenn ja, welche Kurve? Die Echtzeitkurve? Das   Link-Share-Kurve? Die obere Grenzkurve? Alle von ihnen? Würde ich alles geben?   von ihnen die gleiche Steigung oder jeder eine andere und wie man das herausfinden   richtige Steigung?

Es gibt kein Priorisierungsmodell. Ernst. Wenn Sie dem Traffic absolute Priorität geben möchten, verwenden Sie pfifo. Dafür ist es da. Bedenken Sie aber auch, dass wenn Sie dem Web-Verkehr absoluten Vorrang vor dem E-Mail-Verkehr geben, dies bedeutet, dass der Web-Verkehr die Verbindung sättigen kann und somit keine E-Mail-Pakete durchkommen, überhaupt. Alle Ihre E-Mail-Verbindungen sterben dann.

In Wirklichkeit möchte niemand eine solche Priorisierung. Was sie wollen, ist was HFSC bietet. Wenn Sie tatsächlich Echtzeitverkehr haben, bietet HFSC das. Aber es wird alles sein. Im Übrigen erlaubt HFSC Ihnen zu sagen "auf einem überlasteten Link, 90% zu Web zuweisen und lassen Sie E-Mail bei 10% tröpfeln, und oh senden Sie die ungeraden DNS-Paket schnell, aber lassen Sie mich nicht jemand DOS damit."


15
2018-04-24 09:06





Sie könnten die Kurven mit unterschiedlichen Namen definieren:

  • RT, Echtzeit-Kurve, Bandbreite / Verzögerung Garantie.
  • ls, Link-Share-Kurve, Bandbreite / Delay-Sharing (basierend auf der Konfiguration von Nachbarblättern)
  • ul, obere Grenzkurve, maximale Bandbreite / Verzögerung, die es erreichen kann.

Wozu brauche ich überhaupt eine Echtzeitkurve? Angenommen, A1, A2, B1, B2   sind alle 128 kbit / s link-share (keine Echtzeitkurve für beide),   dann bekommt jeder von denen 128 kbit / s, wenn die Wurzel 512 kbit / s hat   verteilen (und A und B sind beide 256 kbit / s natürlich), oder? Warum   würde 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 zu geben?   Laut Originalpapier kann ich ihnen eine höhere Priorität geben   eine Kurve, darum geht es bei HFSC. Indem ich beides gebe   Klassen eine Kurve von [256kbit / s 20ms 128kbit / s] haben beide das Doppelte   Priorität als A2 und B2 automatisch (immer noch nur 128 kbit / s   im Durchschnitt)

Wenn Sie eine Definition in HFSC nur mit Raten vornehmen, wird 'dmax' automatisch auf 0 gesetzt. Dies bedeutet, dass Verzögerungen nicht berücksichtigt werden. Eine gute HFSC-Konfiguration sollte sowohl Bandbreiten- als auch Verzögerungsgrenzen enthalten, die Sie für Ihre Klasse verwenden möchten. Andernfalls kann der Algorithmus nicht genau herausfinden, wie hoch die Priorität einer Klasse sein sollte.

Wenn Sie Paketen Priorität geben, müssen andere Pakete in der Priorität verringert werden. 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 Echtzeit-Bandbreite zur Link-Share-Bandbreite?   Z.B. wenn A1 und B1 beide nur 64kbit / s Echtzeit und 64kbit / s haben   Link-Share-Bandbreite, heißt das, sobald sie über 64kbit / s bedient werden   Echtzeit, ihre Link-Share-Anforderung ist auch erfüllt (sie   könnte überschüssige Bandbreite bekommen, aber ignorieren Sie das für eine Sekunde) oder tut   das bedeutet, dass sie über Link-Share weitere 64 kbit / s bekommen? So auch jeder   Klasse hat eine Bandbreite "Anforderung" von Echtzeit plus Link-Share? Oder   Hat eine Klasse nur eine höhere Anforderung als die Echtzeitkurve?   wenn die Link-Share-Kurve höher ist als die Echtzeitkurve (current   Link-Share-Anforderung entspricht der angegebenen Link-Share-Anforderung minus   Echtzeit-Bandbreite für diese Klasse bereits bereitgestellt)?

Wenn der Fluss die Grenzen der Link-Share-Definition der Klasse nicht überschreitet, wird die Echtzeitkurve nie verwendet. Das Definieren einer Echtzeitkurve in diesem Fall ermöglicht es beispielsweise, ein bestimmtes 'dmax' zu garantieren.

Wenn Ihre Link-Share-Definitionen fehlerfrei sind, benötigen Sie keine Echtzeitkurven. Sie könnten nur Servicekurven (sc) definieren, aber das würde Ihre Konfiguration schwieriger machen.

Wird die obere Grenzwertkurve auch auf Echtzeit angewendet, nur um eine Verbindung zu teilen,   oder vielleicht zu beiden? Manche Tutorials sagen einen Weg, andere sagen es anders.   Einige behaupten sogar Obergrenze ist das Maximum für Echtzeit-Bandbreite +   Link-Share-Bandbreite? Was ist die Wahrheit?

Die Obergrenzenkurve Ihrer Klasse wird nur auf Link-Sharing angewendet. Wenn Sie eine Obergrenzenkurve definieren, müssen Sie eine Link-Share-Kurve definieren. Die obere Grenzkurve der Elternklassen wird jedoch immer noch angewendet.

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

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

Wenn ich die separate Echtzeitkurve verwende, um die Prioritäten zu erhöhen   Klassen, warum sollte ich überhaupt Kurven brauchen? Warum ist Echtzeit nicht flach?   Wert und Link-Share auch einen flachen Wert? Warum sind beide Kurven? Die Notwendigkeit   Für Kurven ist in der Originalarbeit klar, weil es nur eine gibt   Attribut dieser Art pro Klasse. Aber jetzt, mit drei Attributen   (Echtzeit, Link-Sharing und Obergrenze) Was für brauche ich noch?   Kurven auf jedem? Warum sollte ich die Kurvenform haben wollen (nicht durchschnittlich   Bandbreite, aber ihre Steigungen) für Echtzeit und anders zu sein   Link-Sharing-Verkehr?

Echtzeitkurven teilen keinen Verkehr zwischen benachbarten Blättern, Link-Share-Kurven tun dies.

Entsprechend der wenigen zur Verfügung stehenden Dokumentation, Echtzeitkurve   Werte werden für innere Klassen (Klasse A und B) total ignoriert, sie sind   nur für Blattklassen (A1, A2, B1, B2). Wenn das stimmt, warum   macht die ALTQ HFSC Beispielkonfiguration (Suche nach 3.3 Sample   Konfiguration) setzen Echtzeitkurven auf innere Klassen und behauptet, dass   diese stellen die garantierte Rate dieser inneren Klassen ein? Ist das nicht?   völlig sinnlos? (Hinweis: pshare legt die Link-Share-Kurve in ALTQ fest   und raspeln Sie die Echtzeitkurve; Sie können dies im obigen Absatz sehen   die Beispielkonfiguration).

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 der Blattklassen berücksichtigt.

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

Was sie meinen ist: Sie können nicht den gesamten Verkehr priorisieren ... Wenn Sie Pakete Priorität geben, müssen andere Pakete in der Priorität verringert werden. Wenn Sie zu viel garantieren, wird der Algorithmus sinnlos. Definieren Sie Klassen, die Prioritäten setzen und Klassen definieren, die leiden können.

Eine Anleitung besagt, dass Sie die gesamte Theorie vergessen sollten. Egal wie   Dinge funktionieren wirklich (Scheduler und Bandbreitenverteilung), stell dir vor   die drei Kurven nach dem folgenden "vereinfachten Denkmodell":   Echtzeit ist die garantierte Bandbreite, die diese Klasse immer bekommt.   Link-Share ist die Bandbreite, die diese Klasse vollständig erreichen möchte   zufrieden, aber die Zufriedenheit kann nicht garantiert werden. Falls da ist   Übermäßige Bandbreite, könnte der Klasse sogar mehr Bandbreite als angeboten werden   notwendig, um zufrieden zu werden, aber es kann nie mehr als verwenden   Obergrenze sagt. Damit das funktioniert, ist die Summe aller Echtzeit   Bandbreiten dürfen nicht über xx% der Liniengeschwindigkeit liegen (siehe Frage oben,   der Prozentsatz variiert). Frage: Ist das mehr oder weniger genau oder a   totales Missverständnis von HSFC?

Das ist richtig.

Und wenn obige Annahme wirklich richtig ist, wo ist die Priorisierung in   dieses Modell? Z.B. Jede Klasse kann eine Echtzeit-Bandbreite haben   (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und eine vielleicht an   Obergrenze, aber immer noch einige Klassen haben höhere Priorität als   andere Klassen. In diesem Fall muss ich noch irgendwie priorisieren   unter Echtzeitverkehr dieser Klassen. Würde ich priorisieren durch die   Steigung der Kurven? Und wenn ja, welche Kurve? Die Echtzeitkurve? Das   Link-Share-Kurve? Die obere Grenzkurve? Alle von ihnen? Würde ich alles geben?   von ihnen die gleiche Steigung oder jeder eine andere und wie man das herausfinden   richtige Steigung?

Der Unterschied zwischen z.B. HFSC und HTB ist, dass HFSC Ihnen erlauben wird genau zu definieren, wie viel Priorisierung Sie haben möchten. Dazu definieren Sie minimale und maximale Grenzen mit dem Wert 'dmax'.


6
2018-01-03 12:05





Abschließend ein Leitfaden, der die meisten Ungereimtheiten zu erklären scheint und auch, wie sich die aktuelle Implementierung von der ursprünglichen unterscheidet:

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

Laut diesem Handbuch sind viele andere Anleitungen und Forenbeiträge über HFSC völlig unsinnig; Es zeigt nur, wie kompliziert HFSC ist, da viele Leute, die Experten zu sein scheinen und HFSC vollständig verstehen, tatsächlich nur partielles Wissen haben und falsche Aussagen machen, basierend auf Missverständnissen des Konzepts und wie all diese Einstellungen zusammenspielen.

Ich denke, ich werde den HFSC endgültig aufgeben. Wenn Sie Ihr HFSC-Setup richtig einrichten können, ist es vielleicht die beste QoS, die Sie bekommen können, aber die Chancen, dass Sie völlig durcheinander kommen, sind viel höher als die Chancen, dass Sie Erfolg haben.


2
2017-12-21 13:38





Wenn Sie nicht in der Lage sind, die ursprünglichen Autoren zu erreichen, dann würde ich das nächste versuchen:

  1. in den Linux-Kernel-Quellbaum gehen und C-Dateien finden, die das "TC-Scheduling-Framework" implementieren
  2. Sehen Sie sich Header an und finden Sie den Autor des Codes.
  3. E-Mail-Programmierer des "TC Scheduling Framework" fragen sie nach Literatur zu ihrer Umsetzung.

Versuchen Sie auch, andere neuere Papiere zu überprüfen, die dieses anführen. Möglicherweise gibt es neuere Arbeiten, die eine Fortsetzung der Forschung in diesem Bereich darstellen und möglicherweise mehr Informationen über die Fragen enthalten, die Sie stellen.


1
2018-05-23 18:27