@wwwqq8254289 不会用 linux 的问题我不能帮你解决

tcp 加速除了 bbr 还有 kcptun、finalspeed、dragonite。

@weizhen199 根据我自己的测试--timeout 0 和-q1 效果是非常接近的。 不过在 cpu 很忙的情况下--timeout 0 可能不如-q1 好。

>还有-q1 和-timeout 0 一起用大丈夫吗？
可以一起用。不过-q1 会 override 掉 timeout 参数。`-q1 --timeout 0`等于只用`-q1`

@tangyang332 你是不是按照 [udp2raw+UDPspeeder+OpenVРN 原生运行在 windows/macOS 上加速全流量] 这个链接配置的？用里面的 openvpn 配置文件

@wwwqq8254289 udpspeeder 不配合 vpn 只能转发 udp。需要同时转发 tcp 和 udp 用 kcptun+udpspeeder 或者 tinyportmapper+udpspeeder

@wwwqq8254289 我用你贴的命令不能复现 [FATAL]unknown option <3f>的问题。

>这样对否，然后我本地软件填 127.0.0.1 端口 1003 么。。
按照你贴的命令，你连 127.0.0.1 的 1003(udp)就相当于连 66.33.55.4 的 1003(udp)

@wwwqq8254289 你贴的是啥，把命令原样贴出来。

@chocolatesir 抱歉墙的问题不能解答，不过你按照链接里的教程游戏和上网是没问题的。

@Love4Taylor

SIP003 只支持 tcp 不支持 udp，基本不能配合 UDPspeeder 用。

udp2raw 还是可以用的。github 上有 udp2raw+kcptun 的 SIP003 插件，https://github.com/w1ndy/kcptun-plugins。 这个组合是加速 tcp 的，要想支持 udp2raw+UDPspeeder 加速 udp，只能寄希望于 SIP003 协议的作者加入 udp 支持。

>玩游戏加速用？先收藏了
游戏加速可以，最初就是为了玩美服的游戏写的。

@Love4Taylor 不懂 android 不知道啥是 Android Plugin。。

>意思说“ 1 ”，也就是物理上的延迟是没有办法降低的，kcp 也好 udpspeeder 也好，降低的都是 2 的延迟，对吧？

对。 除了物理方法（比如专线），没有软件可以降低物理延迟。

@lly8666 你看一下 tinyfecVPN 的 wiki，有个文章说的就是怎么重定向流量，用在 lede 上可能得结合这个文章自己研究一下。

@lly8666

新建一个类型为 unmanaged 的 interface, 然后在 physisc setting 那里把物理 interface 选成 tunXXX

@SCGabriel
我刚才在你开的 issue 里回你了。

>vps 服务器上的设置错误您能帮忙看下错哪里不？这块咱真的只是刚刚接触的人，捣鼓了一个星期，其他都架成了就这个没架对

有这么复杂吗，repo 里面有这个固件的详细教程，基本上照着敲就可以了。

可以看：
https://github.com/wangyu-/UDPspeeder/wiki/koolshare 版梅林固件 UDPspeeder 和 udp2raw 串联的完整设置
或者：
https://github.com/wangyu-/udp2raw-tunnel/issues/104

搞了一星期，路由器那边的照着敲的设置都填错了？

路由器端明显不对，github 上有这个固件的教程，自己对比。

@bukip

解读：

>Big simplification: Proper way to fix an hardware bug like this, is that newer cpu gets protected by default, and they answer they are when queried.

So you can ask the CPU "what's your status on bug X" and the cpu answers "i'm good, you don't need to do anything" (newer fixed chips), or "i know about it but was already built, and need microcode update/special behavior to protect myself" (current chips with microcode update), "no answer / I'm not good" (old chips without update).

So new stuff is protected, and you add more protection (and slowdowns, and special stuff) for older chips that don't know how to deal with it.

What Intel is trying to do here, is to go the other way: the chips, even the new ones, will stay vulnerable by default, and when queried they say "I have a fix but I don't use it, you can enable it by asking !" and the kernel is supposed to enable it.

It's terrible for a lot of reasons, like "boot an older os and it's vulnerable since it doesn't know to call this", "additional code to enable this feature has to run for all of eternity for new chips now, instead of having to run for older chips and being phased out over time", etc ...

The reason why Intel does that seems obvious: by default the chip does not lose speed since the fix is not enabled, and so instead of "intel chips lose 30% speed over night because of a flaw" it becomes "intel adds a special security mode that protects you even more for critical applications, at the cost of some speed". Purely marketing speech and decision at the cost of proper engineering decisions, and they need and try to get OSes like Linux to play along. That's what he means by "[it] shows intel had no intention of fixing those flaws".

Additionally there seems to be a second issue in that the quality and behavior of the patches they submitted are trying to hide this deceptively simple but technically terrible behavior by making it look/sound obtuse and complicated.

In other words, intel is using its presence and weight to try and push a shitty solution, but one that is better for them marketing wise. Linus is flabbergasted to be treated like an idiot or a obedient drone that should apply such obvious abusive patches.

（搬运自 reddit 和 hacker news，
https://www.reddit.com/r/sysadmin/comments/7s47h9/linus_torvalds_is_not_happy_about_inte ）