转个hfsc的原理，据说比htb强

horny1979

对于复杂的流量管制方案，阶层式演算法是必要的。新近版本的linux可采用的演算法有htb和hfsc 。而htb基本上是将token bucket filter（ tbf ）转换成阶层式架构，保留了tbf的主要特征， 而hfsc允许按比例分配频宽并且控制及分配延迟（latency)。这能够在只有一条实体网路连线的情况下，又快又好地同时提供频宽密集的资料传输服务及互动式服务。
当网路被一个以上的实体连线连结或提供各种不同的服务时，我们需要一些合理的资源管理以保障个人服务及共享连接使用者的最低频宽。尤其是关于VOIP或串流服务，无论是单纯的频宽分配或降低延迟都变得相形重要。
在两个使用者共享一个1000kbit频宽的网际网路连线的情况下，每个使用者在任何特定的时刻都应该享有最低500kbit的保证频宽。其中User A，分配最高100kbit的频宽于网络电话其余的传输流量为一般资料传输。图1显示了相应的结构图。

1: Hierarchy of shared network access.
假设所有封包都是固定的大小1500bytes，并且所有等级都以最快速度发送。在1000kbit的频宽下，每12毫秒(8*1500 byte / 1000000 bit/s = 12ms)发送一个封包。 VOIP占用的100kbit相当于每秒8个封包。为了满足这个类别100kbit的保证速率， qdisc必须从这个类别每120ms发出一个封包，这表示每个封包最高会有132ms的queueing delay。这个例子说明了频宽与latency的关系。
hfsc演算法同时处理频宽和延迟两样资源。为了解决这个问题，演算法使用service curve模型以分配资源。 service curve S(t) 表示单位时间t内的工作成果(bits) ，斜率表示传输速率。
延迟互动的概念存在于个别等级服务曲线的结构。透过选择一个由两部分组成（每一部分都是线性）的服务曲线，VOIP的传输延迟可降到30ms。首段服务曲线在30ms的期间内提供400kbit的斜率（传输速率），而第二部分则呈现出100kbi的速率t 。虽然在任何一点上都是所有曲线加总后顶多到达服务曲线的总容量，但却从其他等级赚到了大约78ms的延迟降低。在我们的例子中，VOIP的延迟降低是以经调整至低于全域限制A群组中未指定资料的等级为成本。因此，这个等级的最高传输延迟从30 ms增加至52.5ms。至于非连续性的资料传输，如ftp ，重要的是总吞吐量，延迟的重要性较为次之，因此仍符合服务曲线的设定值。

Figure 2: Scenario with linear and multi-part linear service curves.
hfsc 演算法区分成即时（real-time）和连接共享（link-sharing）两种标准。一个叶类别可以同时指派real-tim及link-sharing曲线，而子类别只能有一个link-sharing曲线。即时（real-time）只适用于叶类别，因为实际上只有叶类别持有封包。因此即时导向的准则负责必要服务的达成。连接共享（link-sharing）的标准则只涉及本身与相邻类别的关连，负责公平分配，而不提供绝对的保证。为了在各种情况下都能够确保最低延迟时间，分离成两个标准是必要的。以结果而言，这也表示即使已经短暂超过上层子类别link-sharing曲线之限制，仍然可以根据叶类别的即时保证继续发送封包。
让我们谈谈我们例子中已经启用，并以其最高速率400 kbit发送封包的资料类别A。现在，如果VOIP类别在任何时间点启动都被允许根据其real-time的保证得以较高的速率传送（图3 ）。于是，这意味着A类别在短时间内超出了link-sharing的设定参数500kbit。为了达成长期的link-sharing的保证速率。 A类别将因这短暂的超支被”惩罚”。


