Optimized build for the D-Link DIR-860L


#1

I have been building custom builds for my DIR-860L for a while now and now I hope that by sharing them they will make other people happy as well. All my releases are tested on my router before they are released. Ofcourse, these builds cater to my needs but I am open to criticism/suggestions/tips.

I am not responsible for bricked devices, thermonuclear war, you getting in a fight because you destroyed the internet, etc! By flashing this custom, custom firmware you take full responsibility of your actions. That includes knowing what to do when s**t hits the fan! There be dragons here!

What's inside?
LuCI (luci-ssl-openssl-nginx) with material theme
Apps: adblock, banIP, BCP38, SQM QoS (+cake), UPnP and WireGuard
Utilities and others: ethtool, iperf3, irqbalance, nano, msmtp and wget (with ssl support)
Tweaks: built with GCC 8 and binutils 2.31.1

Changelog:
r2919: Initial release to the public
r3128: Dropped the compiler optimization flags (-Os -pipe -mno-branch-likely -mips32r2 -mtune=1004kc -mmt -mdsp) because they caused the build to fail, removed HZ = 1000 since I noticed no real benefit. Removed curl.
r3194: Added iptables-mod-tee iptables extension.
r3636: Removed luci-app-watchcat, added irqbalance and compiled with new compiler optimization flags(-Os -pipe -mno-branch-likely -mips32r2 -march=1004kc -mdsp).
r4245: Removed irqbalance and iptables-mod-tee
r4414: Upstream updates
r4426: Upstream updates (this commit should improve WiFi performance)
r4498: Upstream updates + this commit by blogic which should fix cpu core calibration!
r4577: Upstream changes (most notably newer kernel version (4.9.37) and latest mt76 driver), added BBR TCP congestion control algorithm and the fq packet scheduler (defaults are cubic and fq_codel).
r4633: Upstream changes. Most notably the latest version of the mt76 driver and a patch for the rcu_sched stalls!
r4651+1: Upstream changes and added Qualcomm shortcut-fe (thanks to @dissent1). Due to a derp untested!
r4714+1: Upstream changes and an updated Qualcomm shortcut-fe which should work with SQM QoS.
r4767+3: Upstream changes, most notably this commit.
r4949: Upstream changes, most notably a backport concerning the ethernet driver and an updated version of mt76. Removed addrwatch because it caused the build to fail. Removed Qualcomm shortcut-fe because it doens't play nice with SQM QoS.
r5017: Upstream changes
r5099: Upstream changes, most notably update to mt76 nand driver and KRaCK patches. Compiled with GCC 7.2.0.
r5394: Openssl optimized for speed and upstream changes most notably an updated mt76 driver which should increase throughput.
r5442: Added WireGuard and support for USB storage (untested! FAT32 and ext4 filesystems should work.) Also, as usual, upstream changes. Most notably an updated mt76 driver and an updated cake qdisc.
r5448: Upstream changes, most notably an update to the latest MT76. Instead of using the -Os compiler optimization flag, -O2 is used to fix dropbear bugging out.
r5578: Switched back to GCC 6. Upstream changes most notably an updated mt76 driver and the latest bake of cake with a brand new ack-filter which mostly should improve throughput on asymmetrical connections. Happy holidays!
r5645: Upstream changes, most notably an update to cake.
r5762: Added support for LUKS encryption. Upstream changes most notably a few bugfixes to cake.
r6009: Upstream changes most notably an updated mt76 driver and these two commits (should slightly improve rx performance).
r6150: Replaced SSMTP with msmtp. Upstream changes, most notably an updated mt76 driver and commits which fix the VLAN functionality of the switch.
r6302: Version 4.14 of the linux kernel with the modules required for Flow Offload. Upstream changes, most notably an updated mt76 driver and a couple of mac80211 commits
r6502: Upstream changes, enabled MIPS FPU emulation
r6640: Upstream changes, most notably switch to linux kernel 4.14 and support for HW NAT, huge thanks to @nbd and @blogic!
r6646: Upstream changes, added luci-app-ddns, added support for the exFAT file system
r6653: Upstream changes, most notably an updated mt76 driver
r6690: Upstream changes, most notably an updated mt76 driver.
r6705: Upstream changes, most notably an updated mt76 driver + other assorted fixes for the ramips platform.
r6795: Upstream changes, most notably an updated kernel and a fix for possible data corruption on multicore systems.
r6953: Upstream changes, most notably an updated kernel, an updated mt76 driver, WireGuard MIPS optimatization and fixes for the mt7621 ethernet driver.
r7161: Upstream changes, lots of important ones but due to my laptop dying no listed notable changes from my part.
r7188: Upstream changes, most notably fixes for flow offload.
r7274: Upstream changes, most notably an updated mt76 driver, a fixed full routed GRO->TSO offload and a fix for jumbo frames (mtu > 1500). Switched from uhttpd to nginx for LuCI, which is asynchronous so should be more responsive.
r7301: Upstream changes, most notably an updated mt76 driver.
r7493: Upstream changes, added ebtables, added new compiler optimization flag (-ftree-vectorize).
r7540: Upstream changes, compiled with GCC8, added back filesystem modules (thanks @TPLinkUser!) and cake now supports tc classes (aka more to mess around with).
r7682: Upstream changes
r8089: Upstream changes most notably an updated mt76 driver, updates to WireGuard and re-enabled MIPS vDSO.
r8196: Upstream changes, most notably an updated mt76 driver and commits for mac80211, most notably this one.
r8216: Upstream changes, most notably an update MT76 driver and fixes for the CAKE SQM QoS algorithm.
r8289: Upstream changes, most notably gcc-optimized inlining and enabled memory compaction
r8340: Upstream changes, most notably an updated mt76 driver and a refreshed mt7621 kernel config.
r8349: Upstream changes, most notably an updated mt76 driver (mostly cleanups).
r8467: Lots of upstream changes, most notably updated mt76 driver and wireguard. Also, banIP is now included. It creates an ipset of known bad IP addresses which is kinda neat. Should provide a bit more security at the cost of some ram.

