Looks like you are right. So I should focus my tests on the 2.4Ghz part.
Didn't look as much into it as you did. Bummer!
Anyways, for the people wanting to test the build, you can find it in the OP.
@Bartvz Interesting post by @Borromini here: [Solved] WRT1900ACV1 reboots: kernel 4.9
Might be worth a try for these builds as well 
Edit: Disregard this post. This build already is compiled with GCC 6.3. Then maybe it is one of the commits? More testing is needed. Hopefully @Borromini can clarify whether cake was enabled.
@Mushoz I am using Cake (I wouldn't have mentioned it otherwise, although I don't know if using an alternative is stable on mt7621).
My SQM settings:
# uci show sqm
sqm.eth1=queue
sqm.eth1.qdisc_advanced='0'
sqm.eth1.debug_logging='0'
sqm.eth1.verbosity='5'
sqm.eth1.qdisc='cake'
sqm.eth1.script='piece_of_cake.qos'
sqm.eth1.linklayer='ethernet'
sqm.eth1.overhead='8'
sqm.eth1.interface='pppoe-wan'
sqm.eth1.upload='9000'
sqm.eth1.enabled='1'
sqm.eth1.download='53500'
According to logread, it is enabled as well. The state file in /var/run/sqm/ has an empty ENABLED="" variable, doesn't help much 
I have pulled in an Ubuntu ISO (1+ GB) with another torrent running to max out my connection, that went just fine.
1 Like
That sounds promising. I currently do not have the time to test, but I will get back to you once I do. The empty ENABLED variable is weird, though. Did you verify that your bufferbloat is actually eliminated with SQM enabled?
I did have a quick look at the changelog for the 17.01 and there is nothing really interesting in there with respect to the SQM issue. Maybe it's the kernel update that did the trick?
I think this is conclusive evidence:
# tc qdisc|grep pppoe-wan
qdisc cake 8013: dev pppoe-wan root refcnt 2 bandwidth 9Mbit besteffort triple-isolate rtt 100.0ms raw
qdisc ingress ffff: dev pppoe-wan parent ffff:fff1 ----------------
qdisc cake 8014: dev ifb4pppoe-wan root refcnt 2 bandwidth 53500Kbit besteffort triple-isolate wash rtt 100.0ms raw
I set and tested the SQM settings before I became aware of the instability on mt7621. So they have been unaltered since (except for offload being disabled wherever possible, but I assume you have already done the same).
SQM is relatively stable for me as well with offloading disabled at lower speeds. It is when I am shaping 300+ mbit the issues start cropping up. With offloading enabled, I run into stability issues much sooner. Am I correct to assume you are running a 60/10 mbit connection?
Yeah, more or less that. So no way I can test up to 300 Mbps unfortunately. However, the random reboots I experienced don't seem to be related to SQM load. This morning, I pulled in 10 GB through a torrent and no hitch whatsoever.
@Borromini Is it possible to post a sysupgrade file with your build so I can test on dir860l? I'm on a 118/12 connection so I too am interested in trying to see if mt7621 cake is working now.
@rajsris My own images here are sysprepped (10.0.0.x subnet, Unbound instead of dnsmasq, and some other tidbits that are set if the 'correct' settings aren't detected). I am ashamed to admit, but they might break your setup - if I sysupgrade from stock LEDE to my own builds, before configuring some stuff manually, that first sysupgrade will kind of kill LEDE 
. I haven't found out what's causing it yet.
I'll see if I can whip up an image with all the sysprep stuff removed.
Edit: you can grab the image here. Config.seed is there as well, so you can grab that and build your own images if you want.
Ok, I decided to re-evaluate the latest trunk snapshot, which is running kernel 4.4.70 for DIR860L. This seems to give good results: so far with 2 speed tests, I have SQM Piece of Cake running and no router crashes. I've set SQM to 115 DL, 11.5 upload, and measuring 100/9, which is the best I get usually.
Gonna run some torrents over the next couple of days to evaluate crashes, but looks promising! Something in kernel 4.4.70 fixed our issues with mt7621?
5 days, 12 hours and counting. Might very well be something slipped into .70 that solved it. Only time will tell.
The image I built is from the 17.01 branch btw.
I did get my first crash. I was torrenting some files and went in to adjust a few SQM settings in Luci at the same time. Router stopped responding and required a power cycle to get it back. Everything was still there afterwards though.
Hi Borromini!
I came home after being away for almost 3 weeks, just to find that my
DIR-860L showed an uptime of 18 hours.. so it ran almost three weeks (with no load) and
then rebooted...
I have now pulled fresh sources from master branch and compiled
using your config.seed with gcc 6.3 ...
Lets see how long it works now 
Stormy667
Unless you have some logs that back it up, don't assume it just rebooted once. I have made that mistake as well before. All uptime shows is the time since the last boot...
I've seen mine go belly up with no load at all as well. Felt very random.
Edit: I don't need the 2,4 GHz radio so I disabled it right from the start.
@All, my latest builds have been failing (as in rebooting) as well.
Later in the week I will setup a syslog server so I can catch what is causing the reboots.
My gut says it is going to be the same as the one @Mushoz posted here. If you haven't done so, please vote for it on the bugtracker.
I cannot disable 2.4 GHz because of a two "essential" devices not supporting 5 GHz but does any of you guys test with 2.4 GHz disabled?
Edit: I also get the LuCI not responding bug mentioned earlier with the build I compiled yesterday.
I can try. Slightly different device WE1326, but MT7621 with MT7612 for 5ghz. Mine has the 7603 for 2.4 and also buggy under higher load.
Line speed is officially 200/20; Speedtest.net shows mostly 245/22.
So compile an image with only the MT76 meta + 76x2e SQM with cake? And wait till it crashes 
Still, it uses the same hardware
If you'd want to try it, that would be awesome!
To better standardize the builds we are testing, if you compile your build, please use my config.seed
Hi all,
My DIR-860L with the r4245 build of the first post and a WiFi 2.4 ghz has 8 days uptime and it is still running (54 Mbps since the wireless card of my laptop doesn't support the N standard - no SQM).
About the Wireless 2.4 Ghz bug:
My 2.4 Ghz wireless is under constant upload of 2 Megabyte/s because of the P2P program I use 24/7 (aMule).
In my case the 2.4 Ghz wireless is very stable so perhaps the bug is linked to the wireless "N" standard, to some incompatibles wireless cards or to wi-fi speeds >54 Mbps.
About the SQM bug:
I've voted for it on bugtracker.
Honestly I've bought this router in order to use his great dual-core processor for SQM...I've checked that DIR-860L B was compatible with LEDE before to buy it and after that I discovered that it has big bugs and it is not fully usable with LEDE.
Really hope that the developers will fix this bug soon.
I will retry with your config.seed ( I already build my own version ). That I could crash within a few minutes. Attach an iPad so I can monitor top. Run a Speedtest (the desktop app) on a Windows Laptop and it crashes within a few seconds! Its the script that crashed, not the wifi driver. The log is the same as posted above.
I can try later with your config, but I dont think it will make a difference.