Mailing List Archive: Maemo: Users

Power consumption and WLAN APs

1 2

View All

Index | Next | Previous | View Threaded

advax at triumf

Jul 20, 2008, 1:27 PM

Post #1 of 41 (1794 views)
Permalink

Power consumption and WLAN APs

On Mon, Apr 21, 2008 at 4:58 PM, Eero Tamminen <eero.tamminen[at]nokia.com>
wrote:
> One possibility is a WLAN AP with broken power management

I recently noticed that my tablet battery runs down faster at work than
at home, with the WiFi enabled but otherwise sitting idle (12%/hour vs
1%/hour).

I thought the issue might be that there's more broadcast/multicast
traffic at work, which would get through the filters in the ethernet chip
and into the kernel, but then I found a reference to your post on the
list.

At home I have a Linksys WRT54; at work I think Orinoco-AP2000 where I
may be able to change some settings (writing this at home I can't login
to check).

What power-management issues have you seen affecting battery life ?
Would it affect other laptops as well or just the tablets ?

--
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376 (Pacific Time)
Network Security Manager
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

fred at crozat

Jul 20, 2008, 1:46 PM

Post #2 of 41 (1765 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

On Sun, Jul 20, 2008 at 10:27 PM, Andrew Daviel <advax[at]triumf.ca> wrote:
>
> On Mon, Apr 21, 2008 at 4:58 PM, Eero Tamminen <eero.tamminen[at]nokia.com>
> wrote:
>> One possibility is a WLAN AP with broken power management
>
> I recently noticed that my tablet battery runs down faster at work than
> at home, with the WiFi enabled but otherwise sitting idle (12%/hour vs
> 1%/hour).
>
> I thought the issue might be that there's more broadcast/multicast
> traffic at work, which would get through the filters in the ethernet chip
> and into the kernel, but then I found a reference to your post on the
> list.
>
> At home I have a Linksys WRT54; at work I think Orinoco-AP2000 where I
> may be able to change some settings (writing this at home I can't login
> to check).
>
> What power-management issues have you seen affecting battery life ?

I think it is usually caused by interoperability deficiency between
770/n8x0 and some routers wifi chipset regarding PSM (Power Saving
Management) part of wifi specification.

I'm seeing this kind of issue between my work AP (Linksys) which have
working PSM and my home AP (Freebox, a set-top-box provided by my
ISP), where PSM is not working properly with a maximum uptime of 8h
when wifi is on.

I've been in contact with one of my ISP engineers who is taking care
of writing wifi driver in their set-top-box. From the first
investigation, it seems Conexant chip (used on Nokia tablets) was
known to be problematic (Freebox is using Ralink chipset). A first bug
was found in ralink proprietary driver which was losing AP association
after some time in PSM mode, which was fixed by Ralink.

Unfortunately, this fix was not sufficient to fix the power
consumption issue and we are kind of stuck now :(

If Eero or another Nokia hackers have some information which might
help Freebox engineers to track the issue, I'll be happy to serve as a
proxy.

> Would it affect other laptops as well or just the tablets ?

I guess it will depend on laptop wifi chipset. And compared to Nokia
tablets, entire laptop power consumption is way more important than a
tablet, so if wifi is too important, it is probably hidden by other
component consumption.

--
Frederic Crozat
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 21, 2008, 1:10 AM

Post #3 of 41 (1750 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext Andrew Daviel" <advax[at]triumf.ca> writes:

> On Mon, Apr 21, 2008 at 4:58 PM, Eero Tamminen <eero.tamminen[at]nokia.com>
> wrote:
>> One possibility is a WLAN AP with broken power management
>
> I recently noticed that my tablet battery runs down faster at work than
> at home, with the WiFi enabled but otherwise sitting idle (12%/hour vs
> 1%/hour).

What do you mean by 12%/hour? That the battery will run out in eight
hours?

My rule of thumb is basically this:

o battery lasts 6-8 hours -> PSM not working at all
o battery lasts 6-8 days -> PSM working well

This is on a N810 with clean install (no badly behaving applications
so that CPU can sleep), display turned off and no data traffic in the
network. ping needs to be run occasionally (from network, not from
tablet!) to be sure that the device is really associated to the AP.

> I thought the issue might be that there's more broadcast/multicast
> traffic at work, which would get through the filters in the ethernet chip
> and into the kernel, but then I found a reference to your post on the
> list.

Yes, multicast and broadcast traffic will increase WLAN power
consumption. But there has to be a lot of traffic going on to really
notice it.

If the AP is behaving correctly, the power consumption in PSM on a
idle N800/N810 are mostly affected by these:

o beacon interval (longer has smaller power consumption)
o DTIM interval (same as above)
o broadcast/multicast traffic

If the AP is violating the spec then, well, everything goes.

Disclaimer: written under influence of jet lag at 4am. Reader
discretion is advised.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

advax at triumf

Jul 21, 2008, 2:14 AM

Post #4 of 41 (1748 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

On Mon, 21 Jul 2008, Kalle Valo wrote:

>> I recently noticed that my tablet battery runs down faster at work than
>> at home, with the WiFi enabled but otherwise sitting idle (12%/hour vs
>> 1%/hour).
>
> What do you mean by 12%/hour? That the battery will run out in eight
> hours?

I guess. I was using the "battery-status" application which reports
percentage of battery left, and measuring the slope.

> Yes, multicast and broadcast traffic will increase WLAN power
> consumption. But there has to be a lot of traffic going on to really
> notice it.

I tried doing a broadcast ping every 200ms at home (the tablet sees it if
I run tcpdump) but it had no noticable effect on the battery consumption
graph.

> If the AP is behaving correctly, the power consumption in PSM on a
> idle N800/N810 are mostly affected by these:
>
> o beacon interval (longer has smaller power consumption)
> o DTIM interval (same as above)
> o broadcast/multicast traffic

I'll have a look at the AP config tomorrow and see if I can find
anything.
My linksys at home has beacon interval 100ms, DTIM=1 (i.e. default
values). The Linksys docs
suggest that DTIM data is only sent if there are broadcast packets
waiting, so perhaps setting this larger would have little effect if I
don't have much broadcast traffic. Besides, the problem is at work, not
home.

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 21, 2008, 2:39 AM

Post #5 of 41 (1749 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext Frederic Crozat" <fred[at]crozat.net> writes:

>> What power-management issues have you seen affecting battery life ?
>
> I think it is usually caused by interoperability deficiency between
> 770/n8x0 and some routers wifi chipset regarding PSM (Power Saving
> Management) part of wifi specification.

Exactly. The problems stems from the fact PSM was (and still is?)
mostly unused by the windows laptops. So it seems that some AP
manufactures decided to omit the testing of the PSM implementation
altogether.

Why is PSM so fragile then? Since I can't sleep (jet lag, argh), I'll
write a bit about this.

PSM problems can be categorised into two classes, packet loss and
increased power consumption. But first few definitions:

PSM = Power Save Mode
CAM = Continous Aware Mode, ie. PSM turned off
AP = Access Point
client = a PC or N8x0 connecting to AP
downstream = from AP to client
upstream = from client to AP
frame = packet with WLAN headers sent to the air

If we omit few details, PSM is actually quite simple. Every WLAN frame
has a PSM bit in frame control structure and this bit tells the frame
receiver (AP) the status of transmitter (client). If the bit is set,
the client will go to sleep mode. And naturally if the bit is not set,
the client will stay awake (is in CAM mode). When AP knows that the
client is sleeping it must not send the frames, but buffer them for
later use.

But even though the client is sleeping, it still wakes up for the
beacons transmitted by the AP. The beacon interval is very accurately
defined in the spec, we are talking about microsecond precision here.
So the client can wake up just before the beacon and go back to sleep
right after it has received the beacon. This is how the huge power
consumption saving is possible.

If the AP has buffered frames for the client, it will set the so
called TIM bit for the particular client in the beacon. When a
sleeping client receives the beacon, it will check the TIM bit. If the
bit it is set, the client now knows that AP has buffered frames and
requests the frames from the AP. If there are more buffered frames, AP
will set the MoreData bit in the frame control to notify client. Then
the last buffered frame is being transmitted, AP will clear the
MoreData bit. That way client will know that there aren't anymore
buffered frames. Also after AP has transmitted all frames succesfully
to the client, it will unset the client's TIM bit in beacons.

If AP has buffered broadcast or multicast frames, it will mark a
special broadcast/multicast TIM bit in beacons. This bit tells the
clients that there will be broadcast/multicast frames after this
beacon. When the bit is set, client will not go to sleep immeaditely
after the beacon, but only after it has received all the
broadcast/multicast frames. If there are only few frames, they should
be sent in few milliseconds and the power consumption shouldn't
increase that much.

Ok, that's a short summary how PSM works. I hope it makes it easier to
understand what I'm writing next. As I said, this was very high level
overview of the Power Save Mode. For exact specifications I recommend
to read IEEE 802.11-2007 standard, which is freely available from the
IEEE site.

Now back to the what I really wanted to write about:

Packet loss with PSM happens usually in downstream direction. This is
because most of the time client is sleeping and if the AP transmits
the frames directly without buffering, the client can't receive them.
There is a small window during waking up for beacons when the client
might be able to receive even unbuffered frames and that's why some of
the frames might go through. In this case the packet loss might be
around 90%.

Other way to break PSM is to not set the TIM bit at all, so the client
would have no way to notice that AP has buffered frames. Or, like in
one case, the AP did set the broadcast/multicast TIM bit, but it just
set the bit on the beacon which was sent after multicast traffic. One
would need a time machine to catch that :)