Downloads:


Enabling SQM causes bufferfloat to go from B to C on a cable connection
Enabling SQM causes bufferfloat to go from B to C on a cable connection
#2

Wondering if you'll keep building off master or will switch to the 17.01 branch (or maybe provide both)?


#3

The plan was to switch over to the stable branch with some experimental bleeding edge builds along the way.


#4

I might be interested in buying this router, since the mediatek wifi drivers are the most opensourced ac drivers, but I am wondering whether the CPU in this router is good enough for my needs. I am using a 200/40 Mbit internet connection and I would like to be able to use the piece of cake shaper. Is the CPU in this router able to route and shape 200 Mbit of incoming traffic? Or should I look at beefier routers (probably ipq806x based routers, although I hate the Ath10k driver). Thank you very much in advance!


#5

I am thinking the same thing about the cpu. (not about ath10k)


#6

@Mushoz & @enri: I can not tell from personal experience since I have a 10/1 Mb/s connection since that is the maximum speed possible at my location. But, if this blogpost is something to go by, my guess is that it would be fast enough. An older 680 MHz MIPS CPU in the Netgear WNDR3800 vs the newer, dual-core, hyper-threading MIPS CPU in the D-Link DIR-860L. However, it will not hurt asking around this forum (what you guys are already doing) or on the Cake mailing list.

Also, I have released a new build. Enjoy!


#7

@Mushoz, @enri - Where you able to find out if this CPU will handle cake on so fast connection?


#8

Thanks @Bartvz

@r43k3n I have ordered this and will arrive next few days, hope it will be B1
I don't know the speed. Will update if I have info

FYI, in a remote site which have 100 up 100 down, WZR-HP-G300NH - 400MHz router handle my request well: set 96000 can get 94 Mbps for for cake up down handle well. My only complain is slow CPU make OpenVPN - 16 Mbps down only. (A x86 LEDE VM 80Mbps VPN down.)


#9

I'm thinking about buying Ubiquiti EdgeRouter X which has the same CPU as DIR-860L B1.
I found this information about this unit:

  • Both fq_codel and Cake top out for me somewhere between 120 and 140 Mbit symmetric
  • Both fq_codel and Cake are capable of 20 Mbit upload, 200 download on this hardware, but Cake's results appear "better" (significantly higher average throughput)

Source: Cake and FQ-PIE compiled for the EdgeRouter devices

