Switching SmartReflex on the fly?
 

Over the years, I've messed with various kernel-power settings and reached the conclusions (valid only for my particular device), that

- any voltage profile less than "ideal" seems to introduce problems when accessing microSD
- using SmartReflex on VDD1 and VDD2 results in better battery life, but precludes overclocking beyond 805MHz
- the phone is stable at 250-805MHz with SmartReflex on VDD1 and VDD2 and has been running that way for a year

Now, without SmartReflex on either VDD and using the ideal voltage profile, the phone is perfectly happy at 1000MHz and this provides a noticeable speed boost to the interface. I wouldn't have chosen to do this two years ago, but warranty is no longer relevant and I have a spare N900 anyway. So, fine, we'll overclock the hell out of it. When we need to, that is. Battery life is still a concern, so I'd still like the phone to spend most of its time in 250-805MHz with SR, but to toggle SR and give me 1000MHz (preemptively) when I require it.

I don't want to do this by issuing a "kernel-config load xxx" on every lock/unlock as that takes upwards of half a second to complete, introducing a degree of lag and arguably defeating the purpose of the exercise. But, it has only just dawned on me that I can avoid this by setting the "ideal" voltage profile as default, then overriding clock speed and SmartReflex settings using sysctl. For instance:

/usr/local/bin/smartreflex:

#!/bin/sh

case $1 in
"on")
echo "805000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "250000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "1" > /sys/power/sr_vdd1_autocomp
echo "1" > /sys/power/sr_vdd2_autocomp
;;

"off")
echo "0" > /sys/power/sr_vdd1_autocomp
echo "0" > /sys/power/sr_vdd2_autocomp
echo "1000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "250000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
;;

esac

It seems to work, so, is there any good reason not to do this? The logic I am thinking of employing here is not completely decided yet, but my thinking is that every time I unlock the phone, it'll be to load some sort of application and therefore, that I will benefit from full speed, briefly at least, every time I unlock the phone.

Maybe it needs to be coupled with a timer when we're on battery, because one of two situations will be true. If I unlocked the phone for short-term use, i.e. to read a message or check when my bus is coming, then it'll be relocked again after a minute or two, in which case that relocking can be used as the trigger for reenabling SmartReflex. The problem comes if I unlocked the phone to listen to music or take a phone call, and it perhaps remains unlocked for an hour or two. In this case, we'd want battery life over responsiveness of the user interface and should probably reconfigure accordingly.

So, I guess the logic that I am proposing can be described as:

- on phone unlock, disable SmartReflex and boost to 1000MHz. If on battery, set a timer to revert after five minutes.
- on phone lock, restrict to 805MHz and enable SmartReflex

and the rationale this is that it should improve the responsiveness of the phone / browser / etc. when first unlocking it and selecting or using an application. It is anticipated that this will not improve battery life as compared with leaving SmartReflex enabled, but that it will do a limited amount of harm. Am I making sense, or have I missed something? Comments, suggestions and improvements to this logic are invited...

Re: Switching SmartReflex on the fly?
 

Have you just stepped out of a time machine from 2010? With kernel power49 smart relex is now fixed and working up to 900MHz. Why not just compromise with 900MHz? Read the KP stable v49 thread for details. Also, no need for undervolting anymore, SR does it for you better than your empirical tests show.

The whole switching profiles thing is the basis for batterypatch. Go read the sources to find out more. Whether it works...well that is a major point of contention.

Re: Switching SmartReflex on the fly?
 

Ahem. To all intents and purposes, yes. I did what I was going to do as far as overclocking was concerned and have left it alone since, well, 2010. Guilty of upgrading to KP49 and not reading the fine manual until I wondered why it had lost a few speeds. The shipped configs with SR enabled defaulted to a max of 805, so this was what I presumed remained the safe limit. I'll play with SR and 900MHz. :-)

Still, my reason for doing this was not to reopen the debate about battery life, for which SR wins. Mostly I just want more responsiveness and I am starting feel less conservative about overclocking to attain it (never even actually tested 1100, I just might). There's also the point that if I'm going to buy a microSDXC and load it up with media, I'd like all the speed I can get when it comes to dealing with larger volumes of files/artists/whatever. I haven't undergone a scientific testing process of testing, but I did recently manage to get it to crash at 900MHz with SR enabled on VDD1, I think, and only tried 1000MHz without SR on a whim. If I can use 900MHz with SR that *may* provide a solution, but, I'm becoming tempted to say if I can have 1000, 1100, 1150... what by now is the compelling reason not to?