And about the increased power consumption, that's usually related to
incorrect user of either TIM or MoreData bits. I have seen cases where
the TIM bit in beacons is not cleared even though there are no
buffered frames. So the client will request frames after every beacon,
but there won't be any. Also I have seen a similar problem with the
MoreData bit not cleared by the AP.

> I'm seeing this kind of issue between my work AP (Linksys) which have
> working PSM and my home AP (Freebox, a set-top-box provided by my
> ISP), where PSM is not working properly with a maximum uptime of 8h
> when wifi is on.

It sounds like PSM is not working at all with your home AP.

> I've been in contact with one of my ISP engineers who is taking care
> of writing wifi driver in their set-top-box. From the first
> investigation, it seems Conexant chip (used on Nokia tablets) was
> known to be problematic (Freebox is using Ralink chipset).

I doubt that the Conexant chipset itself is the problematic one, most
probably all chipsets using PSM (with PS-Poll frames) would be
problematic. We have tried to solve a lot of the PSM problems with
Conexant, and usually the problems have been in AP. And usually even
in the i-need-a-time-machine category just to be not able to
workaround them.

I'm quite confident that the PSM mode in the Conexant chip is working
fine. Of course there might be bugs lurking somewhere, I don't deny
that. But I want to see concrete proof of that before I'll believe it :)

> A first bug was found in ralink proprietary driver which was losing
> AP association after some time in PSM mode, which was fixed by
> Ralink.

Hmm, I would first suspect that the AP is not really buffering all
frames. I have seen APs which periodically send Null frames to check
that the client is really alive. Maybe the AP vendor forgot to check
if the client is sleeping when they send the Null frame? Wouldn't be
the first.

