• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [KERNEL] MiRaGe - for HTC stock ICS ROM - 3.0.101 - 10222013

I have noticed that Antutu benchmark is giving inconsistent results. This isn't a Mirage problem because it also happened with Mac 4.0 and Harmonia. This program went through a series of updates over the last few months that resulted in generally lower scores.

The cause of these inconsistent results is not completely clear to me. I suspect that host file ad blocking may play a part because when I disabled adblock I was able to get some results that made sense. It could be something else.

I found a Linpack program by Roy Longbottom that gave consistent results that scaled with cpu speeds. I used the neon version.

At this time I am experimenting with Passmark. Deadline shows a small advantage over SIO on this benchmark, but not every single run. Performance showed no improvement over interactive on either Passmark or Neon Linpack. I believe that to be a good result.
 
The inconsistency of Antutu benchmark (and others) is mainly due to background processes of Android. In the background, Android speculatively loads apps and also kills them when memory is needed. Additionally several/many sync processes run in the background. On top of all, there is htc's mpdecision task constantly stopping the second core, if you have not deleted it. Android does so much more in the background than the desktop operating systems. This kind of inconsistency is normal and expected. If you want to benchmark, the best time is after keeping the system awake for several minutes without opening too many apps, disabling sync can also help. I check the cpu load of running background processes using System Monitor lite and freeze the unneeded ones using link2sd.
 
I did some testing on the parasitic noise issue. It is the same with the stock kernel and worse running Mac 4.0 with Harmonia. Searches revealed the problem is widespread on this hardware and usually noticed with low impedance headphones.
 
ron scubadiver said:
I did some testing on the parasitic noise issue. It is the same with the stock kernel and worse running Mac 4.0 with Harmonia. Searches revealed the problem is widespread on this hardware and usually noticed with low impedance headphones.
Click to expand...

Thank you. This kind of investigation is very helpful. I am still not able to replicate it, probably due to different headphones.

Edit:
I am not able to edit the OP due to an error given by the androidforums web server. I will check back later, you can check the xda thread for today's build for now.
 
I will flash the 4/28 in a few minutes. 1512 default is preferred, I rather not need Nofrills.

I am wondering with the latest changes if mpdecision should be put back in. Easy enough to try. Could you measure the effect?

If the headphones do not provide isolation, environmental background noise will mask the parasitic noise. Active noise cancelling headphones generate their own low level signal and would not show the effect.

edit: definitely more responsive while scrolling in ES file Explorer with mpdecision deleted.
 
ron scubadiver said:
I will flash the 4/28 in a few minutes. 1512 default is preferred, I rather not need Nofrills.

I am wondering with the latest changes if mpdecision should be put back in. Easy enough to try. Could you measure the effect?

If the headphones do not provide isolation, environmental background noise will mask the parasitic noise. Active noise cancelling headphones generate their own low level signal and would not show the effect.

edit: definitely more responsive while scrolling in ES file Explorer with mpdecision deleted.
Click to expand...

It was such a relief getting rid of it, I wouldn't put mpdecision back in there for any reason.

Thanks for the feedback. Please also report if you see any improvement in battery life. I was getting around ~2.5% per hour battery use when I leave the phone over the night. Last night's test gave 1.8% per hour. I also see less drain during the daily use.
 
I will have to do an overnight test. Due to my recent events like a 5 hour time change followed by an 8 hour power outage, that has not been possible. I suspect that my results will be better than yours because I have nothing syncing automatically, very few apps to start with, and tons of stuff deleted or disabled using the native ICS features. Try TrevE's logging test app available over at XDA to see what kind of crap is going on.

Rather than use an app, I rely on the browser heavily. I am very "old school" and can remember when a decent word processing program, Wordstar, could fit on a 160 k-byte floppy and run in 64 k-bytes of memory on a processor that would not power a $50 phone today. I am more likely to ask a dev to take something out than add something in.

The difference that removing mpdecision made was startling.

[BTW I have lots of new photos from the Big Island of Hawaii up on my blog]
 
ron scubadiver said:
I will have to do an overnight test. Due to my recent events like a 5 hour time change followed by an 8 hour power outage, that has not been possible. I suspect that my results will be better than yours because I have nothing syncing automatically, very few apps to start with, and tons of stuff deleted or disabled using the native ICS features. Try TrevE's logging test app available over at XDA to see what kind of crap is going on.

Rather than use an app, I rely on the browser heavily. I am very "old school" and can remember when a decent word processing program, Wordstar, could fit on a 160 k-byte floppy and run in 64 k-bytes of memory on a processor that would not power a $50 phone today. I am more likely to ask a dev to take something out than add something in.

The difference that removing mpdecision made was startling.

[BTW I have lots of new photos from the Big Island of Hawaii up on my blog]
Click to expand...

It seems we are using our phones in very similar ways. I don't delete but freeze the unwanted apps in the original ROM since deleting them becomes trouble when applying an OTA update. I have also disabled sync for everything other than contacts, calendar, gmail and I check the other email using browser instead of installing other mail apps. Likewise, bloated software is something that really annoys me. I remember Wordstar, Lotus123, Turbo Pascal, etc. Software development changed so much since those days. Developers got spoiled with the excess amount resources and DOS turned into Windows we use today. With Android, I am living the nostalgia we had in the DOS days where we had only 512KB RAM, no harddisk, and we had to optimize the code so that we don't waste our time waiting for 8MHz CPU. Although this EVO is at least an order of magnitude faster than the $100K HP Apollo I had used in the graduate school, optimization still makes a huge difference due to limited resources for the extremely rich capabilities Android offers. I love the Android environment because of this challenge. I really love it since sloppy coding is punished. So let me know if you find something that can be thrown out. I will be very happy to do so.

