Related
Anyone having read my well-known articles on measuring the power consumption of Windows Mobile devices (see for example this Pocket PC & Smartphone Magazine article) knows the really excellent, free tool acbPowerMeter perfectly suited for the job.
Now, the same developer, acbPocketSoft, has (finally) released a vastly updated & enhanced version of the application, renamed to acbTaskMan.
The homepage of the application is here and is highly recommended for a quick read so that you'll see what it's all about. In below, I explain why I recommend this application that much and how it compares to the alternates.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
acbTaskMan has a free version (not that the commercial one would be THAT expensive - actually, for $7.95 only, it's definitely cheaper than most of the comparable, but, charting-wise, still inferior alternatives), which is still pretty usable - unless you need quantitive CPU usage results and simple, non-app-specific chart is sufficient for you.
I’ve been using this utility (as a beta) for almost a year and have been absolutely pleased. It helped me hundreds of times in examining the CPU, memory or power usage of a particular application (actually, almost all my CPU usage reports in the last year have been based on the results measured with acbTaskMan – except for some where also the current CPU speed needed to be measured too – for example, in Everything you will ever need to know about the power consumption of Pocket PC audio players, where I also needed to turn to an alternative utility, Dogfood's RegTweak). All I can say it’s perfect and highly recommended, should you really want to maximize your battery life and, for some reason, I haven’t elaborated on the CPU usage of the application you’d like to test.
I also highly recommend the application to ALL software developers. Many applications / games are released with exceptionally high CPU usage, meaning greatly reduced battery life. Many of these games / applications are found by me (when I publish a review, I also check the CPU usage to find if a particular app is misbehaving in this respect.) By getting and using this monitor, you can be absolutely sure you can iron out the CPU usage-related bugs (for example, busy waiting causing 100% CPU usage) before you release it.
Why do I recommend it that much? In what way is it better than the alternatives? It’s pretty simple: it’s perfectly suited for the task, most importantly because it has sophisticated history graphing capabilities, as opposed to the alternates. Let me elaborate on this a bit more.
Say you want to measure the CPU usage of a game or an MP3 player. This situation is very common with Windows Mobile applications as you can be never sure what third-party game or application will chew through your battery if you (as far as multimedia players are concerned) enable the scrolling of the song title or the Real-Time Spectrum Analyzer (both of them are pretty CPU-hungry in general).
If the tested app is clever enough NOT to run the code in charge of doing these, you can’t use the most traditional task managers (for example, TekSoft’s SmartBar as of version 1.2.010 or FdcSoft’s Task Manager - two apps that are, otherwise, excellent) to benchmark the CPU usage of these applications because you only see the CPU usage numbers when the benchmark app’s window is maximized and not that of the just-checked app (and, in addition, the CPU usage meter of SmartBar doesn’t work on some devices; for example, the HTC Universal). (Example screenshot here. Note that Task Manager also has a tendency NOT to display the normal CPU usage of a given app. In the screenshot above, WMPlayer.exe has 0.57% CPU usage (at 520 MHz), which, of course, isn’t valid. Not even the maximal 3% it reports – it’s way bigger.)
Dogfood's RegTweak is better in this respect, but, as it only uses a single bar at the bottom (no numeric and/or process-specific results; see screenshot here and here – note the two bars at the bottom; one of them showing the current CPU speed and the other showing the load) and has no filtering capabilities, is still far inferior to acbTaskMan. Also, the bars won’t be visible in most full-screen apps like games – that is, you won’t be able to check the CPU usage of a game.
SuperTasks 2.0, the, in addition to Pocket Hack Master, only application that offers history and background graphing capabilities, doesn’t let for charting a given process only. This may result in some problems when you, for example, run two CPU-intensive tasks in the foreground and would like to separate the CPU usage of the two from each other. This is why, for example, the thread starter post in this thread had to do twice as many tests to reliably get the CPU usage of a given task. Unfortunately, its chart drawing capabilities is far inferior to that of Pocket Hack Master (let alone acbTaskMan) – the chart only spans about a minute (as opposed to the about 5 minutes of Pocket Hack Master) and has a bit higher (5-7% at 520 MHz) CPU usage when run in background mode: while, in that case, Pocket Hack Master only uses some 1-2% CPU time (at 520 MHz). Of course (as with Pocket Hack Master) you can’t chart just a given app and it has no file output capabilities. The only advantage is its taskbar icon, which shows the batter and the CPU load and can also be used to close / switch to apps. (However, if you do need monitoring, use RegTweak instead – it’s free and uses slightly less resources.)
Here’s a screenshot of the Process monitor and here’s that of Tasks. Note that it, in the last screenshot, it listed abcTaskMan as consuming 15% of CPU time, and, in the next second, it listed it as a 0% task; this means it’s pretty unreliable and much less dependable than abcTaskMan because the results will change all the time and you need to do the averaging yourself.
PHM Task Manager 0.1, while it’s free and running OK even under WM6, only shows the number of internal threads and the CPU time, the latter not really showing the CPU usage of a given app.
Wizcode LLC’s (ex-Anton Tomov’s) well-known Pocket Hack Master, as of version v4.14.033, has a CPU charter module even being able to run in the background (and, as opposed to acbTaskMan, also using high-resolution on VGA devices); it, however, 1. can’t chart a given process only 2. you can’t set the timescale (as opposed to acbTaskMan), which means it’s impossible to make long-time measurements (for example, filesys.exe compaction measurements spanning 12-24 hours) with it – again, unlike with acbTaskMan. The latter is really a pain in the back for any long-time measurements; with short-time ones, not so. Incidentally, as can also be seen in this screenshot, its CPU usage is pretty close to 0 (some 1-2%) when run in background (definitely better than that of acbTaskMan, comparing the two apps using the same refresh rate); on the other hand, when run in the foreground, it’s around 50% (run at 520 MHz). It can’t display task-level CPU usage figures at all as can be seen in here and here. Unfortunately, the debug logging facilities only allow for logging of app-related information; that is, no CPU usage data can be logged.
emProcess by the infamous(?) emCon: it was last updated over 4 years ago (01/2003). The trial doesn’t support process / memory debugging and it seems it doesn’t support any kind of charting.
Bakisoft’s Task Manager PPC has been discontinued and the developer has went out of business. In addition, it doesn’t have a trial version and doesn’t seem to support charting.
XCPUScalar 2007 3.00 only displays a (relocatable) current CPU speed and CPU usage meter (in percents) on the taskbar as can be seen in here. It has no history either. This means it can’t be used to debug apps that hide the taskbar (for example, games). Definitely not recommended for this task only.
Finally, sure there are desktop-side tools (for example, Windows Mobile Developer Power Toys) to measure some parameters but most of them (for example, the SOTi Pocket Controller as of version 5.07 build 966 - see this screenshot of its process monitor tool) aren’t able to monitor CPU usage. (Not to mention they all require a desktop computer connected to the Windows Mobile device, which is not only awkward some times, but, in cases, also renders the application to be tested useless – for example, with many hardware 3D enhanced games like Toy Golf (see this for more info on this problem).)
(Note that MemMaid 1.73 only displays the memory consumption of a given app.)
acbTaskMan to the rescue!
This application really excels in finding “rogue” programs because it, unlike its above-mentioned alternatives, is capable of storing a history (even back to the last 24 hours as can be seen in here) of the CPU usage and drawing a chart of it. Furthermore, during drawing the chart, you can not only chart the full CPU usage of all applications, but, in addition, can instruct acbTaskMan to chart a selected one with a different color so that you can easily see how many percent of the full CPU usage has been consumed by the charted application (game).
For example, let’s assume you’d like to know how, say, Opera Mobile, the, in my opinion, best Windows Mobile Web browser behaves. All you need to do is bringing up the context menu of Opera Mobile in acbTaskMan and select Chart CPU. Then, a red graph, in addition to the standard green one, will be displayed; the former shows the CPU usage of the currently charted app (in this case, Opera). In this screenshot, as you can see, Opera consumes about 0% CPU time (look at the red graph) after enabling its charting in abcTaskMan and waiting for some 4 minutes.
Now, let’s start actively using Opera Mobile – with abcTaskMan running in the background and actively monitoring the CPU usage of all apps, including Opera Mobile. Let’s do some active browsing and, after that, return to abcTaskMan to evaluate the results shown for example here.
As can be seen, this application is really-really excellent at charting the CPU usage of applications, particularly when they can’t run in the background (most games), which would otherwise be needed with CPU usage meters not keeping the history.
The CPU usage of abcTaskMan itself
Note that abcTaskMan is also better than the alternatives in that it uses pretty few CPU cycles itself, particularly if you in Display / Update Speed, select Low or X-Low (screenshot here). Then, from the default ~5%, the CPU usage decreases to ~1.7% and ~0.7%, respectively (all figures measured at 624MHz on the x51v). This is definitely lower than the CPU usage of most alternates (see for example the high CPU usage of FdcSoft’s Task Manager!) – except for RegTweak, which needs some 1% at 208 MHz (!).
Also note that, by selecting Display / CPU Chart / Subtract abcTaskMan CPU, you can entirely “hide” the CPU usage of the app itself. That is, the results won’t be at all reflect the fact that the application, abcTaskMan, that has been collecting them, used some CPU time itself.
Problems
What I miss most is the ability to log the CPU usage figures to a file (with, of course, timestamps) for even more thorough or later examination. This would be VERY cool, even with “only” the ability to export these figures of the “charted” app (and not all of them). Nevertheless, this is more of nitpicking: the app is very cool even without this feature.
Otherwise, the app is very stable and during the long-long months and hundreds of apps and games of testing, I’ve never found any app that it couldn’t run with in the background.
Plans for the near future
The developer has just told me he’ll add support for native VGA mode. (Now, it uses pixel doubling in standard VGA mode.)
Links to the above-mentioned alternatives
(Note that the rest of the alternative applications have already been linked in from the article!)
FdcSoft’s Task Manager – one of the best all-in-one system management, registry editor etc. tools. Make sure you check it out – you’ll love it!
TekSoft’s SmartBar - another highly capable all-in-one tools; highly recommended!
Dogfood's RegTweak (also see this); note that the latest beta (2.2.0.0 beta) was released March 16, 2007. It still doesn’t support CPU usage and frequency monitoring; therefore, for the time being, you’ll want to stick with the old, stable, working 2.1.1.0 version.
I also recommend this XDA-Dev thread for more information.
New, updated version posted.
Thanks! Great job! I really2 like it....
Most of the recent WM6 rom chefs have been advocating making NO performance tweaks, in favor of keeping as large a RAM pool as possible. As I rarely need 30mb to run a program, I am happy to give up what I don't need if it will help get data back and forth to the SD card and so on faster. Has anyone got thoughts or data about this? I don't own a benchmarking program so I can't check it out directly. I have been making all the tweaks anyway, but does it matter?
Thanks for your thoughts!
Ed
X-Plore 1.1
IPL/SPL 3.08
GSM 2.69.11
edhaas said:
Most of the recent WM6 rom chefs have been advocating making NO performance tweaks, in favor of keeping as large a RAM pool as possible. As I rarely need 30mb to run a program, I am happy to give up what I don't need if it will help get data back and forth to the SD card and so on faster. Has anyone got thoughts or data about this? I don't own a benchmarking program so I can't check it out directly. I have been making all the tweaks anyway, but does it matter?
Thanks for your thoughts!
Click to expand...
Click to collapse
I agree completely! I'd like to see a WM6 ROM with all the performance tweaks and 8 MB page pool. I know jwzg is working on an 8MB pp ROM based on Faria's up coming Vanilla WM6 ROM.
Check out this thread for more info http://forum.xda-developers.com/showthread.php?t=299584&page=10
Thanks for the link. I really don't understand the drive for smaller and smaller page pools either...
Some Answers!
OK, here is my contribution to the WM6 literature...
I am running battery status 1.04 beta 3 with the following settings in all tests: cpu speed 247, cpu scalar min 143, boost 278. set on wakeup, remember last speed. My base setup is as per my signature. I ran SK Tools v 3.1.1.0 in demo mode. I also removed the HKLM\init launch100 key in both cases.
All tweaks, No tweaks
Integer (moves/25us) 134.0864, 134.4001
Floating point MWIPS 3.490, 3.489
RAM Access speed index 345, 328
Draw bitmaps speed index 503, 522
Main storage (w) KB/sec 607.78, 612.14
Main storage (r) KB/sec 3670.25, 3469.23
Storage card (w) KB/sec 412.76, 423.11
Storage card (r) KB/sec 3353.71, ! 1119.13
As you can see, the major difference is in the storage card read speed. This led me to retest using only the SD card speed tweak, and no others. Surprisingly, the result was unchanged from using no tweaks! So, likely there is some interaction with the other file system tweaks that is involved. (See the wiki-WM5 performance tweaks). At some point maybe I'll try to pin it down further.
Regards,
Ed
BTW: Sorry for the poor formatting, for some reason the extra white space between columns is being suppressed in the post.
When I was using NotTooSmart's ROM, it had some performance tweaks. I don't have a benchmark prog but it was definitely much faster. I would say it's comparable to when I had it overclocked to 234-247MHz...
I believe what made the most difference was the System Cache... I lost ~10MB of RAM but the ROM was flying... Start up was scary though... I think it went <2MB w/ the progs I had...
edhaas said:
Thanks for the link. I really don't understand the drive for smaller and smaller page pools either...
Click to expand...
Click to collapse
A lot of people tend to be RAM fanatics... that's probably what drove cooks to have smaller and smaller page pools... Another thing is people and numbers.. many tend to feel the bigger, the better.. High IPL/SPL, High Radio, High OS, High Storage, High RAM.. I think you get the picture.. =P
Update on tweaks
I think I'm near the max. I maxed out the file cache, and filter cache, kept the SD cache at 256 and re-ran the benchmarks. Slightly higher numbers all round, but a dramatic increase in SD card read rate, now up to 6.5 mb/sec! I would expect this would speed loading those big programs and files from the SD card, and is 6 times the "stock" speed!.
Regards,
There was a post a few weeks ago (I think) where someone did comparisons with playing with PagePools and the performance. They compared 4MB, 6MB, 8MB, and 12MB pagepools. As I recall there was very little difference between 12MB and 8MB performance. I think 6MB was the worst of the 4.
Again this was all from memory, but I just remember after reading that, I no longer was that concerned about the differenence in performance over the added extra memory available by dropping to 8MB.
Performance tweaks
Actually, in thinking about the issue, it occurs to me that the standard benchmarks we are using (SPB Tools) don't measure things that would likely be changed by a change in page pool. CPU calculations, memory access speeds, would not change by changing the page pool or buffer sizes. The only measurement which would change would be the speed of swapping programs and data in and out of memory (by suppressing the actual need to do so) or accessing the memory card. However, these things *would* impact on "real life" apparent speed of the device in activation of programs and quick response times.
Thoughts?
Forgive my obvious ignorance... This is the closest thread I have found for my search, "SD card speed tweak" so can you please help me? point me to the tweak to speed up my SD card?
thanx in advance!
Re: Speed tweaks
Sure, If you want awesome numbers on SK Tools SD read benchmark, (particularly when combined with overclocking) make these registry changes:
HKLM>Drivers>SDCARD>ClientDrivers>Class>MMC_Class:
Change BlockTransferSize to 256 decimal
HKLM>Drivers>SDCARD>ClientDrivers>Class>SDMemory_Class:
Change BlockTransferSize to 256 decimal
HKLM>System>StorageManager>FATFS:
Change CacheSize to 4096, 8192, or 16384 decimal
HKLM>System>StorageManager>Filters>freplxfilt:
Change ReplStoreCacheSize to 4096, 8192, or 16384 decimal
The larger the numbers the faster the benchmark. However, some of the other benchmarks run slighly slower, and I'm not sure I see significant "real life" improvements in responsiveness. I'd be interested in your impressions. One thing to watch out for, particularly when using the 16384 settings, is that available memory can drop to "dangerously" low levels on start up from soft reboot. If you're using batterystatus you can monitor this. As long as you stay above 2mg or so at the minimum you're ok, as the situation resolves after the start up routines finish. If you do go below, I've had the screen blank temporarily and hang for a moment, but it eventually booted fine anyway.
Have fun!
Thank you for your prompt and courteous answer!! I am still learning this PocketPC stuff. Someday I hope to be able to contribute. It already seems faster!
email tweaks
is there anyway to make my pics in emails auto download?
(instead of having to click "download pics" every time...)
and to create shortcuts to my text messages and other applications, how can i do that?
b.mann said:
is there anyway to make my pics in emails auto download?
(instead of having to click "download pics" every time...)
and to create shortcuts to my text messages and other applications, how can i do that?
Click to expand...
Click to collapse
This question is slightly offtopic, but I'll answer you anyways.
Go to the email account you want to change:
Menu/Tools/Options/Choose The Account (it will take you into email setup):
Next/Next/Next/Options/Next/Next/Download size limit (drop down menu - choose what you want)/Finish
Hi,
I saw the benchmarking results that you guys posted and the difference between "with tweaks" and "without tweaks". The numbers sure show a difference with the benchmarking results but what i'd like to ask and what i'd really like to know is - have you noticed a significant difference in actual/real life performance on ur wizard? Was it obviously faster?
I mean, for me and IMHO, i'm not much of a fan of "benchmark" results and all that unless I actually see a "real" difference in speed when i use my PPC. I don't think i'll go for the performance tweaks if i'll loose 10+MB of RAM and am only able to see "benchmark" results being better instead of overall actual performance. That's why i'd like to get ur inputs on this whole performance tweaks thing...is there a noticeable difference in speed? (not just benchmark data)
WM 6.1 Tweaks
Hi,
Even the thread is quite old,
after some time of using WM6 and 6.1 and test meny mor etweaks, there I post some of them who i found usefull.
TKS to all contributors form xda or another.
1. Stop 3G services: settings\phone\ HSDPA must be disabled; RAT set to GSM; the internt still accesible trought GPRS for the most operators
Result in: less batery consumption 1-2 days stdby increase to 3-4 days
reduce blockings and wake-up problems
2. Disable Power management for SD card: use poket toolman or others and uncheck Enable Power Mgmt for SD card; or use regedit and change to
[HKEY_LOCAL_MACHINE\Drivers\SDCARD\ClientDrivers\Class\SDMemory_Class]
“DisablePowerManagement“=dword:00000001
Other option:
Change reg into
[HKLM\System\StorageManager]
“PNPUnloadDelay“=dword:8196
[HKLM\System\StorageManager]
“PNPWaitIODelay“=dword:8196
Note that the 8196 should be entered as a DECIMAL value. The HEXADECIMAL (HEX) equivalent is 0×00002004.
Result in: Less blocking and sd diseaparing fix or slow upload sd when wake-up
More consumption on batery, about 10% more, but with tweak 1 still OK
3. Uncheck today timeout: settings\items\ uncheck Today timeout
Result in: less delay when a phone call income o r standby resume
4. Try to instal the alarm programs and sounds files direct into main memory instead of SD; to avoid sd blocking when standby resume
5. Install .NET Compact Framework 3.5 (last vers) to your device, as:
1. Download .NET Compact Framework 3.5 from Microsoft and save it on your PC.
2. Run the downloaded MSI file and let it install.
3. Connect your device to Activesync/Windows Mobile Device Center and finish the automatically launched installation on your device.
4. Soft reset your device.
5. Open a Registry editor and navigate to HKLM\Software\Microsoft\.NETCompactFramework where you will see two entries for the (now two) existing version references: the old one, which came with your device and the new one you just installed.
6. Change the DWord value of 3.5.7283.00 from 0 to 1 (thus enabling it) and all the other values (i.e.: 2.0.7045.00) from 1 to 0 (thus disabling it/them).
7. Soft reset your device.
Result in: shorter time (gain 0.5 sec) to navigate trough windows menus and buttons actions.
6. Activate lock applet on today menu; Without this function when the phone is in stand-by and a call income the phone delay has about 8-10s to wake-up.
Result in: the wake-up on call is shorter (gain 4-5 sec) than without this lock checked in today settings; somehow WM use this library to pass trowght to wake up.
7. Speed-up the SD card read; tks to edhaas contributor from xda-developers.
Action: increase some SD cache into registry:
a) HKLM>Drivers>SDCARD>ClientDrivers>Class>MMC_Class:
Change BlockTransferSize to 256 decimal
b) HKLM>Drivers>SDCARD>ClientDrivers>Class>SDMemory_Class:
Change BlockTransferSize to 256 decimal
c) HKLM>System>StorageManager>FATFS:
Change CacheSize to 4096, 8192, or 16384 decimal
d) HKLM>System>StorageManager>Filters>freplxfilt:
Change ReplStoreCacheSize to 4096, 8192, or 16384 decimal (16384 is dangeours high, some blank screen at startup)
a), b) settings are regulary set by default to 256; c), d) is by default to 0, so change-it and see if gain some perf.
All of them has tested and works fine.
Apply and now I found my i-mate ultimate 6150 OK, instead of first phone impression when I blame-it.
When I worked on some ARM embedded projects, we used the zero wait state SRAM of the ARM chip to speed up our applications. The performance benefit is tremendous. There is no published way to access it on Windows Mobile, but there probably is a way. Anyone have a clue? Most likely it will be addresses lower or higher than the video buffer.
Thanks,
L.B.
logical quest..
hi.!
I was interested for your topic..
i know that there are some app
that permise you the overclocking
of texas omap...what is this? another
type of overclocking? i think that is
very dangerous way..the risk for the cpu
fusion is high..!so..i don't think that is
a good idea..and the margin that you have
for example with an 200 Mhz processor is minimum for
a good overclocking..if i were you, i should not force the default limit setting by the HTC company.. Ppc device haven't a fan for heat's dissipation (it isn't a PC!) , so when you use the PDA and consequently you make his overclocked cpu under pressure, its go aut of order and..Bang.! do you agree?
What I'm asking has nothing to do with overclocking. The DRAM in PDA's is slow compared to how fast instructions can execute. Built into most ARM CPUs is a small amount of static RAM (usually 256K or 384K) that is usually used for the video buffer. The excess memory is useful for storing data for your applications to run quicker since it won't have to wait for the RAM.
I personally do not overclock my PDAs.
is this a sort of SecondLevelDataCache as Winzozz XP?
devilpera64: This is SRAM as in STATIC RAM. It's a little area of high speed memory (0 wait state) built onto the processor silicon. It's quite useful for use as a video buffer and for speeding up critical sections of code.
This guide is meant for ALL smartphones that runs the Interactive governor, copy-pasted here for better visibility. Credits goes to @soniCron for starting up the guide and @Alcolawl for further implementing it.
The Introduction
So, I tried copy-pasting the entire thread and realised it looks ugly therefore I'll rewrite it to be more simpler and straightforward.
Imagine a car with manual gears, you choose what speed is best suitable for the road conditions. Going into a curve? Best slow down. Clear straight road? Go fast so you reach the destination safely and efficiently.
That's what this guide aims to do with the Interactive governor, based on the CPU load it will choose the best and the lowest frequency to complete the task without compromising performance.
For example, if you scroll your Facebook page your CPU might clock up to the highest frequency for smooth scrolling. Now lower the frequency one step down and you may find that it's still smooth, so why isn't it choosing that instead? Don't blame the phone companies or Google, that's just a way of ensuring performance at all times. This guide will push the limits of that capability.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Click to expand...
Click to collapse
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing lags or stutters. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)
Remember what was said about scrolling FB pages? This is it.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials.
For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
Imagine a staircase with steps of different heights. You climb these stairs better depending on the height of each steps, do you skip some steps if you can reach the next one easily? Or do you take one step at a time because they are too high?
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 384Mhz
Page Scrolling - 600Mhz (Tested by browsing FB on Chrome browser cause they're intensive enough)
Video - 787Mhz (Same thing, watch 60fps videos on different resolutions on the Youtube app to detect stutters and lags)
App Loading - 960Mhz
High Load Processing - 1440Mhz
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Nexus 5X. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 384Mhz nominal
Page Scrolling - ???Mhz efficient / 600Mhz nominal
Video - ???Mhz efficient / 787Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1440Mhz nominal
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 460000:60000 600000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Nexus 5X, the maximal efficient loads of CPU 1 are:
384000:75
460000:69
600000:80
672000:76
787000:81
864000:81
960000:69
1248000:78
For the Nexus 5X, the minimal efficient loads of CPU 1 are:
384000:0
460000:19
600000:30
672000:12
787000:17
864000:9
960000:11
1248000:30
1440000:15
For the Nexus 5X, the maximal efficient loads of CPU 2 are:
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:83
1344000:84
1440000:84
1536000:84
1632000:86
1689000:83
For the Nexus 5X, the minimal efficient loads of CPU 2 are:
384000:0
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1689000:3
1824000:8
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That 2nd CPU?!
So we've all but ignored the 2nd CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Nexus 5X, the system is pretty smart about when to employ the power of this inefficient 2nd CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
384Mhz
1248Mhz
1824Mhz
In this case, we configure it just as we did with CPU 1, but only worry about keeping it idle as much as possible, allow it to jump to 1824Mhz immediately when needed, and encourage it to fall back to 1248Mhz if a sustained load is needed.
These values are ideal for the Nexus 5X, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
For the Nexus 5X, we'll jump straight to...
The Money Shot: Part Deux
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 2. ("big"–the one with 2 cores)
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1824000
min_sample_time - 20000
target_loads - 98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95
timer_rate - 20000
timer_slack - 80000
Click to expand...
Click to collapse
SO there you go, that's the gist of it. I got some smaller examples written up later so hopefully it's more understandable.
"I'm Too Lazy To Read All That! WHAT DO I NEED TO DO?!?!"
If you own a Nexus 5X or 6P, install the ElementalX Kernel and the EX Kernel Manager. (Yes, it works in other kernels, but you're on your own regarding how to set the values. Other kernel editors, such as Kernel Adiutor, are currently buggy and problematic, so your mileage may vary. And if you have another device, you must follow the instructions in this post to derive your own values.)
UPDATE: EX Kernel Manager now supports governor profiles and most currently published profiles are distributed with the manager. To access: EXKM> CPU> Governor options> Load, then select the profile you wish to try! Many thanks to @flar2 for providing native support!
ALPHAS – USE AT YOUR OWN RISK!! (Actually, we really like "GostPepper". Try it out. It's spicy! And don't worry–it won't break anything!)
GlassFish (For most devices!) - High battery savings with buttery smooth interface!
HawkTail (6P) - An advanced, modern profile that is both battery efficient and highly performant! All users are urged to check out HawkTail!
Butterfly - A culmination of all strategies, provides smoothest performance of all currently published settings, though battery savings are a little more modest. Excellent for light and moderate users; heavy/marathon users might want to check out a different setting profile.
GhostPepper (6P) - Uses a quantized, frequency-aligned parametric curve to influence low core clock rates while providing extremely smooth transitions from each clock rate and exceptional battery life. The current favorite, albeit not very well tested so far. HIGHLY RECOMMENDED
SilverFish - Effectively eliminates "hispeed_freq" so perceptive scrolling performance is increased, giving the illusion of excellent performance while providing great battery life. Some users experience problems with performance while multitasking--NOT RECOMMENDED FOR EVERYONE. Light users should enjoy this very much, however.
MadDog - The first major departure from the core strategy. Very well tested, extremely stable, and HIGHLY RECOMMENDED if you aren't fully satisfied with v2.0 settings. This is on the table to be the next stable v3.0, so rest assured you can't go wrong with this one!
DrunkSauce - Supreme UI fluidity coupled with excellent active and idle battery drain. Idle Drain was consistently measured to be ~1%. And while I don't rely on SOT figures that people constantly throw around, active drain spanned from 15-20%/hr depending on usage. YMMV. And as always, flawless audio playback for you audiophiles and ARISE users out there.
Those are the ones compiled for now, please remember that these are all up to the users' preference. It will improve YOUR own SOT, not straight up 8 hours on every device. You can copy off the profiles and use your own device frequency and target loads, use an app like Kernel Auditor to help edit them. It works for stock and custom roms too.
Extra credits:
Thanks also to:
Every developer who has seen this guide, modified it, and implemented it.
All the members who contributed and argued about the inner workings of this guide, your constructive feedback is amazing and helped fine-tune future profiles.
To the poisonous and toxic trash member(s) of a certain thread for their lack of help and elitist behaviour. Their embarrassing attitude helps open our eyes to the dos and don'ts of internet manners.
This is for calculating target loads.
Let me give you an example from my Note 1:
My clock rates are (in MHz): 200, 500, 800, 1000, 1200, 1400
Their voltages are (in V): 950, 950, 1050, 1125, 1225, 1300
If I were to plot the differences in voltage, it would appear like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
From the graph, 500MHz to 800MHz has a huge difference in voltage increase compared to 1000MHz to 1200Mhz. That frequency BEFORE the huge jump is the efficient clock rate: 500MHz and 1000MHz.
So, the nominal clock rate on the other hand is the minimum frequency you can use to complete a task (such as watching videos, loading apps, page scrolling). In this case, mine are: 200MHz, 800MHz, 1000MHz
Now, we just calculate (from the first post) the minimal efficient loads for efficient clock rate and maximal efficient loads for nominal clock rate.
That means my target loads will be:
500: 60
800: 72
1000: 75
1200: 17
I skipped the calculations but this will be what it looks like from there. Someone pls do let me know if I made a mistake, as it does tend to confuse people with other devices.
Nominal clock rate: Maximal load
Efficient clock rate: Minimal load
Edit: Those are for the target loads, for the rest of the settings I'll use the profiles'.
Eh, mmight as well reserve this too
Nice looking guide, about to read
wtf,you just copy pasted in the end
Nice beginning, but half is missing, and you are referencing things that haven't been done before
nstall both apk but antutu doesn't see the 3d bench and always ask to download it, therefore there is no test button, but only down load but that brings you to the market with missing antutu
Why try to run ATuTu 3D Bench?
The issue with it is that it doesn’t actually judge a device based on its overall performance and experience, it just runs theoretical tests on individual components of the SoCs or some other individual part of the whole device. OK, these are not always wrong, they do suggest the capabilities of a CPU or GPU up to a certain extent but are wrong interpretations for the combined system’s performance and experience, IMO.
still you have't been useffull after all these sspeech