建议引入sch_cake实现

maxsum

由于内核已经升级，现在的爱快应该只需要增加cake的编译选项就可以支持了。

OpenWRT的SQM基于cake实现了基于源Host/目的Host平均分配带宽的功能。
这样可以在应用流控的基础之上，防止某一个用户占用整个应用池的带宽。

OpenWRT的说明：https://openwrt.org/docs/guide-u ... shaping/sqm-details 搜索Per-Host Isolation
cake的说明：https://man7.org/linux/man-pages/man8/tc-cake.8.html

maxsum

目前的流控无法压制bufferbloat。除非做硬限速。
而SQM能做到不硬性限制用户带宽的同时，保证其他人的带宽和延迟。

梦寻凌雪

支持一下这个需求

xiaohhl

QOS高端的有两种，一种是：流量大的人卡（延迟变大），别人不卡（延迟没影响），很多很常见；另一种是：不管怎么折腾，都不卡。第二种很少有，是第一种的升级版，就是带宽利用不明显。大小包等优先级等。

maxsum

xiaohhl 发表于 2022-4-2 02:48
QOS高端的有两种，一种是：流量大的人卡（延迟变大），别人不卡（延迟没影响），很多很常见；另一种是：不 ...

两回事，延迟变大是bufferbloat的问题，就是说在路由这一端的队列太长了导致后续包的排队时间变长。这个是可以通过AQM/SQM来解决的，即主动地扔掉一些排队的包来确保队列不太长。就是通过丢包来换取低延迟。
另一个问题是怎么确保公平性，就是说丢包时要更多地选择丢弃流量大的人/应用的包，从而确保最终发出去的包是公平分配的。
现在爱快的流控只是通过区分不同的应用出了几条队列，分别排队。但是还是会有一些队列很长，而且依然有可能某一个用户挤爆某一条队列，而且造成带宽浪费。

maxsum

还是希望爱快能引入AQM算法，不一定要CAKE。用RED，WRED, CoDel都好，至少解决一下bufferbloat的问题。这个问题在linux社区那边已经有解决方案了。就是不知道爱快是不是用tc来实现流控的。

爱快研发03

爱快内置有随机公平算法，不要把最小值（带宽保障）弄太大就行。楼主测试不生效是自定义规则 还是智能流控

maxsum

爱快研发03 发表于 2022-4-7 08:05
爱快内置有随机公平算法，不要把最小值（带宽保障）弄太大就行。楼主测试不生效是自定义规则 还是智能流控 ...

我设置了智能流控。实测当测速协议被识别到的时候确实可以保障ping不会涨，但是如果没识别到（模拟有用户大流量传输）的时候，别的机器的ping还是会涨一些。

请问这个随机公平是按IP公平还是按4元组公平？

爱快研发03

maxsum 发表于 2022-4-8 06:05
我设置了智能流控。实测当测速协议被识别到的时候确实可以保障ping不会涨，但是如果没识别到（模拟有用户 ...

按内网IP

xiaohhl

maxsum 发表于 2022-4-2 21:59
两回事，延迟变大是bufferbloat的问题，就是说在路由这一端的队列太长了导致后续包的排队时间变长。这个 ...

我表述的是效果。要达到这种效果，就是保留足够的带宽和优先级处理到位。例如：如果始终保留有小带宽给用户，像ping包或游戏包，小流量的不用排队，直接通过。如果保留带宽快不够了（不等已经不够），就压缩优先级低的带宽，阻塞或丢弃，让优先级高的先流畅通过（无阻碍，延迟就不会变高。），如下载、视频等，对延迟要求不高的，相对优先级就可以低点，甚至直播，也要让道。如果直播很重要，可以干预把优先级提高，但是，基本或高要求的通讯，依然要在它之上，别的协议或应用要给直播让道，但高要求和基本通讯，决不让道（别直播不卡，账号掉线了）。至于带宽浪费，要想好，就必然浪费，至于浪费多少，就看这个“流控”水平了