Figure 3: Between t1 and t2, exceeds the total maximum allowed capacity.
每个类别都会被指定一个与服务完成时间一致的”虚拟时间”。为了尽快将封包送出，会从根类别开始之阶层式架构中全面性的搜寻出提供最低达成的虚拟时间之类别。叶类别找出准则后即发送封包并且那个类别的虚拟时间，从其亲类别一路往上到根类别，将相应增加。如果一个类别在其real-time参数的基础上进行传输，其虚拟时间也会被加大。
HFSC usage on Linux
设定一个hfsc qdisc。指定qdisc的根类别到一个网络介面，并且可以自订一些规格：
tc qdisc add dev $dev root handle $ID: hfsc [default $classID ]
建立阶层式的类别
tc add class dev $dev parent parentID classid $ID hfsc [ [ rt SC ] [ ls SC ] | [ sc SC ] ] [ ul SC ]
属性是根据以下描述的服务曲线设定：
SC := [ umax bytes dmax ms ] rate BPS
我们可以如link-sharing （ls）曲线般的指定一条real-time曲线（ rt ）给处于最低层次的叶类别（leaf class），其上层的子类别（inner class）则只能有link-sharing曲线。透过使用ul服务曲线，可以定义每个类别实际对提供服务的上限。可以透过指定单一的SC曲线来代替指定rt曲线及ls曲线。一条服务曲线由斜率描述其传输速率。如果曲线由两部份组成，可以由在保证传输速率umax时的maximum delay – dmax指定。
名词解释：
层级：
root：根类别，制订最上层的总频宽限制
inner class：子类别，定义各主要的频宽分配
leaf class：叶类别，
# Example from Figure 1.
tc qdisc add dev eth0 root handle 1: hfsc
tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbit
tc class add dev eth0 parent 1:1 classid 1:10 hfsc sc rate 500kbit ul rate 1000kbit
tc class add dev eth0 parent 1:1 classid 1:20 hfsc sc rate 500kbit ul rate 1000kbit
tc class add dev eth0 parent 1:10 classid 1:11 hfsc sc umax 1500b dmax 53ms rate 400kbit ul rate 1000kbit
tc class add dev eth0 parent 1:10 classid 1:12 hfsc sc umax 1500b dmax 30ms rate 100kbit ul rate 1000kbit

众人拾柴火焰高，大家一起搞个脚本出来阿，舍弃限速，再加上opendpi的识别，openwrt的qos几乎完美了！

gzokboy

万分期待啊

zhoutao0712

早就研究过了,告诉你们吧,这个是不可能的

流量控制没你们想象的那么简单

原因嘛,嘿嘿,懒得和你们讲,咋们不在一个层次

zhoutao0712

实际结论:hfsc并不比htb好
从内核改进这些调度算法,并且采用多种手段才是正道

phantom-gy

技术贴  绑定

aahhwwrrjj

zhoutao哥也太嚣张了啊

lmx0312

如果真这么好,  我还费劲的把OP原版的HFSC改成HTB干吗.   
TC只是工具, 没有万全的算法 ,  重要的是怎么识别 , 区分各种流量.

老鹰固件专刷

强帖留名！！

horny1979

7# lmx0312


我不是故意抬杠阿，有啥证据么？hfsc下我能把wow的延迟控制在15ms左右(本人4m的adsl，同时一个下载机10k/s上传)，脚本还是照着你的脚本画的葫芦.........

ewolf

zhoutao0712 发表于 2012-1-11 23:30
早就研究过了,告诉你们吧,这个是不可能的

流量控制没你们想象的那么简单

讲下无妨，我们学习学习

江上渔夫

ewolf 发表于 2012-3-19 11:17
讲下无妨，我们学习学习

就是啊,说下.
这个看了后还是不是很明白
既然除了新的调度方法,那肯定有好的地方.要不出来干嘛?

zhanggh新手

专业技术贴。学习。。

sdec040721

LZ, 你的hfsc的Qos用的怎么样啊? 能不能放个脚本出来给共享共享呢? 谢谢

icyboy

在用pfsense 也是hfsc

dato

openwrt里的qos-scripts和石像鬼就用的这个hfsc，你可以看到内部的脚本生成。hfsc对于数学不好的挺难理解的。它最大的特点是延迟可计算，这就要求有一定的保障带宽。但是带宽总是有限的，它没有优先级概念，即便是低延迟分类依然会因为调度问题出现完全的网络阻断情况。虽然只是一个包。
hfsc在网上基本没有可供参考的例子，详解为什么这样设定以及注意事项。不用qos-scripts只是相对htb算法，同样的层级结构140kb的上行，htb可以抢到110kb,而hfsc只有80-90kb。
其实对于延迟良好的层级结构才是关键。非要达到20ms的延迟真觉得没什么必要。