I'll grant you that I got disillusioned by ARM after getting a C2600, and don't have any ipq401* device. They were supposed to deliver gigabit routing, and it turned out really fast that not only they can't do that without special accelerator cores, they're actually slower than the qca mips cores they were replacing.
I already voiced my opinions about ath10k-ct some time ago : it's noble, but it's only one person who's trying to fixup what mess qualcomm did with ath10k. Look at the github bugtracker. I'm glad it works for you, but it's not something I'd feel comfortable deploying in a production setting, especially since a couple of those are mine, and the response is "tough shit, I don't have a qca9980, it's abandoned by qca anyway". Which again, I hold no grudge over, but it's a far cry from the support that ath9k got by virtue of being completely opensource
Yes, Ive seen the threads.
I have openwrt on this router for about a year and a half, never had any problem with it crashing.
I have about 10 devices, most of them 11n and about 3 AC, one is my desktop with 200Mbps broadband, maybe its not enough to cause any problems.
There are different opinons about what best supported means, but mvebu based plattforms (like wrt1900, 3200, ad turrus omnia) and ipq806x (like r7800) seem to work well for quite a number of users.
Sure there are a few issues about configuration and dual-coreness in the light of frequency scaling and power saving that need attention by the user, but over-all these are supported decently.
If upstream openwrt is not a hard requirement, I would say that the turris omnia with its turris os version of openwrt (pretty close to upstream from TOS4 onwards) is quite nice as it has an active developer (that sells the units) that offers automatic updates and over all manages to do a decent job.
@moeller0 yes the marvell chips seem interesting, but not a huge upgrade over mt7621 (zbt-we1326) for my purposes. I think MT7621 has been excellent for all intents and purposes.
Currently I have no CPU bottleneck, but I do not use SQM as I do not seem to need it. So I can't tell what would happen if I used it. Perhaps I would have CPU bottleneck
About Turris, I would rather not divide community by supporting another OS which is a fork of OpenWRT. Reminds me of LEDE The guys who did Turris OS seemed to want to give freedom to users. So they could as well support OpenWRT directly and use OpenWRT on their devices. It is just wrong that they fork it and then make it incompatible. I do not want to end up with 100s of device OSes to choose from.
Well, then just keep using it, the status of best supported anything is prone to change over time, and in say 2 years who knows which arm soc is considered the best match for openwrt...
It is not really a fork, after their initial approach with a soft fork they switched to something were they try to implement TOS as openwrt plus some additional packets, but sure the turris project is not for evertbody, although they are IMHO good neticens and try to upstream relevant changes to all their upstream projects including openwrt. I am not sure whether your assemessment of the turris project might not reflect the past more than the presence...
@moeller0 You may be right for now, and I may be having some paranoid conspiracy theories But they should NOT have forked it to begin with. Do you know about EEE? It is just for show that they look like they upstream the fixes, they will eventually become incompatible enough to stop it.
Simple logic dictates that if they were to upstream all the fixes, they would not need to fork to begin with. They want to become independent and incompatible. Otherwise, they could build TOS as packages over OpenWRT same as how LUCI works right now. Just make your own user interface if you do not like the existing one or you want to customize it.
Would you prefer if many OpenWRT users moved to TOS and OpenWRT becomes a dead project? It is nice to have options, but sort of kills the usability of the software. You end up with 10 different OSes with different bugs and user bases. Just messy!
Why? From the beginning they wanted to do a few things differently, so it was clear that pure OpenWrt was not the right solution. They explored and started to diverge into basically a soft fork more out of necessity IIRC than by desire. When they considered how to update close to current OpenWrt they realized that closer tracking of OpenWrt would require changes in how TOS is cut and distributed and then went and implement those changes. From my end-user perspective, I would say the turris team has been pretty good and they improved over time.
I actually believe this to be not correct, they went the route of a soft fork first and after realizing the down-sides of doing so they worked hard to get close to mainline OpenWrt. Sure it is not guaranteed that they will stay there forever, but their intentions and current execution are quite decent.
And simple logic ignores, that upstream often does not want to take a patch/fix/feature in time for a release or not at all, for a number of good reasons, but if that patch/fix/feature is necessary for a derived distribution like Turris os, than what options are there realistically?
You pretty much decsribe how TOS >= 4 works. How about you have a closer look at how the turris team handles things today, before we continue this discussion?
I consider this to be very unlikely, TOS exists only to expose all the features and promises of the Turris project on turris project hardware, I neither expect all users to switch to turris hardware, nor that the turris project will lead to anemia of the OpenWrt project.
Again, please have a look at the current reality first, before committing to an opinion. I am not saying your opinion will change, but the facts have changed enough that a reconsideration might be in order.