Tks, I keep forgetting that OLPC-Devel doesn't have the list as the default reply-to.<br><br><div class="gmail_quote">On Sat, May 16, 2009 at 7:35 PM, NoiseEHC <span dir="ltr"><<a href="mailto:NoiseEHC@freemail.hu">NoiseEHC@freemail.hu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Please, always use reply-all. Answers inlined where I have an answer.<div class="im"><br>
<br>
Tiago Marques wrote:
<blockquote type="cite">
<div class="gmail_quote">On Sat, May 16, 2009 at 6:42 PM, NoiseEHC <span dir="ltr"><<a href="mailto:NoiseEHC@freemail.hu" target="_blank">NoiseEHC@freemail.hu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The 1GHz C7 is still a slow cpu, as it seems from reviews of similar
netbooks:<br>
<br>
<a href="http://www.notebookreview.com/default.asp?newsID=4352" target="_blank">http://www.notebookreview.com/default.asp?newsID=4352</a><br>
<br>
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?<br>
</blockquote>
<br>
</div>
>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.<br>
<br>
</blockquote>
</div>
<br>
</blockquote>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.<br><blockquote type="cite">
<br>
</blockquote></div>
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.<div class="im"></div></div></blockquote><div><br>Sorry, should have explained myself better, as I was also talking about memory speed and not size, this time.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im"><blockquote type="cite">
<br>
</blockquote>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.<br></div>
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.<br>
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).<br>
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.<div class="im"></div></div></blockquote><div><br>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 <b>random writes</b> 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. <br>
The best drives around, from Intel, can do 20+MB/s in random writes.<br><br>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.<br>
<br><a href="http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=25">http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=25</a><br><br>0.5MB/s in RR should be enough to avoid most stalls.<br><br>Best regards<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><div class="im"><br>
<br>
<blockquote type="cite">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?<br>
<br>
</blockquote></div>
I do not know so reposted to devel.<br>
<blockquote type="cite">Best regards,<br>
<br>
Tiago Marques<br>
</blockquote>
<br>
</div>
</blockquote></div><br>