Based on that I think it will handle 200/40 Mbit connection. Those tests where made on stock RouterOS firmware. I hope LEDE can do better.


#10

Anyone have difficulties when setting 5G to 36-44?
It disconnect after connecting successfully


#11

Below are the log

Sat Feb 11 03:18:31 2017 daemon.info dnsmasq[3173]: read /etc/hosts - 4 addresses
Sat Feb 11 03:18:31 2017 daemon.info dnsmasq[3173]: read /tmp/hosts/odhcpd - 0 addresses
Sat Feb 11 03:18:31 2017 daemon.info dnsmasq[3173]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sat Feb 11 03:18:31 2017 daemon.info dnsmasq-dhcp[3173]: read /etc/ethers - 0 addresses
Sat Feb 11 03:18:32 2017 daemon.info odhcpd[891]: Initial RA router lifetime 0, 1 address(es) available on br-lan
Sat Feb 11 03:18:35 2017 daemon.info dnsmasq-dhcp[3173]: DHCPDISCOVER(br-lan) aa:bb:cc:dd:ee:ff 
Sat Feb 11 03:18:35 2017 daemon.info dnsmasq-dhcp[3173]: DHCPOFFER(br-lan) 192.168.8.145 aa:bb:cc:dd:ee:ff 
Sat Feb 11 03:18:37 2017 daemon.info dnsmasq-dhcp[3173]: DHCPDISCOVER(br-lan) aa:bb:cc:dd:ee:ff 
Sat Feb 11 03:18:37 2017 daemon.info dnsmasq-dhcp[3173]: DHCPOFFER(br-lan) 192.168.8.145 aa:bb:cc:dd:ee:ff 
Sat Feb 11 03:18:37 2017 daemon.info odhcpd[891]: Initial RA router lifetime 0, 1 address(es) available on br-lan
Sat Feb 11 03:18:38 2017 daemon.info dnsmasq-dhcp[3173]: DHCPREQUEST(br-lan) 192.168.8.145 aa:bb:cc:dd:ee:ff 
Sat Feb 11 03:18:38 2017 daemon.info dnsmasq-dhcp[3173]: DHCPACK(br-lan) 192.168.8.145 aa:bb:cc:dd:ee:ff Henrys-Air
Sat Feb 11 03:18:39 2017 daemon.info dnsmasq-dhcp[3173]: DHCPREQUEST(br-lan) 192.168.8.145 aa:bb:cc:dd:ee:ff 
Sat Feb 11 03:18:39 2017 daemon.info dnsmasq-dhcp[3173]: DHCPACK(br-lan) 192.168.8.145 aa:bb:cc:dd:ee:ff Henrys-Air
Sat Feb 11 03:19:01 2017 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff IEEE 802.11: disconnected due to excessive missing ACKs
Sat Feb 11 03:19:01 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED aa:bb:cc:dd:ee:ff
Sat Feb 11 03:19:01 2017 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff IEEE 802.11: disconnected due to excessive missing ACKs
Sat Feb 11 03:19:31 2017 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Edit:
Further adjusting the settings, the default Transmit Power: Auto will disconnect my client. But setting specifically a number, e.g. 19dBm will make it connect without any problem. The Tx-Power is still the same

Channel: 36 (5.180 GHz) | Tx-Power: 19 dBm

So strange.


#12

I notice those "disconnects" too but it looks like only Apple products are affected. My environment consist of mostly PC's and Android phones + 2 Macbooks and 1 iPhone. The latter show the same disconnects.
This looks like the culprit:

Sat Feb 11 03:19:01 2017 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff IEEE 802.11: disconnected due to excessive missing ACKs

A quick Google search led me to the conclusion that is not an exclusive problem to LEDE (OpenWRT ticket).
Reading this led me to a possible solution: try disabling the disassoc_low_ack option in hostapd.

To all: New build is incoming. Working out the kinks atm. A compiler flag caused some exceptions and thus stack traces. Atm testing, testing, testing.


#13

@Bartvz Thanks for letting me know you see the same thing. I am on Macbook too.

To me, after messing with the power settings, plus your disassoc_low_ack trick, it come up in my mind thinking the auto adjust dBm become too weak so it disconnect me? Will try to test further with that option

