|
SQM是突然有一天在这论坛流行起来了,这论坛的回复置顶功能是我最讨厌的,有些帖子原理都搞不清楚,却引来一堆人置顶,可是论坛人气不都这样来的吗,笑。
当时sqm吹得是无需要配置的低延迟,这跟以前思考的需要精确配置以达到延迟和流量的平衡是很吸引人的,你看人家的QOS都NB,根本不需要配置就可以达到低延迟。事实上这些年我获得的QOS经验就是,防止1%的用户占用公司带宽的99%以上,那么你觉得sqm这种NB的无需配置的QOS在1%的用户获得99%的带宽时,那99%的用户是一种什么体验。
我的QOS经验全部来自tomato的/etc/qos,tomato的connmark restore结构通过包标记应用到数据流标记,而且这个标记过程是可以从上行标记到下行过程的。首先就是效率问题,根据当时对openwrt下SQM脚本的分析还在用每包匹配过程,根本不涉及到connmark结构,这在一个繁忙的网络是非常枆CPU资源。当然这个扯蛋的SQM,真得是扯蛋的SQM,论坛讨论了那么久难道从来就没人注意到它用DSCP标记吗?这在普通的openwrt环境根本就不存在这种DSCP标记,又哪来的分类标记,又哪来的流量分组,又哪来的QOS效果。事实上在流量达到80%总带宽时根本不需要QOS策略,QOS往往是要抑制带宽达到80%以上的效果,这也是为什么测试SQM仍然延迟波动厉害。我们可以看看hfsc下面是如何计算延迟的8*1500 byte(包大小) / 512000 bit/s(剩余.带宽) = 23.4375ms,延迟跟包大小有关系,跟带宽也有关系,跟剩余带宽也有关系。对于设置总带宽的80%这种方式我自己本身也一直有疑问的。首先这种设法可能是因为电信局端无法保证10mbps的下行带宽,可能早上时有10mbps,到了晚上只有9.5mbps。除了这种原因,这种80%的设置法对改变流量分组里的延迟根本无效。
openwrt下面的几个脚本的顺序应该是这样排列的吧
qos-scripts(connmark+hfsc)>石像鬼(hfsc)>sqm
qos-scripts是挺接近tomato qos的,可惜这个hfsc太数学化了,我表示解释不清。宁愿用htb对流量分组进行精确分组获取低延迟,也不用hfsc获得精确的延迟。。。
当然以前在群里曾经也跟人家论战 端口QOS 跟 DSCP QOS的缺陷问题,端口QOS只是因为它是linux类最容易获得的filter方法,一个QOS的优劣还在于QOS class结构的设置。这么多年一直使用60/80的htb结构,公司里辅助用脚本3分钟扫描网络将大流量ip重新动态绑定到总带宽50%的流量分组,无视任何P2P行为,又让每个ip都有机会获得100%的带宽。
|
|