I know the datasheet is from 2015.
The ipq6000 series in the Flint and Slate AX are aarch64, but there are currently no stable builds that work with aarch64 on those devices. Everyone I’ve seen is running those on the 4.4 qsdk kernel. The 5.4 qsdk is about 30 percent slower in my testing, with unknown stability. I did get the 5.4 to build in aarch64, but it didn’t boot on first try and I didn’t bother trying to go farther. I sort of feel like that hardware is a dead end given the MT3000 coming out.
Some initial speed tests and … ? I’m not sure where the bottleneck is, but there’s some sort of performance wonky.
I’ve got gigabit fiber, and speed test from the device is pretty decent:
Idle Latency: 19.69 ms (jitter: 0.37ms, low: 19.17ms, high: 19.99ms)
Download: 795.31 Mbps (data used: 889.9 MB)
21.07 ms (jitter: 1.63ms, low: 18.99ms, high: 32.69ms)
Upload: 722.11 Mbps (data used: 1.3 GB)
22.14 ms (jitter: 2.69ms, low: 16.86ms, high: 43.26ms)
Packet Loss: 0.0%
Speed test from a wired client, though… boy howdy:
Testing download speed................................................................................
Download: 351.29 Mbit/s
Testing upload speed......................................................................................................
Upload: 271.42 Mbit/s
I tried several times, and that wasn’t the best I got, but it wasn’t the worst either.
It looks like the a1300 is under some pretty severe load just trying to move packets across the interfaces.
If you’re just using it for a travel router, performance seems fairly decent:
OpenVPN, TCP, CHACHA20-POLY1305, run from A1300, displayed on web because the CLI display janked:
Speed test to same server from wired client was slower but still pretty respectable:
I suspect that some of the problem may be that I’m running iptables-nft (damn you Tailscale!) which may be responsible for some of the performance issues. I don’t know how much if any overhead that introduces over running nftables directly, but that would be the first place I’d look for some gains, if I cared. But largely I don’t.
WireGuard performance was weird too, getting 15mbps down and 200mbps up which seems… wrong? The upload speeds are in line with what you’d expect, so not sure where the D/L problem is. No time to debug at the present. I don’t recall having these problems running stock-ish on 21.02 with either the Slate AX or Brume 2 - I need to fire up an OG Brume and see what I get on performance there building a custom 21.02 and 22.03 build, since GL’s stock builds had some bad openssl options and suffered about a 40% performance penalty compared to a well optimized build.
So anyway… a mixed bag, maybe. I’m sure there are some things I could tweak a bit to get better performance, but this isn’t my main device, so my motivation is somewhat limited.
2 Likes
Have you tested with hardware acceleration? I don’t know if she gives anything on this device in the OpenWRT mainline, that’s why I’m asking.
Crypto acceleration? Yeah, engine support is built in, but GCM isn’t accelerated in hw. Turns out to still be faster than CBC. I tried enabling offload for NAT but that didn’t seem to make a difference.
Ok - so part of my issue in pt 1 is that I was using a really crappy speedtester. So doing things better:
From A1300:
Idle Latency: 24.41 ms (jitter: 0.74ms, low: 23.73ms, high: 25.04ms)
Download: 772.29 Mbps (data used: 923.5 MB)
25.96 ms (jitter: 7.00ms, low: 23.67ms, high: 292.17ms)
Upload: 714.27 Mbps (data used: 951.4 MB)
24.28 ms (jitter: 2.55ms, low: 22.01ms, high: 43.35ms)
From wired client:
Idle Latency: 25.78 ms (jitter: 2.18ms, low: 24.29ms, high: 30.46ms)
Download: 727.12 Mbps (data used: 725.4 MB)
25.37 ms (jitter: 4.37ms, low: 23.23ms, high: 254.52ms)
Upload: 555.91 Mbps (data used: 996.8 MB)
24.49 ms (jitter: 1.68ms, low: 23.39ms, high: 49.96ms)
I also started from a clean slate on WireGuard and got more reasonable results:
(from A1300)
From wired client:
That said I did have to reboot the thing this morning to get an IP address. I’ll leave it up and see how it does through the day.
1 Like
Brief update - I’ve been messing with various builds off and on today. Looks like DCO isn’t ready yet for ovpn (I built 2.6 beta 1 and… well, it didn’t go well). That said, I’m pretty consistently able to get 40/35 or so from a wired client on the LAN using OpenVPN TCP ChaCha20-Poly1305, which is ~2xish the published figures - though IIRC I was able to get well into the 30’s on a clean build from the infra-builder and a 5.4 kernel.
2 Likes
The numbers looks nice!
1 Like
Could you do a performance comparison between OpenWRT and GLiNet firmware?
I just want the test environment to be the same.
1 Like
I’ll try if I get around to it. I assume they’re close enough that it won’t be the determining factor in what you choose. The differences I’m getting are almost certainly down to differences in e.g. OpenVPN configuration (using chacha which is faster on the a1300, unlike the ipq6000 and MT7981 routers) rather than the kernel version.
1 Like
Could you send me the result of the lxc-checkconfig command?
Below is my result
If I understand correctly because the result is missing one parameter that will enable LXC on A1300 using the official GL.iNet software.
I’m curious if you can run LXC containers on the official OpenWRT firmware.
I need LXC containers to run Ubuntu on A1300. Unfortunately, the ARMv7 processor does not support virtualization via KVM.
I need Ubuntu to run many packages that are not available for OpenWRT. e.g. compiling libraries for pip.
Have you installed the rest of the required dependencies for lxc to work?
Link to instructions below:
I’ll check again, but it was an inability to find the kernel config rather than a dependency error, IIRC.
I could go back and compile it all in, but…
Ok. I’ll look more here in a bit.
1 Like
Thank you, I look forward to hearing back from you.
Spinning a snapshot with (supposedly) full lxc compat now. Will let you know
1 Like
root@OpenWrt:~# lxc-checkconfig
LXC version 5.0.1
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
--- Control groups ---
Cgroups: enabled
Cgroup namespace: enabled
Cgroup v1 mount points:
/sys/fs/cgroup/systemd
Cgroup v2 mount points:
/sys/fs/cgroup
Cgroup v1 freezer controller: missing
Cgroup v1 clone_children flag: enabled
Cgroup device: missing
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled
--- Misc ---
Veth pair device: enabled, loaded
Macvlan: enabled, loaded
Vlan: enabled, not loaded
Bridges: enabled, not loaded
Advanced netfilter: enabled, loaded
CONFIG_IP_NF_TARGET_MASQUERADE: missing
CONFIG_IP6_NF_TARGET_MASQUERADE: missing
CONFIG_NETFILTER_XT_TARGET_CHECKSUM: missing
CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled, loaded
FUSE (for use with lxcfs): missing
--- Checkpoint/Restore ---
checkpoint restore: missing
CONFIG_FHANDLE: enabled
CONFIG_EVENTFD: enabled
CONFIG_EPOLL: enabled
CONFIG_UNIX_DIAG: missing
CONFIG_INET_DIAG: missing
CONFIG_PACKET_DIAG: missing
CONFIG_NETLINK_DIAG: missing
File capabilities:
Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
1 Like
Do you have the ability to create a working LXC container?