Talk:XO-1/Software specification

Xavi, Ortiz: please don't change this page before Tuesday at the earlies: I'm doing major work on it, and your edits are causing me to lose work again, and again. Thanks - Jim

We need an easy way to measure power usage. Then we can determine what gcc options give the best power usage. (gcc has "-Os" for size and "-O2" for speed; it could have "-Op" for power) AlbertCahalan 18:53, 2 March 2007 (EST)

If an SD memory card is plugged in and is mounted into the file system, it should still be possible to power down the SD slot, by first sync-ing the file system into a clean status, and then powering down the slot. Whenever it is next accessed, it can be powered-up. Whenever it is next written, the "clean" bits in the superblock can be unset, then the write can take place. In addition, to avoid frequent wakeups if something is looking at the root inode where the SD card is mounted, that inode (and possibly other info, such as its directory contents) can be cached read-only in RAM. They are guaranteed not to change while the card is powered down :-). This is completely independent of CPU power (unless the mobo is wired to depend). -- gnu 7 May 2007

The same strategy can be employed for USB memory sticks: If mounted, they can be sync'd to a clean filesystem state, and then powered down. This can be done independently from CPU power (but I don't know if it's actually wired that way). -- gnu 7 May 2007

I don't understand why "an ebook reader" would ask the system for "aggressive power management". Why wouldn't the system always be aggressively managing its power? Would we instruct students to start up the ebook reader to reduce the power consumption of their systems?

I suspect that in B1 and B2 prototypes, it will be possible to suspend for a period of a second or two (if the user allows this to be done), power-up long enough to figure out whether any key has been held down on the keyboard, and go back to sleep if not. Yes, the screen might glitch; some users will not care. This will give the suspend code about 100x as much testing as it would get on B3 systems only, and will also reduce power for the 3500+ users of B1 and B2 systems.

WiFi Power Save mode

The power consumption of the Marvell wireless module has been measured at just over 300mw; even with power supply losses, we expect the batteries can power the wireless for > 40 hours (to be measured).

I gather the figure of 300mW reflects the WiFi Rx (including DSP) being on all the time because it has to be for a Mesh Relay (as would also be true for an Access Point).

Once the mesh is fully implemented it might be worth considering a possible significant further reduction as follows.

1. Designate a subset of the XOs in a stable Mesh to drop out of the Mesh and become ordinary STAs in infrastructure mode, using the rest of the MPs as their APs. These would of course be selected to ensure the Mesh remains fully connected and reasonably redundantly connected (by examination of neighbour lists and routing tables etc).

2. This would result in greater power consumption by the remaining MPs due to longer hop distances to neighbouring MPs and consequently greater Tx power (since the power saving due to multiple short hops instead of single longer hops is one of the major advantages of the mesh.

3. BUT it would also allow all the XOs in the subset that are only STAs to go into Power Saving mode. They can turn off their Rx most of the time and only turn it on periodically to listen for beacons with Distributed Traffic Information Messages (DTIMs). A lot of 802.11 MAC protocol details are to enable this, with APs buffering broadcast, multicast and any unicast traffic directed to those of their STAs that are in Power Saving mode so that unicast traffic is only forwarded to them after they have done a PS mode poll to request it following notification in a periodic DTIM (and broadcast or multicast traffic immediately following the DTIM so they can listen for that too if they choose). Apparantly enabling PS mode STAs to turn off their Rx most of the time does make a BIG difference in power consumption. (Presumably the 94K RAM in the Marvell chips is partly because they are, like most Mesh Points, expected to function as APs that need lots of buffer space to hold traffic for STAs in PS mode until the next periodic DTIM beacon when they will be listening).

4. This could be significant with the Mesh on continuously since for much of the 24 hours there would be negligible traffic and in particular there would reliably be no traffic for XOs that are just left on to maintain the Mesh in suspend to RAM mode (except when they are woken up).

5. Detailed calculations would be needed (dynamically according to actual conditions). But suppose one third of MPs could become STAs at say 30mW instead of 300mW and that the remaining MPs were using an extra 200mW instead of an extra 100mW for Tx spending say 5% of their time on Tx. That would increase power for 2 of 3 nodes by 2 x 5% of 100mW = 10mW and decrease power for 1 of 3 nodes by 300mW - 30mW = 270mW for a net gain of 260mW per 3 nodes, ie 87mW per node. So it seems worth plugging in some real numbers to consider whether it would be worthwhile.

6. The actual benefit could be greater by selecting those nodes that are awake as MPs and selecting those nodes with the least remaining battery power as preferred candidates to become STAs. (Information available once battery levels are included in routing metrics as planned).

7. Dynamic calculations would bump STAs to become MPs when connectivity is lost due to an MP dropping out (via an election among STAs of the missing AP that have suitable received signal strengths from MPs that were in the neighbour list of the MP that disappeared, and allow MPs to drop out when their battery levels are below those of available replacements from their STAs.

8. In particular note that outlying nodes (those furthest from portals) would ALWAYS be good candidates to become STAs since they are not relaying traffic any further from the portals anyway but are only in the mesh for their own connectivity.

9. Note that a higher proportion of nodes will tend to be at the outlying maximum hop distance than at the smaller hop distances (because with a roughly uniform density of nodes around a school, the roughly circular belt between the fourth and fifth hop would have an area proportional to 5 squared minus 4 squared = 9 while the next closer belts to the school would be proportional to 7, 5, 3 and 1 respectively. So the two furthest belts would be likely to have 9 + 7 = 16 nodes for every 3 + 1 = 4 nodes in the two closest belts.

10. However there has to be a provision for subsequently appearing nodes that are within range of a STA but not in range of an existing MP to trigger the STA switching to become an MP so it can relay for them.

11. While I am at it, directional antennae for the outermost nodes could dramatically enhance both range and power consumption. Item 9 above suggests that a high proportion of homes that would be "just out of range" could become "just within range" if they are able to point a directional antenna inwards. (Nodes closer to the school portal cannot use directional antenna because they need to relay traffic in other directions).

12. Also BTW sector antennas at the school could make a significant difference for both mesh power consumption and range by extending the ring for the first hop eg 3 x 120 degrees or 6 x 60 degrees for coverage in all directions.

13. These considerations apply equally to clusters of home nodes that form a mesh distant from the main mesh around a school or connected to that main mesh by additional fixed permanent relays. Any secondary meshes are likely to equally benefit from some of the nodes becoming STAs and from their outermost participants having directional antennae.

Keyboard picture links

The individual links to keyboard .jpgs in Power_management#Keyboard_Languages_Support should probably be removed as obsolete and potentially misleading. Pages listed on Category:Keyboard page generally link to .png images, not these .jpgs, individual .jpg links are incomplete list. Cjl 02:26, 12 May 2008 (EDT)