[问题]在coyote中用wonder的QOS初始化脚本的问题

clamp

当运行完脚本的最后两行时,内外网络中断
但是用tc -s qdisc ls dev ppp0 和 tc -s class ls dev ppp0可以看到有数据包流经路由器，modem的数据灯还在闪，内外网络就是不通。

希望各位高手能解决这个问题

clamp

这几天查看了些资料，怀疑是内核问题。这里有没有人用wonder的QOS初始化脚本的。不妨大家一起来讨论一下

clamp

Wonder Shaper Qos脚本的Readme

终极的流量控制：低延迟、高速上/下载
Note: This script has recently been upgraded and previously only worked for Linux clients in your network! So you might want to update if you have Windows machines or Macs in your network and noticed that they were not able to download faster while others were uploading.
我试图打造圣杯：
让交互数据包保持较低的延迟时间
也就是说上载或下载文件不会打扰SSH/telnet等。这是最重要的，即使是200ms的延迟也会感觉很差。
上载或下载期间有合理的速率用于网页浏览
即使http属于一种大量数据传输，也不应受其它传输影响太大。
保证上载不会影响下载
98
上载数据流会影响下载的速率，这是相当普遍的现象。
只要花费一点点带宽就可以实现它们。之所以上载流、下载流和ssh之间要互相伤害，是因为像Cable或者DSL Modem这样的家用设备中的队列太大。
下面一节进一步解释了造成延迟的原因和如何缓解。如果你对魔术的咒语不感兴趣，完全可以不看它，直接参考脚本那一节。
15.8.1. 为什么缺省设置不让人满意
ISP们知道人们评价他们的时候要看看下载的速度。除了可用带宽之外，丢包因为会严重地牵制TCP/IP效率而极大地影响下载速度。大队列有助于改善丢包，进而提高下载速度。所以ISP们都配置成大队列。
然而，大队列会破坏交互性。一次击键行为首先要在上行流队列中排队(可能长达数秒！)才能到达对端主机。回显的时候，数据包还要回来，所以还要在你ISP的下行流队列中排队，你的本端显示器才有显示。
这个HOWTO教你如何用多种方法重组和处理队列，但是，并不是所有的队列配置我们都有权访问。你的ISP的队列肯定是无法配置的。上行流可能存在于你的cable modem或DSL设备中，你也许可以配置，也许不可以配置。绝大多数不能配置。
那怎么办呢？既然无法控制那些队列，那就除去它们，让数据包在我们的Linux路由器内排队。幸运的是，这是可能的。
限制上载速率
把上载速率限制在比可用带宽稍小一些的位置上，于是你的MODEM中就不会形成队列了。也就是说，队列转移到你的Linux路由器中了。
限制下载速率
这带点欺骗的味道，因为我们实际上不能控制Internet 向我们发包的速率。但我们可以丢掉那些太快到来的数据包，不让他们导致TCP/IP的速率低于我们期望的速率。因为我们不希望轻易地丢弃数据包，所以我们要配置“burst”来容纳突发传输。
在做完了这些之后，我们就排除了下行队列(除了偶尔的突发)，并让上行队列存在于我们的Linux路由器中，以便施展Linux非凡的能力。
剩下的事情就是保证交互数据包永远排在上行队列的最前面。为了保证上行数据流不会伤害下行流，我们还要把ACK数据包排在队列前面。这就是当发生大批量数据流的时候，双向传输均受到严重影响的原因。因为下行数据的ACK必须同上行流进行竞争，并在处理过程中被延迟。
为了进一步配置，我们使用一个高质量的ADSL连接(荷兰的xs4all)得出了如下测量结果：
基准延迟：
round-trip min/avg/max = 14.4/17.1/21.7 ms
99
不进行流量控制，下载数据：
round-trip min/avg/max = 560.9/573.6/586.4 ms
不进行流量控制，上载数据：
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms
进行流量控制，220kbit/s上行：
round-trip min/avg/max = 15.7/51.8/79.9 ms
进行流量控制，850kbit/s下行：
round-trip min/avg/max = 20.4/46.9/74.0 ms
上载数据时，下载得到约80%的带宽。当上行流达到90%时，延迟一下子增加到850 ms，也能说明问题。
这个脚本的期望效果极大地取决于你的实际上行速率。当你满速率上载的时候，你击键的那个数据包前面总会有一个数据包。这就是你能够达到的上行延迟的下限??MTU除以上行速率。典型值会比它稍高一些。要达到更好效果，可以降低MTU！
然后是两个版本的脚本一个是使用Devik的HTB，另一个是使用Linux内部自带的CBQ。都已经过测试，正常工作。

DreamCat

我在使用 Wonder-shaper init scripts 时会出现webadmin无法工作的情形。目前在使用Coyote init scripts (manual class config)。基本上能满足要求，比如BT的限速。不过klogd: HTB: quantum of class 10002 is big. Consider r2q change这个问题还是没有找到解决的方法。你的第三个帖子不错，置顶了。。

clamp

我现在仍然在使用Wonder-shaper init scripts，第一个帖子出现的问题已经解决了，你所说的在使用 Wonder-shaper init scripts 时会出现webadmin无法工作的情形，是那个问题的其中一种表现形式。问题是出在Wonder-shaper init scripts中的最后一部分

1. 
   
2. ########## downlink #############
   
3. # slow downloads down to somewhat less than the real speed  to prevent
   
4. # queuing at our ISP. Tune to see how high you can set it.
   
5. # ISPs tend to have *huge* queues to make sure big downloads are fast
   
6. #
   
7. # attach ingress policer:
   
8. 
   
9. tc qdisc add dev $DEV handle ffff: ingress
   
10. 
    
11. # filter *everything* to it (0.0.0.0/0), drop everything that's
    
12. # coming in too fast:
    
13. 
    
14. tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
    
15. #   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
    
16. 
    

复制代码

把这部分代码禁用掉的话Wonder-shaper init scripts就能正常工作了