Looking forward to your new build

P.S. the ath10k wifi I have at the moment won't disconnect me


#14

Tested, setting disassoc_low_ack 0 does not help.

Only using higher channel can delay the connection drop, but it will still drop


#15

Then I would advise posting your experience and logs to the mailing list where there are more technical people.


#16

I flashed your r3194 and it is working fine for an hour now, so I don't know if I should report on the bug list - don't have much other info except those few lines I posted above. Let me use a few days and see how it goes.


#17

Is there a way to improve the 2.4GHz performance?

In the stock OEM, it can perform at about 80Mbit, but with LEDE, only 9Mbit is archived.


#18

Quick update: Still building and testing since I have run into some snags.
First snag was stack traces like the one below popping up:

[details=click here]Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.173000] WARNING: CPU: 3 PID: 0 at net/core/skbuff.c:4194 skb_try_coalesce+0x228/0x35c()
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.189000] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TEE xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CLASSIFY slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipvThu Feb 9 18:39:54 2017 kern.warn kernel: [23041.424000] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.47 #0
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.436000] Stack : 00000000 00000000 804c6862 00000033 00000000 00000000 80460000 804e0000
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.436000] 87c4bf6c 80461c83 803df434 00000003 00000000 804c367c 87c21d3f 804fade0
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.436000] 00000000 80063260 80460000 804e0000 80466188 8046618c 803e4068 87c21bec
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.436000] 00000003 8006101c 87c21d3f 804fade0 00000000 00000126 00000000 00c21bec
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.436000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.436000] ...
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.507000] Call Trace:
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.511000] [<8001671c>] show_stack+0x6c/0x88
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.520000] [<801b1180>] dump_stack+0x8c/0xc0
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.529000] [<8002b944>] warn_slowpath_common+0xa0/0xd0
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.539000] [<8002b9fc>] warn_slowpath_null+0x18/0x24
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.549000] [<8028c16c>] skb_try_coalesce+0x228/0x35c
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.559000] [<802e7510>] tcp_try_coalesce+0x70/0xd4
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.569000]
Thu Feb 9 18:39:54 2017 kern.warn kernel: [23041.572000] ---[ end trace a0c02c7791d287cb ]---[/details]

Second snag is random reboots at the moment. I will not release a build unless it is stable. However, if you guys are using "stock" LEDE, do you also run into random reboots?

@enri just did a quick iperf3 run with my latest build (r3511) using my laptop (connects at 144 Mbps) on the 2.4 GHz band using the following switches on the client: "-c -n 512M". These are my results:

