[Cerowrt-devel] AQL in openwrt head, but not 19 stable

[Cerowrt-devel] AQL in openwrt head, but not 19 stable

[Dave Taht]

being that I have got absolutely miserable performance out of the
ath10k based ubnt mesh lite and pro at the moment,
I guess I'm going to bite the bullet and try head.

Not clear what the right things were to get the ath10k up to speed.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f0aff72c2bfae884b5482a288a191cc33a37f66b


-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

Re: [Cerowrt-devel] AQL in openwrt head, but not 19 stable

[David P. Reed]

Pragmatically, I solve this by a mixed, manual strategy. My entry router at home isn't OpenWRT based, it only connects a WAN GigE port to a home LAN GigE port. I use multiple APs, and for now solve the "make wifi fast" problem by using one 5 GHz channel per AP, and enough APs so I can have only one laptop or phone per AP/channel.
And the bulk of my heavy dutu use is wired to a 10 GigE backbone in the house. That way, most of my file transfers only interfere with the same endpoints interactions.

I'd really like to not have to do this, but to be honest, maintaining OpenWRT, and dealing with the super-proprietary garbage in WiFi chipsets is just a waste of my time, which is spent on other efforts - I can buy my way out by treating APs as disposable, suboptimal crap.

I'd really like to see someone fund you guys and to actually learn what you know.

The atheros, broadcom, and other chip providers are the obvious source of support, but for some reason they don't want to compete on getting rid of bloat in the airwaves.

Maybe some Chinese company is motivated to beat Qualcomm and Broadcom by going open in their packet handling driver code and letting you guys make it work?

ESP32 devices show that you don't have to be Broadcom or Qualcomm/Atheros to do WiFi chips. They aren't that open, but they don't seem to be focused on locking out innovators from the parket. Maybe Huawei is motivated, since Qualcomm is the big company behind Trump's trade war against them.

On Sunday, March 29, 2020 2:44pm, "Dave Taht" <dave.taht@gmail.com> said:

> being that I have got absolutely miserable performance out of the
> ath10k based ubnt mesh lite and pro at the moment,
> I guess I'm going to bite the bullet and try head.
> 
> Not clear what the right things were to get the ath10k up to speed.
> 
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f0aff72c2bfae884b5482a288a191cc33a37f66b
> 
> 
> --
> Make Music, Not War
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 

Re: [Cerowrt-devel] AQL in openwrt head, but not 19 stable

[Toke Høiland-Jørgensen]

"David P. Reed" <dpreed@deepplum.com> writes:

> Pragmatically, I solve this by a mixed, manual strategy. My entry
> router at home isn't OpenWRT based, it only connects a WAN GigE port
> to a home LAN GigE port. I use multiple APs, and for now solve the
> "make wifi fast" problem by using one 5 GHz channel per AP, and enough
> APs so I can have only one laptop or phone per AP/channel. And the
> bulk of my heavy dutu use is wired to a 10 GigE backbone in the house.
> That way, most of my file transfers only interfere with the same
> endpoints interactions.
>
> I'd really like to not have to do this, but to be honest, maintaining
> OpenWRT, and dealing with the super-proprietary garbage in WiFi
> chipsets is just a waste of my time, which is spent on other efforts -
> I can buy my way out by treating APs as disposable, suboptimal crap.
>
> I'd really like to see someone fund you guys and to actually learn what you know.
>
> The atheros, broadcom, and other chip providers are the obvious source
> of support, but for some reason they don't want to compete on getting
> rid of bloat in the airwaves.
>
> Maybe some Chinese company is motivated to beat Qualcomm and Broadcom
> by going open in their packet handling driver code and letting you
> guys make it work?

That would be MediaTek (Taiwanese, though). They got Felix to write the
upstream driver (mt76), and I'm sure it'll surprise no one that it's
quite good. Haven't had a chance to actually install any of the hardware
yet, although I do have a few cards lying on my desk, biding their time.

-Toke