ACEMAGICIAN T8PLUS (Intel N95)

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 ?

@fodiator -

  1. In your diagram, is your "switch" is replaced by your T8 using the same network architecture and same physical cables?
  2. What is your "switch?"
  3. 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:

  1. 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
  2. Cisco SG350-20
  3. "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

Yes, apparently it's a bind mount at work, see: /boot is mounted twice - #4 by qwrty-ftw

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

I'd try two things

disable auto neg, and force 1gbit full duplex using ethtool (if it works for RTL NICs)
boot some recent Linux dist from a flash drive, see if the same issue occurs there

Tried the first, nothing happened. Even when auto is on, it is negotiated at 1gbit. Also tried disabling energy efficient stuff on the switch still the same.
So quickly booted an ubuntu 23.04 with 6.2 kernel, and... everything is perfect there.
Same r8169 driver... so i guess it's probably the kernel. 5.15 is quite old. Also it feels like the intel pstate driver behaves differently on 6.2, though nothing scientific i can provide to prove that.