现在使用ALTQ scheduling framework已经为BSD(OpenBSD,FreeBSD等)实现了HFSC,并且已经使用TC scheduling framework(iproute2的一部分)实现了Linux.两种实现都添加了两条额外的服务曲线,这些曲线不在原始论文中！实时服务曲线和上限服务曲线.再次请注意,原始论文提到了两种调度算法(实时和链接共享),但在该论文中,两者都使用一条服务曲线.目前在BSD和Linux中找不到两个独立的服务曲线.
更糟糕的是,某些版本的ALTQ似乎为HSFC增加了一个额外的队列优先级(在原始论文中也没有优先权).我发现有几个BSD HowTo提到了这个优先级设置(即使最新的ALTQ版本的手册页不知道HSFC的这样的参数,所以官方它甚至不存在).
这一切都使得HFSC调度比原始论文中描述的算法更复杂,并且互联网上有大量的教程经常相互矛盾,其中一个声称与另一个相反.这可能是没有人真正理解HFSC调度真正起作用的主要原因.在我提出问题之前,我们需要一些样本设置.我将使用一个非常简单的,如下图所示：
alt text http://f.imagehost.org/0177/hfsc-test-setup.png
以下是一些我无法回答的问题,因为这些教程相互矛盾：
>我该怎么做才能获得实时曲线？假设A1,A2,B1,B2均为128 kbit / s链路共享(任何一个都没有实时曲线),那么如果根分配512 kbit / s,则每个将获得128 kbit / s(和A和B当然都是256 kbit / s),对吗？为什么我还要给出A1和B1一条128 kbit / s的实时曲线？这有什么好处？为了这两个更优先考虑？根据原始论文,我可以通过使用曲线给予他们更高的优先级,这毕竟是HFSC的意义所在.通过给两个类提供[256kbit / s 20ms 128kbit / s]的曲线,两者的优先级都比A2和B2高两倍(平均只有128 kbit / s)
>实时带宽是否计入链路共享带宽？例如.如果A1和B1都只有64kbit / s的实时和64kbit / s链路共享带宽,这意味着一旦它们通过实时服务64kbit / s,他们的链路共享要求也会得到满足(他们可能会得到)多余的带宽,但让我们忽略一秒)或者这是否意味着他们通过链接共享得到另一个64 kbit / s？那么每个类都有实时加链接共享的带宽“要求”吗？或者,如果链路共享曲线高于实时曲线,则类别仅比实时曲线具有更高的要求(当前链路共享要求等于指定的链路共享要求减去已提供给此的实时带宽类)？
>上限曲线是否也适用于实时,仅适用于链接共享,或者可能同时适用于两者？一些教程说一种方式,一些说另一种方式.有些甚至声称上限是实时带宽链路共享带宽的最大值？真相是什么？
>假设A2和B2均为128 kbit / s,如果A1和B1仅为128 kbit / s链路共享,或64 kbit / s实时和128 kbit / s链路共享,则会有所不同吗？那么,有什么区别？
>如果我使用单独的实时曲线来增加类的优先级,为什么我需要“曲线”呢？为什么实时不是实时平价值,链接共享也是平价值？为什么两条曲线？原始论文中对曲线的需求很清楚,因为每个类只有一种属性.但是现在,有三个属性(实时,链接共享和上限)我还需要每个曲线吗？为什么我希望曲线形状(不是平均带宽,但它们的斜率)对于实时和链路共享流量是不同的？
>根据可用的小文档,内部类(A类和B类)完全忽略实时曲线值,它们仅适用于叶类(A1,B2).如果这是真的,为什么ALTQ HFSC sample configuration(搜索3.3样本配置)在内部类上设置实时曲线并声称那些设置了这些内部类的保证率？这不完全没有意义吗？ (注意：pshare在ALTQ中设置链接共享曲线并记录实时曲线;您可以在示例配置上方的段落中看到这一点).
>有些教程说所有实时曲线的总和可能不高于线速度的80％,其他人说它不得高于线速度的70％.哪一个是对的还是他们可能都错了？
>一个教程说你将忘记所有的理论.无论事情如何真正起作用(调度程序和带宽分布),根据以下“简化思维模型”设想三条曲线：实时是此类始终获得的保证带宽. link-share是该类希望完全满足的带宽,但不能保证满意.如果有多余的带宽,该类甚至可能获得比满足要求更多的带宽,但它可能永远不会超过上限.为了使所有这些工作,所有实时带宽的总和可能不高于线速度的xx％(参见上面的问题,百分比变化).问题：这或多或少准确或对HSFC完全误解？
>如果上述假设真的准确,那么该模型中的优先级在哪里？例如.每个类可能具有实时带宽(保证),链路共享带宽(不保证)和可能的上限,但仍然有些类比其他类具有更高的优先级需求.在那种情况下,我仍然必须以某种方式确定优先顺序,即使在这些类的实时流量中也是如此.我会优先考虑曲线的斜率吗？如果是这样,哪条曲线？实时曲线？链接共享曲线？上限曲线？他们都是？我会给他们所有人提供相同的坡度或者每个人不同的坡度以及如何找到合适的坡度吗？
我仍然没有失去希望,在这个世界上至少有一群人真正了解HFSC并能够准确地回答所有这些问题.这样做而不会在答案中相互矛盾,这将是非常好的;-)
解决方法
我写了一篇tutorial for HFSC.如果我的解释不清楚,请阅读.
What for do I need a real-time curve at all? Assuming A1,B2
are all 128 kbit/s link-share (no real-time curve for either one),
then each of those will get 128 kbit/s if the root has 512 kbit/s to
distribute (and A and B are both 256 kbit/s of course),right? Why
would I additionally give A1 and B1 a real-time curve with 128 kbit/s?
What would this be good for? To give those two a higher priority?
According to original paper I can give them a higher priority by using
a curve,that’s what HFSC is all about after all. By giving both
classes a curve of [256kbit/s 20ms 128kbit/s] both have twice the
priority than A2 and B2 automatically (still only getting 128 kbit/s
on average)
实时曲线和链路共享曲线以不同方式进行评估.实时曲线考虑了一个班级在整个历史中所做的事情.必须这样做才能提供准确的带宽和延迟分配.缺点不是大多数人直觉地认为是公平的.在实时的情况下,如果一个类在没有其他人想要的时候借用带宽,那么当别人以后想要它时它会受到惩罚.这意味着在实时保证下,一个类可以长时间不带宽,因为它在没有人想要的时候使用它.
链路共享是公平的,因为它不会因使用备用带宽而惩罚类.但这意味着它无法提供强大的延迟保证.
链接共享与提供延迟保证的分离是HFSC带来的新事物,本文在其开头句中说了很多：在本文中,我们研究了支持链接共享和保证的分层资源管理模型和算法.具有解耦延迟(优先级)和带宽分配的实时服务.该句中的关键词是分离的.翻译,这意味着您需要说明如何与ls共享未使用的带宽,并指定rt需要什么实时保证(也称延迟保证).这两者是正交的.
Does the real-time bandwidth count towards the link-share bandwidth?
是.在HFSC文件中,他们根据类已经发送积压的内容(即包等待发送)来定义带宽. rt和ls之间的唯一区别是rt期待从每次时间类积压并从该集合计算最低保证带宽,而链接共享仅从上次课程积压时查看.因此rt比ls考虑更多的字节,但是每个字节ls考虑也被rt考虑.
Is upper limit curve applied to real-time as well,only to link-share,
or maybe to both?
上限不会阻止发送数据包以满足实时条件.在实时条件下发送的分组仍然计入上限,因此可能很好地延迟将来在链路共享条件下发送的分组.这是实时和链接共享之间的另一个区别.
Assuming A2 and B2 are both 128 kbit/s,does it make any difference if
A1 and B1 are 128 kbit/s link-share only,or 64 kbit/s real-time and
128 kbit/s link-share,and if so,what difference?
是的,它确实有所作为.如上所述,如果你使用实时,延迟是有保证的,但链接不公平共享(特别是类可能遭受带宽饥饿),并且不强制执行上限.如果您使用链接共享,则无法保证延迟,但链接共享是公平的,不存在饥饿风险,并且强制执行上限.在链接共享之前始终检查实时,但这并不意味着将忽略链接共享.那是因为数据包的计数方式不同.由于历史是实时考虑的,因此可能不需要数据包来满足实时保证(因为从历史中包括一个计数),但是需要满足链接共享,因为它忽略了历史数据包.
If I use the seperate real-time curve to increase priorities of
classes,why would I need “curves” at all? Why is not real-time a flat
value and link-share also a flat value? Why are both curves? The need
for curves is clear in the original paper,because there is only one
attribute of that kind per class. But now,having three attributes
(real-time,link-share,and upper-limit) what for do I still need
curves on each one? Why would I want the curves shape (not average
bandwidth,but their slopes) to be different for real-time and
link-share traffic?
实时控制曲线允许您为一个特定流量类别(例如VOIP)交换严格的延迟,因为其他流量类别(例如电子邮件)的延迟较差.在确定在实时约束下发送哪个数据包时,HFSC选择将首先完成发送的数据包.但是,它不使用链路的带宽来计算它,它使用实时曲线分配的带宽.因此,如果我们有相同长度的VOIP和电子邮件数据包,并且VOIP数据包具有凸曲线,如果在电子邮件的凹曲线上增加10倍,那么将在第一个电子邮件数据包之前发送10个VOIP数据包.但这只发生在突发时间,这应该是发送几个数据包所需的时间 – 即毫秒.此后VOIP曲线应该变平,VOIP将无法获得未来的提升,除非它暂停一段时间(鉴于VOIP是低带宽应用,它应该).所有这一切的最终结果是确保第一对VOIP数据包的发送速度比其他任何数据包都要快,从而使电子邮件获得高延迟,从而降低VOIP的延迟.
正如我之前所说,由于链接共享不会查看历史记录,因此无法提供延迟保证.坚如磐石的保证是VOIP等实时流量所需要的.但是,平均而言,链接共享凸曲线仍将为其流量提供延迟增强.它只是不保证.这对大多数事情都很好,比如电子邮件上的网络流量.
According to the little documentation available,real-time curve
values are totally ignored for inner classes (class A and B),they are
only applied to leaf classes (A1,B2). If that is true,why
does the ALTQ HFSC sample configuration (search for 3.3 Sample
configuration) set real-time curves on inner classes and claims that
those set the guaranteed rate of those inner classes? Isn’t that
completely pointless? (note: pshare sets the link-share curve in ALTQ
and grate the real-time curve; you can see this in the paragraph above
the sample configuration).
文档是正确的.层次结构(以及内部节点)对实时计算没有影响.我无法告诉你为什么ALTQ显然认为它确实如此.
Some tutorials say the sum of all real-time curves may not be higher
than 80% of the line speed,others say it must not be higher than 70%
of the line speed. Which one is right or are they maybe both wrong?
两者都错了.如果您的流量的70％或80％具有必须实时指定的硬延迟要求,那么现实是您几乎可以肯定无法使用您正在使用的链接来满足它们.你需要一个更快的链接.
人们可以认为指定80％的流量应该是实时的唯一方法是,如果他们将实时作为优先级提升.是的,为了提供延迟保证,您实际上提高了某些数据包的优先级.但它应该只有几毫秒.这就是所有链接都可以应对并仍然提供延迟保证.
流量很少,需要延迟保证. VOIP是一个,NTP是另一个.其余的都应该通过链接共享来完成.您希望Web快速,通过分配大部分链接容量来快速实现.从长远来看,这一份额是有保证的.你希望它是低延迟(平均),在链接共享下给它一个凸曲线.
One tutorial said you shall forget all the theory. No matter how
things really work (schedulers and bandwidth distribution),imagine
the three curves according to the following “simplified mind model”:
real-time is the guaranteed bandwidth that this class will always get.
link-share is the bandwidth that this class wants to become fully
satisfied,but satisfaction cannot be guaranteed. In case there is
excess bandwidth,the class might even get offered more bandwidth than
necessary to become satisfied,but it may never use more than
upper-limit says. For all this to work,the sum of all real-time
bandwidths may not be above xx% of the line speed (see question above,
the percentage varies). Question: Is this more or less accurate or a
total misunderstanding of HSFC?
这是一个很好的描述上限.虽然链接共享描述严格准确,但它具有误导性.虽然真正的链接共享并没有像实时那样提供硬延迟保证,但它更好地为类提供了比竞争对手(如CBQ和HTB)更多的带宽分配.因此,在说链接共享“不提供保证”时,它将其保持在任何其他调度程序可以提供的标准更高的标准.
实时的描述设法既准确,但如此误导,我称之为错误.顾名思义,实时的目的不是为了保证带宽.它提供有保证的延迟 – 即数据包现在发送,而不是随后的一些随机时间,具体取决于链接的使用方式.大多数流量不需要保证延迟.
也就是说,实时也不能提供完美的延迟保证.如果链接不是由链接共享管理的话,它也可以,但大多数用户希望拥有这两者的额外灵活性,并且它不是免费的.实时可以在发送一个MTU数据包所花费的时间之前错过它的延迟期限. (如果它发生了,那将是因为它是一个MTU数据包链接共享进入实时保持链接空闲,以防它被给予一个必须立即发送的短截止日期的数据包.这是链接共享之间的另一个区别为了提供保证,即使有数据包要发送,实时也可以故意保持线路空闲,从而提供低于100％的链路利用率.链路共享总是使用100％的链路可用容量.与实时不同,可以说是“保留工作”.)
可以说实时提供硬延迟保证的原因是延迟有限.因此,如果您尝试在1Mbit / sec链路上提供20ms延迟保证,并且链路共享正在发送MTU大小(1500字节)数据包,您知道其中一个数据包将需要12ms才能发送.因此,如果你实时告诉你需要8毫秒的延迟,你仍然可以达到20毫秒的最后期限 – 绝对保证.
And if assumption above is really accurate,where is prioritization in
that model? E.g. every class might have a real-time bandwidth
(guaranteed),a link-share bandwidth (not guaranteed) and an maybe an
upper-limit,but still some classes have higher priority needs than
other classes. In that case I must still prioritize somehow,even
among real-time traffic of those classes. Would I prioritize by the
slope of the curves? And if so,which curve? The real-time curve? The
link-share curve? The upper-limit curve? All of them? Would I give all
of them the same slope or each a different one and how to find out the
right slope?
没有优先级模型.认真.如果您想提供流量绝对优先级,请使用pfifo.这就是它的用途.但也要注意,如果你给网络流量绝对优先于电子邮件流量,这意味着让网络流量使链接饱和,从而根本没有电子邮件数据包通过.您的所有电子邮件连接都会消失
实际上,没有人想要那种优先顺序.他们想要的是HFSC提供的.如果您实际拥有实时流量,HFSC会提供.但它将是所有东西.其余的,HFSC允许你说“在拥挤的链接上,分配90％的网络,让电子邮件以10％的速度流动,然后快速发送奇怪的DNS数据包,但不要让别人用它来管理它.”
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。