2.10测试版

在之前 默认状态下UTP是开启的
bc目前的UTP功能还存在问题 其会导致CPU占用升高

在早期测试中发现bc在使用UTP传输时不能正确和其他非bc客户端
协商MTU导致几乎没有传输速度 这可能导致CUP占用提高的一个原因

比特彗星UTP有史以来默认值一直是禁用,没有默认开启,可能是第三方的修改版开起来的
UTP现在不传输任何数据都会吃满一个CPU核心,应该从最早一开始的版本就存在这个现象了

我在两台不同地区的机器上都测试了一下,端口映射后可以检测为绿灯的。会不会是其他原因?

我这里正常的。

我这里做了一下针对性的测试:

peer连接优先级调整

我将连接数进行了限制,现在只有一个任务,并连接最多 40 个 Peers

反吸血检查

直接禁止了

接收到的分块数据进行hash检查

限速 10KB/s。

还是救不回来 WebAPI 的响应速度。

又换了常用的虚拟机测试了一下发现正常了
可能是当时用于测试的虚拟机存在一些问题


目前来看确实是默认禁用的 不过bc支持UTP也有不少时候了
早期的情况有点记不清楚 也许因为测试需要打开了UTP形成了错误的印象
不过这个MTU 的问题应该是真实存在的 也许应该在较新的版本中再测试一下

UTP现在不传输任何数据都会吃满一个CPU核心

这个是怎么测试的,我在我的 VM 里面测了一下,uTP 设置为 “优先”,但我内核占用看着还行。

我开了5个BT任务,下载速度40MB/s,WebUI响应时间基本在500ms以内


这个在前些版本已经支持mtu动态调整了(好像是1.95,要翻一下更新说明才知道了),以前是固定的一个值,后来大概提高3倍的吞吐量,不过依旧很差,视乎是延迟发起引起的,因为通过打流软件是能正常支持高宽带的

试一下打开摘要和用户面板,一旦点开,响应速度就严重受到影响


如果来回切换的话(PBH会轮流请求不同的接口,而且会并发请求),速度会影响更严重,并且延迟可能会累加。切换速度越快,频率越高,响应越慢。

没有任何上传速度的话,只要发起peer请求为utp,就会占用满一个CPU核心,流量图选择CPU占用率,看UDP传输线程,就知道了,如果电脑为8线程,那么启用utp后那么这个线程始终占用100/8=12%的CPU
任务管理器由于调度器问题,可能不显示在一个物理核心上,所以可能不便观察,任务管理器切换到详细信息里面也可以看到占用CPU在12-13%
这个UTP启用后的问题可能官方一直找不到是什么情况所以这都两年了还没修复CPU

关于主界面卡死响应慢的问题我得知结果大概是文件数影响

我打开了 uTP 开关,并看到了有 uTP 用户已连接。

然后我看着占用挺好的。就刚刚截图的一瞬间,CPU 占用率突然就上去了,但在此之前已经有 uTP 连接了,不知道触发了什么条件。

软件和WebUI里的任务摘要和用户列表都试过了,我这边对延迟没有太大影响,是不是还有其他影响因素

我测试了一下,实体机和虚拟机内都有类似的情况。
虚拟机是 Windows 10 22H2,昨天全新安装。实机是 Windows 24H2。

这个问题还会影响到登录,因为登陆的时候它有时候也会超时。比如说添加下载器的时候点击“测试下载器按钮”,PBH 会去尝试登录 BitComet。
体现是 BitComet 要等好久,右下角才会弹出登录提示,然后再等一会儿才会有响应返回。有时 WebUI 自己的登录也是,要等一段时间才能登进去。

这个问题不是 100% 复现的,但不止我一个人存在这个问题。不过多试几次它自己就好了……
考虑到卡住的时间几乎和我上面提到的报错的时间几乎一样长,我怀疑是同一个问题。

是不是还有其他影响因素

应该没有了,计时器直接加在了请求的两侧,没有多余代码。我这里浏览器打开 WebUI 请求性能也不是很好。

目前UTP有两个问题,一个就是CPU,一个就是速度龟速,使用第三方UDP网卡打流软件,发送UTP数据包内容到比特彗星接收,速度是很正常的,所以我猜测是比特彗星有个什么网络处理发起延迟导致速度不快,这两个问题解决后,默认值就可以从禁用改为自动检测了

也有可能是默认的pending的request太小,不过之前开发者说每8秒自动调整一次pending,最大值是1000,不知道是不是对于udp没有自动调整成功,tcp应该是可以调整的,下载速度会随着持续时间变化升高

之前的测试结果已经可以排除运营商限制utp,并且其他BT软件的utp速度也是比特彗星的几十倍(但是其它BT软件都不支持NAT打洞,全世界只有比特彗星这款BT软件支持)

录个视频看一下 什么操作会引起延迟上升?


bc UTP的 似乎比想象中的还要大
在刚才进行了一些简单的测试 发现即使在局域网条件下 两个使用UTP传输的BC客户端
都无法达到较快的速度 更不用说跑满带宽了

其还伴随着不定时的连接断开 以及高CPU占用
更详细的测试准备放到明天

好像有,我刚刚参与 uTP 的调试,调着调着 WebAPI 的延迟就好了。

做了个一个对比测试,在我给种子的下载速度上了个很低的限制后,延迟就会明显下降,恢复到 30ms 的样子。

这个限制一取消,延迟立刻爆表。主线程 CPU 占用率图表上看似乎没有什么太大的变化。

看一下UDP传输线程 UTP的传输占用应可在其中体现出来

uTP 的异常占用可以用 Process Explorer 或者 Process Hacker 之类的工具查看 Threads

严格来说不是占满一个核心,而是某单个线程
奇怪的是下载时启用不一定出现,反而是空闲时突然占用飙升

这是正常情况下

这是开启 uTP 后过一段时间捕捉到的占用瞬间
注意图表中的 UDP 传输线程

可以看到突然有个 BitComet.exe+0xaa04e8 的线程跑上来,CPU 和 Cycles delta 都非常高

另外,我这边监测 uTP 异常占用时,WebUI 的响应并没有变化

我也是这个线程,堆栈如下

0x0000000000000000
ntdll.dll!ZwFreeVirtualMemory+0x14
KERNELBASE.dll!VirtualFree+0x4a
BitComet.exe+0x4e7e70
BitComet.exe+0x4e7a15
BitComet.exe+0x1b8674
BitComet.exe+0x1b8820
BitComet.exe+0x1b950f
BitComet.exe+0x1b795b
BitComet.exe+0x1b5fa6
BitComet.exe+0x1b9e41
BitComet.exe+0x508746
BitComet.exe+0x51db39
BitComet.exe+0x50852b
BitComet.exe+0x9d1a43
BitComet.exe+0xaa0545
KERNEL32.DLL!BaseThreadInitThunk+0x17
ntdll.dll!RtlUserThreadStart+0x2c
1個讚