Talk:Hardware specification: Difference between revisions
Line 2: | Line 2: | ||
A tacit assumption of the OLPC project is that these systems will enjoy limited - or even zero - field maintenance. The best one might hope for is that some onboard diagnostics could warn of impending problems to help the end-user plan for the demise (and possibly the remanufacture) of his unit. In the First World, most are used to tossing out electronic stuff long before it wears out, on account of "technical obsolescence" |
A tacit assumption of the OLPC project is that these systems will enjoy limited - or even zero - field maintenance. The best one might hope for is that some onboard diagnostics could warn of impending problems to help the end-user plan for the demise (and possibly the remanufacture) of his unit. In the First World, most are used to tossing out electronic stuff long before it wears out, on account of "technical obsolescence" |
||
But OLPC units may see use long after they are "obsolete", for complex reasons that don't care about "Moore's Law". And who knows what setbacks will befall schools in the places these machines might go? Consider a country that suffers a decade-long "technology" embargo, for example. |
But OLPC units may see use long after they are "obsolete", for complex reasons that don't care about "Moore's Law". And who knows what setbacks will befall schools in the places these machines might go? Consider a country that suffers a decade-long "technology" embargo, for example. |
||
Units should be designed to keep maintanence as modular and staightforward as possible. Documentation and diagnostics should be exhaustive and could be included in the firmware- or as accessible and independent from the software as possible. |
|||
== Mass storage == |
== Mass storage == |
||
I have not built devices with flash memory, but I understand that it can't be rewritten an indefinite number of times - maybe just a million? |
I have not built devices with flash memory, but I understand that it can't be rewritten an indefinite number of times - maybe just a million? |
Revision as of 19:00, 5 April 2006
Maintenance and diagnostics
A tacit assumption of the OLPC project is that these systems will enjoy limited - or even zero - field maintenance. The best one might hope for is that some onboard diagnostics could warn of impending problems to help the end-user plan for the demise (and possibly the remanufacture) of his unit. In the First World, most are used to tossing out electronic stuff long before it wears out, on account of "technical obsolescence" But OLPC units may see use long after they are "obsolete", for complex reasons that don't care about "Moore's Law". And who knows what setbacks will befall schools in the places these machines might go? Consider a country that suffers a decade-long "technology" embargo, for example. Units should be designed to keep maintanence as modular and staightforward as possible. Documentation and diagnostics should be exhaustive and could be included in the firmware- or as accessible and independent from the software as possible.
Mass storage
I have not built devices with flash memory, but I understand that it can't be rewritten an indefinite number of times - maybe just a million? (Something done twice a minute is done a million times in only a year.) I assume that measures are taken to load-balance the wear on the various blocks of the memory. But IF one suspects that the flash memory may wear out before other laptop components, it would be useful if the end-user could determine how much life was left in it. When the day came the unit did not function, a hint that flash memory wear killed it might keep remanufacture cheap enough to make sense. (At least "run the numbers" before dismissing my concerns!) Of course the same goes for any other parts (e.g. crank) whose usage (and inferred wear) might be measured. (cf. S.M.A.R.T. technology for PCs with hard drives.)
- Linux supports the JFFS2 file system which addresses the issue of limited number of Flash write cycles. (Incidentially, JFFS2 was developed at Red Hat)
(Given the good wear leveling of JFFS2 compute the amount of wear of the flash as .5 gigabytes times of order 100,000 times. You actually get a lot of writing before the first bad flash block should happen due to wear. (50,000 gigabytes of writing). The chips likely have a higher random failure rate than that. - jg)
Recycling of components - even "Frankenstein" repairs in remote field locations with multiple broken units - might well be designed into the system from the ground up. Moreover, it could also prove useful to benchmark software applications for their life-shortening properties. For example, an application that did frequent automated backups of a document being edited might wear the flash memory more than worthwhile. Remember, in the CRT age, "screensavers" once EARNED their name, rather than serving other purposes on cheap displays easily tossed when worn!
(Yup, we expect frankenlaptops will be common, and are doing what we can to make that reasonable. Similarly, we expect folks will hack the battery packs in the field. -jg)
The "prospectus" for the OLPC laptop looks to a five-year-plus life to justify it as a textbook replacement alone. I think that flash memory "forgets" after a decade, so perhaps the "permanent" part of the flash content might also be regenerated episodically, too. If it is a big portion of the total flash memory, perhaps "rotating the tires", by swapping in which physical part of memory it dwells would allow superior wear-balancing as well.
(JFFS 2 in essense does this already; it occasionally moves blocks to keep the wear level, so so long as there is some write activity, eventually all the bits should end up being rewritten over a long period. -jg )
Upkeep will be the problem of the host country, but maybe one should think about it now before the design is complete. Will host countries want to revise the "permanent" memory content one or more times (e.g. via a USB port) before the machine cannot be used? Maybe First World "Gen-Netters" like revving freeware versions monthly, but poor people burdened with long hours of tiring physical work will not want to make a "hobby" of tweaking a laptop. While USAers might prize customization, another culture might want to keep these "personal" units as harmonized as possible, that cross-peer instruction prove easier. "Shudder": they may value common content over the potential to experiment! But perhaps a village "server" which archives multiple flash "images" could embrace experimentation and homogeneous potential at the same time. Maybe you'd want something like this anyway, as important software flaws emerge late - making a patching infrastructure desirable. (The "server" needn't be a real computer- just a collection of one or more USB flash drives.)
(Due to security updates, we have to keep systems up to date in the field of critical problems, so the idea of never touching a system isn't reasonable for a network enabled system - jg).
So in looking to keep the OLPC laptops working, one should perhaps try to think like a carpenter planning to sail with Magellan. There will be no way to "Fedex" in replacement parts overnight.
RF
So perhaps a number of slots for smaller flash drives rather than one big one? Yes, wear-balancing would make it likely that they all age at the same rate, but when random failure does occur the modularity would facilitate Frankensteining. -Chas
CPU
CPU, esp, running firefox with non-latin fonts - isn't it too slow? I have a similiar spec desktop linux machine actually, and whenever I load multilingual pages (even just a wikipedia page with the names of languages listed on the side in Arabic and Hindi and Korean. Rendering a WP page of Korean page on FireFox takes time!), the font rendering seems real slow... I'm running a K6-3@400Mhz.
(dunno: depends on many factors, and Firefox needs lots of work on the memory front. Also, your font cache in your X server might be too small; that can kill performance (you need a bigger cache for eastern languages) - jg)
- The CPU is constrained by "5W max heat dissipation" requirement. AMD Geode System already consumes almost 2 W under load, leaving only 3 W for display, audio, storage and wireless. At Wikipedia it was suggested that lower power Alchemy be used which would allow for higher clock rates, but apparently x86 was chosen for compatibility reasons.
(actually, it turns out that none of the other low power chips like that have an FPU, rather than x86 compatibility per se'. This is a killer when porting applications to whatever architecture. If an alchemy with and FPU existed, it would have been sincerely temping. - jg).
- This AMD document lists Alchemy with "MIPS32" FPU. Is this a real FPU or some kind of emulation?
Heat dissipation
5W heat dissipation requirement was recently dropped and changed to 10W. So there might have been the possibility of using a faster CPU after all. 130.149.23.44 12:33, 9 March 2006 (EST)
(No, the spec was changed to reflect reality of the worst case situation; we couldn't add before ;-). 5 watts for CPU, then you have the display and backlight full bore, and 2 watts for USB, and 2 watts for audio, and losses in the power supply. The low speed chip is chosen so that low power idle is as low as possible. Even more remarkable, though, is what we hope our best case (screen idle) power consumption will be, which is of order half a watt- jg).
- Regarding page rendering, using non-XUL-based Browser such as Epiphany, Konqueror or Opera should speed things up.
BIOS
BIOS, isn't it smart to have OpenBIOS? (ie. Forth?)
(The point of LinuxBIOS is that we only have to do drivers once, have a full blown networking stack during boot, and so can dream of things like boot/install over the wireless mesh network. And LinuxBIOS has already been deployed in quantity millions. - jg).
RAM
I'm worried that 128M of DRAM is going to hobble the machine. Can you get twice as much DRAM if you're willing to take broken DRAMs with parts that don't work, and use the VM hardware to map around the bad spots in them? It's a simple hack and if it cuts the cost of the DRAM chips by 50% then you can put in twice as many. Or are all the DRAMs with failing bits now being used in telephone answering machines where a dropout doesn't matter? -- gnu
(Turns out that trying to use bad chips isn't worthwhile, so the experts tell me, and putting in more chips means more power. It is possible to solder in a larger memory chip, however, at higher cost. - jg)
SOUND
I'm worried that cost considerations might rule out any sound generating and speakers. However I think that to teach analphabets to learn and write, I will need sound, to show for example syllabes and their sound.
At least some provision must be provided for a USB device able to handle and produce sound. Such device might also be useful for blind people, and people that can´t read. - dagoflores
Power Requirement
I see that you have settled on a 14 volt power specification. I think that is a mistake. Living in West Africa for many years now I see that people are very comfortable with 12volt power systems. In almost every remote village one can find an enterprizing person who has fitted out a small TV to run on a car battery. Eventhough there are no solar panels or other power systems in thier village, they will use that battery to run thier "cinama" and then strap that car battery on the back of a bicycle and pedel 20km or more to a town that has some power and a battery charger.
Making the power system 14 volts then mismatches your device with a well understood and locally vibrant technology, that is unless your specification is so "loose" that the device will run on 12 volts. - eu
Please specify the 14 volt power with the allowable voltage tolerance. The unloading end voltage of a 6 cell lead-acid battery (which is probably the most widely spread) is at about 11.8 V (say 11.6 Volt including some resistive voltage drop until it reaches the device) so a specification of a 14V (-18%) would be fine for the lower limit. As written above (eu) 12V is the sweet spot of available voltages. It is very important not to miss it, rather consider going for 7 NiMH cells instead of 8 NiMH cells! - ff
14V DC or 10V DC?
I'm a bit confused here. 8 AA NiMH cells, in series, discharge at 10V DC and would be charged with something like 11.6V. So why 14V DC?
Battery Type/Voltage
The battery pack should accept AA NmH cells, that can be replaced by the teacher. These can also be purchased at a reasonable proce, as opposed to a "battery pack". 10 cells equals 12 volts, as said elsewhere this is a standard that should be adhered to. Allowing a 12v input would not charge the battery properly, but this could be connected to a larger (sealed lead acid) battery. With 2.2 AH cells, and a 12 watt consumption, what is the actual operating life of the battery? If teachers are reading this, this is important to them.
This is a link to a page that talks about an electricity generator that could improve your laptop project http://www.lacapital.com.ar/2006/03/08/general/noticia_275466.shtml
I hope it helps!!!
Internal USB Connector
It would be nice if the space for an internal USB Connector could be found (20x50x8 mm³ and a hole for a mounting screw). This would greatly reduce the risk of mechanical harm or loosing for an USB memory stick. (Rationale: one of the more often seen criticisms of the OLPC is its relatively small mass storage, a relatively high percentage of users might want to upgrade over the laptops lifecycle. Other stuff like an internal USB radio could also make sense).
Internal MMC/SD Card Connector
An internal MMC or SD Card connector would be nice if the specifications for IO-Extensions to the MMC or SD protocols (SDIO or MMCIO) are available (this is an alternative to an internal USB connector (rationale is given there). Probably more power-effective, but less gadgets available today).
Instant/Always On - No Boot
Will the first version be instant-on no-boot?