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@xxxxxxxxxx> 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@xxxxxxxxx https://lists.maemo.org/mailman/listinfo/maemo-users