> Unfortunately, this fix was not sufficient to fix the power
> consumption issue and we are kind of stuck now :(

Too bad :(

> If Eero or another Nokia hackers have some information which might
> help Freebox engineers to track the issue, I'll be happy to serve as a
> proxy.

Dealing with vendors is very slow, it takes hours and hours of work,
consisting mostly writing emails. I simply don't have time for that,
and I rather write code than email.

But what I could do is to analyse the problem myself. It would take
only an hour or two, including writing a small report about the
problem which I can send everyone interested (hopefully this includes
the vendor). So if you would be able to convince the vendor to send
the AP for a loan? If that's not possible, are you coming to Maemo
Summit? If I manage to come and you can take the AP with you, I could
take a look at it onsite.

Please note that I might not be able to join the Summit because of a
reason or another. So don't travel long journeys just because of this
testing session.

This offer is available for others coming to the Summit as well. If
you have badly behaving APs (with PSM or some other problems), take it
with you and I'll take a look.

BTW, is there a bug about this? If not, please file one. I'll forward
it to our IOP testers so that they could try get access to the AP as
well.

>> Would it affect other laptops as well or just the tablets ?
>
> I guess it will depend on laptop wifi chipset. And compared to Nokia
> tablets, entire laptop power consumption is way more important than a
> tablet, so if wifi is too important, it is probably hidden by other
> component consumption.

I'm guessing that none of Windows drivers use PSM. I have seen in few
drivers PSM setting hidden somewhere very deep in the driver settings
maze, but it has been always disabled by default. But I don't use
Windows, so someone more knowledgable can give you an better answer.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 21, 2008, 2:53 AM

Post #6 of 41 (1739 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext Andrew Daviel" <advax[at]triumf.ca> writes:

> On Mon, 21 Jul 2008, Kalle Valo wrote:
>
>>> I recently noticed that my tablet battery runs down faster at work than
>>> at home, with the WiFi enabled but otherwise sitting idle (12%/hour vs
>>> 1%/hour).
>>
>> What do you mean by 12%/hour? That the battery will run out in eight
>> hours?
>
> I guess. I was using the "battery-status" application which reports
> percentage of battery left, and measuring the slope.

Ok, I'm not aware of that application. I hope the percentage is
linear, so that we can trust that.

>> Yes, multicast and broadcast traffic will increase WLAN power
>> consumption. But there has to be a lot of traffic going on to really
>> notice it.
>
> I tried doing a broadcast ping every 200ms at home (the tablet sees it
> if I run tcpdump) but it had no noticable effect on the battery
> consumption graph.

Ok, the result was as expected.

>> If the AP is behaving correctly, the power consumption in PSM on a
>> idle N800/N810 are mostly affected by these:
>>
>> o beacon interval (longer has smaller power consumption)
>> o DTIM interval (same as above)
>> o broadcast/multicast traffic
>
> I'll have a look at the AP config tomorrow and see if I can find
> anything.

I doubt that you will find anything which will fix your problem, I'm
afraid. These are usually software bugs in the AP firmware and which
can be only fixed by a firmware update :/

> My linksys at home has beacon interval 100ms, DTIM=1 (i.e. default
> values). The Linksys docs suggest that DTIM data is only sent if
> there are broadcast packets waiting, so perhaps setting this larger
> would have little effect if I don't have much broadcast traffic.

Actually DTIM makes a difference, because N8x0 will wake up only for
DTIM beacons. Let's take an example: if beacon interval is 100 ms and
DTIM is 10, N8x0 will wake up for beacons every 1000 ms. But if DTIM
would be 3, N8x0 would wake up for beacons every 300 ms.

> Besides, the problem is at work, not home.

That's right. Optimising DTIM might get you, for example, from 5 days
to 6 days of standby time with correctly working APs. But, if at your
work the standby time is 8 hours, optimising DTIM doesn't do any good
because the chip is obviously sleeping very litte, if any.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

jholmblad at acadiasecurenets

Jul 21, 2008, 7:22 AM

Post #7 of 41 (1746 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

Kalle.

thanks for sharing your deep, if sleep deprived, insights re 802.11
power management.

I have read them out of both general interest in the workings of 802.11
but also as a result of the fact that just this weekend I upgraded my
N800 to OS2008 (~20 minutes-yeah) and reinstalled/upgraded/tested most
of my apps (~7 hours-boo).

As you know, the 802.11g standard which uses OFDM modulation supports
backward compatibility with 802.11b which uses DSSS modulation. Does the
PSM method you describe work the same way for 802.11g irrespective of
which modulation method is being used by the radio? I should think so.
However, the reason I ask this question relates to the following
observation:

After the OS upgrade I started getting low battery warnings when my N800
was not connected to AC power for "a while" (less than a few hours). I
do not remember having this problem when my N800 was running OS2007.

Noteworthy here is the fact that both before and after the OS upgrade,
my method of network access for the N800 was the same, that is, 802.11
wireless to a Proxim (formerly Lucent) Orinoco AP-2000. Now this
AP-2000 is a dual radio (802.11a and 802.11g) system with both radios
active at the same time, albeit in their respective frequency bands (5.7
ghz and 2.4 ghz respectively).

Furthermore, I am fairly certain that at least one of the client devices
associated with the 802.11g radio on the AP-2000 is operating in 802.11b
(DSSS) mode (I can, but did not verify this), which, of course, means
that any other 802.11g clients associated with that radio will
"downshift" to 802.11b mode.

One thing that is different is that, prior to the upgrade, my N800 while
at my desk was less than ~1 meter from the AP-2000. Now, because I have
moved my desk to a different location, it is ~5 meters from the AP-2000
and the signal has to penetrate a ceiling/floor to get to the AP. I
will do some more testing today of the N800 while detached from its AC
power source to see how long it can go before the battery runs down.

Best Regards,

John Holmblad

Acadia Secure Networks, LLC

* *

Kalle Valo wrote:
> "ext Frederic Crozat" <fred[at]crozat.net> writes:
>
>
>>> What power-management issues have you seen affecting battery life ?
>>>
>> I think it is usually caused by interoperability deficiency between
>> 770/n8x0 and some routers wifi chipset regarding PSM (Power Saving
>> Management) part of wifi specification.
>>
>
> Exactly. The problems stems from the fact PSM was (and still is?)
> mostly unused by the windows laptops. So it seems that some AP
> manufactures decided to omit the testing of the PSM implementation
> altogether.
>
> Why is PSM so fragile then? Since I can't sleep (jet lag, argh), I'll
> write a bit about this.
>
> PSM problems can be categorised into two classes, packet loss and
> increased power consumption. But first few definitions:
>
> PSM = Power Save Mode
> CAM = Continous Aware Mode, ie. PSM turned off
> AP = Access Point
> client = a PC or N8x0 connecting to AP
> downstream = from AP to client
> upstream = from client to AP
> frame = packet with WLAN headers sent to the air
>
> If we omit few details, PSM is actually quite simple. Every WLAN frame
> has a PSM bit in frame control structure and this bit tells the frame
> receiver (AP) the status of transmitter (client). If the bit is set,
> the client will go to sleep mode. And naturally if the bit is not set,
> the client will stay awake (is in CAM mode). When AP knows that the
> client is sleeping it must not send the frames, but buffer them for
> later use.
>
> But even though the client is sleeping, it still wakes up for the
> beacons transmitted by the AP. The beacon interval is very accurately
> defined in the spec, we are talking about microsecond precision here.
> So the client can wake up just before the beacon and go back to sleep
> right after it has received the beacon. This is how the huge power
> consumption saving is possible.
>
> If the AP has buffered frames for the client, it will set the so
> called TIM bit for the particular client in the beacon. When a
> sleeping client receives the beacon, it will check the TIM bit. If the
> bit it is set, the client now knows that AP has buffered frames and
> requests the frames from the AP. If there are more buffered frames, AP
> will set the MoreData bit in the frame control to notify client. Then
> the last buffered frame is being transmitted, AP will clear the
> MoreData bit. That way client will know that there aren't anymore
> buffered frames. Also after AP has transmitted all frames succesfully
> to the client, it will unset the client's TIM bit in beacons.
>
> If AP has buffered broadcast or multicast frames, it will mark a
> special broadcast/multicast TIM bit in beacons. This bit tells the
> clients that there will be broadcast/multicast frames after this
> beacon. When the bit is set, client will not go to sleep immeaditely
> after the beacon, but only after it has received all the
> broadcast/multicast frames. If there are only few frames, they should
> be sent in few milliseconds and the power consumption shouldn't
> increase that much.
>
> Ok, that's a short summary how PSM works. I hope it makes it easier to
> understand what I'm writing next. As I said, this was very high level
> overview of the Power Save Mode. For exact specifications I recommend
> to read IEEE 802.11-2007 standard, which is freely available from the
> IEEE site.
>
> Now back to the what I really wanted to write about:
>
> Packet loss with PSM happens usually in downstream direction. This is
> because most of the time client is sleeping and if the AP transmits
> the frames directly without buffering, the client can't receive them.
> There is a small window during waking up for beacons when the client
> might be able to receive even unbuffered frames and that's why some of
> the frames might go through. In this case the packet loss might be
> around 90%.
>
> Other way to break PSM is to not set the TIM bit at all, so the client
> would have no way to notice that AP has buffered frames. Or, like in
> one case, the AP did set the broadcast/multicast TIM bit, but it just
> set the bit on the beacon which was sent after multicast traffic. One
> would need a time machine to catch that :)
>
> And about the increased power consumption, that's usually related to
> incorrect user of either TIM or MoreData bits. I have seen cases where
> the TIM bit in beacons is not cleared even though there are no
> buffered frames. So the client will request frames after every beacon,
> but there won't be any. Also I have seen a similar problem with the
> MoreData bit not cleared by the AP.
>
>
>> I'm seeing this kind of issue between my work AP (Linksys) which have
>> working PSM and my home AP (Freebox, a set-top-box provided by my
>> ISP), where PSM is not working properly with a maximum uptime of 8h
>> when wifi is on.
>>
>
> It sounds like PSM is not working at all with your home AP.
>
>
>> I've been in contact with one of my ISP engineers who is taking care
>> of writing wifi driver in their set-top-box. From the first
>> investigation, it seems Conexant chip (used on Nokia tablets) was
>> known to be problematic (Freebox is using Ralink chipset).
>>
>
> I doubt that the Conexant chipset itself is the problematic one, most
> probably all chipsets using PSM (with PS-Poll frames) would be
> problematic. We have tried to solve a lot of the PSM problems with
> Conexant, and usually the problems have been in AP. And usually even
> in the i-need-a-time-machine category just to be not able to
> workaround them.
>
> I'm quite confident that the PSM mode in the Conexant chip is working
> fine. Of course there might be bugs lurking somewhere, I don't deny
> that. But I want to see concrete proof of that before I'll believe it :)
>
>
>> A first bug was found in ralink proprietary driver which was losing
>> AP association after some time in PSM mode, which was fixed by
>> Ralink.
>>
>
> Hmm, I would first suspect that the AP is not really buffering all
> frames. I have seen APs which periodically send Null frames to check
> that the client is really alive. Maybe the AP vendor forgot to check
> if the client is sleeping when they send the Null frame? Wouldn't be
> the first.
>
>
>> Unfortunately, this fix was not sufficient to fix the power
>> consumption issue and we are kind of stuck now :(
>>
>
> Too bad :(
>
>
>> If Eero or another Nokia hackers have some information which might
>> help Freebox engineers to track the issue, I'll be happy to serve as a
>> proxy.
>>
>
> Dealing with vendors is very slow, it takes hours and hours of work,
> consisting mostly writing emails. I simply don't have time for that,
> and I rather write code than email.
>
> But what I could do is to analyse the problem myself. It would take
> only an hour or two, including writing a small report about the
> problem which I can send everyone interested (hopefully this includes
> the vendor). So if you would be able to convince the vendor to send
> the AP for a loan? If that's not possible, are you coming to Maemo
> Summit? If I manage to come and you can take the AP with you, I could
> take a look at it onsite.
>
> Please note that I might not be able to join the Summit because of a
> reason or another. So don't travel long journeys just because of this
> testing session.
>
> This offer is available for others coming to the Summit as well. If
> you have badly behaving APs (with PSM or some other problems), take it
> with you and I'll take a look.
>
> BTW, is there a bug about this? If not, please file one. I'll forward
> it to our IOP testers so that they could try get access to the AP as
> well.
>
>
>>> Would it affect other laptops as well or just the tablets ?
>>>
>> I guess it will depend on laptop wifi chipset. And compared to Nokia
>> tablets, entire laptop power consumption is way more important than a
>> tablet, so if wifi is too important, it is probably hidden by other
>> component consumption.
>>
>
> I'm guessing that none of Windows drivers use PSM. I have seen in few
> drivers PSM setting hidden somewhere very deep in the driver settings
> maze, but it has been always disabled by default. But I don't use
> Windows, so someone more knowledgable can give you an better answer.
>
>

_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

fred at crozat

Jul 21, 2008, 1:08 PM

Post #8 of 41 (1735 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

On Mon, Jul 21, 2008 at 11:39 AM, Kalle Valo <kalle.valo[at]nokia.com> wrote:
> "ext Frederic Crozat" <fred[at]crozat.net> writes:
>
>>> What power-management issues have you seen affecting battery life ?
>>
>> I think it is usually caused by interoperability deficiency between
>> 770/n8x0 and some routers wifi chipset regarding PSM (Power Saving
>> Management) part of wifi specification.
>
> Exactly. The problems stems from the fact PSM was (and still is?)
> mostly unused by the windows laptops. So it seems that some AP
> manufactures decided to omit the testing of the PSM implementation
> altogether.
>
> Why is PSM so fragile then? Since I can't sleep (jet lag, argh), I'll
> write a bit about this.

<snip>

wow, thanks for the detail explanations. I kind of better understand PSM issues.

>> I'm seeing this kind of issue between my work AP (Linksys) which have
>> working PSM and my home AP (Freebox, a set-top-box provided by my
>> ISP), where PSM is not working properly with a maximum uptime of 8h
>> when wifi is on.
>
> It sounds like PSM is not working at all with your home AP.

Yeah, I figured that ;)

However, Freebox engineer told me he could see PSM going up and down
on the AP side.

>> A first bug was found in ralink proprietary driver which was losing
>> AP association after some time in PSM mode, which was fixed by
>> Ralink.
>
> Hmm, I would first suspect that the AP is not really buffering all
> frames. I have seen APs which periodically send Null frames to check
> that the client is really alive. Maybe the AP vendor forgot to check
> if the client is sleeping when they send the Null frame? Wouldn't be
> the first.

I've forwarded your email to Freebox engineer ;)

>> If Eero or another Nokia hackers have some information which might
>> help Freebox engineers to track the issue, I'll be happy to serve as a
>> proxy.
>
> Dealing with vendors is very slow, it takes hours and hours of work,
> consisting mostly writing emails. I simply don't have time for that,
> and I rather write code than email.
>
> But what I could do is to analyse the problem myself. It would take
> only an hour or two, including writing a small report about the
> problem which I can send everyone interested (hopefully this includes
> the vendor). So if you would be able to convince the vendor to send
> the AP for a loan? If that's not possible, are you coming to Maemo
> Summit? If I manage to come and you can take the AP with you, I could
> take a look at it onsite.

Unfortunately, it won't be possible because Freebox (the name of
set-top-box = ADSL modem + wifi mimo router + many other nice things)
can only work when they are synchronized over ADSL with Free ISP
DSLAM. So, even if we could send you a Freebox, you couldn't do
anything with it :(

Anyway, I've pinged Freebox engineer in hope they might have a clue on
the issue.

> BTW, is there a bug about this? If not, please file one. I'll forward
> it to our IOP testers so that they could try get access to the AP as
> well.

Done : https://bugs.maemo.org/show_bug.cgi?id=3481

--
Frederic Crozat
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

advax at triumf

Jul 21, 2008, 5:53 PM

Post #9 of 41 (1737 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

Excellent writeup, thanks :-)

So, what devices apart from the Nokia tablets use PSM ?

iPhone ? Palm ? Windows Mobile devices like the UTstarcom PocketPC ?

I opened a ticket with Proxim; not sure if our contract includes support
but maybe I'll get a reply.

Is there anything for the tablets that can log wireless traffic in enough
detail to show whether PSM is working ? airodump-ng ??

How about on laptops ? Airmagnet drivers perhaps (which we don't have) -
I have an ancient Orinoco Gold card on a Dell Latitude, and a slightly
less old Thinkpad with (I think) madwifi driver, and a new Lenovo on the
way (Windows, though)

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

advax at triumf

Jul 22, 2008, 1:45 PM

Post #10 of 41 (1703 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

On Mon, 21 Jul 2008, Andrew Daviel wrote:

> Is there anything for the tablets that can log wireless traffic in enough
> detail to show whether PSM is working ? airodump-ng ??

Should have tried before posting. I have a couple of capture files made
with airodump-ng --beacons, which I can view in wireshark.

Lots of detail I don't understand. I can see the beacon interval on the
Proxim APs is 100ms (same as the Linksys default), and see the DTIM info
(whether data is being held).

IEEE 802.11 Beacon frame, Flags: ........
Type/Subtype: Beacon frame (0x08)
Frame Control: 0x0080 (Normal)
Flags: 0x0
...0 .... = PWR MGT: STA will stay up
IEEE 802.11 wireless LAN management frame
Fixed parameters (12 bytes)
Beacon Interval: 0.102400 [Seconds]
Capability Information: 0x0421
.... .... .... ...1 = ESS capabilities: Transmitter is an AP
.... 0... .... .... = Automatic Power Save Delivery: apsd not implemented

home and work have the same flags, except at home
short preample is allowed. I.e. PWR MGT is 0 at home, too.

We have multiple APs at work; I assume that in normal operation the
tablet is registered with only one and will ignore beacons from
the others.

All the packets from home, and most from work, show as "malformed packet"
for some reason. airodump didn't offer a capture length and the packets
are fairly small (85 bytes) so I don't think truncated

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

advax at triumf

Jul 23, 2008, 1:40 AM

Post #11 of 41 (1694 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

I opened a ticket with Proxim. They suggest turning off SSID broadcast
and see if that reduces the battery use. Sounds like b/s to me, but I may
be wrong. If I try that at home, I have to mark the connection as
"hidden" otherwise I can't select it to connect to, and I suspect it
would annoy people at work. I still get beacons every 100ms.

I can't set the wireless chip in my IBM laptop to monitor mode
(atheros/madwifi driver) but I can on an old Orinoco Gold card. That only
does 802.11b. airodump-ng captures some beacons and broadcast packets,
but not as many as airodump-ng on the N810, and just wireless headers,
not data packets. So I'm definitely missing lots of packets, though I
did see one frame from the N810 with the PSM bit set, talking to my old
SMC AP on 802.11b.

The Linksys lets me change the beacon interval and DTIM multiplier. The
Proxim lets me change DTIM, but not beacon interval. The SMC does
neither.

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 23, 2008, 12:34 PM

Post #12 of 41 (1674 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext John Holmblad" <jholmblad[at]acadiasecurenets.com> writes:

> Kalle.

Hi John,

> thanks for sharing your deep, if sleep deprived, insights re 802.11
> power management.

I'm glad that it was helpful.

> I have read them out of both general interest in the workings of
> 802.11 but also as a result of the fact that just this weekend I
> upgraded my N800 to OS2008 (~20 minutes-yeah) and
> reinstalled/upgraded/tested most of my apps (~7 hours-boo).
>
> As you know, the 802.11g standard which uses OFDM modulation supports
> backward compatibility with 802.11b which uses DSSS modulation. Does
> the PSM method you describe work the same way for 802.11g irrespective
> of which modulation method is being used by the radio? I should think
> so.

Yes, PSM does not depend on the modulation (DSSS, OFDM) or the band
(2.4 or 5 GHz).

> However, the reason I ask this question relates to the following
> observation:
>
> After the OS upgrade I started getting low battery warnings when my
> N800 was not connected to AC power for "a while" (less than a few
> hours). I do not remember having this problem when my N800 was
> running OS2007.

I would first recommend to see if you have badly behaving application
which is waking up CPU too often. Other option is to disable WLAN
altogether using Offline mode and try to test if it's really WLAN
related.

> Noteworthy here is the fact that both before and after the OS upgrade,
> my method of network access for the N800 was the same, that is, 802.11
> wireless to a Proxim (formerly Lucent) Orinoco AP-2000. Now this
> AP-2000 is a dual radio (802.11a and 802.11g) system with both radios
> active at the same time, albeit in their respective frequency bands
> (5.7 ghz and 2.4 ghz respectively).

Like I said, the band and modulation shouldn't affect here in any way.

> Furthermore, I am fairly certain that at least one of the client
> devices associated with the 802.11g radio on the AP-2000 is operating
> in 802.11b (DSSS) mode (I can, but did not verify this), which, of
> course, means that any other 802.11g clients associated with that
> radio will "downshift" to 802.11b mode.
>
> One thing that is different is that, prior to the upgrade, my N800
> while at my desk was less than ~1 meter from the AP-2000. Now, because
> I have moved my desk to a different location, it is ~5 meters from
> the AP-2000 and the signal has to penetrate a ceiling/floor to get to
> the AP. I will do some more testing today of the N800 while detached
> from its AC power source to see how long it can go before the battery
> runs down.

There's also the background scan which is enabled if the RSSI value
goes below a certain threshold. But the threshold is nowadays quite
low and it doesn't increase power consumption that much, even with
background scanning enabled you should still get days of standby time.

I bet my money on a badly behaving application. But as usually with
gambling, I'm just guessing here.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 23, 2008, 12:43 PM

Post #13 of 41 (1680 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext Frederic Crozat" <fred[at]crozat.net> writes:

>> Why is PSM so fragile then? Since I can't sleep (jet lag, argh), I'll
>> write a bit about this.
>
> <snip>
>
> wow, thanks for the detail explanations. I kind of better understand
> PSM issues.

Excellent.

>>> A first bug was found in ralink proprietary driver which was losing
>>> AP association after some time in PSM mode, which was fixed by
>>> Ralink.
>>
>> Hmm, I would first suspect that the AP is not really buffering all
>> frames. I have seen APs which periodically send Null frames to check
>> that the client is really alive. Maybe the AP vendor forgot to check
>> if the client is sleeping when they send the Null frame? Wouldn't be
>> the first.
>
> I've forwarded your email to Freebox engineer ;)

Thanks.

>> But what I could do is to analyse the problem myself. It would take
>> only an hour or two, including writing a small report about the
>> problem which I can send everyone interested (hopefully this includes
>> the vendor). So if you would be able to convince the vendor to send
>> the AP for a loan? If that's not possible, are you coming to Maemo
>> Summit? If I manage to come and you can take the AP with you, I could
>> take a look at it onsite.
>
> Unfortunately, it won't be possible because Freebox (the name of
> set-top-box = ADSL modem + wifi mimo router + many other nice things)
> can only work when they are synchronized over ADSL with Free ISP
> DSLAM. So, even if we could send you a Freebox, you couldn't do
> anything with it :(

This is getting difficult. So if your ADSL line is dead for a day your
WLAN AP will not work, did I understand this right? If yes, that sucks
big time.

> Anyway, I've pinged Freebox engineer in hope they might have a clue on
> the issue.

That's your only chance, unfortunately. I would assume now that WLAN
is getting more popular in mobile phones they would get more pressure
to fix this. Let's hope for the best.

>> BTW, is there a bug about this? If not, please file one. I'll forward
>> it to our IOP testers so that they could try get access to the AP as
>> well.
>
> Done : https://bugs.maemo.org/show_bug.cgi?id=3481

Thanks a lot.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 23, 2008, 12:57 PM

Post #14 of 41 (1676 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext Andrew Daviel" <advax[at]triumf.ca> writes:

> Excellent writeup, thanks :-)

You welcome.

> So, what devices apart from the Nokia tablets use PSM ?

Nokia phones (N95, N81 etc) use WLAN PSM. They might even have more
aggressive PSM tablets have.

> iPhone ?

I once (like a year ago) played with an iPhone. What it did was that
it disassociated (ie. disconnected) from the AP few minutes after the
display was turned off. But I haven't looked at it since.

> Palm ? Windows Mobile devices like the UTstarcom PocketPC ?

No idea. I haven't had access to those kind of devices.

> I opened a ticket with Proxim; not sure if our contract includes
> support but maybe I'll get a reply.

I wish you luck.

> Is there anything for the tablets that can log wireless traffic in
> enough detail to show whether PSM is working ? airodump-ng ??
>
> How about on laptops ? Airmagnet drivers perhaps (which we don't have)

Good question. I should write something about this as well because
having proper airlogs would help a lot with these kind of problems. I
just don't have the time to do it right now :/

But basically you use can set the driver to monitor mode (iwconfig
wlan0 mode monitor), set the correct channel (iwconfig wlan0 channel
7) and use tcpdump to save the log to a file (tcpdump -i wlan -w
wlandump.cap). The cap file can be read with wireshark and you can see
all the WLAN frames trasmitted over the air.

Please note that not all drivers support monitor mode or they have
some quirks using it. Here's a link to page describing how to use
monitor mode with madwifi:

http://madwifi.org/wiki/UserDocs/MonitorModeInterface

> I have an ancient Orinoco Gold card on a Dell Latitude, and a slightly
> less old Thinkpad with (I think) madwifi driver, and a new Lenovo on
> the way (Windows, though)

I have used madwifi to sniff WLAN frames quite a lot, but nowadays I
use iwl3945 because it's fully Open Source.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

fred at crozat

Jul 23, 2008, 12:59 PM

Post #15 of 41 (1683 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

On Wed, Jul 23, 2008 at 9:43 PM, Kalle Valo <kalle.valo[at]nokia.com> wrote:
> "ext Frederic Crozat" <fred[at]crozat.net> writes:
>
>>> But what I could do is to analyse the problem myself. It would take
>>> only an hour or two, including writing a small report about the
>>> problem which I can send everyone interested (hopefully this includes
>>> the vendor). So if you would be able to convince the vendor to send
>>> the AP for a loan? If that's not possible, are you coming to Maemo
>>> Summit? If I manage to come and you can take the AP with you, I could
>>> take a look at it onsite.
>>
>> Unfortunately, it won't be possible because Freebox (the name of
>> set-top-box = ADSL modem + wifi mimo router + many other nice things)
>> can only work when they are synchronized over ADSL with Free ISP
>> DSLAM. So, even if we could send you a Freebox, you couldn't do
>> anything with it :(
>
> This is getting difficult. So if your ADSL line is dead for a day your
> WLAN AP will not work, did I understand this right? If yes, that sucks
> big time.

Only if there is also a power loss and AP need to reboot (it needs
ADSL line working to download its
firmware over DSL at each boot). And frankly, it is not really an
issue (no downtime for several years
for myself ;).

>> Anyway, I've pinged Freebox engineer in hope they might have a clue on
>> the issue.
>
> That's your only chance, unfortunately. I would assume now that WLAN
> is getting more popular in mobile phones they would get more pressure
> to fix this. Let's hope for the best.

Well, when I discussed with them, they told me they already fixed PSM
for usage with Wifi phones
they are selling. So, PSM is working, but not (yet) with Nokia
internet tablet ;)

--
Frederic Crozat
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

jholmblad at acadiasecurenets

Jul 23, 2008, 2:33 PM

Post #16 of 41 (1667 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

Andrew,

after thinking about Kalle's explanation of PSM, and as the owner of a
UTStarcom Windows Mobile handset (Verizon Wireless XV6700) that supports
both EVDO and 802.11b, I have to conclude that, The UTS XV6700 does not
do a satisfactory job with respect to PSM.

My conclusion here is based on the fact that the XV6700 quickly runs out
of battery when the WIFI is turned on. Although I have an app on the
XV6700 that will dump packet traces, I don't know of a way to enable, as
Kalle suggests, monitor mode, or if it is even supported by the chipset
used in the Xv6700 in order to investigate the root cause of this problem.

Needless to say, whenever I bring my handset somewhere where I plan on
using the WIFI, or,, for that matter the EVDO interface (which also
seems to use a lot of "juice") so I can access the Internet from the
Xv6700 or from the N800), I bring an AC adapter along.

Best Regards,

John Holmblad

Acadia Secure Networks, LLC

* *

Andrew Daviel wrote:
> Excellent writeup, thanks :-)
>
> So, what devices apart from the Nokia tablets use PSM ?
>
> iPhone ? Palm ? Windows Mobile devices like the UTstarcom PocketPC ?
>
> I opened a ticket with Proxim; not sure if our contract includes support
> but maybe I'll get a reply.
>
> Is there anything for the tablets that can log wireless traffic in enough
> detail to show whether PSM is working ? airodump-ng ??
>
> How about on laptops ? Airmagnet drivers perhaps (which we don't have) -
> I have an ancient Orinoco Gold card on a Dell Latitude, and a slightly
> less old Thinkpad with (I think) madwifi driver, and a new Lenovo on the
> way (Windows, though)
>
>
>

_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 24, 2008, 4:27 AM

Post #17 of 41 (1663 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext Andrew Daviel" <advax[at]triumf.ca> writes:

> Lots of detail I don't understand. I can see the beacon interval on
> the Proxim APs is 100ms (same as the Linksys default), and see the
> DTIM info (whether data is being held).
>
> IEEE 802.11 Beacon frame, Flags: ........
> Type/Subtype: Beacon frame (0x08)
> Frame Control: 0x0080 (Normal)
> Flags: 0x0
> ...0 .... = PWR MGT: STA will stay up
> IEEE 802.11 wireless LAN management frame
> Fixed parameters (12 bytes)
> Beacon Interval: 0.102400 [Seconds]
> Capability Information: 0x0421
> .... .... .... ...1 = ESS capabilities: Transmitter is an AP
> .... 0... .... .... = Automatic Power Save Delivery: apsd not implemented
>
> home and work have the same flags, except at home
> short preample is allowed. I.e. PWR MGT is 0 at home, too.

Beacons (and all other frames originating from the AP) will always
have the PWR MGT bit zeroed, because AP will never sleep.

> We have multiple APs at work; I assume that in normal operation the
> tablet is registered with only one and will ignore beacons from
> the others.

Correct.

> All the packets from home, and most from work, show as "malformed
> packet" for some reason. airodump didn't offer a capture length and
> the packets are fairly small (85 bytes) so I don't think truncated

Usually missing FCS causes this. There's a setting in Wireshark under
IEEE 802.11 to enable and disable FCS calculation. Try reverting that
option.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 24, 2008, 4:34 AM

Post #18 of 41 (1662 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext Andrew Daviel" <advax[at]triumf.ca> writes:

> I opened a ticket with Proxim.

Very good, thanks.

> They suggest turning off SSID broadcast and see if that reduces the
> battery use. Sounds like b/s to me, but I may be wrong.

Yes, that has nothing to do with your problem.

> If I try that at home, I have to mark the connection as "hidden"
> otherwise I can't select it to connect to, and I suspect it would
> annoy people at work. I still get beacons every 100ms.

Yeah, hiding SSID just makes it more difficult (=slower) to find the
network while scanning, because you have to explicitly scan for all
saved networks. My strong recommendation is to avoid that feature
altogether, and it doesn't really improve security.

> I can't set the wireless chip in my IBM laptop to monitor mode
> (atheros/madwifi driver)

Madwifi does it a bit differently, here's some documentation:

http://madwifi.org/wiki/UserDocs/MonitorModeInterface

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 24, 2008, 4:42 AM

Post #19 of 41 (1667 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext Frederic Crozat" <fred[at]crozat.net> writes:

> On Wed, Jul 23, 2008 at 9:43 PM, Kalle Valo <kalle.valo[at]nokia.com> wrote:
>>
>> This is getting difficult. So if your ADSL line is dead for a day your
>> WLAN AP will not work, did I understand this right? If yes, that sucks
>> big time.
>
> Only if there is also a power loss and AP need to reboot (it needs
> ADSL line working to download its firmware over DSL at each boot).
> And frankly, it is not really an issue (no downtime for several
> years for myself ;).

Good then. For me that kind of setup just sounds too much of a company
control for my taste.

>>> Anyway, I've pinged Freebox engineer in hope they might have a clue on
>>> the issue.
>>
>> That's your only chance, unfortunately. I would assume now that WLAN
>> is getting more popular in mobile phones they would get more pressure
>> to fix this. Let's hope for the best.
>
> Well, when I discussed with them, they told me they already fixed
> PSM for usage with Wifi phones they are selling. So, PSM is working,
> but not (yet) with Nokia internet tablet ;)

