Fwd: The XO-1.5 software plan.
-- Forwarded message -- From: Tiago Marques tiago...@gmail.com Date: Sat, May 16, 2009 at 6:18 PM Subject: Re: The XO-1.5 software plan. To: b...@alum.mit.edu On Sat, May 16, 2009 at 5:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Ball wrote: We have some good news: OLPC has decided to base its software release for the new XO-1.5 laptop on Fedora 11. Unlike previous releases, we plan to use a full Fedora desktop build, booting into Sugar but giving users the option to switch into a standard GNOME install instead. (This will mostly be useful for older kids in high school.) I'm particularly happy about this plan because it will allow us to catch up with the awesome work present in the Sugar community's most recent release, Sugar 0.84, as well as merging the latest Fedora work and including GNOME into the mix for the first time. The new machines will have 1GB of RAM and 4GB of flash, so we have enough room for both environments at once. Hi, Where does rainbow and bitfrost come in all of this? This raises an interesting question: should we still be using a compressed filesystem? On the XO-1, an uncompressed FS was essentially not an option. There would be almost no space left for users' files after the uncompressed system files. Unfortunately, this causes tremendous slowdowns all over the system, as it causes reads from flash to (a) be CPU-limited, and (b) compete with the rest of the system for CPU time. Writes are even worse. On the 1.5, we will have more space (so less need for compression), but more system files, and also more CPU to handle it. I think we should remember to test the final images both with and without compression. The 1GHz C7 is still a slow cpu, as it seems from reviews of similar netbooks: http://www.notebookreview.com/default.asp?newsID=4352 For most tasks it is slower than an 600MHz Celeron M and that's not exactly fast. Does anyone more familiar with the hardware have any idea of how fast it is when compared to the Geode? Of course, this equation gets still more complicated depending on whether we have MTD or FTL flash. Choosing a filesystem will be an interesting exercise. Is MTD still up for discussion? Wasn't it going to be FTL? Best regards, Tiago Marques - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoO7LkACgkQUJT6e6HFtqTH/QCfYUitcwLq8bTF2E1g+rbwyfa8 t1sAoIcQ0FXXm16GlFriJ1A2n+Bv4Fe1 =v9fu -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: The XO-1.5 software plan.
The 1GHz C7 is still a slow cpu, as it seems from reviews of similar netbooks: http://www.notebookreview.com/default.asp?newsID=4352 For most tasks it is slower than an 600MHz Celeron M and that's not exactly fast. Does anyone more familiar with the hardware have any idea of how fast it is when compared to the Geode? From my measurements of the Geode and the very limited documentation of the C7 I can speculate that the integer unit can have similar speed to the Geode clock-by-clock (but can have a better branch predictor and faster movsb/movsd implementation) and probably the floating point unit is better integrated so floating point code does not block the integer unit like on the Geode. So if we do not consider the 3d unit or the probably better flash hardware (scatter-gather support) it will have exactly the same speed on similar clock speeds but of course it can go more than 2x faster. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: The XO-1.5 software plan.
Please, always use reply-all. Answers inlined where I have an answer. Tiago Marques wrote: On Sat, May 16, 2009 at 6:42 PM, NoiseEHC noise...@freemail.hu mailto:noise...@freemail.hu wrote: The 1GHz C7 is still a slow cpu, as it seems from reviews of similar netbooks: http://www.notebookreview.com/default.asp?newsID=4352 For most tasks it is slower than an 600MHz Celeron M and that's not exactly fast. Does anyone more familiar with the hardware have any idea of how fast it is when compared to the Geode? From my measurements of the Geode and the very limited documentation of the C7 I can speculate that the integer unit can have similar speed to the Geode clock-by-clock (but can have a better branch predictor and faster movsb/movsd implementation) and probably the floating point unit is better integrated so floating point code does not block the integer unit like on the Geode. So if we do not consider the 3d unit or the probably better flash hardware (scatter-gather support) it will have exactly the same speed on similar clock speeds but of course it can go more than 2x faster. And the memory should also help, it should be enough. But still, IMHO Xfce would still be a better fit, especially since these laptops go to places where things being snappy is almost a requirement. I do not think that the memory speed is a bottleneck on the XO-1. The problem is that the Geode is an in-order processor and an uncached memory read block the processor for 25 clocks. It will be the same on the C7 unless it has a Core2 Duo category speculative memory prefetcher but of course I doubt it... BTW the faster memory will not hurt either. What about random write performance of the flash memory this time? That will be a show stopper if it's below at least 0.5MB/s. But that would be hard without cache for the flash. The 0.5 MB/s came mostly from the zlib compression code. With LZO the Geode could compress 10MB/sec so it would have been a big help in write performance but the conclusion from most of the developers was that the biggest win would be having per inode compression setting (like not compressing zip and jpeg files) but of course nothing was implemented. BTW I have a half-made asm zlib decompressor what I have left rotting since it became impossible to debug (hallowed are gcc developers and the holy UNIX command piping, gcc generates 1 line of debug info for a whole asm block). I have another half-made asm decompressor for LZO but it seems that the creator of LZO f***ed up the code and it has unused opcodes so I tried to actually document the LZO compressor but my efforts stalled since kernel developers were fired from OLPC (I will not integrate such code to the kernel that is sure). The conclusion is that if the XO 1.5 will use a normal filesystem then compression will not be supported so flash write speed will not be a bottleneck. As for Gnome/Xfce/KDE, whatever, how are you considering that older students guess where F1-12 are? Are any changes planned for the keyboard stamping to accommodate this change in direction or are you taking that as part of the learning process? I do not know so reposted to devel. Best regards, Tiago Marques ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: The XO-1.5 software plan.
Tks, I keep forgetting that OLPC-Devel doesn't have the list as the default reply-to. On Sat, May 16, 2009 at 7:35 PM, NoiseEHC noise...@freemail.hu wrote: Please, always use reply-all. Answers inlined where I have an answer. Tiago Marques wrote: On Sat, May 16, 2009 at 6:42 PM, NoiseEHC noise...@freemail.hu wrote: The 1GHz C7 is still a slow cpu, as it seems from reviews of similar netbooks: http://www.notebookreview.com/default.asp?newsID=4352 For most tasks it is slower than an 600MHz Celeron M and that's not exactly fast. Does anyone more familiar with the hardware have any idea of how fast it is when compared to the Geode? From my measurements of the Geode and the very limited documentation of the C7 I can speculate that the integer unit can have similar speed to the Geode clock-by-clock (but can have a better branch predictor and faster movsb/movsd implementation) and probably the floating point unit is better integrated so floating point code does not block the integer unit like on the Geode. So if we do not consider the 3d unit or the probably better flash hardware (scatter-gather support) it will have exactly the same speed on similar clock speeds but of course it can go more than 2x faster. And the memory should also help, it should be enough. But still, IMHO Xfce would still be a better fit, especially since these laptops go to places where things being snappy is almost a requirement. I do not think that the memory speed is a bottleneck on the XO-1. The problem is that the Geode is an in-order processor and an uncached memory read block the processor for 25 clocks. It will be the same on the C7 unless it has a Core2 Duo category speculative memory prefetcher but of course I doubt it... BTW the faster memory will not hurt either. Sorry, should have explained myself better, as I was also talking about memory speed and not size, this time. What about random write performance of the flash memory this time? That will be a show stopper if it's below at least 0.5MB/s. But that would be hard without cache for the flash. The 0.5 MB/s came mostly from the zlib compression code. With LZO the Geode could compress 10MB/sec so it would have been a big help in write performance but the conclusion from most of the developers was that the biggest win would be having per inode compression setting (like not compressing zip and jpeg files) but of course nothing was implemented. BTW I have a half-made asm zlib decompressor what I have left rotting since it became impossible to debug (hallowed are gcc developers and the holy UNIX command piping, gcc generates 1 line of debug info for a whole asm block). I have another half-made asm decompressor for LZO but it seems that the creator of LZO f***ed up the code and it has unused opcodes so I tried to actually document the LZO compressor but my efforts stalled since kernel developers were fired from OLPC (I will not integrate such code to the kernel that is sure). The conclusion is that if the XO 1.5 will use a normal filesystem then compression will not be supported so flash write speed will not be a bottleneck. Thing is, most flash controller implementations are crap, and it will probably be the case with the one in Gen 1.5. I'm quoting 0.5MB/s in *random writes* to the file system, nothing to do with compression. Most decent SSDs can write at last 1MB/s with some topping 2MB/s, in random patterns, sequential is about 150MB/s+. Sequential is not the problem when using SD cards or most USB drives, random writes is, when you're trying to have an OS on it. The best drives around, from Intel, can do 20+MB/s in random writes. Most SSDs on the market are based on J-Micron controllers that can do, at most, 0.04MB/s in random writes. This causes the system to frequently stall when some app is performing heavy writes to arbitrary locations. Random reads are mostly very fast with every type of flash you can get. http://www.anandtech.com/storage/showdoc.aspx?i=3531p=25 0.5MB/s in RR should be enough to avoid most stalls. Best regards As for Gnome/Xfce/KDE, whatever, how are you considering that older students guess where F1-12 are? Are any changes planned for the keyboard stamping to accommodate this change in direction or are you taking that as part of the learning process? I do not know so reposted to devel. Best regards, Tiago Marques ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: The XO-1.5 software plan.
Sorry, should have explained myself better, as I was also talking about memory speed and not size, this time. Ahh, if you wrote about memory size then never mind my comments. :) Thing is, most flash controller implementations are crap, and it will probably be the case with the one in Gen 1.5. I'm quoting 0.5MB/s in *random writes* to the file system, nothing to do with compression. Most decent SSDs can write at last 1MB/s with some topping 2MB/s, in random patterns, sequential is about 150MB/s+. Sequential is not the problem when using SD cards or most USB drives, random writes is, when you're trying to have an OS on it. The best drives around, from Intel, can do 20+MB/s in random writes. Most SSDs on the market are based on J-Micron controllers that can do, at most, 0.04MB/s in random writes. This causes the system to frequently stall when some app is performing heavy writes to arbitrary locations. Random reads are mostly very fast with every type of flash you can get. http://www.anandtech.com/storage/showdoc.aspx?i=3531p=25 http://www.anandtech.com/storage/showdoc.aspx?i=3531p=25 0.5MB/s in RR should be enough to avoid most stalls. I hope that Mich Bradley will educate us but it seems to me that the hidden eraseblock handling can be the problem with those devices (and if it is true then compression will not help it either). It seems to be that some tests are required with physical hardware, a paper processor will not be enough... :) Are there any plans using UBIFS? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: The XO-1.5 software plan.
On Sat, May 16, 2009 at 8:14 PM, NoiseEHC noise...@freemail.hu wrote: Sorry, should have explained myself better, as I was also talking about memory speed and not size, this time. Ahh, if you wrote about memory size then never mind my comments. :) Thing is, most flash controller implementations are crap, and it will probably be the case with the one in Gen 1.5. I'm quoting 0.5MB/s in *random writes* to the file system, nothing to do with compression. Most decent SSDs can write at last 1MB/s with some topping 2MB/s, in random patterns, sequential is about 150MB/s+. Sequential is not the problem when using SD cards or most USB drives, random writes is, when you're trying to have an OS on it. The best drives around, from Intel, can do 20+MB/s in random writes. Most SSDs on the market are based on J-Micron controllers that can do, at most, 0.04MB/s in random writes. This causes the system to frequently stall when some app is performing heavy writes to arbitrary locations. Random reads are mostly very fast with every type of flash you can get. http://www.anandtech.com/storage/showdoc.aspx?i=3531p=25 0.5MB/s in RR should be enough to avoid most stalls. I hope that Mich Bradley will educate us but it seems to me that the hidden eraseblock handling can be the problem with those devices (and if it is true then compression will not help it either). It seems to be that some tests are required with physical hardware, a paper processor will not be enough... :) True, I just thought it was a good idea to point this out before any decisions are made, especially when most Flash vendors completely disregard random write performance. Best regards Are there any plans using UBIFS? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
