有人真正了解 Linux/BSD 中的 HFSC 調度是如何工作的嗎？
我閱讀了關於 HFSC 的原始SIGCOMM ‘97 PostScript 論文，它非常技術性，但我了解基本概念。您可以指定凸或凹服務曲線，而不是給出線性服務曲線（與幾乎所有其他調度算法一樣），因此可以將頻寬和延遲解耦。然而，即使本文提到了正在使用的調度算法（實時和鏈路共享），它總是只提到每個調度類的一條曲線（解耦是通過指定這條曲線來完成的，只需要一條曲線） ）。
現在已經使用ALTQ 調度框架為 BSD（OpenBSD、FreeBSD 等）實現了 HFSC，並且已經使用TC 調度框架（iproute2 的一部分）在 Linux 上實現了它。兩種實現都添加了兩條額外的服務曲線，這在原始論文中是**沒有的！**實時服務曲線和上限服務曲線。再次請注意，原始論文提到了兩種調度算法（實時和連結共享），但在那篇論文中，它們都使用一個單一的服務曲線。正如您目前在 BSD 和 Linux 中發現的那樣，從來沒有兩條獨立的服務曲線。
更糟糕的是，某些版本的 ALTQ 似乎為 HSFC 添加了額外的隊列優先級（原始論文中也沒有優先級這樣的東西）。我發現有幾個 BSD HowTo 提到了這個優先級設置（儘管最新的 ALTQ 版本的手冊頁不知道 HSFC 的這個參數，所以正式它甚至不存在）。
這一切都使得 HFSC 調度比原始論文中描述的算法更加複雜，並且網際網路上有大量的教程經常相互矛盾，其中一個聲稱與另一個相反。這可能是為什麼似乎沒有人真正了解 HFSC 調度的真正工作原理的主要原因。在我提出問題之前，我們需要某種範例設置。我將使用一個非常簡單的方法，如下圖所示：
替代文字 http://f.imagehost.org/0177/hfsc-test-setup.png
以下是一些我無法回答的問題，因為教程相互矛盾：
- 我到底需要什麼實時曲線？假設 A1、A2、B1、B2 都是 128 kbit/s 的鏈路共享（其中任何一個都沒有實時曲線），那麼如果根有 512 kbit/s 分配（並且A 和 B 當然都是 256 kbit/s），對吧？為什麼還要給 A1 和 B1 一個 128 kbit/s 的實時曲線？這有什麼好處？給這兩個更高的優先級？根據原始論文，我可以通過使用曲線給它們更高的優先級，畢竟這就是 HFSC 的意義所在。通過給兩個類一個曲線
$$ 256kbit/s 20ms 128kbit/s $$兩者的優先級都是 A2 和 B2 的兩倍（平均仍然只有 128 kbit/s） 2. 實時頻寬是否計入鏈路共享頻寬？例如，如果 A1 和 B1 都只有 64kbit/s 的實時頻寬和 64kbit/s 的鏈路共享頻寬，這是否意味著一旦通過實時為它們提供 64kbit/s 的服務，它們的鏈路共享要求也得到了滿足（他們可能獲得額外的頻寬，但讓我們暫時忽略它）或者這是否意味著他們通過連結共享獲得了另外的 64 kbit/s？那麼每個類是否都有實時加連結共享的頻寬“要求”？或者，如果鏈路共享曲線高於實時曲線（目前鏈路共享要求等於指定的鏈路共享要求減去已經提供給此的實時頻寬），一個類是否只具有比實時曲線更高的要求？班級）？ 3. 上限曲線是否也適用於實時，僅適用於連結共享，或者可能適用於兩者？有些教程說一種方式，有些人說另一種方式。甚至有人聲稱上限是實時頻寬+鏈路共享頻寬的最大值？真相是什麼？ 4. 假設 A2 和 B2 都是 128 kbit/s，如果 A1 和 B1 僅是 128 kbit/s 鏈路共享，或 64 kbit/s 實時和 128 kbit/s 鏈路共享，是否有任何區別？ ，有什麼區別？ 5. 如果我使用單獨的實時曲線來增加類的優先級，我為什麼需要“曲線”呢？為什麼實時不是一個固定值，連結共享也是一個固定值？為什麼兩條曲線？原始論文中明確需要曲線，因為每個類只有一個此類屬性。但是現在，有了三個屬性（實時、連結共享和上限），我還需要每個屬性上的曲線做什麼？為什麼我希望曲線形狀（不是平均頻寬，而是它們的斜率）對於實時和連結共享流量是不同的？ 6. 根據可用的少量文件，內部類（A 類和 B 類）的實時曲線值完全被忽略，它們僅適用於葉類（A1、A2、B1、B2）。如果這是真的，為什麼ALTQ HFSC 範例配置（搜尋3.3 範例配置）設置內部類的實時曲線並聲稱這些設置了這些內部類的保證速率？這不是完全沒有意義嗎？（注意：pshare 在 ALTQ 中設置鏈路共享曲線並光柵化實時曲線；您可以在範例配置上方的段落中看到這一點）。 7. 有的教程說所有實時曲線的總和不能高於線速的80%，也有的說不能高於線速的70%。哪一個是對的，或者他們可能都錯了？ 8. 一個教程說你會忘記所有的理論。不管事情真的如何運作（調度程序和頻寬分配），根據下面的“簡化思維模型”想像這三條曲線：實時是此類將始終獲得的保證頻寬。link-share 是這個類想要完全滿足的頻寬，但是不能保證滿足。如果有多餘的頻寬，該類甚至可能會獲得比滿足所需更多的頻寬，但它可能永遠不會使用超過上限所說的。要使所有這些工作，所有實時頻寬的總和可能不會超過線路速度的 xx%（請參閱上面的問題，百分比會有所不同）。問題：這或多或少是準確的還是對 HSFC 的完全誤解？ 9. 如果上述假設確實準確，那麼該模型中的優先級在哪裡？例如，每個類可能有一個實時頻寬（保證）、一個鏈路共享頻寬（不保證）和一個上限，但仍然有一些類比其他類具有更高的優先級需求。在那種情況下，我仍然必須以某種方式優先考慮，即使在這些類的實時流量中也是如此。我會按曲線的斜率優先考慮嗎？如果是這樣，哪條曲線？實時曲線？連結份額曲線？上限曲線？他們都是？我會給它們所有人相同的斜率還是每個不同的斜率以及如何找出正確的斜率？
我仍然沒有失去希望，這個世界上至少存在一群真正了解 HFSC 並能夠準確回答所有這些問題的人。這樣做而不在答案中相互矛盾會非常好;-)
閱讀有關 HFSC 及其表親的論文並不是理解它的好方法。HFSC 論文的主要目標是為其聲明提供嚴格的數學證明，而不是解釋其工作原理。事實上，您無法僅從 HFSC 論文中理解它是如何工作的，您還必須閱讀它所引用的論文。如果您對索賠或其證明有疑問，那麼聯繫論文的作者可能是個好主意，否則我懷疑他們會不會有興趣收到您的來信。
我已經為 HFSC 編寫了教程。如果我在下面的解釋不清楚，請閱讀它。
我到底需要什麼實時曲線？假設 A1、A2、B1、B2 都是 128 kbit/s 的鏈路共享（其中任何一個都沒有實時曲線），那麼如果根有 512 kbit/s 分配（並且A 和 B 當然都是 256 kbit/s），對吧？為什麼還要給 A1 和 B1 一個 128 kbit/s 的實時曲線？這有什麼好處？給這兩個更高的優先級？根據原始論文，我可以通過使用曲線來賦予它們更高的優先級，畢竟這就是 HFSC 的全部意義所在。通過給兩個類一個曲線
$$ 256kbit/s 20ms 128kbit/s $$兩者的優先級都是 A2 和 B2 的兩倍（平均仍然只有 128 kbit/s）
實時曲線和鏈路共享曲線以不同的方式評估。實時曲線考慮了一個班級在其整個歷史中所做的事情。它必須這樣做才能提供準確的頻寬和延遲分配。缺點不是大多數人直覺地認為是公平的。在實時情況下，如果一個類在其他人不想要它的時候借用頻寬，那麼當其他人想要它回來時它就會受到懲罰。這意味著在實時保證下，一個類可以在很長一段時間內得不到頻寬，因為它在沒有人想要的時候使用它。
連結共享是公平的，因為它不會因為使用空閒頻寬而懲罰一個類。然而，這意味著它不能提供強大的延遲保證。
將鏈路共享與提供延遲保證分開是 HFSC 帶來的新事物，該論文在開場白中說了很多：在本文中，我們研究了支持鏈路共享和保證的分層資源管理模型和算法具有解耦延遲（優先級）和頻寬分配的實時服務。 那句話中的關鍵詞是解耦的。翻譯後，這意味著您應該說明如何與 ls 共享未使用的頻寬，並指定 rt 需要哪些實時保證（也稱為延遲保證）。兩者是正交的。
實時頻寬是否計入鏈路共享頻寬？
是的。在 HFSC 論文中，他們根據自類已積壓（即有數據包等待發送）以來類已發送的內容來定義頻寬。rt 和 ls 之間的唯一區別是 rt 從每次類積壓的時間開始向前看，並從該集合中計算最低保證頻寬，而連結共享只從類的最後一次積壓開始看。所以 rt 比 ls 考慮更多的字節，但是 ls 考慮的每個字節也被 rt 考慮。
上限曲線是否也適用於實時，僅適用於連結共享，或者可能適用於兩者？
上限不停止發送數據包以滿足實時條件。在實時條件下發送的包仍然計入上限，因此將來可能會延遲在鏈路共享條件下發送的包。這是實時和連結共享之間的另一個區別。
假設 A2 和 B2 都是 128 kbit/s，如果 A1 和 B1 僅是 128 kbit/s 鏈路共享，或 64 kbit/s 實時和 128 kbit/s 鏈路共享，是否有任何區別？ ，有什麼區別？
是的，它確實有所作為。如上所述，如果您使用實時，則可以保證延遲，但不能公平地共享連結（特別是該類可能會遭受頻寬不足），並且不強制執行上限。如果您使用連結共享，則無法保證延遲，但連結共享是公平的，沒有飢餓的風險，並且強制執行上限。在連結共享之前總是檢查實時，但這並不意味著連結共享將被忽略。那是因為數據包的計數方式不同。由於歷史是實時考慮的，因此一個數據包可能不需要滿足實時保證（因為從歷史中計算了一個），但需要滿足鏈路共享，因為它忽略了歷史數據包。
如果我使用單獨的實時曲線來增加類的優先級，我為什麼需要“曲線”呢？為什麼實時不是一個固定值，連結共享也是一個固定值？為什麼兩條曲線？原始論文中明確需要曲線，因為每個類只有一個此類屬性。但是現在，有了三個屬性（實時、連結共享和上限），我還需要每個屬性上的曲線做什麼？為什麼我希望曲線形狀（不是平均頻寬，而是它們的斜率）對於實時和連結共享流量是不同的？
實時控製曲線允許您用一個特定流量類別（例如 VOIP）的緊延遲來換取其他流量類別（例如電子郵件）的低延遲。當決定在實時約束下發送哪個數據包時，HFSC 會選擇最先完成發送的數據包。但是，它不使用鏈路的頻寬來計算它，它使用實時曲線分配的頻寬。因此，如果我們有相同長度的 VOIP 和電子郵件數據包，並且 VOIP 數據包有一個凸曲線，如果電子郵件的凹曲線有 10 倍的提升，那麼將在第一個電子郵件數據包之前發送 10 個 VOIP 數據包。但這僅發生在突發時間，最多應該是發送幾個數據包所需的時間 - 即毫秒。此後 VOIP 曲線應該變平，並且 VOIP 將不會在未來得到任何提升，除非它退出一段時間（鑑於 VOIP 是一種低頻寬應用程序，它應該）。所有這一切的最終結果是確保前幾個 VOIP 數據包的發送速度比其他任何東西都快，從而以電子郵件獲得高延遲為代價提供 VOIP 低延遲。
正如我之前所說，由於連結共享不查看歷史記錄，因此無法提供延遲保證。像 VOIP 這樣的實時流量需要堅如磐石的保證。但是，平均而言，連結共享凸曲線仍會為其流量提供延遲提升。只是不能保證。這對大多數事情都很好，例如通過電子郵件的網路流量。
根據可用的少量文件，內部類（A 類和 B 類）的實時曲線值完全被忽略，它們僅適用於葉類（A1、A2、B1、B2）。如果這是真的，為什麼 ALTQ HFSC 範例配置（搜尋 3.3 範例配置）設置內部類的實時曲線並聲稱這些設置了這些內部類的保證速率？這不是完全沒有意義嗎？（注意：pshare 在 ALTQ 中設置鏈路共享曲線並光柵化實時曲線；您可以在範例配置上方的段落中看到這一點）。
文件是正確的。層次結構（以及內部節點）對實時計算沒有任何影響。我不能告訴你為什麼 ALTQ 顯然認為它確實如此。
有的教程說所有實時曲線的總和不能高於線速的80%，也有的說不能高於線速的70%。哪一個是對的，或者他們可能都錯了？
兩者都是錯誤的。如果 70% 或 80% 的流量具有必須實時指定的硬延遲要求，那麼現實情況是，您幾乎可以肯定您使用的連結無法滿足它們。您需要更快的連結。
有人認為指定 80% 的流量應該是實時的唯一方法是，如果他們將實時作為優先級提升。是的，為了提供延遲保證，您實際上是在提高某些數據包的優先級。但它應該只有幾毫秒。這就是連結可以處理的所有內容，並且仍然提供延遲保證。
很少有流量需要延遲保證。VOIP 是一個，NTP 是另一個。其餘的都應該通過連結共享來完成。如果您希望網路快速，您可以通過為其分配大部分連結容量來使其快速。從長遠來看，這一份額**是有保證的。**如果您希望它具有低延遲（平均而言），請在連結共享下給它一個凸曲線。
一個教程說你會忘記所有的理論。不管事情真的如何運作（調度程序和頻寬分配），根據下面的“簡化思維模型”想像這三條曲線：實時是此類將始終獲得的保證頻寬。link-share 是這個類想要完全滿足的頻寬，但是不能保證滿足。如果有多餘的頻寬，該類甚至可能會獲得比滿足所需更多的頻寬，但它可能永遠不會使用超過上限所說的。要使所有這些工作，所有實時頻寬的總和可能不會超過線路速度的 xx%（請參閱上面的問題，百分比會有所不同）。問題：這或多或少是準確的還是對 HSFC 的完全誤解？
這是一個很好的描述上限。雖然連結共享描述是嚴格準確的，但它具有誤導性。雖然它真正的連結共享並沒有像實時那樣提供硬延遲保證，但它在為類分配頻寬方面做得比它的競爭對手（如 CBQ 和 HTB）更好。因此，在說連結共享“不提供保證”時，它將其保持在任何其他調度程序可以提供的更高標準。
實時的描述設法既準確，但誤導我認為它是錯誤的。顧名思義，實時的目的不是保證頻寬。這是為了提供有保證的延遲 - 即現在發送數據包，而不是稍後發送的隨機時間量，具體取決於連結的使用方式。大多數流量不需要保證延遲。
也就是說，實時也不能提供完美的延遲保證。如果連結也不是由連結共享管理的，它可以，但大多數使用者希望同時擁有兩者的額外靈活性，而且它不是免費的。發送一個 MTU 數據包所需的時間，實時可能會錯過它的延遲期限。（如果發生這種情況，那將是因為它是一個 MTU 數據包鏈路共享偷偷進入，同時實時保持鏈路空閒，以防它收到的數據包的截止日期很短，必須立即發送。這是鏈路共享之間的另一個區別和實時。為了提供保證，即使有數據包要發送，實時也可能故意保持線路空閒，從而提供低於 100% 的鏈路使用率。鏈路共享總是使用 100% 的鏈路可用容量。與實時不同,
可以說實時提供硬延遲保證的原因是延遲是有限的。因此，如果您嘗試在 1Mbit/sec 鏈路上提供 20ms 延遲保證，並且鏈路共享正在發送 MTU 大小（1500 字節）的數據包，那麼您知道其中一個數據包需要 12ms 才能發送。因此，如果您告訴實時您想要 8 毫秒的延遲，您仍然可以滿足 20 毫秒的最後期限 - 絕對保證。
如果上述假設確實準確，那麼該模型中的優先級在哪裡？例如，每個類可能有一個實時頻寬（保證）、一個鏈路共享頻寬（不保證）和一個上限，但仍然有一些類比其他類具有更高的優先級需求。在那種情況下，我仍然必須以某種方式優先考慮，即使在這些類的實時流量中也是如此。我會按曲線的斜率優先考慮嗎？如果是這樣，哪條曲線？實時曲線？連結份額曲線？上限曲線？他們都是？我會給它們所有人相同的斜率還是每個不同的斜率以及如何找出正確的斜率？
沒有優先級模型。嚴重地。如果您想給予流量絕對優先級，請使用 pfifo。這就是它的用途。但也要注意，如果您將網路流量絕對優先於電子郵件流量，這意味著讓網路流量使連結飽和，因此根本沒有電子郵件數據包通過。然後，您所有的電子郵件連接都會消失。
實際上，沒有人想要這種優先順序。他們想要的是 HFSC 提供的。如果你真的有實時流量，HFSC 會提供。但這將是一切。對於其餘部分，HFSC 允許您說“在擁塞的連結上，將 90% 分配給網路，讓電子郵件以 10% 的速度發送，哦，快速發送奇怪的 DNS 數據包，但不要讓別人用它來攻擊我。”