Dear OLPC devel,
Actually, I made experiment long time ago but did not given the results.
Today I repeat my experiment using 3 pc namely:
1. my server, 2 GB RAM, pentium4 2.6 Ghz 512 K cache
2. my old pc, 256 MB RAM, cerelon 1.3 Ghz 128 K cache
3. OLPC 128 MB RAM, Geode 400 Mhz, 64 K cache
The limiting factor to limit the overall performance is USB storage speed
and NOT CPU at all.
My server can read USB at speed 17.52 MB/sec
My old pc read USB at speed 986.17 KB/sec
OLPC read USB at speed varied from 5.6 MB/sec to 14.06 MB/sec
Ofcause in my experiment OLPC at 400 Mhz run much faster than cerelon 1.3
Ghz but only a little bit slower than pentium 4 2.6 Ghz.
At this moment I run netscape under OLPC and no problem to watch huge .swf
movies from my server while 1.5 Ghz pentium 4 in my department cause
serious problem and unable to watch my web at http://supat.eu.org/
Based on my experiment, OLPC has no serious problem any more.
I just solve Thai kbd problem from earlier Xorg version.
I will give OLPC-SLAK image to you soon after I am sure it was a good an
alternative.
regards,
supat
ps. conclusion: processor speed is not the first limiting factor to effect
the total performance of OLPC.
On Mon, 25 Sep 2006, [EMAIL PROTECTED] wrote:
Hi,
Total performance of OLPC based on "Limiting Factors Theory".
We cannot know its total performance at this day because we still use USB
storage while true performance based on internal memory.
So, increasing CPU performance may or may not affect total performance but
improve in storage speed are surely improve total OLPC performance.
At this moment, the first limiting factor is USB storage speed and it has
acceptible performance based on my experiment.
Ofcause, improve in CPU performance and internal memory storage may imporove
OLPC quality much. And we should do it.
Regards,
supat
On Mon, 25 Sep 2006, Zarro Boogs per Child wrote:
#125: Geode GX is a poor CPU choice
------------------------+---------------------------------------------------
Reporter: bluefoxicy | Owner: mfoster
Type: defect | Status: new
Priority: low | Milestone:
Component: hardware | Resolution:
Keywords: |
------------------------+---------------------------------------------------
Old description:
The first revision of machines is going to be based on the Geode GX.
Reviewing its data sheet, there are a few numbers that need attention:
* Memory controller on the CPU
* 32KiB L1 cache
** 16KiB I1
** 16KiB D1
** 4-way Set Associative
** 1 Cycle Cache hits
** 2 Cycle Cache hits if not using the same way
** '''25 Cycle''' Cache misses (give or take a few depending on the exact
conditions)
* No L2 Cache
* 80-Entry TLB
** 8 L1 ITLB
** 8 L1 DTLB
** 64 L2 TLB
To simulate cache, you can use the following cachegrind line:
''valgrind --tool=cachegrind --I1=16384,4,32 --D1=16384,4,32
--L2=64,2,32 [program]''
Ignore L2, it doesn't exist on the Geode GX. Cachegrind demands it be
set valid.
A simulation of Rhythmbox shows a 1.2% overall cache miss rate. Multiply
this by 25 cycles and that's a 33.2% slowdown; multitasking will give you
another 0.7% slowdown give or take a little bit but this is negligible.
The folks in ##electronics on Freenode seemed to be under the impression
that 25 cycle cache miss penalties indicate a "crippled" CPU and that
this thing is "dumpster-bait." I'm no EE so I'll have to go with what
they came up with.
Point being, we should look at moving to a new CPU in the next revision,
if possible. Another choice is to try to get AMD to redesign the memory
controller to find some L2 somewhere at only a few cycles per cache miss;
but this is probably not really feasible (modify the hardware? Uh..).
I've had thoughts along this vein but I'm not an EE, and they're already
splattered on the mailing list so I'll spare you.
[''Adjust the L2 level in cache grind and check out the miss rate to
figure out how much L2 would be good. As indicated on the mailing list,
I favor siphoning a little from RAM and making it BIOS adjustable...'']
The point is, this kind of performance hit isn't going to be fixed by
software; you CAN make improvements, but they'll be on orders of much
lower magnitude. Taking a cup of water out of a swimming pool for
example....
New description:
The first revision of machines is going to be based on the Geode GX.
Reviewing its data sheet, there are a few numbers that need attention:
* Memory controller on the CPU[[BR]]
* 32KiB L1 cache[[BR]]
** 16KiB I1[[BR]]
** 16KiB D1[[BR]]
** 4-way Set Associative[[BR]]
** 1 Cycle Cache hits[[BR]]
** 2 Cycle Cache hits if not using the same way[[BR]]
** '''25 Cycle''' Cache misses (give or take a few depending on the exact
conditions)[[BR]]
* No L2 Cache[[BR]]
* 80-Entry TLB[[BR]]
** 8 L1 ITLB[[BR]]
** 8 L1 DTLB[[BR]]
** 64 L2 TLB[[BR]]
To simulate cache, you can use the following cachegrind line:
''valgrind --tool=cachegrind --I1=16384,4,32 --D1=16384,4,32
--L2=64,2,32 [program]''
Ignore L2, it doesn't exist on the Geode GX. Cachegrind demands it be set
valid.
A simulation of Rhythmbox shows a 1.2% overall cache miss rate. Multiply
this by 25 cycles and that's a 33.2% slowdown; multitasking will give you
another 0.7% slowdown give or take a little bit but this is negligible.
The folks in ##electronics on Freenode seemed to be under the impression
that 25 cycle cache miss penalties indicate a "crippled" CPU and that this
thing is "dumpster-bait." I'm no EE so I'll have to go with what they
came up with.
Point being, we should look at moving to a new CPU in the next revision,
if possible. Another choice is to try to get AMD to redesign the memory
controller to find some L2 somewhere at only a few cycles per cache miss;
but this is probably not really feasible (modify the hardware? Uh..).
I've had thoughts along this vein but I'm not an EE, and they're already
splattered on the mailing list so I'll spare you.
[''Adjust the L2 level in cache grind and check out the miss rate to
figure out how much L2 would be good. As indicated on the mailing list, I
favor siphoning a little from RAM and making it BIOS adjustable...'']
The point is, this kind of performance hit isn't going to be fixed by
software; you CAN make improvements, but they'll be on orders of much
lower magnitude. Taking a cup of water out of a swimming pool for
example....
--
Ticket URL: <http://dev.laptop.org/ticket/125#comment:1>
One Laptop Per Child <http://laptop.org/>
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
