@wegster

Quote:
Are these posted somewhere?



Yes here

Didn't find XE results performed with ramspeed ...

Here:

G3-SE 750 CXe 666/133 , 32 kb L1, 256 kb L2, 512 MB Kingston reg. ECC CL3

2.OS4:> ramspeed -b1
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

INTEGER & WRITING 1 Kb block: 2409.41 Mb/s
INTEGER & WRITING 2 Kb block: 2409.41 Mb/s
INTEGER & WRITING 4 Kb block: 2438.10 Mb/s
INTEGER & WRITING 8 Kb block: 2409.41 Mb/s
INTEGER & WRITING 16 Kb block: 2438.10 Mb/s
INTEGER & WRITING 32 Kb block: 2409.41 Mb/s
INTEGER & WRITING 64 Kb block: 1137.78 Mb/s
INTEGER & WRITING 128 Kb block: 1137.78 Mb/s
INTEGER & WRITING 256 Kb block: 1083.60 Mb/s
INTEGER & WRITING 512 Kb block: 119.70 Mb/s
INTEGER & WRITING 1024 Kb block: 119.28 Mb/s
INTEGER & WRITING 2048 Kb block: 119.50 Mb/s
INTEGER & WRITING 4096 Kb block: 119.21 Mb/s
INTEGER & WRITING 8192 Kb block: 119.28 Mb/s
INTEGER & WRITING 16384 Kb block: 119.21 Mb/s


2.OS4:> ramspeed -b2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

INTEGER & READING 1 Kb block: 2438.10 Mb/s
INTEGER & READING 2 Kb block: 2438.10 Mb/s
INTEGER & READING 4 Kb block: 2467.47 Mb/s
INTEGER & READING 8 Kb block: 2467.47 Mb/s
INTEGER & READING 16 Kb block: 2467.47 Mb/s
INTEGER & READING 32 Kb block: 2438.10 Mb/s
INTEGER & READING 64 Kb block: 1219.05 Mb/s
INTEGER & READING 128 Kb block: 1211.83 Mb/s
INTEGER & READING 256 Kb block: 1170.29 Mb/s
INTEGER & READING 512 Kb block: 196.73 Mb/s
INTEGER & READING 1024 Kb block: 195.05 Mb/s
INTEGER & READING 2048 Kb block: 195.23 Mb/s
INTEGER & READING 4096 Kb block: 195.23 Mb/s
INTEGER & READING 8192 Kb block: 195.94 Mb/s
INTEGER & READING 16384 Kb block: 194.86 Mb/s

2.OS4:> ramspeed -b4
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT & WRITING 1 Kb block: 4654.55 Mb/s
FL-POINT & WRITING 2 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 4 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 8 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 16 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 32 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 64 Kb block: 1393.20 Mb/s
FL-POINT & WRITING 128 Kb block: 1374.50 Mb/s
FL-POINT & WRITING 256 Kb block: 1321.29 Mb/s
FL-POINT & WRITING 512 Kb block: 121.47 Mb/s
FL-POINT & WRITING 1024 Kb block: 120.90 Mb/s
FL-POINT & WRITING 2048 Kb block: 120.90 Mb/s
FL-POINT & WRITING 4096 Kb block: 120.90 Mb/s
FL-POINT & WRITING 8192 Kb block: 120.97 Mb/s
FL-POINT & WRITING 16384 Kb block: 120.90 Mb/s


2.OS4:> ramspeed -b5
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT & READING 1 Kb block: 4762.79 Mb/s
FL-POINT & READING 2 Kb block: 4876.19 Mb/s
FL-POINT & READING 4 Kb block: 4876.19 Mb/s
FL-POINT & READING 8 Kb block: 4876.19 Mb/s
FL-POINT & READING 16 Kb block: 4876.19 Mb/s
FL-POINT & READING 32 Kb block: 4762.79 Mb/s
FL-POINT & READING 64 Kb block: 1505.88 Mb/s
FL-POINT & READING 128 Kb block: 1505.88 Mb/s
FL-POINT & READING 256 Kb block: 1442.25 Mb/s
FL-POINT & READING 512 Kb block: 206.87 Mb/s
FL-POINT & READING 1024 Kb block: 205.01 Mb/s
FL-POINT & READING 2048 Kb block: 205.21 Mb/s
FL-POINT & READING 4096 Kb block: 205.01 Mb/s
FL-POINT & READING 8192 Kb block: 205.21 Mb/s
FL-POINT & READING 16384 Kb block: 205.21 Mb/s


