it's supposed to fall back to 500 when there is low load.
note that ideal completely disables 125 and 250 Mhz.
if you want lower frequencies than 500 you need to use the other profiles (ulv, xlv etc).

Thanks. I created a modified profile with 250 added back in and that's now my default. The thing is, i never see a frequency lower than 850 reported and the battery consumption seems consistent with that observation (i.e. high). Is there something that would lock it at 850?

I recommend to verify the settings with "kernel-config show" first.
only a high load would lock it at 850. do you have some daemon running in the background (tracker)? how do you check the frequenceny? conky?

I did verify with kernel-config show first. Both that and checking the /cpu0/cpufreq/scaling_cur_freq show 850. I have the cpumem-applet installed and have also checked with top and there's nothing pegging the cpu.

I wrote a python script to check the scaling_cur_freq and sleep 2 seconds in a loop. It's coming up as whatever i set max to every time. Any ideas?

Edit: Hmm, strike that. Think i figured it out: running cat command to show the scaling_cur_freq must cause the CPU to bump up to top frequency. If i use cat to display the frequency, it always shows as the max, as does calling the "show" command for kernel-config. If i use a python script, it shows the max frequency the first time and then the minimum frequency after that because it settles back down to a slower setting.

Example:
850000
250000
250000
250000
250000

The reason i thought the python script was having the same result is because i had set the max to 500 to save my battery, and then was running it on USB power just now (so of course it showed 500 as the frequency).

Moral of the story: don't use an instantaneous check to find CPU speed, as the act of checking will interfere with the results.

Thanks for the work on the kernel, titan. It's nice to OC with undervolting.

I updated the wiki with basic undervolting instructions and added a note warning that directly checking processor frequency will probably change it.

I setup some BeeCon widgets with Starving 125-600mhz for battery conservation mode. Starving 125-1000mhz also seems to run very stable for me.

Question I have is, obviously overclocking can reduce processor life and cause damage. Can undervolting be similarly bad for hardware life? (If Starving is stable, why not always run there(seems like no point to running Ideal 125-1000mhz)?

I agree, if Starving is stable. But you may run into situations in which Starving is not stable. Or not, depending on what you do and your CPU, I guess.

I wouldn't be a bit surprised to find Nokia voiding the warranty if you use the alternate kernel, regardless of whether you actually overclock. If they know.

The reason overclocking causes decreased life is because the higher voltage and current can cause physical damage/wearing to the silicon of the chip. Undervolting won't do this (assuming you're within the original frequency range - the situation gets more complex with higher frequencies). So it won't cause decreased life to the chip. It can cause data corruption if you go too low, but that's not a physical change, of course.

The manufacturer has to find frequency and voltage settings that work reliably for all devices in all situations. Most people won't use the full range of conditions in everyday life. For example, the starving config was stable for me until my wife used my phone - she sets the brightness all the way up, meaning that watching videos over wifi with low battery caused a reset. Low brightness was fine for me. The manufacturer has identified a worst-case condition that they make sure can be run successfully.

The default voltages also have to be stable for the worst device shipped - meaning most people have processors that are slightly better. So no surprise that you can usually get a little more out of your device.

Of course, he physics of device wearing have nothing to do with warranties - manufacturers don't like customers messing with defaults, period.

Since quite some time passed (which my fine tuning tests went on), i tought i'll post my updated drained settings.

here my config

# Jokah drained undervolt configuration
# minimum frequency to use
MINFREQ=250
# maximum frequency to use
MAXFREQ=1000
# list of frequency configurations: each "frequency:volt,dsprate"
FREQS="0:24,90 125:24,90 250:24,180 500:28,360 550:30,400 600:32,430 700:36,430 750:39,430 805:42,430 850:45,500 900:48,500 950:51,500 1000:54,500 1100:62,520 1150:66,520"
SMARTREFLEX_VDD1=0
SMARTREFLEX_VDD2=0
GOVERNOR=ondemand
UP_THRESHOLD=60
SAMPLING_RATE=150000
IGNORE_NICE_LOAD=1
POWERSAVE_BIAS=1

Hi,
I'm currently running the stock PR 1.2 kernel, but with nice'd apps ignored and SR on VDD1 enabled.

I'm debating with myself whether to go with the "Enhanced linux kernel for power users" 2.6.28-maemo37. This would primarily for power saving.

Can I expect much battery life improvement with this kernel. I'm assuming I'll be going for a deprived setting up to 600-750 or so.

I also have jokiuspot installed. I gather there's a possible glitch with loading the bouncer module manually but apart from that it's fine (and I should be able to load the module on startup anyway?)

Am I likely to see any other significant impact ie to responsiveness (I really need to try the kernel to figure out what the settings would do).

Other than any "warranty" issues anything else I should be concerned about? I have no problem flashing the device and am a linux old-hand

I'm interested also in looking at some of the other features such as IPv6 support...

Thanks...