Battery life remains a concern, but I now carry a USB power brick and most people have microUSB chargers, so it's less of a worry than it was. Doesn't mean that I don't benefit from SR most of the time, but, I'd ditch it for 30 seconds for a 200-250MHz boost if I could sensibly identify circumstances in which to do so. Device life is less of a concern; I won't do anything that causes more than a couple of crashes. If I really do fry it, which I doubt, I have good backups and spare hardware. Warranty is no longer relevant. The only real concerns (to me) are stability, performance, and not wasting battery for the sake of it.

Thank you though for your input, I was not aware of this and will RTFM and do some further testing with SR at 900MHz.

Re: Switching SmartReflex on the fly?
 

If you want performance...

1. Do a complete reflash (unless you are convinced your setup is healthy)
2. Don't use widgetz
2. Install CSSU.
3. Install KP49.
4. Enable SR.
5. Change CPU speeds 500 low, 900 high.
6. Put swap on your SD card.
7. Apply some virtual memory tweaks.
8. Investigate compcache
9. Investigate swap reset script with cron/alarmd.

Do the above and your device will be as someone said, 'snappier than a crocodile at a penguin parade'.

// EDIT

Above is more or less my setup (except the swap on SD) and I see around 2 days battery life, and christ knows I am a serious fiddler.

Re: Switching SmartReflex on the fly?
 

How do you connect to WiFi APs w/ hidden SSID without ConnectNow Widget? "Browsing" from the statusbar plugin certainly doesn't work.

Re: Switching SmartReflex on the fly?
 

Once device is reflashed, does the order of above operations matter?

Where can one find information for 7, 8 & 9?

Re: Switching SmartReflex on the fly?
 

Recently,I wanted to create a dedicated partition for easy debian.Got lot of helpful members around.Even then I could not mount it to that partition.while going through this ,I had to flash my device.But I learnt how to use gparted,created a swap space of 384 MB on sd card.After that I have edited /etc/pmconfig enabling smartreflex,cpu to 900 following vi's advice.Believe me my device became too fast.I stopped caring about battery long ago ,though smart reflex gives me best battery life of approximately 8 hours(my battery is old).

Thank you.

Re: Switching SmartReflex on the fly?
 

xterm my son! Seriously I don't use any AP with hidden SSID, if I did I would just use kismet to figure out the SSID then take it from there. I actually use Queen Beecon to add a connect/disconnect button to the top right of the status bar area for my connect/disconnects.


No the order does not matter, neither does the method by which you achieve the aim. Virtual memory tweaks can be found with swappolube and here.

Compcache here.

As for the swap script, you will have to be a bit creative, I am sure Estel can chip in on that one.

Re: Switching SmartReflex on the fly?
 

Ok, so you actually also USE WIDGETS.

Re: Switching SmartReflex on the fly?
 

I think you will find I quite specifically typed "widgetz".

Re: Switching SmartReflex on the fly?
 

What is the intended difference? The time people actually appended 'z' to single word descriptors was during the late 1990ies, when there in general were 'appZ', gameZ', and 'wareZ'. (A meme stupid enough during it's heyday, if you ask me)

Re: Switching SmartReflex on the fly?
 

@vi_ Thanks for your tips. From what you say there's no need to activate/deactivate SmartReflex because of the way KP-49 is set up? Info on all of this seems quite dispersed and if someone misses a thread (or sometimes a mere post) or two on TMO, he/she is none the wiser (OP is good example). I think we all* need to have a good read of recent developments and the new "ideal" setup. I saw one post of your's in the KP-49 thread saying don't bother with xulv etc. but I'm sure there's more to know for optimal basic setup.
*we all - those of us not actively involved in creating or regularly commenting on system development.

I have found even "hidden" networks are visible to the N900. Surely if you've got the password, connecting is the same as to those networks that announce their SSID?

You said remove "widgetz". what do you mean by this term? Isn't QB for preparing widgetz? Or do you simply mean the pre-installed ones like the amazon etc.?
Clearly, an item that doesn't poll isn't quite the same level of a juice-drinker as one that does poll or auto-connects. All the same, it seems some desktop items are more hungry than others.
- what's you're differentiating factor b/w widgets and widgetz? (following comment to don_falcone)

From experience, I've found the order of installing/uninstalling can make a difference. I suppose that if nothing else is installed except CSSU and KP, on a "fresh" system, there's no difference in outcome, whichever is installed first. And, as much of the system set up should be done at this point?

I'll look into these. Thanks.

Re: Switching SmartReflex on the fly?
 

For SR and overclocking, try QCPUFreq with my modified helper script: http://talk.maemo.org/showpost.php?p...&postcount=180