2.OS4:> ramspeed -b3
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

INTEGER Copy: 129.05 Mb/s
INTEGER Scale: 128.72 Mb/s
INTEGER Add: 131.56 Mb/s
INTEGER Triad: 137.05 Mb/s
---
INTEGER AVERAGE: 131.60 Mb/s

2.OS4:> ramspeed -b6
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT Copy: 141.34 Mb/s
FL-POINT Scale: 140.76 Mb/s
FL-POINT Add: 144.26 Mb/s
FL-POINT Triad: 144.16 Mb/s
---
FL-POINT AVERAGE: 142.63 Mb/s




Next is performed with SetA1 tool:


G3-SE 750 CXe 666/133 , 512 MB Kingston reg. ECC CL3 , same machine as previous


seta1 configured as below

5.OS4:> seta1 RAS2CAS=2 R2A=1 FASTMEM
SetA1 hardware config utility for AmigaOne SE/XE/Micro
Version 0.23 alpha, copyright 2005 Gary Colville
======================================================

Switching Refresh-to-Active delay to 1 clks
Switching RAS-to-CAS delay to 2 clks
Setting fast memory timings



And then tests, this time I added -m2 switch to save time ... I know that it is generally bad idea to remove or add switches during tests, but this -m2 switch don't make any difference to performance, just cut test with 4096 MB and above away.

2.OS4:> ramspeed -b1 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

INTEGER & WRITING 1 Kb block: 2409.41 Mb/s
INTEGER & WRITING 2 Kb block: 2409.41 Mb/s
INTEGER & WRITING 4 Kb block: 2438.10 Mb/s
INTEGER & WRITING 8 Kb block: 2438.10 Mb/s
INTEGER & WRITING 16 Kb block: 2409.41 Mb/s
INTEGER & WRITING 32 Kb block: 2409.41 Mb/s
INTEGER & WRITING 64 Kb block: 1144.13 Mb/s
INTEGER & WRITING 128 Kb block: 1137.78 Mb/s
INTEGER & WRITING 256 Kb block: 1101.08 Mb/s
INTEGER & WRITING 512 Kb block: 136.62 Mb/s
INTEGER & WRITING 1024 Kb block: 136.08 Mb/s
INTEGER & WRITING 2048 Kb block: 136.08 Mb/s


2.OS4:> ramspeed -b2 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

INTEGER & READING 1 Kb block: 2438.10 Mb/s
INTEGER & READING 2 Kb block: 2467.47 Mb/s
INTEGER & READING 4 Kb block: 2467.47 Mb/s
INTEGER & READING 8 Kb block: 2467.47 Mb/s
INTEGER & READING 16 Kb block: 2467.47 Mb/s
INTEGER & READING 32 Kb block: 2438.10 Mb/s
INTEGER & READING 64 Kb block: 1219.05 Mb/s
INTEGER & READING 128 Kb block: 1219.05 Mb/s
INTEGER & READING 256 Kb block: 1183.82 Mb/s
INTEGER & READING 512 Kb block: 246.45 Mb/s
INTEGER & READING 1024 Kb block: 243.81 Mb/s
INTEGER & READING 2048 Kb block: 243.81 Mb/s


2.OS4:> ramspeed -b4 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT & WRITING 1 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 2 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 4 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 8 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 16 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 32 Kb block: 4762.79 Mb/s
FL-POINT & WRITING 64 Kb block: 1383.78 Mb/s
FL-POINT & WRITING 128 Kb block: 1383.78 Mb/s
FL-POINT & WRITING 256 Kb block: 1338.56 Mb/s
FL-POINT & WRITING 512 Kb block: 138.66 Mb/s
FL-POINT & WRITING 1024 Kb block: 138.19 Mb/s
FL-POINT & WRITING 2048 Kb block: 138.19 Mb/s


2.OS4:> ramspeed -b5 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT & READING 1 Kb block: 4876.19 Mb/s
FL-POINT & READING 2 Kb block: 4876.19 Mb/s
FL-POINT & READING 4 Kb block: 4995.12 Mb/s
FL-POINT & READING 8 Kb block: 4995.12 Mb/s
FL-POINT & READING 16 Kb block: 4876.19 Mb/s
FL-POINT & READING 32 Kb block: 4876.19 Mb/s
FL-POINT & READING 64 Kb block: 1505.88 Mb/s
FL-POINT & READING 128 Kb block: 1505.88 Mb/s
FL-POINT & READING 256 Kb block: 1473.38 Mb/s
FL-POINT & READING 512 Kb block: 262.90 Mb/s
FL-POINT & READING 1024 Kb block: 259.90 Mb/s
FL-POINT & READING 2048 Kb block: 259.57 Mb/s


2.OS4:> ramspeed -b3 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

INTEGER Copy: 143.57 Mb/s
INTEGER Scale: 142.82 Mb/s
INTEGER Add: 143.75 Mb/s
INTEGER Triad: 152.15 Mb/s
---
INTEGER AVERAGE: 145.57 Mb/s

2.OS4:> ramspeed -b6 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT Copy: 161.83 Mb/s
FL-POINT Scale: 161.01 Mb/s
FL-POINT Add: 162.75 Mb/s
FL-POINT Triad: 162.75 Mb/s
---
FL-POINT AVERAGE: 162.09 Mb/s



Next uA1, results are bit incomplete.

uA1 750GX v1.1 800/133 32kb L1, 1024 kb L2, memory module unknown.

3.RAM Disk:>RAMSPEED -b1 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04


4Gb per pass mode


INTEGER & WRITING 1 Kb block: 2925.71 Mb/s
INTEGER & WRITING 2 Kb block: 2925.71 Mb/s
INTEGER & WRITING 4 Kb block: 2925.71 Mb/s
INTEGER & WRITING 8 Kb block: 2968.12 Mb/s
INTEGER & WRITING 16 Kb block: 2968.12 Mb/s
INTEGER & WRITING 32 Kb block: 2968.12 Mb/s
INTEGER & WRITING 64 Kb block: 1473.38 Mb/s
INTEGER & WRITING 128 Kb block: 1484.06 Mb/s
INTEGER & WRITING 256 Kb block: 1484.06 Mb/s
INTEGER & WRITING 512 Kb block: 1473.38 Mb/s
INTEGER & WRITING 1024 Kb block: 161.64 Mb/s
INTEGER & WRITING 2048 Kb block: 123.37 Mb/s

3.RAM Disk:>RAMSPEED -b2 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04


4Gb per pass mode


INTEGER & READING 1 Kb block: 2968.12 Mb/s
INTEGER & READING 2 Kb block: 2968.12 Mb/s
INTEGER & READING 4 Kb block: 3011.76 Mb/s
INTEGER & READING 8 Kb block: 2968.12 Mb/s
INTEGER & READING 16 Kb block: 3011.76 Mb/s
INTEGER & READING 32 Kb block: 2968.12 Mb/s
INTEGER & READING 64 Kb block: 1575.38 Mb/s
INTEGER & READING 128 Kb block: 1587.60 Mb/s
INTEGER & READING 256 Kb block: 1575.38 Mb/s
INTEGER & READING 512 Kb block: 1587.60 Mb/s
INTEGER & READING 1024 Kb block: 1039.59 Mb/s
INTEGER & READING 2048 Kb block: 199.03 Mb/s


3.RAM Disk:>RAMSPEED -b4 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT & WRITING 1 Kb block: 5688.89 Mb/s
FL-POINT & WRITING 2 Kb block: 5851.43 Mb/s
FL-POINT & WRITING 4 Kb block: 5688.89 Mb/s
FL-POINT & WRITING 8 Kb block: 5851.43 Mb/s
FL-POINT & WRITING 16 Kb block: 5851.43 Mb/s
FL-POINT & WRITING 32 Kb block: 5688.89 Mb/s
FL-POINT & WRITING 64 Kb block: 1932.08 Mb/s
FL-POINT & WRITING 128 Kb block: 1914.02 Mb/s
FL-POINT & WRITING 256 Kb block: 1932.08 Mb/s
FL-POINT & WRITING 512 Kb block: 1914.02 Mb/s
FL-POINT & WRITING 1024 Kb block: 1008.87 Mb/s
FL-POINT & WRITING 2048 Kb block: 124.80 Mb/s


