On the Glinet Marble, are there tests with/without Network Acceleration?
What is the great benefit of activating Network Accel?
With the hadrware acceleration, the load for the CPU will be lower.
by how much, which percentage?
It will activate propetairy boost function of the chip so that packets are better offloaded.
If the driver support hw acceleration, it can make your internet speed a little faster without the cost of the cpu.
But since we talk about qualcomm (nss offloading), and gl-inet, maybe hw acceleration doesn't work, numberous times I readed to disable it for qsdk platform to fix issues, I believe nss offloading is by default active by a background script.
If you want to use some sort of QoS/traffic control, hw acceleration is not compatible because these sort of functions skip the cpu.
You have to try it, but expect it could have downwards effects.
1 Like
I have been using a Flint2 for about 6 months now. Until about a month ago I used hardware acceleration. I read on this forum about users starting to have random problems and one solution was to disable hardware acceleration. I then ran several days of speedtests, and decided to leave it disabled.
I have a fairly simple setup. I have about 50 clients, 4 of which are TV’s that can all be streaming at the same time, and I run Adguard on the router. I don’t have any VPN’s. I use about 60% of the memory. I have a 500mb fiber line.
The tests I ran indicated that Hardware Acceleration made a minor difference in cpu usage. I would go from 1% with it on, to 3-4% with it off (measured with Netdata). I couldn’t find any change in router temperature. My download speeds were the same with it on or off, about 600mb.
From other posts on this forum, it seems that MediaTek has greatly reduced or abandoned support for this chip. I decided I was willing to live with a small increase in CPU usage. Even if I’m not having problems with hardware acceleration now, it seems likely that I would in the future.
Others on this forum have 1gig or even 2 gig fiber lines. Maybe hardware acceleration makes a bigger difference for them.
2 Likes
from what I know from this feature in gl ui, is that it is just this in luci under the firewall tab:
^ note I use a custom theme.
But since luci is designed for OpenWrt, and also OpenWrt drivers, the MTK SDK did a poor job of implementing the full luci support, and likely if not all it either doesn't work, or broken.
however when I read responses of GL devs, it gives me the assumption they are not going to fix it which mean this functionality is more of a remnant if not broken, you have likely much more better chance on OP24 builds for this, for QSDK platforms this is kinda the same except you need to disable GL_QOS scripts for NSS offloading to work.
but as offloading also ignores certain firewall implementations such as QoS, SQM these are not compatible and ignore any traffic limiting tools.
it would be a good practice to check how it performs with these gl qos scripts turned off, which are in /etc/init.d/ although they keep renaming them so you have to ask them which one incorperates the speed limiter one.
1 Like
Thank you for the answers about Hardware acceleration.
Additionally I got once more confirmed to discourage Glinet Mediatek routers, but to go with Glinet Qualcomm instead…
I’m using Hardware Acceleration on my Flint 2 and I don’t face any issues. However, disabling it seems intriguing since I want accurate speed/traffic statistics, parental control, and VPN w/ IPv6. What would I lose out on if I disable it?
Honestly it isn't the router, but the lack of GL-iNet software control imo, I see lately much more reports on issues for mtk sdk, than for their op24 versions.
But they have no plans to make op24 the mainstream one, therefor their statement on their dl site is something I don't agree on.
Op24 has a recenter base of OpenWrt than MTK sdk, but op24 has a lower version of the GL-sdk (ui, and stuff), MTK has a ancient version of OpenWrt which is EOL but has a newer version of gl sdk, it doesn't mean they can backport security patches but...
The same count for Qualcomm, but Qualcomm has less support to be official supported by OpenWrt and luci is there also not fully supported.
And then they also compile a group of packages and share it among all these different OpenWrt versions which can cause all sorts of other issues, they really make it complicated 
Tl;dr for devs:
Here is one thing I learned from java and most of it also applies on other softwares, pointing towards OpenWrt buildtools.
one can compile something with java 11 and it can still run with java 7 and it is backwards compatible most of the times.
but when one compiles at java 7 and runs java 11, likely it breaks.
Now if you place this vision on the tools which come from make download on different SDK, then the compillation forward compatibility breaks because these group of packages where under a older sdk with older tools, you want to compile at highest version for backward compatibility which isn't possible with these sdks.
so ultimately you want to have each kernel have its own package chain rather than moving a group of packages on completely different compiled platforms, they can cause unexpected results and I'm not talking about kmods.
3 Likes