由TG散户群体自发形成的测速社区。专注*用户测*的体验:单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿,共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项,仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿,共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项,仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
《关于YouTube跑分和入口距离两个看似不相关的问题》
1️⃣ 先谈谈 YouTube 跑分
许多人喜欢用 油管跑分 作为节点优劣的评估工具,看谁能突破「100万、200万、…」。但实际上,这种 #油管娱乐分,和你本地的带宽关联不大!
既然 YouTube 跑分和带宽的关系不大,那还剩下什么意义呢?它可以辅助对比节点表现。例如,你有同样25ms RTT的两个节点,如果其中一个娱乐分100w,另一个90w,那么100w分的节点 #抖动 无疑更低。仅此而已!
2️⃣ 25ms RTT 的另一个“魔咒”
事实上,这个原理恰好又表现成两个看似不相关的症状:
虽然前者能通过
🧩 所以,25ms RTT 既是 #远距离 临界线,也是 #油管娱乐分 的百万分水岭。你看到的“突破”,其实都是这条延迟线在背后捣鬼!
#技术杂谈 #软路由
1️⃣ 先谈谈 YouTube 跑分
许多人喜欢用 油管跑分 作为节点优劣的评估工具,看谁能突破「100万、200万、…」。但实际上,这种 #油管娱乐分,和你本地的带宽关联不大!
🎯 举个极端例子:
假设有人在 上海 拉来一条 #万兆宽带,或许会 误以为 YouTube 跑分能突破100万?
No way!
如果按上海电信走👑👑超顶尖专线到🇭🇰的29ms RTT来估计,闲时的YouTube跑分也很难超过90w——哪怕你用10G家宽,甚至40G IDC宽带。
💡据观察,在谷歌RTT > 25ms (大约) 时,YouTube跑分上限的估算公式:
上限分 = 130 - RTT * 抖动惩罚系数
💡或,更粗略的:
上限分 ≈ 120 - RTT [电/联]
上限分 ≈ 110 - RTT [移动]
若想突破200w分,谷歌RTT则要控制在10ms以内➕千兆宽带(不刚需2000M宽带)❗️
注意共同的前提条件必须满足:终端设备🉑硬解4k油管视频,且有线连路由器,且本地宽带>500M。
既然 YouTube 跑分和带宽的关系不大,那还剩下什么意义呢?它可以辅助对比节点表现。例如,你有同样25ms RTT的两个节点,如果其中一个娱乐分100w,另一个90w,那么100w分的节点 #抖动 无疑更低。仅此而已!
2️⃣ 25ms RTT 的另一个“魔咒”
在 Linux / BSD 默认参数下,TCP 吞吐在 RTT 超过 25ms 后会明显下降。
这个问题在本频道早前的《TCP 鸡血补丁》推文中曾有讨论。另外,谷歌云☁️ 也提供了详细的原理讲解。
事实上,这个原理恰好又表现成两个看似不相关的症状:
✅ 后端到入口 >25ms ➜ 跑不满 千兆单线程
✅ 终端到节点 >25ms ➜ YouTube 娱乐跑分 达不到100w
注意:仅广东及周边省市能够同时化解以上2个症状,如图所示❗️
虽然前者能通过
sysctl.conf #打鸡血 来攻克,但后者因谷歌(利用RTT估算用户侧带宽)的算法写死,无法逆转。🧩 所以,25ms RTT 既是 #远距离 临界线,也是 #油管娱乐分 的百万分水岭。你看到的“突破”,其实都是这条延迟线在背后捣鬼!
#技术杂谈 #软路由
#技术杂谈
承上篇👈
1️⃣ #打鸡血 💉一定奏效吗?
对。只要某机场在入口省市能跑1G,那么理论上,#远距离 也能跑到近乎同样速度。已利用 #一线机场 #二线机场 实测,总是奏效!
感兴趣见谷歌云☁️的论述
2️⃣ 参数的试错风险和注意事项
建议二次修改《评论区上传的sysctl.conf》,节省试错时间:
❶ 先选一个距你家最近的 /etc/sysctl.conf 作为蓝本,
❷ 再基于此调试net.ipv4.tcp_rmem的最小值、默认值、最大值,取值大小俗称“剂量”。
⚠️ 这3个参数,因你的城市、运营商、带宽及软路由CPU架构而异。
➤若剂量太离谱,会导致断流
➤若剂量不精细,抖动不够优雅
📝 剂量建议:
➤性能差的软路由,需更大剂量
➤移动宽带,比电/联需更大剂量
➤省会、地市、县城、乡镇,逐级加剂量
➤总之,越导致你家⇄入口RTT>临界延迟的干扰,越要加大剂量
📐该临界延迟约在25~30ms之间
若追求完美毕业,务必反复尝试➕仔细打磨。纯属💦体力活!
3️⃣ 鸡血实验的操作台
✅首选:Linux。能做到大胆改,随便试,毫无后遗症!若效果不佳,另调剂量并替换到/etc/sysctl.conf,重启后又是一条好汉。
⭕️次选:Win。因Windows修改注册表后,恢复或会带记忆性,不如Linux无损试错。建议利用专业版Win附赠的 #HyperV 虚拟一个 #Openwrt 进行尝试。
❌勿选:近4年的 #macOS、#iOS,或未root的 #安卓,因参数已锁死,无解💀💀💀
注意:
调试时建议🔌有线➕一线机场,尽量排除干扰!
4️⃣ 进阶参数
数据包排队规则net.core.default_qdisc也可改:
➤fq,默认,稳妥之选
➤fq_pie,抖动控制很香,但性能开销加剧,仅建议x86或临近入口省份的arm尝试
➤cake,适合武汉等 #先天圣地 的精益求精。离多个入口距离不一者慎选!
其他:欢迎补充✍️
5️⃣ 主/旁路由💉鸡血后,局域网设备能否跟着沾光?
能。但翻墙须部署在鸡血路由上(若其为虚拟机,翻墙插件也要挂在同一虚拟机内)。否则,buff无法传递。具体见图“二”。
⚙️更专业的资料,请参考谷歌云☁️Google Cloud教程
欢迎在评论区补充、分享经验,让鸡血补丁更臻完善。