3.RAM Disk:>RAMSPEED -b5 -m2
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT & READING 1 Kb block: 5851.43 Mb/s
FL-POINT & READING 2 Kb block: 5851.43 Mb/s
FL-POINT & READING 4 Kb block: 6023.53 Mb/s
FL-POINT & READING 8 Kb block: 6023.53 Mb/s
FL-POINT & READING 16 Kb block: 6023.53 Mb/s
FL-POINT & READING 32 Kb block: 5851.43 Mb/s
FL-POINT & READING 64 Kb block: 2155.79 Mb/s
FL-POINT & READING 128 Kb block: 2155.79 Mb/s
FL-POINT & READING 256 Kb block: 2155.79 Mb/s
FL-POINT & READING 512 Kb block: 2155.79 Mb/s
FL-POINT & READING 1024 Kb block: 1248.78 Mb/s
FL-POINT & READING 2048 Kb block: 199.03 Mb/s

@mlehto

So....hmm. Lookin at the use of that tool, this looks like uBoot is artificially limiting the RAM speed to slow down timings....is that true? (anyone?)

_________________
Are we not done with the same silly arguments and flames yet??!

@wegster

Quote:
BTW, bear in mind it depends on what is being tested as far as results 'should or shouldn't be' similar. In this case, we're seeing some effect of the cache speeds, as well as the cache size, plus the effeciency (or lack thereof) of the memory controller.


It could be memory controller, or beta thingy. With my all respect to OS4 team, uboot should be incomplete in it's current state. This is totally my own idea ...


Quote:
I'd fully expect an XE and uA1 with the same CPU to run similar results...what is/was a surprise is the current uA1-C runs on the write side, which may be a result of the OS not optimizing the size of writes (IOW, not knowing the CPU has a 1M L2 cache), or of the compiler.




Something same came to my mind. Look uA1 results:

INTEGER & WRITING 512 Kb block: 1473.38 Mb/s
INTEGER & WRITING 1024 Kb block: 161.64 Mb/s
INTEGER & WRITING 2048 Kb block: 123.37 Mb/s

INTEGER & READING 512 Kb block: 1587.60 Mb/s
INTEGER & READING 1024 Kb block: 1039.59 Mb/s
INTEGER & READING 2048 Kb block: 199.03 Mb/s

FL-POINT & WRITING 512 Kb block: 1914.02 Mb/s
FL-POINT & WRITING 1024 Kb block: 1008.87 Mb/s
FL-POINT & WRITING 2048 Kb block: 124.80 Mb/s

FL-POINT & READING 512 Kb block: 2155.79 Mb/s
FL-POINT & READING 1024 Kb block: 1248.78 Mb/s
FL-POINT & READING 2048 Kb block: 199.03 Mb/s


So all operations drops down after 512 kt, sw can use L2 properly in 512 kt, but not any more in 1024 mb.

So sw is most likely compiled without proper cpu-switch. Not surprise, because it is older than uA1. Or do you have some other ideas ??


Overall performance is not optimal. Alltought it is imposibble to make direct comparisons between different OS'es, but something they tell...

As I'm seen my own eyes 650 MB/s performance from XE, so it is clear (at least for me...), that ArticiaS can perform quite well in SOME conditions.

Anyone don't tell much, is there been improved ArticiaS circuits or not. So this is more or less shooting in dark. At least XE's has "fixed" ArticiaS, whatever it is.

Do you know ... I start to get bad bad headache


Quote:
Not really, see above. If we were doing a purely computational test, or a 'combined' test using CPU as well as IO, then I'd expect to see (more) differences....


Yeah, this is something, wich worries me a bit. This test seems to test CPU performance at same time, than memory speed. It does make me anything but happy.