Re: Switching SmartReflex on the fly?
 

AFAIK use either undervolting profile or SR. Don't use both at the same time

I use dsp profile (modified to 250-600) + SR VDD1 & 2

Re: Switching SmartReflex on the fly?
 

I shall stop being flipant for once...


You are right, my comments are a little confusing and subtly rude. Information is all over the place and a combination of things moving at rapid speed with no documentation means it is easy for a new person to become lost. I just assume everyone is like me and will devour the facts presented all over the place to create a coherent 'whole' understanding of the subject at hand. There literally is no more too it.

Enable smart reflex, either by kernel power settings or some shell script and never load an undervolt profile again. Job done. That is all. The smart reflex values for your own personal CPU are calculated from values internal to your CPU giving you your own personal PERFECT undervolting profile that tweaks itself depending on load. I know, incredible! Thank you freemangordon, we have the beerfund, now tell us where to send it.


I was suggesting that to connect to a network which does not broadcast it's SSID is to use xterm and connect by the stations BSSID. Again I was being flipant. I am sure connect now works perfectly well for this task.


The difference between widgets and widgetz is an ideological one. Here I was making a wry reference to the dirth of badly programmed junk that some users love to install on their machines, usually just before they start a 'why is my battery life so short thread'. It is not as simple as to whether the widget polls hardware or not. Python stuff requires you to load in a stack of python libs, QT stuff requires me to have a bunch of QT libs in memory. All this affects performance. Take callnotify for example, it appears to be a well made and useful piece of software. It is not. It is a python script that causes over 400 wakeups/S. While it's function is semi useful it is not worth pulling my CPU out of C4 for.

Queen beecon widget is different. It has been very well coded by a skilled programmer. With smart scripting its performance impact is quite small. The performance cost to benefit ratio is very much in its favor. Thus it has passed the test and shall be classed as a 'widget'.

Marmistz post above is a prime example. WTF is qcpufreq with a modified helper script? (ok, I already kind of know but that spoils the point). The fact is you do not need any more junk to overclock/underclock/tweak/mod/hax than you already have with just a basic setup. The more of this trash you install the worse your system gets. Of course you are free to customise your n900 how you see fit, that is the beauty of this computer, but just understand that it has finite battery life and every computer cycle burned through chores your juice.

Consider my case, I evolved over the series of several months from the original setup to 9 desktops with the ideas behind batterypatch (swapping junk around using dbus-scripts( before batterypatch was even conceived of)) and over 30 QBW. Then one day my hardware failed and I had to get a new n900. I now have 3 desktops and 4 QBW total. Now the system is fast and has good battery life. The system is complete, not when there is anymore to add but when there is no more to take away.

I do not wknow where I am going with this rambling nonsense, damn I wish I was as eloquent as mentalist_traceur.


The stuff I have highlighted above is 'order agnostic'. The order in which you install things SHOULD have little effect on the final system.

Also, do not use any voltage profiles anymore.

Re: Switching SmartReflex on the fly?
 

Thanks for this - am pleased to find that most of this is what I've been doing anyway. I've a few thoughts / questions on the latter points, though.

5. Running at 500/900 is fast, but, it's a fairly conservative improvement on the 500/805 that I was running before. Testing with 500/1100 feels really sleek - I really want this, and I accept full well that it's not optimal for battery life or (possibly) for device lifetime. I remain interested in achieving this on a transient, as-needed basis. In doing so, I'm also seeking to mitigate the impact on battery life by applying this on an as-needed basis, and should add some kind of safeguard against remaining in 1100MHz mode for too long in case of constant loading. What else am I not aware of?

6. Does the proposed benefit of this come from the assumption that the microSD card is fundamentally faster than the eMMC (not sure mine is), or from the fact that it is a separate device? I'm not filled with confidence by this thread either, is there a material benefit to this?

7. Good call, I've used Swappolube previously and neglected to reapply it after a reflash. Redone, with thanks for the reminder.

8. Thanks for the heads-up. Having read the entirety of this thread on compcache, I have gained the impression that reports are mixed and that we have a bunch of opinions - but no clear guidance or an obvious way to assess - how much use it will be to a given user in a given situation.

