Why "Limiting Factors Theory" is so important for OLPC devel. (Re: [Trac #125] Geode GX is a poor CPU choice
supat at supat.eu.org
supat at supat.eu.org
Mon Sep 25 23:24:27 EDT 2006
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, supat at supat.eu.org 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
>> Devel at laptop.org
>> http://mailman.laptop.org/mailman/listinfo/devel
>>
>
More information about the Devel
mailing list