I dig some other linux related memspeed tests, but wasn't cabable to compile them, since they use some specific memory.h thingy, wich is nothing standard ANCI C.

Hmh ... quoting, I use IB and it is not cabable to use javascript, wich is needed to proper quoting in here :-|

@wegster

Quote:
So....hmm. Lookin at the use of that tool, this looks like uBoot is artificially limiting the RAM speed to slow down timings....is that true? (anyone?)



It should be true. Maybe because Articia is bit picky with different memory sticks.

And There is nothing in uboot, what you can use to adjust memory timings. So there is some relativelly basic primitive settings, for compatibility in mind, I suppose (??)

Hope that DrBombCrater publish next version soon

@mlehto

Quote:

Something same came to my mind. Look uA1 results: INTEGER & WRITING 512 Kb block: 1473.38 Mb/s INTEGER & WRITING 1024 Kb block: 161.64 Mb/s INTEGER & WRITING 2048 Kb block: 123.37 Mb/s INTEGER & READING 512 Kb block: 1587.60 Mb/s INTEGER & READING 1024 Kb block: 1039.59 Mb/s INTEGER & READING 2048 Kb block: 199.03 Mb/s FL-POINT & WRITING 512 Kb block: 1914.02 Mb/s FL-POINT & WRITING 1024 Kb block: 1008.87 Mb/s FL-POINT & WRITING 2048 Kb block: 124.80 Mb/s FL-POINT & READING 512 Kb block: 2155.79 Mb/s FL-POINT & READING 1024 Kb block: 1248.78 Mb/s FL-POINT & READING 2048 Kb block: 199.03 Mb/s So all operations drops down after 512 kt, sw can use L2 properly in 512 kt, but not any more in 1024 mb. So sw is most likely compiled without proper cpu-switch. Not surprise, because it is older than uA1. Or do you have some other ideas ??

No, that's exactly what I think is happening, in which case I'd love to see a beta-testers results, or at least confirmation that they do in fact stay in cache for writes and see improved numbers at the 1024K block writes. (dunno what beta NDA entails, but would expect ok to say 'seeing same thing currently, or seeing higher numbers')

The other disturbing part here really is in the fact that uBoot is limiting RAM speeds. I'm guessing this is a by-product of initial release, when it was discovered the A1s were particularly 'picky' about RAM, but I'm hoping this isn't hiding _another_ chipset/A1 issue. I would _really_ like to see DrBombCrater's thoughts on this one, or of course, one of the Freidens. Maybe this 'fact' is known, but I didn't see it until you posted your settings from the SetA1 tool, and now it makes more sense.

_________________
Are we not done with the same silly arguments and flames yet??!

@wegster

Quote:
No, that's exactly what I think is happening, in which case I'd love to see a beta-testers results, or at least confirmation that they do in fact stay in cache for writes and see improved numbers at the 1024K block writes. (dunno what beta NDA entails, but would expect ok to say 'seeing same thing currently, or seeing higher numbers')


Ok, you now it better than me.


Quote:
The other disturbing part here really is in the fact that uBoot is limiting RAM speeds. I'm guessing this is a by-product of initial release, when it was discovered the A1s were particularly 'picky' about RAM, but I'm hoping this isn't hiding _another_ chipset/A1 issue. I would _really_ like to see DrBombCrater's thoughts on this one, or of course, one of the Freidens. Maybe this 'fact' is known, but I didn't see it until you posted your settings from the SetA1 tool, and now it makes more sense.


There is most likely improved ArticiaS around, because friend of mine gets significally better results with his XE. Ok. it is G4, but anyway.

So it should be nice to get info from Frieden brothers. Anyway DrBombCrater has old SE ...

If it is uboot, wich is not entirely completed yet, it is good news anyway If it is yet another Articia-issue ...

It is mostly pointless to refer any P1 / P1+april experience, since they are relativelly old. In case there is improved Articia ... you got a point

Last edited by mlehto on 06-Mar-2005 at 02:07 AM.
Last edited by mlehto on 06-Mar-2005 at 02:06 AM.

@wegster

Check your mail.

@wegster

Huh ... my posts start to shatter.