Then that's very strange. I wonder do they refer here that they fixed
the frame loss problems (ie. disconnecting from networks etc) or power
consumption problems.

If I would just get access to this device for few hours. This is not
easy.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

kalle.valo at nokia

Jul 24, 2008, 4:47 AM

Post #20 of 41 (1665 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

"ext John Holmblad" <jholmblad[at]acadiasecurenets.com> writes:

> Kalle,

Hi John,

> thanks for the response,and yes, after another day of work with the
> upgraded OS on the N800 I concluded that the N800 was low on battery
> as a result of either
>
> a) the unit was not fully charged to begin with, or
>
> b) for a while I used the speakers on the N800 to listen to the radio
> while I was working, or
>
> c) the processor was working hard while doing the downloads/upgrades.
>
> At this point the unit is behaving quite nicely from a power
> consumption perspective even though the wilaninfo app shows signal
> quality at ~40% with the poll interval set to 5 sec.

Ok, let's hope that the problem you saw was just a random glitch.

> It also appears that all of my client wireless cards are running
> 802.11g because the wilaninfo app is showing the raw channel rate as
> fluctuating between 36, 48, and 54mbps.

Actually 11g devices can always use 54 Mbps even if there are 11b
devices around. What the AP will do is that it will enable the so
called ERP protection methods CTS-to-Self and long slot time, which
make it possible for 11g devices to still use higher bitrates.

