>意思说“ 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 ）

root@vultr:~# time dd bs=64k count=4k if=/dev/zero of=test
4096+0 records in
4096+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 1.03808 s, 259 MB/s

real 0m1.044s
user 0m0.004s
sys 0m0.707s

vultr 最低配的。

> 我原来是用的 $$TAP 和 $$R 组合的，卡
这样只是做了流量转发，没有优化丢包率。你可以尝试在 tap 和 R 之间加个 UDP 加速器。

@Loyalsoldier

软件的定位是网络工具，目标用户是有一定动手能力的人。

另外你说的很复杂的东西，只是敲 3 条命令而已。

UDP 协议本身虽然是无连接的，在防火墙 /NAT 设备 /应用程序中一般都是有连接的概念的。
所谓中断是说某个 4 tuple 比如（ 2.2.2.2,4444,3.3.3.3,5555 ）在一定时间内无法发送或接收数据了。（被防火墙故意阻拦了、NAT 设备把 NAT pipe 掐断了，等原因）

udp2raw+udpspeeder+$$tap 的教程，别人写的：

https://burgertown.site/2017/12/25/Speeder/

>但是又被原来的 eRecovery 覆盖了。

现在 android 刷入第三方 recovery 之后，必须在手机重启后强制进入 recovery 一次，recovery 会对 android 打补丁；如果你没做这个操作直接进入了 android，你的 recovery 就会被还原成官方的。

>其中掌声最热烈的一次来自 Google 云首席科学家李飞飞，宣布成立 AI 中国中心，落地在北京，李飞飞与李佳亲自领导中心研发。

这算不算回归中国有点进展了？

@mandymak
不需要

>VPN 拨回家里只能电信进入
这句没看懂
>除非你有 BGP，否则是无法实现这种路由策略的。
楼主有 2 条宽带，用 2 个宽带分别开一个 openvpn client 连到 vps，然后自己做路由策略，决定上传和下载走哪条 VPN。是可行的，不需要有自己的 AS 号。

google 一下 UDPspeeder 或者 tinyFecVPN，就是像楼主所说的用带宽换丢包率。 如果丢包高是 ISP 造成的，应该可以解决。 如果是 wifi 信号造成的，不是很确定，你可以试一下。