"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. -- Kalle Valo _______________________________________________ maemo-users mailing list maemo-users@xxxxxxxxx https://lists.maemo.org/mailman/listinfo/maemo-users