--
Kalle Valo
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

tony at beermad

Jul 24, 2008, 5:26 AM

Post #21 of 41 (1664 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

On Wednesday 23 Jul 2008, maemo-users-request[at]maemo.org wrote:
> > After the OS upgrade I started getting low battery warnings when my
> > N800 was not connected to AC power for "a while" (less than a few
> > hours). �I do not remember having this problem when my N800 was
> > running OS2007.
>
> I would first recommend to see if you have badly behaving application
> which is waking up CPU too often. Other option is to disable WLAN
> altogether using Offline mode and try to test if it's really WLAN
> related.

A lot of audio applications in particular seem to behave badly where power's
concerned, still consuming a lot even when they aren't playing. Canola's
particularly nasty in that respect, in my experience.

--
Tony Green
Ipswich, Suffolk, England
http://www.beermad.org.uk
http://no2id-ip.web-brewer.co.uk

** This message is digitally signed. If your email client is unable to read
digital signatures, you may see an attachment that you cannot open. See
http://www.gnupg.org/documentation/faqs.en.html for more information.
You can validate my PGP key from my website: http://www.beermad.org.uk/
* No Micro$oft products were used in the generation of this communication

Attachments:

signature.asc (0.18 KB)

advax at triumf

Jul 26, 2008, 11:51 AM

