@goodryb #7 配置了一个 goreleaser 的 github workflow ，现在有自动的打包了 https://github.com/faceair/clash-speedtest/releases/tag/v1.0.0

@1423 #12 是存在的，而且很普遍。

类比一下你去阿里云开一个小鸡，带宽只给 1m ，那么延迟可以很低同时带宽也很低。在机场这里的情况一般是香港的节点延迟低，但是可能受限于机器的带宽或者 IEPL 、IPLC 专线的带宽，实际大文件的下载或者看视频会卡。这种情况通过 Clash 的 url-test 或者你之前提到的 ttfb 是看不出来的。

@gujigujij #13 这个帖子里就不歪楼了，可以搜一下站内之前的讨论 https://www.google.com/search?q=site:v2ex.com/t%20%E6%9C%BA%E5%9C%BA%20%E6%8E%A8%E8%8D%90

@cssk #8 这是两个类型的指标，应该独立看待，我在 README 中已经有些介绍了。

@christin #4 你可以使用 -f 参数来指定你想测速的节点，也可以使用 -s 参数指定单次测试要下载的文件大小。

@1423 #5 介绍中我已经对比了 TTFB 类型的测速方法的几种缺陷：
1. 如果 Loadbalance 的策略不好测出全部节点的延迟
2. TTFB 只能代表延迟不能测出带宽，是有可能延迟低但带宽也低的
所以实际上 TTFB 的测试在这种情况下并不好用。

@goodryb #7 这种比较敏感的应用如果手动 Release 二进制还是有些风险的，后面我看下是否可以通过 Github Workflow 来自动打包，增强中间的透明度

很怪，你看可以单开一个项目的

在 macOS 端也是可以用命令行来登录的，在点击 UI 的 get started 之后，不点 join network ，然后去命令行执行

/Applications/Tailscale.app/Contents/MacOS/Tailscale up --login-server https://login.xedge.cc

就可以连上了，目前官方的客户端体验比 xedge-tui.app 好不少

你的这个计算方法 QPS 不叫并发，并发一般指同时进行的请求数。

From GPT-4:

在这个情况下，由于你设置了 -t 30 参数，这意味着 ab 压测工具在 30 秒后会停止发送请求。因此，在压测过程中，只有在 30 秒内完成的请求会被记录。在你的压测结果中，只有 319 个请求在 30 秒内完成，因此 Complete requests 和 Failed requests 的和不等于 1000 。

为了确保你的 1000 个请求都被发送和记录，你可以将 -t 参数去掉，或者将其设置为一个足够长的时间，以便所有请求都能在这段时间内完成。

同时，请注意，如果你想要发送更多的请求，也可以适当增加并发级别（-c 参数）。但请注意，增加并发级别可能会增加服务器的负载，所以需要根据实际情况进行调整。

2 个

@jybox 可以拆分一下问题。
该不该有监管？我提 GPT4 的例子是想表达这部分大家都是得做的，但都凭借自己的理解搞的话比较难统一思想。国内涌现的 ChatAI 太多了，可以有个法规规定下限。
这个法规是否过度？我之前没有发表看法，从大家的讨论来看某些条款是过度的，是可能会影响到商业创新。我觉得法律规定到下限比较合理，即至少不反人类、反国家，至于在其他的种族歧视或者一些道德问题上暂时可以适当宽容一点。

https://i.imgur.com/Dw2fqo6.png

GPT4 训练出来后也是多花了半年来做内容安全，由厂商自觉变成法律规定其实也没啥问题吧。

升级内核试试

JSON 是专有名词，不应该有小写形式的 Json

简单自用场景开通 plus 更便宜？

之前插别的充电器后出现过类似情况，重启就好了

白痰问题不是很大，黄痰细菌感染 可以监测一下血氧，不放心就去查 ct

https://i.imgur.com/518H7kI.png
32g + 1t ，余量很足

小孩是前一两天发烧，大人是从二三天开始发烧，正常情况下就会有一点错峰。我家小孩刚满 1 岁，发了两天烧后面就没啥事了，精神和状态都恢复地挺好，没有其他咳嗽相关的症状。