|
|
本帖最后由 dato 于 2015-4-24 14:11 编辑
http://www.bufferbloat.net/proje ... SQM_for_CeroWrt_310
http://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN
http://snapon.lab.bufferbloat.ne ... t-practices-00.html
https://github.com/openwrt/packa ... /lib/sqm/simple.qos
https://github.com/zcecc22/sqm-qos/blob/master/nxt_v2.qos
从论坛上了解到SQM可以在下载的同时保证游戏的延迟，而且据反应是普遍非常低，最关键是基本无需配置。
config queue 'eth1'
option qdisc 'fq_codel'
option script 'simple.qos'
option linklayer 'none'
option enabled '1'
option download '4104'
option upload '1115'
option interface 'pppoe-wan'
option qdisc_advanced '1'
option ingress_ecn 'ECN'
option egress_ecn 'NOECN'
option qdisc_really_really_advanced '1'
option squash_dscp '1'
option squash_ingress '1'
今天简单测试了一下SQM 实现。挺郁闷的以失败告终。
设备RTN16 OpenWrt Chaos Calmer r45203，家里用的是电信光纤4Mbps线路，用 www.speedtest.net 测试
不加载SQM
下行4.52 上行1.23
下行 4.47 上行1.20
加载SQM
下行 3.69 上行1.03
下行 3.84 上行1.00
也不知道为什么会有这么大的损耗， 从脚本里没看到这部分损耗存在啊。
用tcping，平板手机用泰捷看电影，电脑开始web下载其中的一部电影开始带宽不足缓冲，lol延迟一直正常。有点高兴看起来还有效果。
开启旋风下载，tcp -t www.qq.com 开始波动，lol延迟也开始波动。郁闷。。。20-250ms
哈哈，这叫什么测试，想了解SQM需要具备DSCP标记实现，抓包，还有htb的相关知识。
通过tc -s class show dev pppoe-wan，流量只命中了11,12子类，按以往的经验修改BE_CEIL=`expr $CEIL - 240` ,预留30kb的流量在单机上能区分不同的流量，应该延迟就正常了。可惜没效果。。。
simple.qos
# TC rules
egress() {
CEIL=${UPLINK}
PRIO_RATE=`expr $CEIL / 3` # Ceiling for prioirty
BE_RATE=`expr $CEIL / 6` # Min for best effort
BK_RATE=`expr $CEIL / 6` # Min for background
BE_CEIL=`expr $CEIL - 16` # A little slop at the top
LQ="quantum `get_mtu $IFACE $CEIL`"
$TC qdisc del dev $IFACE root 2> /dev/null
$TC qdisc add dev $IFACE root handle 1: `get_stab_string` htb default 12
$TC class add dev $IFACE parent 1: classid 1:1 htb $LQ rate ${CEIL}kbit ceil ${CEIL}kbit `get_htb_adsll_string`
$TC class add dev $IFACE parent 1:1 classid 1:10 htb $LQ rate ${CEIL}kbit ceil ${CEIL}kbit prio 0 `get_htb_adsll_string`
$TC class add dev $IFACE parent 1:1 classid 1:11 htb $LQ rate 128kbit ceil ${PRIO_RATE}kbit prio 1 `get_htb_adsll_string`
$TC class add dev $IFACE parent 1:1 classid 1:12 htb $LQ rate ${BE_RATE}kbit ceil ${BE_CEIL}kbit prio 2 `get_htb_adsll_string`
$TC class add dev $IFACE parent 1:1 classid 1:13 htb $LQ rate ${BK_RATE}kbit ceil ${BE_CEIL}kbit prio 3 `get_htb_adsll_string`
Simple.qos is a three band system that can use diffserv and simple prioritization to give or remove priority to certain kinds of identifiable flows.
It gives priority to CPE generated DNS and NTP packets, respects a few diffserv markings, and deprioritizes CS1.
It is not feature-competitive with OpenWrt's qos-scripts, which have (for example) l7 inspection to find common torrent-like protocols, and a gui with lots of knobs to control that aspect.
It does, however, work correctly with ipv6 and IPv4, which most shapers today do not do.
HTB queue 3 bands
|
|= fq-codel (Strict priority max 30% admission controlled)
|
|= fq-codel (best effort)
|
|= fq-codel (background max 30%)
Figure 2: Description of CeroWrt 3 band SQM system
The first band is strictly admission controlled, and is limited to DNS and NTP queries emitted directly from the local router's DNS and NTP servers, and packets marked TOS-immediate.
Optionally the user can specify additional devices, protocols or diffserv classifications to fit into this band (or any other band).
The priority band is limited to a maximum of 30% of all bandwidth by default.
The second band (Best Effort) can absorb all bandwidth available on the system.
The third band (Background) is limited to a minimum of 30%, due to observing many mis-classified flows in the field. Experiments with a maximum of 5% starved many common flow types.
By default ECN is enabled on ingress and disabled on egress. It is recomended that ECN be enabled when using fq_codel or pie at bandwidths above 10Mbit.
购物-Codel uses a quantum of 300, giving some priority to smaller packets.
There is extensive support in the HTB-based rate limiter for correctly estimating bandwidth for various forms of (mostly xDSL) based framing.
TBF + DRR could be substituted for HTB.
这个SQM还是个标记QOS，只是相对qos-script它的效率更差，它是基于每个包都要匹配这将严重消耗CPU性能， 而以往用的qos基本是第一个包标记跟着整条链接标记不再单独的匹配每包。
既然分不清 旋风跟lol的流量，那就指定lol的端口标记，结果还是失败了。。。好了基本到这里就不知道如何修正了。SQM看起来没什么特别都是htb结构的通过标记不同的流量到不同class，因为流量饱合度产生不同的延迟效果。我们可以看看hfsc下面是如何计算延迟的
8*1500 byte(包大小) / 512000 bit/s(剩余.流量) = 23.4375ms，延迟跟包大小有关系，跟流量也有关系，跟剩余流量也有关系。按说这个SQM跟其它的htb没有差别啊，除了包标记问题以外。延迟太不稳定了。在下行 4.47 上行1.20 的线路上表现不怎么样。也许是RTn16性能太差了。
ipt_setup() {
ipt -t mangle -N QOS_MARK_${IFACE}
ipt -t mangle -A QOS_MARK_${IFACE} -p tcp -m multiport --dport 2099,5060,5222,5223,6060,8088,8393:8400 -j MARK --set-mark 0x1${IPT_MASK_STRING}
ipt -t mangle -A QOS_MARK_${IFACE} -p udp -m multiport --dport 5000:5500,5060,6060,8088 -j MARK --set-mark 0x1${IPT_MASK_STRING}
ipt -t mangle -A QOS_MARK_${IFACE} -j MARK --set-mark 0x2${IPT_MASK_STRING}
# You can go further with classification but...
ipt -t mangle -A QOS_MARK_${IFACE} -m dscp --dscp-class CS1 -j MARK --set-mark 0x3${IPT_MASK_STRING}
ipt -t mangle -A QOS_MARK_${IFACE} -m dscp --dscp-class CS6 -j MARK --set-mark 0x1${IPT_MASK_STRING}
ipt -t mangle -A QOS_MARK_${IFACE} -m dscp --dscp-class EF -j MARK --set-mark 0x1${IPT_MASK_STRING}
ipt -t mangle -A QOS_MARK_${IFACE} -m dscp --dscp-class AF42 -j MARK --set-mark 0x1${IPT_MASK_STRING}
ipt -t mangle -A QOS_MARK_${IFACE} -m tos --tos Minimize-Delay -j MARK --set-mark 0x1${IPT_MASK_STRING}
* 2015年04月24日星期五
- 给SQM下个结论吧，由于环境不具备DSCP标记，所以SQM如果你仔细观察iptables -t mangle -vnL QOS_MARK_pppoe-wan，发现大量的数据包都进入了0x2低优先级规则。
至于大家反应的效果是有点的。。。根本就是错误认识。以前做的60/80htb就是想说明ADSL线路在流量80%以下是根本不需要qos的，而我们往往是要在大部分时间抑制它超过80%的比例而导致的延迟波动。
以后不再关注SQM，主要是家用环境没有设备可以打DSCP标记，这将导致分类结果基本无效。所以SQM当然是会产生延迟波动的，而且是经常的，视低优先级的剩余流量情况决定。
* 2015年04月23日星期四
- 重新测试
- 修改/usr/lib/sqm/simple.qos，将icmp置于高优先级分类，解决延迟问题。
\大概在 120 处的 $TC filter add dev $IFACE parent 1:0 protocol ip prio 8 \u32 match ip protocol 1 0xff flowid 1:13
为$TC filter add dev $IFACE parent 1:0 protocol ip prio 8 \u32 match ip protocol 1 0xff flowid 1:11
- 其实这步看自己需要了，代码里的解释为防止ping floods。但改了比较符合自己的爱好吧，不改即便是180左右的ping有没有发现跟平时的不一样人物在游戏里还是正常的走位，而不是卡顿。
- 在28前插入，因为不擅长抓包不清楚游戏包是否正确归类，那就直接根据lol的游戏端口定义吧，虽然这跟SQM的出现的意义不再精确分类有所违背。
其实这里也是理解SQM疑惑的地方，如何给每个包打上准确的DSCP标记?当时跟QQ群里的朋友争论的时候，人家很鄙视的说你这种端口QOS如何在复杂环境定义大量的优先级规则，那时候第一次意识到端口QOS的缺点无法适应复杂环境。当时他提供的截图显示有专门的一个软件用于给不同的流量打标记，而且这个过程是完全自定义的根本不遵守标准。 所以一个疑惑的地方，windows系统要开启DSCP是要修改系统配置的，路由里的数据包DSCP标记是天生的吗?它能准确的将上行方向游戏的包准确归类吗?由于不会抓包还是请有经验的朋友解答。谢谢！
ipt -t mangle -A QOS_MARK_${IFACE} -p tcp -m multiport --dport 2099,5060,5222,5223,6060,8088,8393:8400 -j MARK --set-mark 0x1${IPT_MASK_STRING}
ipt -t mangle -A QOS_MARK_${IFACE} -p udp -m multiport --dport 5000:5500,5060,6060,8088 -j MARK --set-mark 0x1${IPT_MASK_STRING}
ipt -t mangle -A QOS_MARK_${IFACE} -j MARK --set-mark 0x2${IPT_MASK_STRING}
- 以下图为平板在看pps时的一些延迟情况
左边为icmp ping结果经过调整以后这下看起来正常了 ，右边的是tcping看情况也属于12分类，下面为包标记过程
- 目前还没长时间，特别是没机会在大量ip存在的环境测试，目前担心SQM的效率问题只有一点，每包匹配过程对cpu的消耗，是否会导致严重的性能问题。
-functions.sh有处注释，Note limits are tuned towards a <10Mbit uplink <60Mbup down
在另外一帖也有朋友反馈在7620A设备100M下载会被限到6M左右，网上提到的似乎是说egress+ingress的总流量不能超过，这可能是openwrt的硬件性能上的一个限制，没去验证过，不知道是否不用egress+ingress改用具体的br-lan接口是否会解除该限制。
- 看到一个老外的反馈
WDR4900 V1，I have SQM active on eth0.2, which is my WAN. It is set up for 120Mbps down, 12Mbps up. Working as expected: ~110Mbps down, ~11MBps up.
* 2015年04月22日星期三
- 简单测试
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？立即注册
×
|
| 江苏省互联网有害信息举报中心 举报信箱：js12377 | @jischina.com.cn 举报电话：025-88802724
本站不良内容举报信箱：68610888@qq.com
简体中文
繁體中文
English
日本語
Deutsch
한국 사람
بالعربية
TÜRKÇE
português
คนไทย
IP卡
狗仔卡
发表于 2015-4-22 19:45
置顶卡
沉默卡
喧嚣卡
顶贴卡
显身卡