Post #22 of 41 (1612 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

On Thu, 24 Jul 2008, Kalle Valo wrote:

(packets from N810 captured with airodump-ng show as malformed)

> Usually missing FCS causes this. There's a setting in Wireshark under
> IEEE 802.11 to enable and disable FCS calculation. Try reverting that
> option.

Yes. Edit/Preferences/Protocols/IEEE 802.11. Also lets me set WEP keys.
Not sure I have that working right, but I turned off WEP/WPA to debug,
anyway.

I was able to get the IBM laptop into monitor mode using the madwifi
instructions (thanks) - airodump did not do it as it does on the tablet.
# wlanconfig ath0 destroy
# wlanconfig ath0 create wlandev wifi0 wlanmode monitor
# ifconfig ath0 up
# echo '801' > /proc/sys/net/ath0/dev_type

then I could use tcpdump or ethereal/wireshark. If I don't suppress
prism headers then I can't refilter with "tcpdump wlan host <node>"
which makes it hard to sift through the traffic at work.

I have placed some capture data on my server at
http://andrew.triumf.ca/reqauth/PSM/
(password test/test to keep out robots and the clueless)
I may be being dumb, but I can't see a problem. I can see the tablet
doing a power-save poll and saying it is going to sleep after the
transactions, and the more-data bit appears cleared. I can see the DTIM
bits being set in the beacon before the data transactions and cleared
afterwords.

