Fwd: The XO-1.5 software plan.
tiagomnm at gmail.com
Sat May 16 14:54:40 EDT 2009
Tks, I keep forgetting that OLPC-Devel doesn't have the list as the default
On Sat, May 16, 2009 at 7:35 PM, NoiseEHC <NoiseEHC at 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 <NoiseEHC at freemail.hu> wrote:
>> The 1GHz C7 is still a slow cpu, as it seems from reviews of similar
>>> 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
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
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.
0.5MB/s in RR should be enough to avoid most stalls.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel