本帖最后由 hasuboy 于 2024-9-20 13:31 编辑
microka 发表于 2024-9-20 12:34
小白表示很多地方看不懂，想问问中高度pt使用（日常下行跑在几百至千兆上下，峰值跑满2.5G下行，上行不超过 ...
都2024年了，为什么还有人认为PT是小包应用。。。
P2P只是对设备的扛高连接数能力有一定要求，而且PT因为其私有tracker的原因本身就属于小众圈子，就连接数上来说还不如普通的bt。。。而且楼主的测试已经很明显了，消费级别的SOC转发能力其实在高连接数下是要打折扣的，相反我认为软路由在这方面的表现可能还要好那么一丢丢。
我拿PXXX来测了一下，你觉得你玩那个PT有我这个压力大么？[偷笑]
microka 发表于 2024-9-20 12:34
小白表示很多地方看不懂，想问问中高度pt使用（日常下行跑在几百至千兆上下，峰值跑满2.5G下行，上行不超过 ...
以我的环境来看，最高峰上下行1000Mbps，总包速率120Kpps（家用就这点包量），总连接19500(这是连接跟踪数，包含TCP+UDP+DNS+ICMP等，不是活动连接)
2.5G你按倍率往上称，再留点余量就够了，个人认为总包率不会超过350Kpps
cigiti 发表于 2024-9-20 11:30
有现成X86硬件闲置，Vyos可能真就是最佳方案。唯一不爽就是基本只能用nightly build，LTS一般人下不到。 ...
1.4 LTS是订阅（很贵）用户才有，但是，可以自己拉LTS源码编译，中间有些曲折但也能完成，也有能找到编译好的1.4 LTS ISO
myway 发表于 2024-9-20 13:29
1.4 LTS是订阅（很贵）用户才有，但是，可以自己拉LTS源码编译，中间有些曲折但也能完成，也有能找到编译 ...
官方LTS编译源被停了，当然有曲线方式，但是太折腾，有点犯不着。家用nightly build反正也没啥问题。
简化版Winbox加物理机裸装Vyos可能是最理想的方案，但是官方UI不知道啥时候能实现。人懒，现在安安心心用RB5009拉倒，慢慢等。
cigiti 发表于 2024-9-20 13:40
官方LTS编译源被停了，当然有曲线方式，但是太折腾，有点犯不着。家用nightly build反正也没啥问题。
简 ...
1. 先折腾一下VyOS，看看能搞成啥样子。。。这玩意没用过，打算Google + Chat** Plus组合学习
2. 实在不行，RB5009吧。。。
话说回来， 你说的【简化版Winbox】是啥意思？这不是RouterOS的客户端吗？ 不能用于配置VyOS吧。。。
myway 发表于 2024-9-20 13:29
1.4 LTS是订阅（很贵）用户才有，但是，可以自己拉LTS源码编译，中间有些曲折但也能完成，也有能找到编译 ...
LTS源码关闭了外部访问，很多人报告说编译不过，反正Vyos逐步走向死亡。我刚用Vyos不久，Nightly build有很多的bug，比如Cake流控在pppoe没上线时配置报错。
myway 发表于 2024-9-20 13:45
1. 先折腾一下VyOS，看看能搞成啥样子。。。这玩意没用过，打算Google + Chat** Plus组合学习
2. 实在不 ...
虽然 Vyos 命令行并不多复杂，懒人还是需要一个GUI配置工具，类似Mikrotik的Winbox但是不需要WInbox那种巨细靡遗，基本配置尤其拨号设置 、防火墙设置、状态、日志之类的能在GUI里面进行和查看，基本配置之外的用命令行解决。
hasuboy 发表于 2024-9-20 13:16
都2024年了，为什么还有人认为PT是小包应用。。。
P2P只是对设备的扛高连接数能力有一定要求，而且PT因 ...
谢谢，看来不用太在意小包转发能力了
rx_78gp02a 发表于 2024-9-20 13:28
以我的环境来看，最高峰上下行1000Mbps，总包速率120Kpps（家用就这点包量），总连接19500(这是连接跟踪 ...
谢谢，目前在用 x86 j4125 + immortalwrt 23.05，还勉强够用。
rx_78gp02a 发表于 2024-9-20 13:49
LTS源码关闭了外部访问，很多人报告说编译不过，反正Vyos逐步走向死亡。我刚用Vyos不久，Nightly build有 ...
所以，我去找了1.4 LTS编译好的
编译文档：https://gitee.com/gas32/vyos/tree/master/note
1.4 LTS ISO
https://www.123pan.com/s/DvnRVv-hiHY.html
提取码:2mFM
以及这个 https://github.com/dd010101/vyos-build
都挺靠谱的
从家庭宽带用户出发，就我个人的bpi r4使用经验来看，价格，功耗，功能性等综合来考虑，是很满意的。在此之前，我是ros x86的长期用户。
3个PPE的负载不确认下么？237的固件可以看到每个PPE的链接数。
[傻笑]bpi-r4用户来围观，这小路由除了那四个千兆有点食之无味弃之可惜，其它都挺满意的。
myway 发表于 2024-9-20 14:10
所以，我去找了1.4 LTS编译好的
编译文档：https://gitee.com/gas32/vyos/tree/master/note
划重点 vyos目前vpp不支持nat，也就是说，只支持bridge加速。距离完善还有很久
normanlu 发表于 2024-9-20 14:11
从家庭宽带用户出发，就我个人的bpi r4使用经验来看，价格，功耗，功能性等综合来考虑，是很满意的。在此之 ...
要不要跟着我入tnsr教？
我也在用r4，正常使用没有啥特别大的问题，但就是开了PT，上传一大之后，随机可能卡死，UI无法访问，只能拔电重启，也不知道哪边出现了问题，看日志也没有任何的记录
现在用的是lean的6月份的qwrt
本帖最后由 myway 于 2024-9-20 15:59 编辑
summerq 发表于 2024-9-20 15:24
要不要跟着我入tnsr教？
你的大house用的是10GE，固定IP，又不需要PPPoE client，而TNSR不支持，怎么玩？
虽然VyOS的VPP不能用，但NAT目前走常规kernel-based network stack，对于我这1~2 GE下行，<500M上行的，或许kernel的也行。。。？或许 OVS-DPDK 还能抢救一下？
myway 发表于 2024-9-20 15:55
你的大house用的是10GE，固定IP，又不需要PPPoE client，而TNSR不支持，怎么玩？
虽然VyOS的VPP不能用， ...
这周末我去试试，看看能不能给tnsr的vpp加一个pppoe的plugin。vpp自己是带的，但是netgate没有放进去而已。pppoe配置就需要在vppclt里面手动配了。
其实我最近是从tplink硬路由转回到tnsr了，因为有三个原因：1.高并发降速的问题，2. 以及nat转发只有1mpps的问题，3. 硬路由加软路由加ac控制器功耗来到了60-80瓦，而我换成ms-01之后，一个设备替换三个，功耗只有40瓦，比起原来那个p340 tiny，性能强很多，还带了一个15t的u2 ssd，连nas也可以需要时再开机了
本帖最后由 myway 于 2024-9-20 17:24 编辑
summerq 发表于 2024-9-20 16:22
这周末我去试试，看看能不能给tnsr的vpp加一个pppoe的plugin。vpp自己是带的，但是netgate没有放进去而已 ...
这要是能走通，我也可以玩玩TNSR，很久很久以前就留意了，但是早几天去查手册，检索PPPoE，依然没有答案，所以我以为还是不支持。。。
我得找找TNSR的页面，去翻出哪个社区/个人免费版的下载~~
Edit: 噩耗。。。。
大约一年前左右，，，，
TNSR Home+Lab licenses were removed from our store due to factors beyond our control with third party piracy of our software for both pfSense Plus and TNSR. If you would like to try out TNSR there is a 30 day evaluation available. Thank you for your interest.
TNSR software starts at $999/yr per instance.
baicaiwow 发表于 2024-9-20 15:24
我也在用r4，正常使用没有啥特别大的问题，但就是开了PT，上传一大之后，随机可能卡死，UI无法访问，只能拔 ...
我测试的时候崩了很多次，尤其是连接大于10K很容易出现，报错指向硬件PPE模块。
myway 发表于 2024-9-20 17:16
这要是能走通，我也可以玩玩TNSR，很久很久以前就留意了，但是早几天去查手册，检索PPPoE，依然没有答案 ...
定位成企业应用，就不用考虑其他各色人等了。Vyos估计迟早也是殊途同归，无论曾经承诺多美好。最终只能是Bugtik成品越看越亲切。
cp8869 发表于 2024-9-20 11:42
这个应该是mtk hnat版本，最新的openwrt主线6.6也可以硬件加速了，但用的是op自己的硬件加速架构，楼主能 ...
官方的OP安装完LUCI又折腾静态ARP，一堆问题，还没法设置交换芯片，折腾老久。在Firewall下顺利打开了硬件加速，但是发现只有PPE1是正常工作的，PPE0默认使用的交换机上，PPE2闲置，导致打流的时候，从ETH1往ETH2打流数据倒回了ETH1，走的硬件加速，转发2.97Mpps，和闭源驱动的3.08Mpps差不多。从ETH2往ETH1打流数据流向正常，但是走的软件转发，两个CPU核心满载，软件转发251.9Kpps，比我之前用的固件204Kpps高一些（单核满载）。
官方固件版本 OpenWrt SNAPSHOT r27433-7e1d092552 / LuCI Master 24.262.77208~470bb2b
ETH1——>ETH2 打流，但流量返回ETH1，原因未知，转发2.78Mpps
ETH2——>ETH1 打流，双核满载，转发251.9Kpps，流量方形倒是正常的
PPE1 BIND数据
PPE1 ENTRY数据
pdvc 发表于 2024-9-20 14:48
3个PPE的负载不确认下么？237的固件可以看到每个PPE的链接数。
以50条流测试
使用命令cat /sys/kernel/debug/ppe1/bind 人肉目测条数正好是50条
使用命令cat /sys/kernel/debug/ppe1/entries 人肉目测条数正好是50条
cat /sys/kernel/debug/ppe1/bind （末尾）
03d70 BND IPv4 5T orig=16.0.0.14:5789->48.0.0.14:2001 new=16.0.0.14:5789->48.0.0.14:2001 eth=76:e2:02:22:69:d7->26:8a:07:b7:a8:76 etype=0008 vlan=0,0 ib1=60500039 ib2=00f08501 packets=3997236 bytes=239834160
03eb0 BND IPv4 5T orig=16.0.0.30:22125->48.0.0.30:2001 new=16.0.0.30:22125->48.0.0.30:2001 eth=76:e2:02:22:69:d7->26:8a:07:b7:a8:76 etype=0008 vlan=0,0 ib1=60500039 ib2=00f08501 packets=3997205 bytes=239832300
03ff0 BND IPv4 5T orig=16.0.0.46:38461->48.0.0.46:2001 new=16.0.0.46:38461->48.0.0.46:2001 eth=76:e2:02:22:69:d7->26:8a:07:b7:a8:76 etype=0008 vlan=0,0 ib1=60500039 ib2=00f08501 packets=3997197 bytes=239831820
cat /sys/kernel/debug/ppe1/entries（末尾）
03d70 BND IPv4 5T orig=16.0.0.14:5789->48.0.0.14:2001 new=16.0.0.14:5789->48.0.0.14:2001 eth=76:e2:02:22:69:d7->26:8a:07:b7:a8:76 etype=0008 vlan=0,0 ib1=60500057 ib2=00f08501 packets=4605333 bytes=276319980
03eb0 BND IPv4 5T orig=16.0.0.30:22125->48.0.0.30:2001 new=16.0.0.30:22125->48.0.0.30:2001 eth=76:e2:02:22:69:d7->26:8a:07:b7:a8:76 etype=0008 vlan=0,0 ib1=60500057 ib2=00f08501 packets=4605301 bytes=276318060
03ff0 BND IPv4 5T orig=16.0.0.46:38461->48.0.0.46:2001 new=16.0.0.46:38461->48.0.0.46:2001 eth=76:e2:02:22:69:d7->26:8a:07:b7:a8:76 etype=0008 vlan=0,0 ib1=60500057 ib2=00f08501 packets=4605293 bytes=276317580
以5W条流测试
使用命令cat /sys/kernel/debug/ppe1/bind 显示为空
使用命令cat /sys/kernel/debug/ppe1/entries显示如下结果，出现很多new=0.0.0.0:0->0.0.0.0:0 eth=00:00:00:00:00:00->00:00:00:00:00:00空错误
03ffc UNB IPv4 5T orig=16.0.0.230:29728->48.0.11.219:2001 new=16.0.0.230:29728->48.0.11.219:2001 eth=76:e2:02:22:69:d7->26:8a:07:b7:a8:76 etype=0008 vlan=0,0 ib1=500032d3 ib2=00f08501 packets=31817 bytes=1909020
03ffd UNB IPv4 5T orig=16.0.0.230:29808->48.0.91.139:2001 new=0.0.0.0:0->0.0.0.0:0 eth=00:00:00:00:00:00->00:00:00:00:00:00 etype=0000 vlan=0,0 ib1=500002d2 ib2=00000000 packets=0 bytes=0
03ffe UNB IPv4 5T orig=16.0.0.230:29824->48.0.107.123:2001 new=0.0.0.0:0->0.0.0.0:0 eth=00:00:00:00:00:00->00:00:00:00:00:00 etype=0000 vlan=0,0 ib1=500062d3 ib2=00000000 packets=0 bytes=0
rx_78gp02a 发表于 2024-9-20 19:01
官方的OP安装完LUCI又折腾静态ARP，一堆问题，还没法设置交换芯片，折腾老久。在Firewall下顺利打开了硬 ...
楼主辛苦啦！我现在用的是immortalwrt 6.6.51，估计里面有些优化，eth2拨号，eth1为lan，ppe1和ppe2都是可以正常绑定的，mtk网卡驱动默认的ppe最大连接现在应该是16k，可以改到32k，但根据楼主的测试应该作用不大。根据一些大神的经验，家用硬路由里面并发最强的应该是tp的10890，但具体能力未知。另外acwifi测过米万也还行，2k条流无衰减，5k条流才减半，感觉ipq9570的缓存能支持4k。
买完之后，加了一个群[困惑]
BPI受害者交流群（187）
啥固件都不是很好使
cp8869 发表于 2024-9-20 20:11
楼主辛苦啦！我现在用的是immortalwrt 6.6.51，估计里面有些优化，eth2拨号，eth1为lan，ppe1和ppe2都是 ...
immortalwrt的我有看，但是找不到BPI-R4的专属版本，MT7988的烧录SD卡后无法启动，报错
U-Boot 2023.07.02-ImmortalWrt-r27917-81a1f98d5b (Jul 18 2024 - 06:35:54 +0000)
CPU: MediaTek MT7988
Model: mt7988-rfb
DRAM:4 GiB
Core:48 devices, 18 uclasses, devicetree: embed
MMC: mmc@11230000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial@11000000
Out: serial@11000000
Err: serial@11000000
Loading Environment from MMC... *** Warning - bad CRC, using default environment
Net:
Warning: ethernet@15100000 (eth0) using random MAC address - 6a:9b:10:12:8d:87
eth0: ethernet@15100000
MT7988>
rx_78gp02a 发表于 2024-9-20 20:41
immortalwrt的我有看，但是找不到BPI-R4的专属版本，MT7988的烧录SD卡后无法启动，报错
U-Boot 2023.07.0 ...
楼上说的qq群，bpi受害者，里面有固件。
本帖最后由 rx_78gp02a 于 2024-9-20 21:32 编辑
cp8869 发表于 2024-9-20 20:58
楼上说的qq群，bpi受害者，里面有固件。
换了一个版本ImmortalWrt SNAPSHOT r31694-9022262539 / LuCI Master 24.222.22847~fbe46d7，这次测试双向流正常的，但是发现一个新问题，不清楚是不是和我用的桥接有关。之前的测试WEB访问专门弄了一个管理端口，WAN和LAN都是指定的端口，没有用桥接，这次测试LAN是桥接的，WAN还是单独ETH2，测试120条流单向只能到4.6Mpps，并没有实现小包线速，查看CPU的占用为0，确认流量是由硬件转发，并且桥接也没经过CPU。
更新：去掉桥接后结果一致，看来小包跑不满
更新：降低成10条流也跑不满线速，结果为4.5Mpps
更新：1W流由2.05Mpps降低为0.4Mpps，看来非mtk hnat的转发要弱不少
Akiiiiii 发表于 2024-9-20 20:21
买完之后，加了一个群
BPI受害者交流群（187）
这东东有上网行为管控吗？
rx_78gp02a 发表于 2024-9-20 21:21
换了一个版本ImmortalWrt SNAPSHOT r31694-9022262539 / LuCI Master 24.222.22847~fbe46d7，这次测试双 ...
op架构lan可以单独用eth1，不用brlan，mtk hnat是必须要用brlan。