Am I correct in thinking that what makes the difference is not the overall amount of swap that is in use, but the amount of I/O to and from that swap that will (or won't) be made faster by caching to RAM?

If so, is there something sensible I can do with iostat or similar, to assess the size/frequency of reads/writes to/from the swap? I know broadly how to use it, but not necessarily how to use it to produce a test that anybody can run with comparable results, or how to interpret the results to determine whether it is likely to help.

9. How frequently do you find it worth refreshing the swap? I see a previous post from you that describes doing this nightly - is this still true? I currently perform a nightly cycle of reboot -> automated backupmenu -> reboot -> rsync to remote machine every day at 0430, provided that we're on charge, not in use and on the home WiFi network. So, since I rarely reach an uptime of 24 hours in the name of having good backups, I suspect this is redundant as far as I am concerned.

I'd be interested in your thoughts... and thanks for your input on this so far.

Re: Switching SmartReflex on the fly?
 

I'm not proposing to use both "at the same time"; if SR is on, then it overrides the voltage profile. The idea behind using the "ideal" profile as the default is that, when I turn SR off through sysctl, I can use manually specified voltages to achieve overclocking that would be incompatible with SR.

As vi_ says, it probably ain't necessary, but if I can do it with minimal fallout (no widgetz either) then I want to.

Re: Switching SmartReflex on the fly?
 

What you could do is load your system to the max (play a movie with mplayer and force it to scale to video output or something), lock to each frequency you want to record then write down what smart reflex chooses as a voltage for each frequency. Thus you could use some relatively sane voltages and just guess for the ones outside the SR range (1000MHz etc). This would allow you to PERHAPS create a voltage under clock profile that is safe for your device that will go up to 1000MHz. Although I think it should be said it really can not recommended to push the processor so hard without adequate cooling.

No, the uSD is slower than the eMMC, however you are not competing with your programs to read/write to it. Thus cuts down IO collisions. Thus swap can run uninterrupted. Yippee!

I will answer more later.

Re: Switching SmartReflex on the fly?
 

That won't work, one of the things SR driver does is to store current voltage for an OPP (+2 for pre50) before switching to a new OPP(avoiding current peak next time this(current) OPP is active again). So if you do kernel-config show after your system was up for a while with SR turned on, you will see what voltages(+2) SR has calculated for every frequency in allowed range. And disabling SR does not reload profile voltage values, you have to manually reload the profile after turning SR off. Not only that, SR driver "boosts" voltage a little bit when DSP is active, because on most devices even if CPU is stable with a particular voltage for a given frequency, DSP is not. And that boost depends whether DSP is OC too along with MPU. Also have in mind that SR uses(in theory) 3 variables to calculate the voltage: load, temperature and aging. So the values that SR has calculated might be stable for current temperature and load, but who knows whether they will be enough tomorrow when it is not -20 outside.

EDIT:
And if you turn SR on with MAX frequency above 900 (which is maximum supported by SR driver) you most probably will have a crash.

Re: Switching SmartReflex on the fly?
 

I could, if there's any real advantage to be had by doing this, or I can take the view that the best case in most situations is to use SR, and that previous testing has shown that, when I'm not using SR (for which the only argument is overclocking, all caveats and disclaimers accepted), the "ideal" profile works in all situations but anything lower seems to cause problems. So, we're in agreement that most of the time, I want SmartReflex and do not want to overclock to the max.

What would be nice, though, and what I am driving at, is if I could have full speed for 20 seconds when I first unlock the phone, bring up the required application (e.g. my browser) and point it at a page (e.g. Facebook). This would not be planned to last more than a minute or two before reverting to sane defaults, and should involve fairly low overhead. The best way to describe what I am aiming at is probably with the current script:

Disclaimer: the following script is posted here for comment and discussion and should not be installed or used by anybody who doesn't know what they are doing. You have been warned!

maemo:~# cat /usr/local/bin/smartreflex
#!/bin/sh

case $1 in
"on")

# This is called when the system gets locked, or taken off charge.
# It should always set sane defaults.

echo "805000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "500000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "300000" > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
echo "1" > /sys/power/sr_vdd1_autocomp
echo "1" > /sys/power/sr_vdd2_autocomp
# If we've been turned back on by relocking, then kill any waiting instance.
kill -9 `pgrep -f smartreflex.wait` >/dev/null 2>&1
;;

"off")

# This is called when the system gets unlocked. It temporarily disables SmartReflex,
# permits overclocking to 1100MHz, and reduces the sampling_rate so that the CPU speed
# will boost quickly as the user (for instance) loads a browser and selects a web page.

# It then enters a loop by running "smartreflex wait". This sleeps for 20 seconds, then
# tests whether we're still using a speed above 600MHz. If we are, then allow this to
# persist for up to two minutes / six iterations before reverting to the sane defaults.

echo "0" > /sys/power/sr_vdd1_autocomp
echo "0" > /sys/power/sr_vdd2_autocomp
echo "1100000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "500000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "150000" > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
/usr/local/bin/smartreflex wait &
exit
;;

