based on this commit it should do the trick
uci set firewall.@defaults[0].flow_offloading=1 && uci commit && /etc/init.d/firewall restart
1 Like
It worked. Still, the uplink speedtest takes 2-3 seconds to start and it is not reaching 200megs. On the other hand, when I upload to Gdrive, I can reach a stable 27MB/s.
This enables software flow offload, if you want to try hardware flow offloading, change flow_offloading to flow_offloading_hw.
And, if you want to check which connections are offloaded:
cat /proc/net/nf_conntrack
Offloaded connections will have the [OFFLOAD] tag
I i use flow_offloading_hw and execute
cat /proc/net/nf_conntrack | grep OFFLOAD
I get none...
When i use flow_offloading i get a few connections...
actually hw offload works.. it seems to need both flow_offloading_hw and flow_offloading to work..
I confirm. Both offload and hw_offload needs to be enabled. I now reach 910-920Mbits DL, 213Mbits UL on a PPPoE connection, with almost no CPU usage at all.
ndb did an extremely good job here.
So the commands that makes this work are:
uci set firewall.@defaults[0].flow_offloading=1
uci set firewall.@defaults[0].flow_offloading_hw=1
uci commit
/etc/init.d/firewall restart
1 Like
Out of curiosity: how much % idle are you seeing during:
- Upload
- Download
Uploading with 220Mbits via PPPoE to Gdrive:
Downloading with speedtest, about 900Mbits via PPPoE:
As you can see the download consumes a lot less resources then the upload. But none the less: it is signifficantly better then it was before. I never reached above 700megs (it was around 600megs on average) for the DL, and now its 900+ all the time.
Very nice. Yeah uploading via a pppoe connection is pretty brutal on CPU usage. It sucks my ISP is using pppoe as well, because I am capping at 400 mbit instead of reaching 500 mbit. Even with flow_offload (no difference compared to having it turned off). Haven't tried flow_offload_hw just yet, but I am thinking the bottleneck will be the same. The pppoe encapsulation seems to utilize 100% of one thread and doesn't scale to more threads.
Well, if you look at the PPPoE protocol, I really dont see why would it take 3-4 times more resources the encapsulate then decapsulate PPPoE packets, yet thats what happnes. I dont think this is something to do with PPPoE itself, maybe the offloading is not yet working for the upink direction or the uplink+pppoe direction.
Hi!
I built an image for xiaomi mir3g. from freshly cloned lede source change kernel to 4.14
it works but only software offloading work or i don't know, but firewall doesn't recognise the hw version. Do i have to install something else then kmod-ipt-offload, which is already default?
i get this warning on firewall restart.
Warning: Option @defaults[0].flow_offloading_hw is unknown
Build from nbd's git, then you have hw offload 
It seems I was overly optimistic. Today I checked the kernel log and it is completely full with the following repeating content:
[168855.532588] net_ratelimit: 1 callbacks suppressed
[168855.532597] nf_conntrack: nf_conntrack: table full, dropping packet
[168856.055732] nf_conntrack: nf_conntrack: table full, dropping packet
[168858.799980] nf_conntrack: nf_conntrack: table full, dropping packet
[168858.805211] nf_conntrack: nf_conntrack: table full, dropping packet
[168859.235466] nf_conntrack: nf_conntrack: table full, dropping packet
[168859.325488] nf_conntrack: nf_conntrack: table full, dropping packet
[168859.327403] nf_conntrack: nf_conntrack: table full, dropping packet
In my case both offload and offload_hw is enabled. It seems the system itself works correctly, but I am fairly sure this is not normal.
@Mushoz Just to reply to the PPPoE question: I took a look at the code and I think the PPPoE is also "accelerated" in a sense that after the PPPoE encap/decap the packets are being offloaded. The PPPoE protocol itself is so simple, that I dont know if its possible to "accelerate" any part of it by hardware. But maybe I am wrong.
Yes, this is also what I saw when I played around with the software flow offload. CPU usage was quite a bit lower with it enabled versus disabled. However, they both were capped at the same speed and with one thread being pegged at 100% CPU usage. While pppoe is a very simple protocol, at high speeds it can still saturate a single core of the dir-860l since those aren't that fast. Bummer is isn't multithreaded.
increase your conntrack table size
1 Like
I couldn't compile my default image configuration, ntfs-3g failed to compile no matter what i tried. For now i removed ntfs-3g then it is compiled. I'll try it out soon. GCC7.3, binutils 2.30, -O3 optimization.tried O2 and Os too. I didn't tried 2.29.1 binutils.
To spot errors while compiling I use the following make command:
make V=s 2>&1 | tee build.log | grep -i error
Multiple causes exist why a module does not compile but without a build log it is hard to diagnose.
i found out that with make V=s that is /sbin/ldconfig not update /etc/ld.so.cache because of permission issue. the strange thing is that if compile from original master source it can be built without errors, but nothing has changed in nbd git's ntfs3g. However i didn't run make clean, since than so that is a cached package. the main prolem is with ldconfig. Can i safely delete the cache file from etc?
in that case, I would run make dirclean before compiling the build
Were the earlier Tx power issues ever fixed? Also, can anyone give a rough range for wifi with this router in feet/meters?