少校
- 注册时间
- 2010-1-31
- 金币
- 1969 个
- 威望
- 5 个
- 荣誉
- 1 个
尚未签到
|
发表于 2017-9-25 20:35
本帖最后由 dato 于 2017-9-25 20:39 编辑
以前跟人家争论过 linux qos跟pa的差距，最终我能认可的只有一点 linux下我能找到的只有基于目的端口的流量过滤方法，而没像pa那么多的基于商业目的有人维护的l7规则。
习惯用命令行因为if then这种逻辑判断能力，脚本的灵活性远不是呆板的web管理界面能比的，任何时候都可以用逻辑判断触发改变网络状态。更何况这种呆板的web管理界面对于系统管理员来说完全就是一头雾水不清楚系统底层是如何运行的。以前看过爱快的两篇web管理界面的qos，以自己掌握的qos经验完全看不懂那两篇文档在说什么，区别在哪里。。。
ADSL好古老的词汇，基本上只有64KB/s的上行。早先遇到的就是电信提供了腌割猫，这种猫稍微用一下迅雷流量就波动厉害，刷固件解决。ADSL也是最早用于60/80htb实现的，所谓60%的流量达到延迟最低，80%的流量达到延迟和流量的平衡，80%以上ADSL线路就开始掉速度根本达不到承诺的下行数值，可以认为是局端并发限制导致的tcp握手失败而导致的流量变小。这也是openwrt下的sqm一直在宣扬的Bufferbloat 概念。
- Bufferbloat is high latency in packet-switched networks caused by excess buffering of packets. Bufferbloat can also cause packet delay variation (also known as jitter), as well as reduce the overall network throughput. When a router or switch is configured to use excessively large buffers, even very high-speed networks can become practically unusable for many interactive applications like Voice over IP (VoIP), online gaming, and even ordinary web surfing.
- Some communications equipment manufacturers placed overly large buffers in some of their network products. In such equipment, bufferbloat occurs when a network link becomes congested, causing packets to become queued in buffers for too long. In a first-in first-out queuing system, overly large buffers result in longer queues and higher latency, and do not improve network throughput.
- The bufferbloat phenomenon was initially described as far back as in 1985.[1] It gained more widespread attention starting in 2009.[2]
以前ADSL测试时遇到的问题
- - 回家终于有机会用家里的itv线路ADSL4M上行有55kb/s进行测试，一个nw618 cpu主频240MHZ tomato-K26-1.28.RT-MIPSR1-101-MiniIPv6.trx
- 玩CS同一服务器网络空闲 时延迟在27ms左右，在low全速占用时延迟在47ms之间。但是发现启用itv时悲剧发生了，延迟很难看。itv部分没办法只能使用内置的pppoe拔号，尝试使用DHCP结果发现很多频道都出现等待信号的问题。启用ITV时线路速率会变化的。而且基本在一个特定的值，最低的时候下行才125kb/s，最高的时候下行才200kb/s，显然这itv猜想可能局端有特殊的设备对itv pppoe拔号过程进行侦测并动态的对ADSL线路进行QOS调整，又或者这个home plusplus 500性能不行（手里没ADSL modem感觉也不大是它的问题）。偶没测在itv时上行变化情况。肯定比原有的55kb/s小很多，从tc的1:1 rate来看大概只有33KB左右了。此时发现CS的延迟已经600ms左右了，因为原有的55kb/s已经不适合在itv时的情况了，郁闷不知道如何对itv线路状态进行侦测，无法动态调整这个上行值。杯具啊。。。
- - 试图在itv时限制总上行带宽值为33kb/s，结果使用web方式向QQ中转站上传东西，medium组占用了184.32kbit/s基本占用了上行组，但是CS延迟没变化。使用pps时延迟就到600ms以上了。以前用的20M光纤因为这样那样的问题，没大可能全速下行的。但是ADSL上的itv由于下行只有125kb/s左右，结果下行又再次对游戏延迟进行了影响。有机会测试一下光纤是否也有该问题存在。
一直以为自己使用的60/80实现已经没有任何问题了，但是不同线路依然会出现因为并发导致的网络异常。甚至出现远超过实际带宽的灵异事件。。。很多情况已经远超过我的理解了。
各种稀奇古怪的情况都记录在这里了。
我的tomato 原版QOS 设定
http://www.**/forum/thread-102891-1-1.html
好吧，竞争关系，网址都被过滤了。。。
|
|
IP卡
狗仔卡