Yes, OS4 is not compiled/ported entirely to GX. GX was surprise to OS4 team, as @Rogue said elsewhere.

@mlehto

Quote:

So all operations drops down after 512 kt, sw can use L2 properly in 512 kt, but not any more in 1024 mb. So sw is most likely compiled without proper cpu-switch. Not surprise, because it is older than uA1. Or do you have some other ideas ??

Some of the cache is taken up by the code of the benchmark, background precesses, kernel stuff, etc, so a 1MB cache cannot fully hold ramspeed's 1MB blocks. That's why you see a drop-off between 512K and 1MB, because 512K can fit completely in the cache and 1MB can't. This is normal and you'll see it on benchmarks on any platform.

@wegster
Quote:

The other disturbing part here really is in the fact that uBoot is limiting RAM speeds. I'm guessing this is a by-product of initial release, when it was discovered the A1s were particularly 'picky' about RAM, but I'm hoping this isn't hiding _another_ chipset/A1 issue. I would _really_ like to see DrBombCrater's thoughts on this one, or of course, one of the Freidens. Maybe this 'fact' is known, but I didn't see it until you posted your settings from the SetA1 tool, and now it makes more sense.

The goal of any firmware writer is to set the system up so it will work under the widest range of circumstances. That usually means playing it very safe, which is exactly what the Friedens have done. This leaves a gap between the default settings and what your own hardware can do, and SetA1 exploits that gap.

As for hiding chipset issues, well, there's probably a certain amount of truth in that. The Articia's memory controller is fairly naff, so the timings U-Boot has to use to ensure stability will be slower than they could be on a chipset with a well designed memory controller.

But memory speed isn't all that critical to overall system performance, so I wouldn't bother about it too much.

_________________
Who do you serve, and who do you trust? - Galen

@DrBombcrater

Thanks for the response. Your comments RE: cache are exactly the reason I'd like to see a test being done with the cache disabled, to simply test the hardware, in this case the Articia.

Different apps obviously have different needs, which is why benchmark writers and people using them argue forever about the usefulness of almost any benchmark...but each plays it's part in the overall system. For example, image and video editing would certainly benefit from faster RAM speeds, while for opening a system shell and running a few DOS commands, it's just not relevant.

Anyways, this primarily meant to be the start of 'seeing what there is to see,' with information from elsewhere, at least that I've seen so far, lacking...or of course, me being unable to find it

_________________
Are we not done with the same silly arguments and flames yet??!

@DrBombcrater

Your comments were welcome :)

@mlehto

Quote:

There is most likely improved ArticiaS around, because friend of mine gets significally better results with his XE. Ok. it is G4, but anyway. So it should be nice to get info from Frieden brothers. Anyway DrBombCrater has old SE ... If it is uboot, wich is not entirely completed yet, it is good news anyway If it is yet another Articia-issue ... It is mostly pointless to refer any P1 / P1+april experience, since they are relativelly old. In case there is improved Articia ... you got a point

Well, I dunno if I believe that or not (improved Articia). It's possible that the G4s cache simply is much faster, plus AOS4 isn't optomized for either the FX or GX CPUs at this point.

I'd still like to see a Peg 1/Peg w/April fix for comparison.

I also wonder if there are plans in future to allow uBoot to have a setting for 'safe' or actual 'performance' settings. As it is, I've seen a good jump in ramspeed benchmarks on my XE with DrBC's tool, but the problem is it goes away at reboot, and as a binary only, can be certainly added to a startup script, but what of Linux on the same system?

IOW, it would be ideal to have a toggle in uBoot to initialize the RAM settings...obviously with a disclaimer, as DrBC is right- the A1s seem to be picky enough about RAM, so it looks like uBoot is 'playing it safe' to avoid problems with some RAM combinations, which is better for most users.

It may wind up making sense to check out the uBoot code, as I believe that's open source...I'm assuming Hyperion is contributing their changes back?

Will post improved #s in a bit, still playing/re-running tests a bit, along with a single post complete summary.

_________________
Are we not done with the same silly arguments and flames yet??!

Quote:

