I've seen a number of people who either have their N900's not stable with a "stock" OC profile like ULV, LV or ideal.
The -proper- solution to this - and in fact, all OCing - is to test it at each voltage/speed combination, adjusting the voltage until its perfectly stable. This is done on Desktop chips, on your GPU... why not here?

I think its because it appears too long or too complex an issue to deal with. Loading a default setting's so much easier than crashing your N900 9-12 times getting the settings right.

What I propose is a simple shell script.
The user will set the max OC they want to have tested, and the script will get to work. It will:
1. Starting at 200mhz, lock to that frequency and stock/above stock voltage.
2. Play a 1-minute video via mplayer that takes the entire CPU and still drops frames(fully loaded).
3. Drops the voltage by 1, repeats the video.
4. Repeat step 3 until the system crashes.
5. On next boot, it will take the last - bad - value, up it by three. This will be a stable, minimal value, and should work fine. The script will then go onto the next voltage and repeat. *

By the end, this script should end up with a profile that's about as low as possible, while still stable.

Would anyone be interested in using this?
You can figure it would take a dozen reboots and an hour or so to find best, perfectly stable settings.

*Note: I intentionally left out some technical details in the script description. I know exactly how this would work, but I see no reason to do it if it won't be used.

-Rob

if it could be totally automated, hands off type of testing application, I would be happy to leave my N900 for a few hours on the the charger at night to let it go through all combinations. I'm currently using a modified Ideal profile with just a higher max frequency and I think I could go lower in voltages on quite a few frequencies. I tried it a few times manually but I gave up, too much hassle.

So yes, I would be trying it ! Just make sure there is a easy escape route, in case the script gets evil and keeps on running...

If you can do it, I would be happy to test it. My only concern is having to reflash, or it getting stuck in some sort of boot-loop impervious to being loaded in flashing mode. Reflash is fine, the other one, not so much. I agree with Netweaver's easy escape route suggestion.

I have also been thinkering on this... The only problem would be to test it's stability. A video is not enough.. but if you would find a way i am pretty sure it will be greatly apreciated.

One thing i am conserned about is the "dspbridge" problem that appears if you have barely enough voltpower to run the camera/mediaplayer. You will be able to take the picture but then the error appear and loops. It will deplete the battery faster but have no other negative impact. You could see it by doing an "dmesg" after trying to use the camera or mediaplayer. A normal user would never discover this.

Maybe finding out how much current/volt different task would need and then calculate a setting from that would be a "nicer" way of doing it?

I will be a proud guinea pig tester. Go for it!

It's very hard and time-consuming to do a reliable stability test. For example file system corruption - that sneaky bastard - might not show up until after days of normal use. There should be many different tests to be performed and the they definitely should include some heavy read/write operations to different memories (rootfs flash/eMMC/microSD) with checksumming.

It does not always work that well in the PC world either, for example ATI overclock auto-tune can find values which are stable in the test but still make some games crash.

What I've found with mine - though this may differ also - is that video decoding and encoding seem to be very "sensitive" tasks.
For example, while my OC'd N900's been 100% stable for weeks, it has always had two problems:
1. If I try to record a video without locking it to a frequency, the camera app would crash and
2. On bootup, the boot video would freeze after a couple seconds.
Everything else worked perfectly.

I just did some tests, and found that my 250mhz voltage was a little too low - I had it at 22. Bringing it up to 28 solved the problem entirely.

So, I'm thinking that between a couple of more sensitive tasks - and playing a video'd be good for at least one of them - we can get -close- to the needed value. Then, we add enough margin of error such that if its just a little below what's needed, it will still work right.

Speaking of that, if you guys have any good scriptable test ideas, I'd like to hear them.

Yeah, video is one.. but it run on the DSP. So even if it crash due to volt it could leave the telephone still running. We need something that stress the CPU too. Otherwise it will only make peoples batteries last shorter.

But i think the best way would be to listen for the errors that occur due to volt famine.. that way the user would not need to wait for the device to restart. Then maybe set the voltage two points higher.

Good idea, but I'm not sure the voltage control is fine enough. While using Mplayer to test mine, and reduce the voltage by one, I'd find that some of the time I'd see errors in mplayer, sometimes it would crash outright - and it would work fine at 1 voltage point higher.

Would be a great app.
Also it should do a some more tests than just Video Playback.
I found out that having WLan active at LEAST produces much Heat. io should be tested on internal and SD memory too (at least as an option, having the OC limited by faulty SD Cards doesnt help)
Im not sure if it may create problems. If you are sure it doesnt it doesnt matter of course.

And it should run fully automatic, time doesnt matter then. (i can live with leaving my N900 alone for 10 Hours or so)