"wait")
# While SmartReflex is switched off...
let count=0;
while [ `cat /sys/power/sr_vdd1_autocomp` -ne 1 ]; do
# Wait twenty seconds for user to load whatever he unlocked the phone for
sleep 20;
# We can reenable SmartReflex provided that our current speed is not greater than 600MHz
# NB less than or equal to 600MHz, so we still re-enable SR if locked to 600MHz by a phone call
if [ `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq` -le 600000 ]; then
/usr/local/bin/smartreflex on;
exit;
fi;
# Hmm, we're still using our overclocking it seems. Let's use a time limit as well.
let count=$count+1;
if [ "$count" -ge 6 ]; then
# After six iterations, we've been running for two minutes above 600MHz. SmartReflex it is.
/usr/local/bin/smartreflex on;
exit;
fi

done;

;;
esac

Whether it's desirable or not remains moot, but, my intention is that this should mean that when I unlock the phone, we enable an overclock to 1100Mhz on a hair trigger (but do not lock it). When we then fire up Opera Mobile and hit Facebook, we get full speed whilst we're swapping, displaying and messing about. This persists on an "if needed" basis for twenty seconds to two minutes, after which it is disabled to protect both battery life and CPU. Most of the time, it will downgrade after 20 seconds or less, giving me just enough clout to get to my desired application and then relax again. In terms of any overhead caused by the switching, it's pretty darn minimal:

maemo:~# cat test1.sh
let x=1; while [[ "$x" -le "1000" ]]; do smartreflex on; smartreflex off; let x=$x+1; done;

maemo:~# time sh test1.sh
real 0m 55.27s
user 0m 12.05s
sys 0m 30.03s

so, each cycle from SR to overclock and back again costs us approximately one twentieth of a second. Thoughts?

Re: Switching SmartReflex on the fly?
 

Further to the above (experimental) script, I've just taken it out on the road for a few hours, to see whether I've done the overall performance any good. Results are mixed... the good news is that I haven't produced a single crash and that the impact on battery life (whilst not yet measured) is (subjectively) acceptable.

The impact on performance/responsiveness is the mixed bag; once the overclocking happens, I can really tell the difference between Opera running at 1100 and Opera running at 805 or 900. However, it can take a couple of seconds to surpass the up_threshold and increase the clock speed, so it shows the benefit more when it's rendering the first web pages loaded than while bringing up Opera itself. I could solve that by temporarily locking a frequency, but that would guarantee to waste more power on every unlock, whether it turns out to be needed or not.

From watching conky while playing with commonly used applications, I've seen quite a lot of the CPU hitting 50-60% usage (at 500MHz) for a while before it triggering the desired speed boost. OK, the system may not be CPU-bound at that point, but two or three seconds later we hit the up_threshold. This makes me tempted either to lower the up_threshold and make our hair trigger even finer, or to keep it at 75 but lower the minimum speed to 250MHz. My intention is that merely unlocking the phone (such as to check the time) should not do any more than it has to (staying at minimum speed would be nice), but that unlocking the phone and e.g. starting Opera should trigger 1100MHz before I ask it even to give me the start page.

Again, I don't warrant that this is either clever or desirable, but I'm having fun. Comments or refinements welcomed...

Re: Switching SmartReflex on the fly?
 

Try custom menu shortcuts

Ya create a script that will launch the commad that's its arg and modify the .desktop files

Re: Switching SmartReflex on the fly?
 

Try custom menu shortcuts

Ya create a script that will launch the commad that's its arg and modify the .desktop files

Re: Switching SmartReflex on the fly?
 

Hrm... this sounds like it is potentially useful, but the problem with any desktop "toggle" switch is that I have to remember to use it.

I did consider the idea of replacing specific shortcuts (such as Opera) with scripts that would set appropriate values and then launch the application, so that it remains a one-step process, but I found several reasons not to do that:

1) I'd have to do this per application, in order not to add additional steps of launching a script and selecting an app. Would be a PITA to maintain.

2) I don't have an event-driven method of detecting the closure of that application, so I'd still have to rely on either DBUS, a timer or looping with pgrep to revert any temporary settings I made.

3) This being the case, and provided that the ondemand frequency governor lets me achieve sane behaviour, it makes sense (to me at least) to preempt the CPU demand by assuming that when I unlock the phone, it will normally be to load or switch an application, so within reason, overclock by default.

Thanks for the thought, though.

Re: Switching SmartReflex on the fly?
 

If there was a governor with multiple values, e.g. 250,600,805,950