wegster wrote: @rinaldo00 Hmm, that's interesting. Obviously a 1024Kb block won't fit entirely in your cache, but most of it will, so I'd expect the numbers going from 512k to 1Mb blocks to be closer than this: FL-POINT & READING 512 Kb block: 2155.79 Mb/s FL-POINT & READING 1024 Kb block: 447.16 Mb/s But it looks like the other uA1-C does the same. Numbers from my 'hardware fixed' A1XE-G4 933MHz, CPU 7455 (256k L2 cache):

Hi wegster,

If the cache is 1 MegByte, and the data block is one MegByte, doesn't that make the cache totally full, and therefore, the computer code that is running the test, is FORCED to use some of the cache ram, to retrieve computer code from sdram, that is running the test??? Who writes this stuff??


Also, are Kb == Kilobits, and Mb/s == Megabits per second?

@Atheist

Quote:

Also, are Kb == Kilobits, and Mb/s == Megabits per second?

They should be, but in this case the coder has written Kb and Mb when he really means KB and MB.

_________________
Who do you serve, and who do you trust? - Galen

@Atheist

Quote:

Atheist wrote: Quote: wegster wrote: @rinaldo00 Hmm, that's interesting. Obviously a 1024Kb block won't fit entirely in your cache, but most of it will, so I'd expect the numbers going from 512k to 1Mb blocks to be closer than this: FL-POINT & READING 512 Kb block: 2155.79 Mb/s FL-POINT & READING 1024 Kb block: 447.16 Mb/s But it looks like the other uA1-C does the same. Numbers from my 'hardware fixed' A1XE-G4 933MHz, CPU 7455 (256k L2 cache): Hi wegster, If the cache is 1 MegByte, and the data block is one MegByte, doesn't that make the cache totally full, and therefore, the computer code that is running the test, is FORCED to use some of the cache ram, to retrieve computer code from sdram, that is running the test??? Who writes this stuff?? Also, are Kb == Kilobits, and Mb/s == Megabits per second?

yes, Kb here = KB.

DrBC gave a good explanation of affects of cache on results here, and I thought I gave one in here somewhere as well. You _will_ have some overhead in running tasks, even in just the core OS, to some extent, so that the 'full' < whatever size your cache is > will never be 100% available for a 'data block' to be written to it, which is why the 'crossover point' as shown in the full data...ie on a 256KB(yte) L2 cache, a 128KB block is very fast, the 256KB block is 'pretty fast, but slower', the 512KB block is much slower but still higher than larger blocks, as still a good chunk of it is going into cache...and then the rest of the (larger) results are pretty similar to one another.

_________________
Are we not done with the same silly arguments and flames yet??!

@wegster

Quote:

I'd still like to see a Peg 1/Peg w/April fix for comparison.

As far as I know April has no impact on the memory bus, so results from the Peg1 will be little different from an A1 in the same configuration. The Peg's firmware may be more or less aggressive at setting timings than U-Boot, but that can be replicated on the A1 by re-configuring the memory controller.

Of course, a Peg1 should be considerably slower than even an A1-SE simply because that board runs at 100MHz. Not just memory speed, either. The 750CXe hates running on a 100MHz bus. I did some tests on my SE using Quake and got slightly better scores at 600/133MHz than at 700/100MHz

Quote:

It may wind up making sense to check out the uBoot code, as I believe that's open source...I'm assuming Hyperion is contributing their changes back?

I believe the A1 version of U-Boot has some non-GPL additions that act as a key to stop people running OS4 on other systems (such as a Peg1 flashed with U-Boot). That was the original plan, anyway. So if you compile a custom version of U-Boot and flash it in, OS4 won't boot.
Not that I fancy the idea of flashing in my own firmware

_________________
Who do you serve, and who do you trust? - Galen

@wegster

Quote:

DrBC gave a good explanation of affects of cache on results here, and I thought I gave one in here somewhere as well. You _will_ have some overhead in running tasks, even in just the core OS, to some extent, so that the 'full' < whatever size your cache is > will never be 100% available for a 'data block' to be written to it, which is why the 'crossover point' as shown in the full data...ie on a 256KB(yte) L2 cache, a 128KB block is very fast, the 256KB block is 'pretty fast, but slower', the 512KB block is much slower but still higher than larger blocks, as still a good chunk of it is going into cache...and then the rest of the (larger) results are pretty similar to one another.