[details=click here][ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 8.75 MBytes 72.9 Mbits/sec
[ 4] 1.01-2.02 sec 7.75 MBytes 64.3 Mbits/sec
[ 4] 2.02-3.00 sec 8.00 MBytes 68.2 Mbits/sec
[ 4] 3.00-4.00 sec 6.88 MBytes 57.7 Mbits/sec
[ 4] 4.00-5.00 sec 6.12 MBytes 51.4 Mbits/sec
[ 4] 5.00-6.00 sec 5.88 MBytes 49.3 Mbits/sec
[ 4] 6.00-7.00 sec 7.50 MBytes 62.9 Mbits/sec
[ 4] 7.00-8.00 sec 8.25 MBytes 69.1 Mbits/sec
[ 4] 8.00-9.00 sec 7.00 MBytes 58.8 Mbits/sec
[ 4] 9.00-10.00 sec 5.88 MBytes 49.3 Mbits/sec
[ 4] 10.00-11.00 sec 6.75 MBytes 56.6 Mbits/sec
[ 4] 11.00-12.00 sec 6.25 MBytes 52.5 Mbits/sec
[ 4] 12.00-13.00 sec 5.50 MBytes 46.1 Mbits/sec
[ 4] 13.00-14.00 sec 5.62 MBytes 47.1 Mbits/sec
[ 4] 14.00-15.00 sec 4.25 MBytes 35.7 Mbits/sec
[ 4] 15.00-16.00 sec 3.75 MBytes 31.5 Mbits/sec
[ 4] 16.00-17.00 sec 3.88 MBytes 32.5 Mbits/sec
[ 4] 17.00-18.00 sec 4.88 MBytes 40.9 Mbits/sec
[ 4] 18.00-19.00 sec 4.12 MBytes 34.6 Mbits/sec
[ 4] 19.00-20.00 sec 3.75 MBytes 31.5 Mbits/sec
[ 4] 20.00-21.00 sec 4.75 MBytes 39.8 Mbits/sec
[ 4] 21.00-22.00 sec 4.00 MBytes 33.5 Mbits/sec
[ 4] 22.00-23.00 sec 3.00 MBytes 25.2 Mbits/sec
[ 4] 23.00-24.00 sec 3.38 MBytes 28.3 Mbits/sec
[ 4] 24.00-25.00 sec 4.25 MBytes 35.6 Mbits/sec
[ 4] 25.00-26.00 sec 1.50 MBytes 12.6 Mbits/sec
[ 4] 26.00-27.00 sec 4.00 MBytes 33.6 Mbits/sec
[ 4] 27.00-28.00 sec 4.00 MBytes 33.5 Mbits/sec
[ 4] 28.00-29.00 sec 4.38 MBytes 36.7 Mbits/sec
[ 4] 29.00-30.00 sec 4.12 MBytes 34.6 Mbits/sec
[ 4] 30.00-31.00 sec 3.00 MBytes 25.2 Mbits/sec
[ 4] 31.00-32.00 sec 4.12 MBytes 34.6 Mbits/sec
[ 4] 32.00-33.00 sec 3.88 MBytes 32.5 Mbits/sec
[ 4] 33.00-34.00 sec 4.88 MBytes 40.9 Mbits/sec
[ 4] 34.00-35.00 sec 5.50 MBytes 46.1 Mbits/sec
[ 4] 35.00-36.00 sec 5.12 MBytes 43.0 Mbits/sec
[ 4] 36.00-37.00 sec 4.88 MBytes 40.9 Mbits/sec
[ 4] 37.00-38.00 sec 5.12 MBytes 43.0 Mbits/sec
[ 4] 38.00-39.00 sec 3.75 MBytes 31.5 Mbits/sec
[ 4] 39.00-40.00 sec 4.75 MBytes 39.8 Mbits/sec
[ 4] 40.00-41.00 sec 6.50 MBytes 54.6 Mbits/sec
[ 4] 41.00-42.00 sec 7.50 MBytes 62.9 Mbits/sec
[ 4] 42.00-43.00 sec 7.75 MBytes 65.0 Mbits/sec
[ 4] 43.00-44.02 sec 5.00 MBytes 41.2 Mbits/sec
[ 4] 44.02-45.00 sec 5.00 MBytes 42.7 Mbits/sec
[ 4] 45.00-46.00 sec 7.25 MBytes 60.8 Mbits/sec
[ 4] 46.00-47.00 sec 9.12 MBytes 76.6 Mbits/sec
[ 4] 47.00-48.00 sec 7.12 MBytes 59.8 Mbits/sec
[ 4] 48.00-49.00 sec 7.38 MBytes 61.8 Mbits/sec
[ 4] 49.00-50.00 sec 7.12 MBytes 59.8 Mbits/sec
[ 4] 50.00-51.00 sec 6.50 MBytes 54.5 Mbits/sec
[ 4] 51.00-52.00 sec 5.88 MBytes 49.3 Mbits/sec
[ 4] 52.00-53.00 sec 5.62 MBytes 47.1 Mbits/sec
[ 4] 53.00-54.00 sec 7.00 MBytes 58.8 Mbits/sec
[ 4] 54.00-55.00 sec 7.75 MBytes 64.9 Mbits/sec
[ 4] 55.00-56.00 sec 4.62 MBytes 38.8 Mbits/sec
[ 4] 56.00-57.00 sec 5.88 MBytes 49.3 Mbits/sec
[ 4] 57.00-58.00 sec 5.38 MBytes 45.1 Mbits/sec
[ 4] 58.00-59.00 sec 5.00 MBytes 42.0 Mbits/sec
[ 4] 59.00-60.00 sec 6.50 MBytes 54.5 Mbits/sec
[ 4] 60.00-61.00 sec 6.88 MBytes 57.7 Mbits/sec
[ 4] 61.00-62.00 sec 6.62 MBytes 55.6 Mbits/sec
[ 4] 62.00-63.00 sec 5.75 MBytes 48.2 Mbits/sec
[ 4] 63.00-64.00 sec 8.62 MBytes 72.4 Mbits/sec
[ 4] 64.00-65.00 sec 5.25 MBytes 44.0 Mbits/sec
[ 4] 65.00-66.00 sec 5.75 MBytes 48.2 Mbits/sec
[ 4] 66.00-67.00 sec 4.25 MBytes 35.7 Mbits/sec
[ 4] 67.00-68.00 sec 6.88 MBytes 57.6 Mbits/sec
[ 4] 68.00-69.00 sec 7.12 MBytes 59.7 Mbits/sec
[ 4] 69.00-70.00 sec 6.38 MBytes 53.6 Mbits/sec
[ 4] 70.00-71.00 sec 7.12 MBytes 59.8 Mbits/sec
[ 4] 71.00-72.00 sec 6.62 MBytes 55.5 Mbits/sec
[ 4] 72.00-73.00 sec 5.88 MBytes 49.2 Mbits/sec
[ 4] 73.00-74.00 sec 5.88 MBytes 49.3 Mbits/sec
[ 4] 74.00-75.00 sec 4.00 MBytes 33.6 Mbits/sec
[ 4] 75.00-76.00 sec 4.38 MBytes 36.7 Mbits/sec
[ 4] 76.00-77.00 sec 5.12 MBytes 43.0 Mbits/sec
[ 4] 77.00-78.00 sec 5.75 MBytes 48.3 Mbits/sec
[ 4] 78.00-79.00 sec 5.25 MBytes 44.0 Mbits/sec
[ 4] 79.00-80.00 sec 5.38 MBytes 45.1 Mbits/sec
[ 4] 80.00-81.00 sec 6.00 MBytes 50.3 Mbits/sec
[ 4] 81.00-82.00 sec 6.00 MBytes 50.4 Mbits/sec
[ 4] 82.00-83.00 sec 5.12 MBytes 43.0 Mbits/sec
[ 4] 83.00-84.00 sec 5.50 MBytes 46.1 Mbits/sec
[ 4] 84.00-85.00 sec 5.50 MBytes 46.2 Mbits/sec
[ 4] 85.00-86.00 sec 1.75 MBytes 14.7 Mbits/sec
[ 4] 86.00-87.00 sec 3.38 MBytes 28.3 Mbits/sec
[ 4] 87.00-88.00 sec 4.38 MBytes 36.7 Mbits/sec
[ 4] 88.00-89.00 sec 4.25 MBytes 35.6 Mbits/sec
[ 4] 89.00-90.00 sec 4.62 MBytes 38.8 Mbits/sec
[ 4] 90.00-91.00 sec 5.38 MBytes 45.1 Mbits/sec
[ 4] 91.00-92.00 sec 4.38 MBytes 36.7 Mbits/sec
[ 4] 92.00-92.69 sec 3.88 MBytes 47.5 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-92.69 sec 512 MBytes 46.3 Mbits/sec sender
[ 4] 0.00-92.69 sec 512 MBytes 46.3 Mbits/sec receiver

iperf Done.[/details]
Sounds to me like a problem somewhere. Could be you chose a crowded band or that your device connects at a low speed due to hardware. This is a good setup guide and contains excellent pointers on how to improve wireless performance for the 2.4 GHz band.


Dir-860l Rev B1 very poor wifi performance
#19

@Bartvz
Thanks for the test results. It is about the same of the best I can get.
In the 11 channels (1 to 11) I can choose from, only 1 can create a speed up to 70Mbps at 2 times out of 20 times with speedtest.net. Others are well below, like 30Mbps is the maximum, and usually below 20Mbps. It is not so noise and busy here, only 11 AP around. With the old ath9k and another ath10k 2.4GHz performance are always around 85Mbps, in all 11 channels.

The 5GHz connection is stable now, no obvious problem.

My usage of the device is low, longest 2 hours in a time. Only take it out for some test. I remember a reboot (crash) of 1 or 2 times, I though it was my unit's problem.


#20

New build is finally up!
No more random reboots or stack traces in the logs. It has been running for 3 days rock solid. Compiled with compiler flags which should eek out a bit more performance. Let me know what you guys think/experience!