Optimized build for the D-Link DIR-860L

Hi Jaap, due to the flu I haven't done any testing except for testing my bed :stuck_out_tongue:
However, I noted two new mac80211 commits so I'll make a new build and test it tomorrow!

1 Like

I'm on a skiing holiday in Sweden, so no testing from my side either for the next week :slight_smile: good luck testing!

Enjoy your holiday!

Compiled a fresh new build (r6420) with the latest mac80211 patches, ran my non-scientific tests and the results are in the table below.

Build Band (GHz) Speed (Mbits/sec)
r6420 2.4 40.0
r6420 5 41.1
r6339 2.4 105
r6339 5 14.59
r6336 2.4 75.6
r6336 5 99.1
r6302 2.4 58.4
r6302 5 91.8
r6150 2.4 56.7
r6150 5 107
r6009 2.4 43.7
r6009 5 40.7
r5442 2.4 73.5
r5442 5 57.4

So WiFi throughput is down as compared to previous builds. @nbd if you want me to post wireless stats, do certain tests or test builds with or without certain commits let me know!

@Bartvz Could we get a new build with whatever commits you think are good based on your testing? Would like some of that WiFi goodness!

kmod-fs-ntfs is the module, you may need to force because of the checksums. There should be some more info above when i tried to install the ext4 module (which is now built in and if you format your usb to ext4 it will work)

Please post the rate control stats while transferring data. Thanks.

OP updated with a fresh new build. Thank Windows Update for the wait, explanation below :wink:

As @pivanov84 said, install the kmod-fs-ntfs module and then it should work. NTFS is not recommended on Linux since it is cpu hungry and write speeds are slow. EXT4 is a better choice unless you are also going to use the disk on a Windows machine.

Turns out that the reason for my "performance anomaly" was Windows Update "updating" the drivers of my wireless nic to a previous version which was buggy. Disabled Windows updating drivers and speeds are back to the for me normal 100 MBits/sec range.My apologies for wasting your time!
Will do some testing with a new build and if you want the rate control stats, I'll provide them.

How much is there difference between 17.01.4 and this build? Would you recommend this over the 17.01.4 for daily use (I don't plan to use SQM or cake)? Thanks!

This is more cutting ding edge, meaning lots of updates to packages and more importantly, updates to the mt76 driver. Cutting edge doesn't mean unstable because builds are tested before release or in the case that they aren't tested, they are marked as such. And, yes, I run this in a production environment (~15 wireless devices).
Secondly, built with latest binutils, GCC6 (next build is with 7) and optimized compiler flags. This should produce better code and this should run better.
Lastly, even though you can install packages quite easily via an ssh terminal or via LuCI, my builds contain what I consider base packages. Stuff like AdBlock, BCP38 and WireGuard among others.
Some new features are in the planning stages but due to getting a new job next to my regular job, time is limited. Hope this answers your question!

2 Likes

In case you guys missed it, this is kinda interesting :wink:

2 Likes

Awesome! When can we try out a build?!

Testing stage at the moment :wink:

1 Like

No weirdness on my part so for those wanting to test, download the r6562 experimental build here.

2 Likes

Running fine for me after ~5 hours up time!

I am seeing close to 100% utilization (mostly kernel) on all four cores with a gigabit PPPoE connection, and the max speed in DL is about 600megs. Do I need to enable anything for the HW NAT to work?

1 Like

Yes. You need a firewall rule that defines which connections to offload. I am not sure if the command works the same for HW offload, or if you need to specify that manually, but the following command was used to enable software offloading:

iptables -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD

Maybe @nbd could elaborate? Also, PPPoE encapsulation / decapsulation isn't offloaded and also takes up quite some processing power. So it could be that PPPoE will bottleneck you before you are able to hit gigabit speeds.

Out of interest, what kind of upload speeds does your line have and how much are you seeing?

After I gave the command you suggested, the connection performns signifficantly better on the DL side: I am now reaching 820-850megs with the CPU still not maxed out. A lot better then it previously was. But the uplink is now slower, and strangely the speedtest uplink test's first 2-3 seconds is 0Mbits, but even then it is not reching the 200megs (which was available before I applied the rule).

MOD: maybe I need to delete the default conntrack rule before I add the flowoffload rule?

The connection is 1gig/200megs GPON over PPPoE.

You should try flow_offloading in /etc/config/firewall if you have recent firewall3!

EDIT: correct config option

1 Like

can you explain please? what should i add to /etc/config/firewall ?

Is this configurable in luci-app-firewall?