Caches don't work like this, if you are reading a block of data from RAM you will only get a small portion of it held in the cache.

The cache divides it's address range into (large) blocks and each can hold an amount of data on the 7447A its 512 Bytes per block (note: *not* KBytes).

Whats happening in these tests is a portion of the data is getting held in the cache and as the reading block size increases the ratio of memory to cache is remaining constant. If you notice in the previous tests minimum block size is 1KByte - this is to big to fit in a specific portion of the G4's L2 cache so it's never actually working directly out of the cache (my previous explantion was wrong). What it's really measuring is the ability of the CPUs mechanisims to hide memory access for a given block size.

I modified my memory test to specifically test the cache, it reads a block of RAM in 64 byte chunks (8 doubles). For each iteration the block size increases but it's still read in 64 bytes at a time:

The first 4 lines are completely inside the L1/L2 cache. The G4 is capable of much higher transfer rates direct from cache (something close to 40GB / Second from L2) but these are not showing because the computations in the inner loop are taking too long to get an accurate reading - it's difficult to see if getting an accurate measure would be possible in C.

Reading 6472.60 MB/Second, 6.33 seconds, 40960 MB read, 64 Bytes
Reading 7790.24 MB/Second, 5.26 seconds, 40960 MB read, 128 Bytes
Reading 8603.42 MB/Second, 4.76 seconds, 40960 MB read, 256 Bytes
Reading 9197.84 MB/Second, 4.45 seconds, 40960 MB read, 512 Bytes
Reading 9382.69 MB/Second, 4.37 seconds, 40960 MB read, 1024 Bytes
Reading 9571.57 MB/Second, 4.28 seconds, 40960 MB read, 2048 Bytes
Reading 9610.15 MB/Second, 4.26 seconds, 40960 MB read, 4096 Bytes
Reading 9718.03 MB/Second, 4.21 seconds, 40960 MB read, 8192 Bytes
Reading 9658.86 MB/Second, 4.24 seconds, 40960 MB read, 16384 Bytes
Reading 9639.80 MB/Second, 4.25 seconds, 40960 MB read, 32768 Bytes
Reading 2997.90 MB/Second, 13.66 seconds, 40960 MB read, 65536 Bytes
Reading 2973.54 MB/Second, 13.77 seconds, 40960 MB read, 131072 Bytes
Reading 2916.34 MB/Second, 14.04 seconds, 40960 MB read, 262144 Bytes
Reading 1018.36 MB/Second, 40.22 seconds, 40960 MB read, 524288 Bytes
Reading 422.20 MB/Second, 97.02 seconds, 40960 MB read, 1048576 Bytes
Reading 364.34 MB/Second, 112.42 seconds, 40960 MB read, 2097152 Bytes
Reading 360.63 MB/Second, 113.58 seconds, 40960 MB read, 4194304 Bytes
Reading 360.51 MB/Second, 113.62 seconds, 40960 MB read, 8388608 Bytes

Performance is constant up to 32 KBytes, after this it falls by 2/3 until 256 KBytes after which then performance rolls off rapidly until the cache has little if any effect.


So, developers should keep their working set to under 32KB if you want real speed and 256KB if you can't get away with 32KB. If you're real 133t however, hack into the kernel and use the locking cache functionality (available on some G3s / G4s).

_________________
Whyzzat?

@minator

Quote:

Caches don't work like this, if you are reading a block of data from RAM you will only get a small portion of it held in the cache.

It's a simplification, but a fairly accurate one. When you are simply pulling data out of memory in a linear fashion the exact arrangement and mapping of the cache is almost irrelevant.

Quote:

So, developers should keep their working set to under 32KB if you want real speed and 256KB if you can't get away with 32KB.

Developers should ignore such concerns as much as possible because you don't know what kind of environment your code will be executing in. Targetting 256K as a maximum working set, for example, would work well on a 750FX or G4 with 512K L2, but cause a performance hit on a 256K G4 or 750CXe.

_________________
Who do you serve, and who do you trust? - Galen