[OpenWrt-Devel] Why OpenWrt sucks?

Adam Kuklycz adamk at mcservices.com.au
Wed Mar 11 17:39:12 EDT 2015


I think what everyone needs to just think and remember for a minute:

*  OpenWRT is built by the community and not by highly paid engineers
*  OpenWRT is often far more feature rich than stock firmwares written for
the devices supported
*  OpenWRT is even used sometimes by hardware vendors as a baseline for
their own firmwares

I think that suggesting OpenWRT is done by guesswork and not done by people
who know their code is just counter productive and if we're to criticize the
hard work of the OpenWRT team then we should at least be upbuilding in what
we say rather than just saying OpenWRT performance sucks balls.

-----Original Message-----
From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On
Behalf Of Zefir Kurtisi
Sent: Wednesday, 11 March 2015 11:13 PM
To: Felix Fietkau; David Lang; José Vázquez
Cc: OpenWrt Development List
Subject: Re: [OpenWrt-Devel] Why OpenWrt sucks?

On 03/10/2015 10:39 PM, Felix Fietkau wrote:
> On 2015-03-10 20:22, Zefir Kurtisi wrote:
> 
>> This gives at least two sources for optimization for the reference 
>> driver: 1) save inter-layer processing overhead (passing commands 
>> from hostapd directly to HW is cheaper than passing it through 4 
>> layers), and 2) vastly reduce locking when you are in full control of
concurrency.
> The overhead of commands issued by hostapd is pretty much irrelevant.
> All that matters for driver performance is the actual data path 
> (network stack, mac80211 tx/rx, driver tx/rx).
> Also, I've not seen any indication in my tests that locking is a 
> measurable cause of performance issues.
> When it comes to performance issues, guesswork is meaningless, 
> measurements (e.g. profiling results) matter!
> 
> - Felix
> 
Hm, maybe my memory is deceiving me, but I'm pretty sure my statement is not
based on guesswork but in fact on measurements.

Like 3 years ago, for a PPC based platform we had to decide whether to go
with the reference driver or with aht9k. For that, thorough performance
measurements were performed and ath9k was somewhere between 10 and 30%
behind throughput wise.
Guessing that synchronization might be one factor, we removed locking in
ath9k and results improved noticeably by up to 5%. At that time and on a PPC
platform it was a factor, it might be irrelevant today. I remember it well
since it indicated that ath9k has some optimization potential left and we
finally decided for it.

Anyway, that was not my point here. What I claim is that a proprietary
driver always opens more optimization potential (cross-layer wise).


Cheers,
Zefir
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list