pretty sure the double /boot is normal, I've seen the question asked before.
Yes.
I just shoved 23.05.0-rc2 on it, a couple of minutes ago (the download page showed that the files had uploaded nearly two hours ago, so I took a gamble...) by sticking the 23.05.0-rc2 squashfs-combined-efi image into the GUI, like normal.
The upgrade completed successfully, and the device retained its configuration. What might happen if and/or when the partition table in the image gets altered, I don't know. But an in-place upgrade worked for now.
I just built a snapshot and found the double mount.
1 Like
Hooking up two network cables (pc & switch) and doing a simple speedtest. This shows about 50% of the normal speed at the switch directly.
I’m positively surprised by your iperf3 metrics - will do these here as well and report back.
Once I have some more time to setup the device (needs lxc/pihole and wireguard plus a bunch of VLANs/interfaces setup), I will replace my RPi4B with it and test apples-to-apples with iperf3 and with general stuff and also report back in this thread.
1 Like
Finally got the t8plus rotated into the same space as the RPi4B and am happy to report the iperf3 test saturates the line as it did with RPi4B.
# iperf3 -s -f m
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 10.9.8.101, port 37930
[ 5] local 10.9.8.1 port 5201 connected to 10.9.8.101 port 37946
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 109 MBytes 913 Mbits/sec
[ 5] 1.00-2.00 sec 109 MBytes 913 Mbits/sec
[ 5] 2.00-3.00 sec 109 MBytes 913 Mbits/sec
[ 5] 3.00-4.00 sec 109 MBytes 913 Mbits/sec
[ 5] 4.00-5.00 sec 109 MBytes 912 Mbits/sec
[ 5] 5.00-6.00 sec 109 MBytes 912 Mbits/sec
[ 5] 6.00-7.00 sec 109 MBytes 913 Mbits/sec
[ 5] 7.00-8.00 sec 109 MBytes 913 Mbits/sec
[ 5] 8.00-9.00 sec 109 MBytes 913 Mbits/sec
[ 5] 9.00-10.00 sec 109 MBytes 911 Mbits/sec
[ 5] 10.00-10.00 sec 369 KBytes 1540 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.06 GBytes 913 Mbits/sec receiver
-----------------------------------------------------------
Server listening on 5201 (test #2)
-----------------------------------------------------------
1 Like
Given that a ten year old Atom j1900 can do routing at 1 GBit/s wirespeed (without sqm) easily, the previous results were pretty unexpected, given how much faster this system is.
Happy to share that this PC can do snort3 in IPS mode and deliver >650 Mbps on a speed test. Link to post. The RPi4B by contrast, only powers snort3 around 100-200 Mbps.
2 Likes
Power consumption
- Idle = 6 W (0.01 loadavg)
- Snort3 IPS with no network load = 6 W (0.08 loadavg)
- During speed test = 9-11 W
- Running stress with 4 threads = 13 W
1 Like
I still have issues (although I may have created them myself, should take some time with default configs). My remark above was from my initial test, where I stopped when I saw the ~100 mbits result. However this is assymetric as can be seen below.
First, here is my ACE Magician T8 OpenWRT fingerprint:
root@OpenWrt:~# ubus call system board
{
"kernel": "5.10.176",
"hostname": "OpenWrt",
"system": "Intel(R) Celeron(R) N5095 @ 2.00GHz",
"model": "Intel Corporation Jasper Lake Client Platform",
"board_name": "intel-corporation-jasper-lake-client-platform",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "22.03.4",
"revision": "r20123-38ccc47687",
"target": "x86/64",
"description": "OpenWrt 22.03.4 r20123-38ccc47687"
}
}
Network setup
ACE Magician T8 WAN <-> Switch <-> Raspberry Pi
ACE Magician T8 LAN <-> Win11 PC
Iperf3 results (arrow indicates client to server)
ACE Magician T8 WAN -> Raspberry Pi 708/705
ACE Magician T8 WAN <- Raspberry Pi 108/108
ACE Magician T8 LAN -> Win11 PC 721 / 721
ACE Magician T8 LAN <- Win11 PC 941 / 941
Win11 PC -> Raspberry Pi 793 / 793
The low throughput (Pi->PC vs PC->Pi) may be due to retransmissions (~300 vs ~0). There is no significant amount of retransmissions to the T8 from either side.
It is not an iperf3 version mismatch, also not a Windows issue (Ubuntu shows the same). Wiping the raspberry pi to see if that resolves the issue.
I would run an 2nd ssh session on the pi and run top or htop while doing the testing. It might be that it is just running out of CPU cycles causing the low performance from Rpi to Ace
Thank you - I do not see a bottleneck at the Raspberry Pi 4B CPU.
In my opinion there is something wrong with (the OpenWRT install at) the ACE Magician T8 (clean config with WAN & LAN in br-lan).
RPi -> Switch -> Win 949/949
Win -> Switch -> RPi 942/942
RPi -> T8 -> Win 108 / 108
Win -> T8 -> RPi 711 / 710
Linespeeds to the T8 are ~940, so the issue must be (with OpenWRT) handling the routing/switching between eth0 and eth1 on my device.
@darksky : I'd be really curious to see your config and settings. Would you be willing to share so I can try to replicate ?
what does htop say about the cpu load, during those slow T8 benchmarks ?
- In your diagram, is your "switch" is replaced by your T8 using the same network architecture and same physical cables?
- What is your "switch?"
- What kernel is your T8 running?
My T8's:
/etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd1d:692b:58dc::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
option ipv6 '0'
config bridge-vlan
option device 'br-lan'
option vlan '3'
list ports 'eth0:t'
config bridge-vlan
option device 'br-lan'
option vlan '4'
list ports 'eth0:t'
config bridge-vlan
option device 'br-lan'
option vlan '5'
list ports 'eth0:t'
config bridge-vlan
option device 'br-lan'
option vlan '10'
list ports 'eth0:t'
config device
option type 'bridge'
option name 'lxcbr0'
option ipv6 '0'
option bridge_empty '1'
config interface 'wan'
option device 'eth1'
option proto 'dhcp'
config interface 'guest'
option device 'br-lan.3'
option proto 'static'
option ipaddr '10.9.7.1'
option netmask '255.255.255.0'
config interface 'homeoffice'
option device 'br-lan.4'
option proto 'static'
option ipaddr '10.9.6.1'
option netmask '255.255.255.0'
list dns '1.1.1.1'
list dns '1.0.0.1'
config interface 'iot'
option device 'br-lan.5'
option proto 'static'
option ipaddr '10.9.5.1'
option netmask '255.255.255.0'
config interface 'lan'
option device 'br-lan.10'
option proto 'static'
option ipaddr '10.9.8.1'
option netmask '255.255.255.0'
config interface 'lxc'
option device 'lxcbr0'
option proto 'static'
option ipaddr '10.0.4.1'
option netmask '255.255.255.0'
config interface 'wg0'
...
@darksky -
thank you for your prompt feedback and config.
Regarding your questions:
- Not an in-place swap, but reconnected cables to the T8 (instead of wall outlet). Same cables were used, just total length was shorter. Cables were swapped to rule out cable issue
- Cisco SG350-20
- "kernel": "5.10.176"
Essentially I had the same set up as you (but without VLANs). DHCP client on eth1 (WAN), static on eth0 (LAN).
I then moved them into the same bridge and zone for the re-test, without effect on the iperf3 results.
I’ll have a closer look at htop as suggested by @konus and @frollic above.
I’ll report back with more detail
I am using a snapshot I build which is running the 5.15 series of kernel so if your network hardware is identical, recommend that you try a snapshot.
EDIT:
We are not running the same hardware at all:
# ubus call system board
{
"kernel": "5.15.119",
"hostname": "t8plus",
"system": "Intel(R) N95",
"model": "Default string Default string",
"board_name": "default-string-default-string",
"rootfs_type": "ext4",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r0+23454-01885bc6a3",
"target": "x86/64",
"description": "OpenWrt SNAPSHOT r0+23454-01885bc6a3"
}
}
https://www.cpu-monkey.com/en/compare_cpu-intel_celeron_n5095-vs-intel_processor_n95
Yes, you are right - mine is the T8 Pro (not T8 plus).
Glad you’re not seeing the issue. Maybe it’s just the T8 Pro. Will post findings here.
-- EDIT --
Tried again, different cables & different machines (xeon && i7) - issue has gone away (kind off)
Iperf3 now reports ~700 Mbps in either direction, both forward and reverse testing.
Hooking up the raspberry pi shows the same behaviour - so probably bad cable (connection). Still puzzled why that would be unidirectional...
In comparison to my switch, there is still a ~30% performance hit (~700 vs ~940 Mbps) when using the T8pro. Maybe caused by the slower CPU as compared to the T8plus.
Network interface is indeed the same:
root@OpenWrtX86:~# lspci
...
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter
I've been having roughly the same issue since i got my T8plus. It's still in the testing phase, and i could narrow my issue to this:
Somehow, the nics in this mini pc do not like switches.
If i do a direct cable between a pc and the device ( doesnt matter if its the lan or wan interface) iperf3 results are stable ~950mbit. If i put any switch ( i tried unifi switch and a cisco) between a pc and the device, one direction in iperf3 will be ~80-90mbit, while the reverse will be ~940mbit. And it gets more weird... If i do iperf3 with 4-5 parts, sometimes it does ~940mbit combined, sometimes ~70-80mbit.
Also, for a quick test i just plugged the WAN port into my existing network, disabled the input fw on it and did some speed tests with the ookloa speedtest script. My gigabit fiber had like... 4 mbit down and ~900mbit up according to it. If i leave out the switch connecting directly to my old routers lan port, its 940/940. Something is wrong here but i can't really find it why.
Tried replacing cables, changing ports on the switch, changing ports on the t8plus, nothing really helps. Also its the same with 23.05-rc2 and 22.03.5.
Does anyone have any advice about this? I can't put this into production in this state...
Thanks!
1 Like