Please consider ath10k (non-ct) drivers instead of ct

The speed issues could be reproduced with Intel 8260 based wifi adapters on 2.4ghz. Plus, non-ct drivers support IBSS and wpa3-sae encrypted 802.11s mesh which I could not get running with ct drivers.

1 Like

Exact same reason, why I also use the non-ct drivers on the deployed archer units. Missing support (iwlwifi), or unstable operation (mt7xxx) for encrypted 802.11s mesh and RSN-IBSS on 5Ghz is my greatest annoyance in the Wifi landscape

IMO you should ask this on the OpenWrt devel mailing list, in order to reach the desired audience.

Oh, never was part of a mailing list yet. Can you please give me the pointer where to mail to?

See https://openwrt.org/contact#mailing_lists

1 Like

@tmomas I've followed your advice, thanks.

I use the CT-drivers on my r7800 with mesh/batman-adv. The trick on the R7800, at least on this particular router, is to disable powermanagement on the cpu. Very stable. Without this it’s a crashing mess.

1 Like

The reason for the CT variant of drivers is because this is the open-source version prepared by Candela Technologies

you can read about it here
https://www.candelatech.com/ath10k.php

Despite some issues with specific versions of their drivers, and missing features....there is also a vast amount of bugs fixed that are still in the original non-CT variant, so there is a lot of variables here that can result in bad performance.

It seems to me that this is device / chip specific issues, so I think a good solution would be to only use non-ct drivers for some devices and only on the stable release branch...

or maybe consider two sets of image for some boards...

3 Likes

"powermanagement on the cpu."? or you mean power saving of the Wi-Fi chip? If its former, I wonder if C7 v5 also has that option to disable.

1 Like

no the r7800 has a completely different SOC (IPQ806x)

sounds like in that case that the wifi driver is not the cause of the problem

1 Like

I screwed up my device last night by updating some packages, good thing I had backup though. Installed latest snapshot and this time I decided to use non-ct driver/fw.

I must say it feels like same before, rock solid good. Maybe ct/non-ct is more like feature-wise problematic for some users.

1 Like

On my device I installed the non-ct drivers. When my kids started their online meetings, the ap got reset/restarted, no crash in the log. Just activated WPA2 with Dawn and fast roaming. This happened twice within 2 min. I did one more test, starting a download and it reseted again. So I got rid of the non-ct drivers and since I have the ct drivers, all is good.

Also consider that there is many improvements to CT variant drivers in master since last release, and that the next release will probably resolve these issues even with CT drivers

(next release means 21.xx.xx since it is 2021 already)

If anyone here is comfortable with TFTP recovery, feel free to try a snapshot build
(not likely that you would need to recover, but you never know)

example

1 Like

I've been running snapshot images for a while now on Netgear R7800, UniFi AP AC Lite and Archer C7 v4. In my environment I have stability issues with a Nest E thermostat and 2018/2019 MacBook Pro laptops with CT firmware. If I switch the firmware to mainline, the issues are gone. Throughput is also terrible with CT. The driver doesn't make a difference, CT or mainline they both work, it's all about the firmware.
I reported many of these issues long time ago and there are no fixes. Here are my latest perf numbers from yesterday, I do try CT once in a while hoping for magic fixes but so far they haven't appeared.
https://github.com/greearb/ath10k-ct/issues/138#issuecomment-778880989

I started a thread too before I found this one. I struggle to understand the decision to default to CT when there are many threads with similar issues reported.

4 Likes

the reason of the ct switch is that while on mainline firmware we never know the changes... ct produce a changelog of the changes and actually the reported bugs can be fixed since ct have source code and can produce their firmware.
So if many people report the problem in a good way (not the chip works good on the oem and works bad on openwrt) the problem can actually be fixed and a beta firmware can be produced asap. It's the interest of ct company since it does sell that chip and these problem are also present on their chips.

1 Like

That all sounds good in theory. Over the past 2 years I tried to help, I reported issues, I bisected firmware many times and we never got anywhere towards any actual fixes. I'm not alone, you can see past issues in the repo where others like me go through the same thing and eventually give up and move on.
This is very likely environment related, the type of clients being used (though the problems I experience are with common hardware not obscure no-name devices), but the reality is that I would rather use firmware with no changelog that works over firmware that comes with a changelog but does not work well.

5 Likes

probably they need help with actual development...maybe there is too many problems for Mr. Greear to handle himself...

I agree with you but only for the stable branches, for the end-user's sake

The real goal of Openwrt is to be completely open-source and give 100% control of the hardware to the user, not to increase performance. Often there is performance improvement, due to replacing outdated software with the latest, but other than that, we can only hope for and work towards good performance as an added bonus whenever the open-source code is not performing well.

Absolutely. This doesn't sound like a job for a single person who requires lots of hardware to test on. And Mr. Greear also has a business to run, so ...

IMO the change from non-CT to CT drivers was too early.

5 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.