Release CPU stress test

[foft]

Like the new version - can not set the max to stop it crashing. Since it was crashing on the old version at 1246MHz I've started it at 1245MHz and... so far so good!


So that gives:


i) 1GHz no 1: 1166MHz (overnight)


ii) 1GHz no 2: 1245MHz (15 mins in... will edit to update in an hour)


Shame the keyboard doesn't work properly on (ii)!

No (ii) crashed as 1245MHz and 1244MHz. Running fine at 1240MHz with no errors. Think for this one neon fails higher than the rest.

 

[FaeMinx]

I've now thoroughly tested every OPP level.


My complete results (CC 256mb):


821Mhz @ OPP3


897Mhz @ OPP4


968Mhz @ OPP5


That's a 76Mhz then 71Mhz increase between OPP levels.

Spoiler

So, just to round things down and for that extra smidgen of stability (even though the above levels have proven stable with many hours under the belt at each OPP) when I overclock in the future for neon apps, these will be my settings:


820Mhz @ OPP3


895Mhz @ OPP4


965Mhz @ OPP5


Giving me a 75Mhz then 70Mhz increase between OPP levels respectively.

I'm keen to do similar tests to determine maximum overclock for non-neon applications. Hopefully someone will be able to create such a stress test. Till then, I'm done!


Hooray! :lol:

 

[_wb_]

Updating the aggregated info:


- original (CC) Pandora @ OPP3: 778 (onpon4), 821 (FaeMinx), 897@OPP4 (FaeMinx)


- Rebirth (GC) Pandora @ OPP3: 789 (B-ZaR), 825 (graupelschauer), 853 (_wb_), 862 (stardroid)


Preliminary conclusion: CC model goes to ~800MHz on average at normal OPP3, GC model goes to ~832MHz on average. Warning: this is based on few data points.


- original (CC) Pandora @ OPP5: 917 (notaz), 928 (TrashyMG), 932 (Linux-SWAT), 946 (Googer), 954 (Fahrstuhl), 954 (PokeParadox), 967 (Takedown), 968 (FaeMinx), 969 (ZXDunny), 973 (Budweiser), 975 (m1ch3l), 977 (meandu229), ~978 (BaDToaD), 1006 (Ian J)


- Rebirth (GC) Pandora @ OPP5: 947 (B-ZaR), 955 (Gausen), 956 (apersonthinks), 985 or 989 (TrashyMG), 999 (_wb_), 1009 (lemondragon), ~1010 (Cyberworm), <1015 (Steven Craft), 1017 (Mosschops)


Preliminary conclusion: CC model goes to ~960MHz on average at OPP5 (14 data points), GC model goes to ~987MHz on average (9 data points)


- 1GHz Pandora @ max (OPP4): 1157 (Lafazar), 1166, ~1240 (foft), 1214 (kamui_kun), 1249 (notaz)


Preliminary conclusion: 1GHz model goes to ~1205MHz on average at max OPP.


Overall preliminary conclusions: 1GHz clocks about 220 MHz higher than Rebirth model, which clocks about 30 MHz higher than the original CC model. All 600MHz models can do 750 MHz at normal OPP3 and 900 MHz at OPP5.

 

[PokeParadox]

I have to update that I ran an overnight test and got 940MHz @ OPP5 on my CC256.

 

[A2000]

CC 256M Pandora: 963 @ OPP5


BTW Due to continuously charging overnight I had some strange effects with my battery and think it is up for a replacement now. Will explain that more thoroughly in the System Info thread.

 

[BaDToaD]

CC 256MB


I've just finshed 4 hours at OPP3 and ended up with a respectable 826Mhz

 

[_wb_]

Meh, tried to paste a table but it didn't work.

 

[McLovin]

CC@OPP5 -> 973 several hours stable and reproducable


Take that, GC

 

[notaz]

I'm keen to do similar tests to determine maximum overclock for non-neon applications. Hopefully someone will be able to create such a stress test. Till then, I'm done!

I'm afraid that might be too difficult to do without crashing the system. When only NEON misbehaves the system stability is hardly affected, as kernel never uses it (except saving/restoring it's context). When ARM misbehaves, there are lots of bad things that can happed, like pointer arithmetic going wrong and some critical data getting corrupted or just access of unmapped memory in privileged mode, all leading to kernel crash or some sort of deadlock. It could be possible to take control away from Linux, take over exception handlers, remap all memory and then run the test, but that's a lot of work just to try something that might not work anyway due to some other reason.

 

[_wb_]

Why does the kernel not use NEON?

 

[notaz]

For what tasks would you use it in kernel? There is no SIMDy work to do there. It could perhaps use it for memcpy, but it has been shown that kernel mostly deals with small blocks of data, so it's not really worth it. The kernel never uses float too. This also gives benefit of not having to save/restore NEON registers on syscalls/interrupts/whatever.

 

[_wb_]

Yes, I was thinking about memcpy, since that is 30% or so faster with NEON: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html


But you're probably right: it probably is not worth the overhead of having to save those registers all the time.

 

[meandu229]

After 19hours on 974 it found an error. Think that's good enough for me though


Sent from my Titan using Board Express

 

[ShleeDragon]

This stress testing tool is great. being able to set the CPU to default to an acceptable speed and jump to the max CPU in PCSX is excellent..


Cannot wait for the next PCSX update to take advantage of this

 

[Linux-SWAT]

Still at 932MHz.

 

[konqithedragon]

I've now thoroughly tested every OPP level.


My complete results (CC 256mb):


821Mhz @ OPP3


897Mhz @ OPP4


968Mhz @ OPP5


That's a 76Mhz then 71Mhz increase between OPP levels.

Spoiler

So, just to round things down and for that extra smidgen of stability (even though the above levels have proven stable with many hours under the belt at each OPP) when I overclock in the future for neon apps, these will be my settings:


820Mhz @ OPP3


895Mhz @ OPP4


965Mhz @ OPP5


Giving me a 75Mhz then 70Mhz increase between OPP levels respectively.

Spoiler

I'm keen to do similar tests to determine maximum overclock for non-neon applications. Hopefully someone will be able to create such a stress test. Till then, I'm done!


Hooray! :lol:

Redid mine for a 2nd time still got the same results


855MHz @ OPP3


933MHz @ OPP4


1009MHz @ OPP5


78MHz/76MHz difference.


So it seems that whatever your Max is at OPP3 you can get 140-160MHz more on OPP5

 

[klapse]

What is the official word on how such high speeds affect cpu life?

 

[_wb_]

At OPP3, the difference should be minimal. At OPP5, the lifetime will be reduced, but it remains unlikely that the cpu will be the first thing to fail. At least that's my understanding.


I myself use 600MHz @ OPP3 most of the time, mostly because I want to make sure that the things I make run smoothly at that clockspeed. I go higher, but still OPP3, whenever I need more horsepower (e.g. a big compile). I would use OPP5 in emulators if needed, but if it's nearly full speed at 800MHz, that's good enough for me - I can llive with a few dropped frames every now and then.

 

[Linux-SWAT]

I'll just add that you can run this test safely.

 

[notaz]

What is the official word on how such high speeds affect cpu life?

It's all in TI's documentation at http://www.ti.com/product/omap3530 .


TI guarantees 50000 hours if you run OPP5 nonstop, 100k if if you limit OPP5 to 23k hours.


Remember that if you run 3.2 kernel there is also idle power saving, where CPU is completely turned off while not in use, so it doesn't count while idle even if you have OPP5 set.