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?