V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Untu
V2EX  ›  宽带症候群

国内有没有 Bufferbloat Test 网站可以用于验证 QOS 效果

  •  
  •   Untu · 10 天前 · 1141 次点击
    https://bufferbloat.libreqos.com/

    类似这个网站。

    感觉日常只要多个人一起用网 SQM QOS 搭配 piece_of_cake 还是很有必要的,除了压力打流的时候 ping 之外就是想找个网站再验证下效果
    5 条回复    2026-01-26 10:12:04 +08:00
    datocp
        1
    datocp  
       9 天前 via Android   ❤️ 1
    我要嘲笑我自己了。。。
    自认为 qos 很懂,当年鄙视的就是 SQM ,特别是在网络满载时的效果,根本就没有 dscp 标记,屁的效果都没。之后想来作者也应该很牛逼都能写内核模块。

    今天我自以为是的 qos 牛逼效果,在这个测试网站竟然除了流媒体 2 颗星,其它都是 1 颗星。。。。

    早期的版本最大的问题,不使用 conntrack 导致缺少包到连接的转换非常耗 cpu 。想来作者也提出了很多新颖的观点,实际效果不敢点赞。
    Chihaya0824
        2
    Chihaya0824  
    PRO
       8 天前

    感觉和线路能不能跑满也有关系?如果他们服务器跑不满感觉结果也不对?
    没开 qos
    qwvy2g
        3
    qwvy2g  
       6 天前 via Android
    这个要看运营商的,小地方的运营商使用老的 QoS 限速而不是智能队列限速+超售严重,这种情况下 sqm 就没办法(限速到 1m 延迟测试依然剧烈波动)。理想情况下,带宽和并发连接数等资源没有用完情况下,对同一个稳定服务器建立多个连接,在这个过程中第一次建立连接到最后一次建立连接延迟上不应该有巨大变化。
    qwvy2g
        4
    qwvy2g  
       6 天前 via Android
    说起这个就想笑某地联通 ipv6 和 ipv4 共用一个传统限速队列,具体表现是 ipv6 只要超过一定规模的并不是很大的流量,ipv4 延迟就极度不稳定。最后只能把 ipv6 给禁用了。
    datocp
        5
    datocp  
       5 天前
    qos 这个话题随着经验增长,挺有趣的。

    当年在使用 modem 时
    当上行 60%时,延迟极低,下载速度最大化。
    当上行 80%时,延迟开始变得更高,下载速度开始受影响。
    当上行超过 80%时,延迟开始变得更高,下载速度开始变低。

    所以,当你有办法把上行流量控制在 80%时,似乎说的就是 SQM(tc scripts)那一套,当然没有 SQM 宣传的每 IP 平均化。QOS 要做的是当上行流量超过 80%时,该如何控制延迟。当然这个 80%不是直接在一些普通路由器设置为 80%总上行。按照 tc 反馈的结果这样设置依然有延迟问题。

    于是从 56kmodem>2m adsl>4M adsl>8M 光纤>20m 光纤>100m 光纤 20mbps 上行
    随着带宽的不断变大,上行越来越大,越来越不可能达到 80%的上行,延迟问题也就越来越不明显。当然这中间,在 4~8M 时也遇到并发数导致 qos 失效,甚至一些 403 的重定向导致下载流量远远超过 qos 限制的下载,影响了延迟结果。至今百思不得其解。

    在 mips 小路由,以前用 ddwrt 时 imq 接口会让路由直接 cpu 耗死机。。。ifb 倒稍微测试了一下,取得了一些非常奇异的结果就是上行的标记可以出现在下行的流量里,直接进入 qos 队列。当然基于对这些 tun 接口 cpu 性能消耗的担忧,现实中依然不敢用这些接口,而是直接作用于 eth1/br-lan/pppoe-wan???。

    sqm 并不具备 tomato 路由的每包到链接的过程,导致之前测试时 cpu 性能消耗非常厉害,讨论中动不动就去换个 cpu 性能更好的路由。。。
    $IPT -t mangle -I QOSO -m mark ! --mark 0/0xff -j ACCEPT #ACCEPT
    $IPT -t mangle -A QOSO -j CONNMARK --save-mark --mask 0xff

    $IPT -t mangle -I PREROUTING 2 -i $UDEV -j CONNMARK --restore-mark --mask 0xff

    这么多年过去了,在 100mbps 线路,上行一直跳不出这个设置,下行动态抓取实时有流量的 ip ,不需要根据 ip 做平均,做到带宽的 100%利用。
    # add HTB root qdisc

    $TC qdisc del dev $UDEV root 2>/dev/null
    $TC qdisc add dev $UDEV root handle 1: htb default 40 r2q 300

    #$TC class add dev $UDEV parent 1: classid 1:1 htb rate 1Gbit ceil 1Gbit
    $TC class add dev $UDEV parent 1: classid 1:1 htb rate 150Mbit ceil 150Mbit

    #$TC class add dev $UDEV parent 1:1 classid 1:100 htb quantum 1514 rate $((UPLINK*10/100))kbps ceil 1Gbit prio 5
    $TC class add dev $UDEV parent 1:1 classid 1:2 htb rate $((UPLINK*8/10))kbps ceil $((UPLINK*9/10))kbps

    #$TC class add dev $UDEV parent 1:1 classid 1:10 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 0
    $TC class add dev $UDEV parent 1:1 classid 1:10 htb rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 0
    $TC class add dev $UDEV parent 1:1 classid 1:20 htb rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 2
    $TC class add dev $UDEV parent 1:2 classid 1:30 htb rate $((UPLINK*3/10))kbps ceil $((UPLINK*90/100))kbps prio 3
    $TC class add dev $UDEV parent 1:2 classid 1:40 htb rate $((UPLINK*3/10))kbps ceil $((UPLINK*85/100))kbps prio 4

    # cat /tmp/port.tmp
    udp_6060_0x10/0xff
    tcp_992,1992_0x10/0xff
    udp_53,123_0x20/0xff
    tcp_22,23,3389_0x20/0xff
    tcp_80,443,1080,1863,8080:8081,12000,14000,15000,16285_0x30/0xff
    udp_80,443,500,1701,3478:3481,4000:4030,4500,5989,8000:8020,16285,50000:55000_0x30/0xff
    tcp_20,21,25,143,465,993,1024:65535_0x40/0xff
    udp_1:65535_0x40/0xff
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2351 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 09:14 · PVG 17:14 · LAX 01:14 · JFK 04:14
    ♥ Do have faith in what you're doing.