There is a lot more traffic at work (duh), including lots of ip broadcast
traffic on a VLAN connected to our wired LAN. But that's on a different
SSID. We recently created a separate VLAN & SSID with encryption on,
which is what I normally use on the tablet, but here I used our visitor
SSID. These don't see the ip broadcasts from the wired LAN, but in any
case as I understand it these should not make a substantial difference in PS mode.

A battery graph is at
http://andrew.triumf.ca/reqauth/PSM/batt.use2.gif

I may be able to get a spare Proxim AP to take home. There's a limit on
what I can mess with on our production WLAN :-7, and I'd have a less
noisy environment.

I'm not sure what I can tell Proxim. Send them the capture files, I
guess. Setting the AP to closed mode made no difference.

notes:
If I want to see ping broadcasts, I can do
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

I wondered whether setting /proc/sys/net/ipv4/tcp_frto helps, as per
kernel ip-sysctl.txt ("particularly beneficial in wireless environments")
Not for the power, just for transmission errors.

I thought that unicast data was buffered till the next beacon in PS mode,
with broadcast/multicast buffered till the next DTIM interval, but at
least on my Linksys router it looks like unicast is buffered till DTIM
too. It lets me adjust both the beacon interval and DTIM; the Proxim
allows only DTIM. Defaults are 100ms and 1x.
If the delay (beacon interval x DTIM) exceeds about 10 seconds, the
tablet won't respond to incoming data. My desktop says "network not
reachable". I thought that was a tunable parameter but the only one I
found was a SYN timeout at 60x.
If the tablet is in power-save mode, doing "iwconfig wlan0 power off"
will momentarily revert it to non-PS, and incoming data is received.
Outgoing data is unaffected.
Doing a broadcast ping was interesting with DTIM > the ping interval;
wired stations respond every second but the wireless ones are bunched up
in a group. As expected; it just looks weird.

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

advax at triumf

Jul 30, 2008, 2:42 PM

Post #23 of 41 (1542 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

On Sat, 26 Jul 2008, Andrew Daviel wrote:

> I may be able to get a spare Proxim AP to take home. There's a limit on
> what I can mess with on our production WLAN :-7, and I'd have a less
> noisy environment.

Well, I got one. The power consumption seems normal (i.e. PS mode seems
to be working). I did an HTTP GET off the tablet httpd every 20 seconds
with no apparent effect on battery (1%/hour slope or whatever). If "more
data" or DTIM bits were getting stuck I'd think that would trigger it.
But as before, I can't see any problem in captured data.
Foo. What's different:
- at work there are multiple APs each with 3 SSIDs with VLAN
tagging
- at work there is way more traffic - unicast, broadcast, multicast
- at work there are more clients

I seem to have the same power issue on at least 2 different APs at work,
and I think 2 different VLANs. Wish I could easily stick an ammeter
inline instead of waiting a couple of hours ... hmm, tiny little clips
from a logic analyzer lead set ... perhaps not impossible...

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

advax at triumf

Aug 5, 2008, 11:27 AM

Post #24 of 41 (1449 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

I have done some more tests with the Proxim AP4000, but I still cannot
see a problem in the protocol. I have put an ammeter inline between the
N810 battery and connectors so I can see the current consumption in real
time - it is pretty impressive that it can draw virtually no current at
all (<10mA on a 1A scale) and still respond to incoming network traffic
or a cron job.

I took an AP4000 home and modified the configuration to work without
Radius authentication. At work, we have multiple AP4000's with 3 SSID's
each, using (mostly) non-overlapping channels 1,6,11. But there may still
be some in-channel interference from our or foreign APs.

With the AP4000 broadcasting one SSID (which the N810 is associated
with), power consumption is low in PS mode. An incoming packet, e.g. ICMP
ping, gives a brief kick on the ammeter.
My Linksys AP broadcasting on the same channel makes no difference -
there are two beacon frames, one for each SSID, but power consumed is
low.

With the AP4000 broadcasting 2 or 3 SSIDs on different VLANs, then power
consumption rises to an average 100mA. If "broadcast unique beacon" is
disabled for all SSIDs, then the power consumption is low. The AP
broadcasts only one beacon, with no identifier. But if it is enabled for
one or more SSIDs, the consumption can rise:

With beacon SSID enabled on "triumf" but disabled on "test" - <10mA
With beacon SSID enabled on "triumf" and enabled on "test" - 100mA
With beacon SSID disabled on "triumf" but enabled on "test" - 100mA
With beacon SSID disabled on "triumf" and disabled on "test" - <10mA
(The N810 is associated with "triumf")

Capture files on
http://andrew.triumf.ca/reqauth/PSM/

I can see nothing in the capture file (madwifi libpcap -i ath0, no
filters) from the tablet after it responds to the ping, but it is
consuming power. I might be able
to try a spectrum analyzer, but not today.

This is driving me crazy .. I'd give up if there weren't such dramatic
power savings when it works properly.

--
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376 (Pacific Time)
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

dgs at pangea

Aug 5, 2008, 11:41 AM

Post #25 of 41 (1450 views)
Permalink

Re: Power consumption and WLAN APs [In reply to]

> Capture files on
> http://andrew.triumf.ca/reqauth/PSM/
>
It is necessary an user and a pass =-O
_______________________________________________
maemo-users mailing list
maemo-users[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-users

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com