Lösung 1:
Das Lesen der Artikel über HFSC und seine Cousins ist kein guter Weg, es zu verstehen. Das Hauptziel des HFSC-Papiers ist es, einen rigorosen mathematischen Beweis für seine Behauptungen zu liefern, nicht zu erklären, wie es funktioniert. In der Tat können Sie aus dem HFSC-Papier 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 Beweisen haben, ist es vielleicht eine gute Idee, die Autoren der Papiere zu kontaktieren, andernfalls bezweifle ich, dass sie 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.
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 natürlich beide 256 kbit/s), oder? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit/s geben? Wozu soll das gut sein? Diesen beiden eine höhere Priorität zu geben? Laut Originalarbeit kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende, darum geht es bei HFSC schließlich. Indem Sie beiden Klassen eine Kurve von [256 kbit/s 20 ms 128 kbit/s] geben, haben beide automatisch die doppelte Priorität als A2 und B2 (erhalten immer noch nur 128 kbit/s im Durchschnitt)
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. Er muss dies tun, um eine genaue Bandbreiten- und Latenzzuweisung bereitzustellen. Der Nachteil ist nicht das, was die meisten Menschen intuitiv als fair ansehen . Wenn eine Klasse unter Echtzeit Bandbreite leiht, wenn niemand sie will, wird sie bestraft, wenn jemand anderes sie später zurückhaben will. Das bedeutet unter der Echtzeitgarantie, dass eine Klasse über einen längeren Zeitraum keine Bandbreite erhalten kann, weil sie diese früher verwendet hat, als niemand sie haben wollte.
Das Link-Sharing ist insofern fair, als es eine Klasse nicht dafür bestraft, dass sie freie Bandbreite verwendet. Dies bedeutet jedoch, dass es keine starken Latenzgarantien bieten kann.
Die Trennung der gemeinsamen Nutzung von Links von der Bereitstellung von Latenzgarantien ist das Neue, was HFSC auf den Tisch bringt, und das Papier sagt dies auch in seinem Eröffnungssatz:In diesem Papier untersuchen wir hierarchische Ressourcenverwaltungsmodelle und Algorithmen, die sowohl Link- gemeinsame Nutzung und garantierte Echtzeitdienste mit entkoppelter Verzögerung (Priorität) und Bandbreitenzuweisung. Das Schlüsselwort in diesem Satz ist entkoppelt. Übersetzt bedeutet dies, dass von Ihnen erwartet wird, dass Sie sagen, wie ungenutzte Bandbreite mit ls geteilt werden soll, und angeben, welche Echtzeitgarantien (auch bekannt als Latenzgarantien) mit rt benötigt werden. Die beiden sind orthogonal.
Zählt die Echtzeit-Bandbreite zur Link-Share-Bandbreite?
Ja. In dem HFSC-Papier definieren sie die Bandbreite in Bezug auf das, was die Klasse gesendet hat, seit die Klasse in Rückstand geraten ist (dh Pakete hat, die darauf warten, gesendet zu werden). Der einzige Unterschied zwischen rt und ls besteht darin, dass rt jedes Mal nach vorne schaut, wenn eine Klasse in Rückstand geraten ist, und die niedrigste garantierte Bandbreite aus diesem Satz berechnet, während Link Sharing nur nach dem letzten Mal schaut, als die Klasse in Rückstand geraten 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 immer noch zur Obergrenze und können daher ein Paket, das in der Zukunft unter der Link-Sharing-Bedingung gesendet wird, sehr wohl verzögern. Dies ist ein weiterer Unterschied zwischen Echtzeit und Linkfreigabe.
Unter der Annahme, dass A2 und B2 beide 128 kbit/s haben, 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, was Unterschied?
Ja, es macht einen Unterschied. Wie oben erläutert, wenn Sie Echtzeit verwenden, sind die Latenzen garantiert, aber die Verbindung wird nicht fair geteilt (und insbesondere könnte die Klasse unter Bandbreitenmangel leiden), und die Obergrenzen werden nicht erzwungen. Wenn Sie die Linkfreigabe verwenden, ist die Latenz nicht garantiert, aber die Linkfreigabe ist fair, es besteht kein Hungerrisiko und es wird eine Obergrenze erzwungen. Die Echtzeit wird immer vor der Linkfreigabe überprüft, dies bedeutet jedoch nicht unbedingt, dass die Linkfreigabe ignoriert wird. Das liegt daran, dass Pakete unterschiedlich gezählt werden. Da der Verlauf in Echtzeit berücksichtigt wird, muss ein Paket möglicherweise nicht die Echtzeitgarantie erfüllen (weil eines aus dem Verlauf gezählt wird), es wird jedoch benötigt, um die Linkfreigabe zu erfüllen, da es das historische Paket ignoriert.
Wenn ich die separate Echtzeitkurve verwende, um die Prioritäten der Klassen zu erhöhen, warum brauche ich dann überhaupt "Kurven"? Warum ist Echtzeit kein Flatwert und Link-Share auch ein Flatwert? Warum sind beide Kurven? Die Notwendigkeit von Kurven wird in der Originalarbeit deutlich, da es pro Klasse nur ein Attribut dieser Art gibt. Aber jetzt, wo ich drei Attribute habe (Realtime, Link-Share und Upper-Limit), wozu brauche ich noch Kurven für jedes? Warum sollte die Form der Kurven (nicht die durchschnittliche Bandbreite, sondern ihre Steigungen) für Echtzeit- und Link-Share-Verkehr unterschiedlich sein?
Die Kurve für Echtzeitsteuerungen ermöglicht es Ihnen, eine kurze Latenz für eine bestimmte Verkehrsklasse (z. B. VOIP) gegen eine schlechte 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 dasjenige aus, das das Senden zuerst abschließen wird. Es verwendet jedoch nicht die Bandbreite der Verbindung, um dies zu berechnen, 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 einen 10-fachen Schub gegenüber der konkaven Kurve für E-Mail ergibt, 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 zum Senden einiger Pakete benötigt wird - also Millisekunden. Danach sollte die VOIP-Kurve abflachen, und VOIP wird keinen zukünftigen Schub erhalten, es sei denn, es wird für eine Weile zurückgenommen (was angesichts der Tatsache, dass VOIP eine Anwendung mit geringer Bandbreite ist, sollte). Das Endergebnis von all dem ist sicherzustellen, dass diese ersten paar VOIP-Pakete schneller als alles andere gesendet werden, wodurch VOIP eine niedrige Latenz auf Kosten einer hohen E-Mail-Latenz erhält.
Wie ich bereits sagte, kann die Linkfreigabe keine Latenzgarantien geben, da sie sich nicht mit der Historie befasst. Eine felsenfeste Garantie ist das, was für Echtzeitverkehr wie VOIP benötigt wird. Im Durchschnitt wird eine konvexe Kurve, die von einem Link geteilt wird, jedoch immer noch einen Latenzschub für den Datenverkehr bieten. Es ist nur nicht garantiert. Das ist für die meisten Dinge in Ordnung, z. B. Webverkehr per E-Mail.
Laut der wenigen verfügbaren Dokumentation werden Echtzeit-Kurvenwerte 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 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? (Anmerkung:pshare setzt die Link-Share-Kurve in ALTQ und gruppiert die Echtzeitkurve; Sie können dies im Absatz über der Beispielkonfiguration sehen).
Die Dokumentation ist korrekt. Die Hierarchie (und damit innere Knoten) hat keinerlei Einfluss auf die Berechnung der Echtzeit. Ich kann Ihnen nicht sagen, warum ALTQ offensichtlich davon ausgeht.
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 liegen vielleicht beide falsch?
Beides ist falsch. Wenn 70 % oder 80 % Ihres Datenverkehrs harte Latenzanforderungen haben, die in Echtzeit angegeben werden müssen, können Sie diese mit ziemlicher Sicherheit nicht mit dem von Ihnen verwendeten Link erfüllen. Sie benötigen einen schnelleren Link.
Die einzige Möglichkeit, wie jemand denken könnte, dass 80 % des Datenverkehrs in Echtzeit erfolgen sollten, besteht darin, Echtzeit als Prioritätsschub zu nutzen. Ja, um Latenzgarantien zu bieten, erhöhen Sie tatsächlich die Priorität einiger Pakete. Aber es sollte nur für Millisekunden sein. Das ist alles, was ein Link verkraften kann und trotzdem die Latenzgarantien bietet.
Es gibt sehr wenig Datenverkehr, der Latenzgarantien benötigt. VOIP ist das eine, NTP das andere. Der Rest sollte alles mit Link-Sharing erledigt werden. Wenn Sie möchten, dass das Internet schnell ist, machen Sie es schnell, indem Sie ihm die meiste Link-Kapazitä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 (Scheduler und Bandbreitenverteilung), stellen Sie sich die drei Kurven gemäß dem folgenden "vereinfachten Gedankenmodell" vor:Echtzeit ist die garantierte Bandbreite, die diese Klasse immer erhalten wird. Link-Share ist die Bandbreite, die diese Klasse haben möchte vollkommen zufrieden, aber die Zufriedenheit kann nicht garantiert werden. Falls es zu viel Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite als nötig angeboten, um zufrieden zu sein, aber sie darf nie mehr als die Obergrenze angeben. Damit das alles funktioniert, darf die Summe aller Echtzeitbandbreiten nicht über xx% der Leitungsgeschwindigkeit liegen (siehe obige Frage, der Prozentsatz variiert). Frage:Ist das mehr oder weniger genau oder ein totales Missverständnis von HSFC?
Es ist eine gute Beschreibung der Obergrenze. Die Beschreibung der Linkfreigabe ist zwar streng korrekt, aber irreführend. Während True Link Share nicht die harten Latenzgarantien gibt, wie dies bei Echtzeit der Fall ist, gibt es der Klasse seine Bandbreite besser zu als seine Konkurrenten wie CBQ und HTB. Wenn Sie also sagen, dass das Teilen von Links "keine Garantien bietet", hält es es auf einem höheren Standard als jeder andere Planer.
Die Beschreibung der Echtzeit ist zwar genau, aber so irreführend, dass ich sie als falsch bezeichnen würde. Wie der Name schon sagt, besteht der Zweck von Echtzeit nicht darin, eine garantierte Bandbreite bereitzustellen. Es soll eine garantierte Latenz bieten – dh das Paket wird JETZT gesendet, nicht irgendeine zufällige Zeitspanne später, je nachdem, wie die Verbindung verwendet wird. Der meiste Datenverkehr benötigt keine garantierte Latenzzeit.
Allerdings gibt Echtzeit auch keine perfekte Latenzgarantie. Es könnte, wenn der Link nicht auch von Link Share verwaltet würde, aber die meisten Benutzer möchten die zusätzliche Flexibilität, beides zu haben, und es ist nicht kostenlos. Die Echtzeit kann ihre Latenzfrist um die Zeit verfehlen, die zum Senden eines MTU-Pakets benötigt wird. (Wenn es passiert, liegt es daran, dass sich ein MTU-Paket Link Share eingeschlichen hat, während der Link in Echtzeit im Leerlauf gehalten wurde, falls es ein Paket mit einer kurzen Frist erhalten hat, 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, wodurch weniger als 100 % der Verbindungsauslastung bereitgestellt wird. Die Verbindungsfreigabe verwendet immer 100 % der verfügbaren Verbindungskapazität. Im Gegensatz zu Echtzeit , es kann als "arbeitserhaltend" bezeichnet werden.)
Der Grund, warum man sagen kann, dass Echtzeit harte Latenzgarantien bietet, ist, dass die Verzögerung begrenzt ist. Wenn Sie also versuchen, eine 20-ms-Latenzgarantie auf einer 1-Mbit/s-Verbindung anzubieten, und die Linkfreigabe Pakete in MTU-Größe (1500 Byte) sendet, wissen Sie, dass eines dieser Pakete 12 ms zum Senden benötigt. Wenn Sie also in Echtzeit sagen, dass Sie eine Latenzzeit von 8 ms wünschen, können Sie immer noch die Frist von 20 ms einhalten – mit einer absoluten Garantie.
Und wenn die obige Annahme wirklich richtig ist, wo bleibt dann die Priorisierung in diesem Modell? Z.B. Jede Klasse kann eine Echtzeit-Bandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und möglicherweise eine Obergrenze haben, aber dennoch haben einige Klassen höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich immer noch 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 obere Grenzkurve? Alle von ihnen? Würde ich allen die gleiche Neigung geben oder jedem eine andere und wie finde ich die richtige Neigung heraus?
Es gibt kein Priorisierungsmodell. Ernsthaft. Wenn Sie dem Datenverkehr absolute Prioritäten geben möchten, verwenden Sie pfifo. Dafür ist es da. Beachten Sie jedoch auch, dass, wenn Sie dem Webverkehr absolute Priorität gegenüber dem E-Mail-Verkehr geben, dies bedeutet, dass der Webverkehr den Link sättigt und somit keine E-Mail-Pakete überhaupt durchkommen . 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. Aber es wird alles sein. Im Übrigen erlaubt Ihnen HFSC zu sagen:"Auf einer überlasteten Verbindung 90 % dem Web zuweisen und 10 % E-Mail durchsickern lassen, und oh, schnell das eine oder andere DNS-Paket senden, aber lassen Sie mich nicht damit beschimpfen."
Lösung 2:
Sie könnten die Kurven mit unterschiedlichen Namen definieren:
- RT, Echtzeitkurve, Bandbreiten-/Verzögerungsgarantie.
- ls, Link-Share-Kurve, Bandbreiten-/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 erhält 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), oder? Warum sollte ich A1 und B1 zusätzlich eine Echtzeitkurve mit 128 kbit/s geben? Wozu soll das gut sein? Diesen beiden eine höhere Priorität zu geben? Laut Originalarbeit kann ich ihnen eine höhere Priorität geben, indem ich eine Kurve verwende, darum geht es bei HFSC schließlich. Indem Sie beiden Klassen eine Kurve von [256 kbit/s 20 ms 128 kbit/s] geben, haben beide automatisch die doppelte Priorität als A2 und B2 (erhalten immer noch nur 128 kbit/s im Durchschnitt)
Wenn Sie in HFSC eine Definition nur mit Raten vornehmen, wird 'dmax' automatisch auf 0 gesetzt. Das bedeutet im Grunde, 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, da der Algorithmus sonst nicht genau herausfinden kann, wie viel Priorität eine Klasse erhalten sollte.
Immer wenn Sie Paketen Priorität geben, muss die Priorität anderer Pakete verringert werden. Basierend auf den 'dmax'- und 'rate'-Werten werden alle Klassen unter Verwendung virtueller Timer gemultiplext. Siehe tc-hfsc(7) für weitere Informationen.
Zählt die Echtzeit-Bandbreite zur Link-Share-Bandbreite? Z.B. Wenn A1 und B1 beide nur 64 kbit/s Echtzeit- und 64 kbit/Slink-Share-Bandbreite haben, bedeutet das, sobald sie 64 kbit/s über Echtzeit bedient werden, ihre Link-Share-Anforderung ebenfalls erfüllt ist (sie erhalten möglicherweise überschüssige Bandbreite, aber ignorieren wir das für eine Sekunde) oder bedeutet das, dass sie weitere 64 kbit / s über Link-Share erhalten? Hat jede Klasse also eine "Anforderung" an Bandbreite 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 (aktuelle Link-Share-Anforderung gleich spezifizierter Link-Share-Anforderung minus Echtzeitbandbreite, die dieser Klasse bereits bereitgestellt wird)? /P>
Wenn der Fluss die Grenzen der Link-Share-Definition der Klasse nicht überschreitet, wird die Echtzeitkurve nie verwendet. Das Definieren einer Echtzeitkurve ermöglicht Ihnen in diesem Fall z. B.:ein bestimmtes 'dmax' zu garantieren.
Wenn Ihre Link-Share-Definitionen fehlerfrei sind, brauchen Sie keine Echtzeitkurven. Sie könnten einfach Servicekurven (sc) definieren, aber das würde Ihre Konfiguration erschweren.
Wird die obere Grenzkurve auch auf Echtzeit angewendet, nur auf Link-Share oder vielleicht auf beide? Einige Tutorials sagen so, manche sagen anders. 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 Link-Share angewendet, wenn Sie eine Obergrenzenkurve definieren, MÜSSEN Sie eine Link-Share-Kurve definieren. Die Obergrenzenkurve der Elternklassen wird jedoch immer noch angewendet.
Unter der Annahme, dass A2 und B2 beide 128 kbit/s haben, 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, was 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. Wenn Pakete in A2 klassifiziert werden, werden sie sofort verarbeitet. Die Echtzeitkurve von B2 wird aber trotzdem dafür sorgen, 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 Flatwert und Link-Share auch ein Flatwert? Warum sind beide Kurven? Die Notwendigkeit von Kurven wird in der Originalarbeit deutlich, da es pro Klasse nur ein Attribut dieser Art gibt. Aber jetzt, wo ich drei Attribute habe (Realtime, Link-Share und Upper-Limit), wozu brauche ich noch Kurven für jedes? Warum sollte die Form der Kurven (nicht die durchschnittliche Bandbreite, sondern ihre Steigungen) für Echtzeit- und Link-Share-Verkehr unterschiedlich sein?
Echtzeitkurven teilen den Verkehr nicht zwischen benachbarten Blättern auf, Link-Share-Kurven tun dies.
Laut der wenigen verfügbaren Dokumentation werden Echtzeit-Kurvenwerte 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 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? (Anmerkung:pshare setzt die Link-Share-Kurve in ALTQ und gruppiert die Echtzeitkurve; Sie können dies im Absatz über der Beispielkonfiguration sehen).
Echtzeitkurven werden zwar für innere Klassen ignoriert, sie werden nur auf Blattklassen angewendet. Die in diesen inneren Klassen definierten Echtzeitkurven werden jedoch für Berechnungen in den 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 liegen vielleicht beide falsch?
Was sie bedeuten ist:Sie können nicht den gesamten Datenverkehr 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 Klassen, die priorisiert werden, und definieren Sie Klassen, die darunter leiden können.
Ein Tutorial sagte, Sie sollen 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 erhalten wird. Link-Share ist die Bandbreite, die diese Klasse haben möchte vollkommen zufrieden, aber die Zufriedenheit kann nicht garantiert werden. Falls es zu viel Bandbreite gibt, wird der Klasse möglicherweise sogar mehr Bandbreite als nötig angeboten, um zufrieden zu sein, aber sie darf nie mehr als die Obergrenze angeben. Damit das alles funktioniert, darf die Summe aller Echtzeitbandbreiten nicht über xx% der Leitungsgeschwindigkeit liegen (siehe obige Frage, 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 richtig ist, wo bleibt dann die Priorisierung in diesem Modell? Z.B. Jede Klasse kann eine Echtzeit-Bandbreite (garantiert), eine Link-Share-Bandbreite (nicht garantiert) und möglicherweise eine Obergrenze haben, aber dennoch haben einige Klassen höhere Prioritätsanforderungen als andere Klassen. In diesem Fall muss ich immer noch 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 obere Grenzkurve? Alle von ihnen? Würde ich allen die gleiche Neigung geben oder jedem eine andere und wie finde ich die richtige Neigung heraus?
Der Unterschied zwischen z. HFSC und HTB ist, dass Sie mit HFSC genau definieren können, wie viel Priorisierung Sie haben möchten. Sie tun dies, indem Sie minimale und maximale Grenzen mit dem 'dmax'-Wert definieren.
Lösung 3:
Endlich ein Leitfaden, der die meisten Inkonsistenzen zu erklären scheint und auch, wie sich die aktuelle Implementierung vom Originalpapier unterscheidet:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
Laut dieser Anleitung sind viele andere Anleitungen und Forenbeiträge über HFSC völliger Unsinn; Es zeigt nur, wie kompliziert HFSC ist, da viele Leute, die Experten zu sein scheinen und vorgeben, HFSC vollständig verstanden zu haben, in Wirklichkeit nur ein Teilwissen haben und falsche Aussagen machen, die auf einem Missverständnis des Konzepts und dem Zusammenspiel all dieser Einstellungen beruhen. P>
Ich denke, ich werde HFSC endlich aufgeben. Wenn Sie Ihr HFSC-Setup richtig hinbekommen, ist es vielleicht die beste QoS, die Sie bekommen können, aber die Chancen, dass Sie es komplett vermasseln, sind viel höher als die Chancen, dass Sie Erfolg haben.