Let's talk ath10k CT firmware

For Developers
1

Devices I use:

  • Netgear R7800 (QCA9984)
  • UniFi AP AC Lite, TP-Link Archer C7 v4 (QCA988X)

I consistently notice stability issues and reduced performance with CT driver + firmware on all the devices above. For example, the real throughput as measured by an iperf3 TCP test on my R7800 is 3x worse than mainline (sometimes called "old").

The CT driver doesn't seem to make a difference, with or without it, the perf is the same. It's all about the firmware.

I realize this may be specific to the environment, but for me I have consistent problems with CT firmware with a Nest E thermostat and MacBook Pro laptops. Things such as packet loss, low throughput, devices that go into low power mode and stop responding completely, etc. Switch to mainline firmware and the issues are gone, so my conclusion is clear, it's a CT firmware issue. I reported them in the repo but there are no fixes, some issues have been there for 2+ years.

My question is why did OpenWRT decide to default to CT? What do we really get out of it and is it a disservice to the community? There are many threads where users complain about similar issues.

1 Like
2

The r7800 is fortunate to have a viable alternative to the ct firmware - at least for now. For other devices, namely my r7500v2, the ct driver and firmware are really the only option being updated.

I'm not saying ct is perfect, I've noticed issues that might turn out to be ct/firmware related, but I'm pretty sure if i get a clue as to the root cause I at least have a chance of having the dev fix it or suggest a work around.

Device specific issues are tough. Unless the dev can reproduce it (i.e. have the problematic devices to test with), it will be difficult to identify and fix the problem.

Hope you find a fix.

3

Have you tried older versions of CT firmware?
If older versions do not have stability and performance problems, then perhaps you can try bisecting to see which CT version is the first bad version, and report it to greearb.

4

I tried bisecting many times, unfortunately we never got to any fixes. You will see the same story in the issues in the repo, people try to help and after a while they just give up and move on, issues just stay open or are closed but the problems are not really fixed, e.g. https://github.com/greearb/ath10k-ct/issues/114#issuecomment-586746463

I fully recognize that it's very difficult for a single firmware developer to address these issues, they need access to hardware to test with. WiFi is not easy and can become an expensive hobby.

I believe OpenWRT should try and stay with firmware versions that are perhaps used in enterprise APs, e.g. Cisco/Meraki, UniFi, Netgear, etc. Those companies have the resources to test and see real life experience across a variety of devices and have the power to push Qualcomm to fix issues.

We may not know the changelog, but mainline still puts out new firmware, e.g.
https://github.com/kvalo/ath10k-firmware/commits/master/QCA9984/hw1.0

4 Likes
5

I’m a long time OpenWRT user, enthusiast. I’ve got a R7800 since a few years and my networked devices have been the same for a few years. I also experience a worse user experience in stability and performance when using a stable 19.07.5, master build from March 28 recently or a stable 19.07.7 release. In the latter two I’ve replaced the -ct driver and firmware with what is known as the mainline ath10k driver and firmware. When doing that, stability and performance increased to the levels of user experience I’m used to ever since I flashed my first OpenWRT release years ago.

I understand the decision from devs to switch from mainline ath10k to ath10k-ct as default. But from what I see, after searching for similar experience I’d like to advocate for an open and fair discussion together.

From a developer point of view I understand the motivation to switch to -ct because at least both driver and firmware go from 0 active developers to 1 active developer, with a changelog so it is public what has been changed. I totally agree and support that. Now comes the “but”:

But as we can see from that one active -ct developer’s GitHub repo, there is not much activity during the year. Issues are created but take a long time to bisect. Like @wired mentioned, reporters are simply giving up because one developer can only do so much, just like the reporter. In some cases there is a knowledge gap between reporter and developer so they can only get to a point as to agree there’s an issue, but are unable (but not unwilling) to help eachother.

In fact, in retrospect, one could suggest that instead of having one active developer occasionally solving old “mainline” issues might not weigh up to the active development causing regression and introducing new functionality that statistically will introduce new bugs as well, causing a degraded experience on stability and performance.

However, as we can also see on the other GitHub repo, the mainline ath10k firmware is still actively developed. And true; there is no changelog so no public knowledge of what’s changed. I can imagine that is hard to work with as a developer. But it also seems to me that there’s a lot of happy OpenWRT folks out there experiencing a setback on performance and stability when the switch to -ct drivers and firmware was made, causing them to either undo that manually to “old mainline” ath10k driver and firmware if they manage to do that themselves, or give up on OpenWRT (whilst this is often the basis on which other firmware’s are built upon).

Please bear with me, open and fair. No bad intent, just the intention to explore and do good :innocent:

1 Like