Andy Green wrote:
> maxperf is one of those names that makes you wonder why it isn't the
> default.
Alas, maximum performance also means maximum power burn:
System battery current (*)
AR6k module disabled: 135.2mA
AR6k with default settings: 139.2mA
wmiconfig --power maxperf: 260.7mA
(*) At 4.0V lab supply. USB current limit set to 100mA.
Oh, and I just noticed that wmiconfig --wlan disable is affected
by --power maxperf. So to properly cool down, we also need to
--power rec.
> | I thought --power was mainly affecting latency, so I didn't expect
>
> It sounds more like it impacts TX RF power level.
That may at least be part of it, yes. But it looks more like a
whole group of things. I hope Atheros can clarify.
> It's like an on / off switch Werner.
>
> Surely it doesn't have that many complicated decisions to ponder and
> discuss :?)
Well, you've seen the discussion on linux-wireless. The issue is
precisely that what we have is not the simple on/off switch rfkill
expects to find but more like a Rube Goldberg apparatus.
> | clear that most issues are connected to the frozen access point list.
> | I can reproduce this problem, even if it sometimes takes a while.
>
> What does pulling and re-inserting the modules do for this issue?
It resets the whole WLAN subsystem, so it clears the stuck list.
So do suspend/resume or unbind/bind. This means that we have a
number of work-arounds if it should turn out that the frozen list
is some firmware feature we can't solve.
However, I'd rather avoid this sort of work-around where you either
need some middleware that's good at guessing when the layers below
are falling apart, or even something that requires user action. The
fewer reset buttons we need, the better ;-)
- Werner
_______________________________________________
devel mailing list
devel@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/devel