I checked your Hawaii pictures. Beautiful is the only thing I can say. Can I carry your camera next time? :)
 
Here is a data point on battery:

At 2:15 pm I had a a green led and disconnected the charger. A bit later I went out and rode my bicycle 14 miles at a leisurely pace with the phone in my pocket. The bike ride was through an area with good coverage, although I did go under a few bridges. There were a few time checks, not more than 5 and at 8:15 had 97%. Anyway, I think most people would be happy to get that with 6:15 on their night table while snoozing.

I will try that next.

edit: 96% at 9 PM, that's 7 hours and 14 miles.
 
ron scubadiver said:
Here is a data point on battery:

At 2:15 pm I had a a green led and disconnected the charger. A bit later I went out and rode my bicycle 14 miles at a leisurely pace with the phone in my pocket. The bike ride was through an area with good coverage, although I did go under a few bridges. There were a few time checks, not more than 5 and at 8:15 had 97%. Anyway, I think most people would be happy to get that with 6:15 on their night table while snoozing.

I will try that next.

edit: 96% at 9 PM, that's 7 hours and 14 miles.
Click to expand...

Thanks for testing. I think your observation is even better than mine due to your controlled sync settings. I have tried last night again and I got around 1.8% per hour battery drain with mainly standby and sync/data enabled. As I wrote before, I was not able to go below 2% before. But so much for my testing, I need test a couple changes and reboot my phone several times today.
 
I did the night table test last night, 8 hours without touching the phone (literally) starting at 10 pm with a green led and 100% charged. After 8 hours the battery widget read 99%. It does not get any better than that.

Remember, I have autosync and Google location services turned off. Network and WiFi were on, bluetooth and GPS off. No apps are installed that check for things on their own and very few altogether. These are probably the kind of settings used by manufacturers to get their very long advertised standby times.

Next time I will try it with Google location services on.
 
nsciucco said:
Deleting mpdecision was a good move. It increases battery life and responsivenss
Click to expand...

And the purpose of mpdecision was shutting down the unused core for saving battery. But it is implemented so poorly that the shutdowns were occurring too frequently and this was turning into a considerable overhead for the first core. The result is constantly stuttering interface, keeping the first core constantly at higher-than-minimum frequency, and extra battery drain.

With the mpdecision removed, the second core still shuts down when the screen turns off. When the screen is on, both cores idle at minimum frequency most of the time when there is no user interaction. Additionally, there are actually c-states of the CPU itself which means that the idle cores still shut down the unused parts of their circuitry.

There is a new kernel-level implementation of mpdecision for msm-3.4 at CAF. I checked the code and I am still not convinced about its value. I might try it in the future when there is no better thing left to do in this kernel.
 
From what I've seen Dual Core or not if the screen is on it doesn't really make too much of a difference. The Screen is what really eats your battery. However I'm pretty sure its better to have only 1 core on with the screen off.

Also when it comes to battery life its better to have a faster processor that stays low and occasionally peaks then to have a slower one that is constantly at its max.
 
mrg666 said:
I have included... CPU voltage table after requests over at XDA.

Actually, I will not do anything else for a while. Later.
Click to expand...

What does a CPU voltage table do?

Here is what I want you to add:

Set the phone down next to a bottle of white wine. In 1 minute the wine is cool and the cork is out. :)
 
ron scubadiver said:
What does a CPU voltage table do?

Here is what I want you to add:

Set the phone down next to a bottle of white wine. In 1 minute the wine is cool and the cork is out. :)
Click to expand...

You can use the voltage table to crash your phone by playing with my fine tuned voltage profile. ;)

Actually, I was planning to make the phone join me for dinner after that easy wine trick. :cool:
 
I have overhauled the CPU/GPU overclocking.
- added a faster (467 MHz) bus speed to support 1.6 and 1.7 GHz CPU frequencies.
- modified the low 3D frequency to save battery (high is same)
- modified the low 2D frequency to save battery (high is same)
- added cpu voltage table

These are critical changes. You will probably see a faster kernel or a crashing phone :p

ronscubadiver and I have tested and didn't see any problems. Please test and make sure this works with your phone if you are planning to stick with MiRaGe kernel. And let me know if you find any problems or improvements. Next build will be posted on 5/4/2013 together with Linux 3.0.76, a very nice date for a release, to give time for testing. Thanks everyone!
shooter_test_kernel_754.zip
 
masterchief3k said:
I'd love to know where they came up with the '12.5 day standby' figure. really.
Click to expand...

I would say no carrier installed apps, no Google location, no auto sync and no checking. They probably can tell when the battery is dead without turning the phone on by using some gadget to see if the radio is still on.

Remember, the screen is the power hog. If it stays off, the battery lasts a lot longer.
 
I was going to post this two days later but it seems I won't be around at that time. This is tested long enough without any complaints. So here is the latest MiRaGe kernel build.

- synced with Linux 3.0.76
- GPU overclock has been revised
-- 266 and 160 MHz 2D clocks are added to 200 MHz
-- lower 160 MHz 3D clock added to save battery
- CPU overclock has been improved
-- 467 MHz bus speed added to add performance at 1.6 and 1.7 GHz CPU clock
-- all of the lower bus speeds are bumped up slightly for balanced performance
-- CPU voltage table added for user control
- Default CPU frequency is again 1.5 GHz

Enjoy!
 
You must log in or register to reply here.
Back
Top Bottom