Been testing the processor out on my Galaxy Nexus. I rooted it and installed a custom kernel (GLaDOS). Some of my observations.
First off, the kernel control program has options for nearly everything: sound enhancement, screen coloring, vibration control, MPU/Core/GPU adjustments, voltage tables, and more. It's a blast to work with since long pressing any option usually gives you an explanation as to what it does.
First off, core speed adjustments. The core or bus speed is usually involving the RAM. Running at 400 MHz, the program adjusts it up in percentages. Therefore, 110% equals boosting the core speed to 440 MHz. Strangely, I noticed markedly weaker performance.
This is likely due to the fact that the governor for the kernel, Wheatley, is a specially designed version for the phone itself. It works by keeping the processor at its highest frequency set in order to conserve battery. As insane as that sounds, it works. Think of using cruise control on your car to help fuel efficiency and how acceleration reduces it when you start off from a complete stop. The same thing applies here. Forcing the CPU to ramp up, as with OnDemand, the stock governor across most Android phones, wastes energy. I've sampled OnDemand, Wheatley, and Performance (for benchmarking) and have noticed much better response and battery life with Wheatley which is what I maintain for daily use. Core boosting really only seemed to assist benchmarking. Day to day use was impacted negatively. It also was unstable. Approximately one out of four times when I would adjust it, I would suffer a reboot.
MPU adjusting or the stereotypical thought of overclocking is by adjusting the frequency sets for the CPU. My kernel allows for up to 2 GHz, but this varies greatly between chips. My phone can obtain 1.6 GHz before it suffers reboots and freezes. Performance increased across the board from day to day use and benchmarking. Battery life was impacted only slightly and there was obvious heat increases. For maintaining the life of the battery and CPU, I don't think it's good for long term use. The control program also has live OC which allows you to step up the speed in percentages. This can boost performance and speed in a more controlled manner than just jumping to a different frequency set. However, the trade off is reduced stability. My phone may be able to exceed 1.6 GHz, but it will require live OC and voltage increases.
GPU overclocking sets at either 384 or 512 MHz. 384 MHz provides excellent performances boosts with negligible battery impact. 512 MHz also boosted performance without battery impact, but resulted in screen tearing and artifacts. The only way to mitigate this was to boost the core speed. Likely an issue with RAM bottlenecks as the phone wasn't intended to be pushed to this level of speed.
Voltages are controlled in the program and the CPU has a system called Smart Reflex Voltage. This combined with the control program tells me exactly what the optimum voltage is for each frequency set. Adjusting this to the optimum dramatically increased battery life with no stability loss. An amazing idea that really works out. You can adjust even lower to some degree in case the system didn't calibrate correctly, but I wouldn't jump more than 10 at a time for safety. Sometimes when you do reduce it actually re-calibrates it to your value proving it could go just a little lower.
A few other options can boost performance. FSync control reduces I/O operations increasing speed and battery life, but a crash can result in lost data. TCP congestion scheduler settings can boost data speeds. The default is set to westwood, but I found that Reno increased both ping and download speeds. The other two schedulers reduced speeds to a small degree instead.
I haven't done anything with the I/O schedulers. In the past, I've rarely seen much difference in performance. At least on this type of phone. Some earlier phones with weaker processors benefited from a change in scheduler, but with Project Butter, I see no real differences in performance pertaining to this as the only other scheduler is noop which is very similar to sio anyway.
Overall, the kernel and CPU performs admirably. The only real adjustments I found beneficial in the long run were boosting the GPU slightly, undervolting the processor, and TCP adjustments.
Update: I've found that my processor can achieve 1.712 GHz before suffering freezes and reboots. I'm going to be looking into whether underclocking the phone with Wheatley benefits the battery in any way soon.
Thanks for this post. I was really looking into some information on core clock speed and overclocking and this really helped a lot. However on my Galaxy Nexus overclocking the core made a huge difference in performance. It's working perfectly stable at a core clock speed of 130%. Even at 1.2Ghz it's getting Vallemo scores higher then a the Galaxy S3 dual core, and at 1.63Ghz much faster then even the OneX. I noticed bringing up the share to menu used to take a few seconds and now it's a fraction of the time. My 3d scores at 1.63Ghz with 130% core have significantly improved compared to stock core and cpu speed. Nenamark 27fps now 42fps scores, GLbenchmark from 31pfs now 44fps. Not sure why you're seeing a slow down but for me it's really made a huge difference. This is all while running ParanoidAndroid 2.99 and ak.536.42 Dummy kernel. With Franko kernel 342 I've been able to clock it as high as 1.8Ghz with no stability issues but with almost no gains over 1.63ghz. It gets so hot after two benchmarks that it'll automatically shut down with additional cooling. Thanks for the good information. Thanks.
ReplyDeleteI'm glad you found my post informative. Seeing as how you pushed it to 130% core OC, I attempted to go as far as I could. I maxed at 120%. Every chipset is different. My old Nexus One could do 1228 MHz while my Nexus S wouldn't undervolt for shit. Seems like you got a good strong chipset to be able to go that far.
ReplyDeleteThe GLaDOS kernel was really designed to be ran as stock as possible on speeds. I've switched away from overclocking to attempting to reduce I/O lag wherever possible. Right now I'm working with Seeder, Lagfix, and toying with the sysctl settings in the kernel to make the system more responsive.
I think a big problem with the Galaxy Nexus and Android in general is it really needs at least 2 GB or more of RAM. The Galaxy Nexus allocates 300 MB to the GPU alone, leaving a pitiful 694 MB for the main system. We really need to have more RAM or dedicated RAM for the GPU. That right there would give these phones some serious performance gains and would free up a good deal for the system. I have plans on getting the Nexus 4 when I have the money.
Android in general is it really needs at least 2 GB or more of RAM... More than Windows 8? I think you overreacting
DeleteWell, Windows 8, which I assume functions the same as 7, only loads programs in memory when they are in use. Whereas Linux attempts to keep programs in memory even after they aren't being used in order to maintain quick loading.
DeleteYou really see it working as a chain when you move from say a program with coordinates immediately to Google Maps and there about. Eventually, memory gets full and Linux starts clearing out the oldest program/process. In that moment, you get stutters and lag, as well as the lag to reload an older program you were using.
This is why many low end Android phones benefit from minfree programs. They attempt to keep a minimum amount of RAM at all times. You still suffer the lost of the last program, but it mitigates the stutter by not slowing it down.
With my Nexus 4, I was able to not require minfree values and keep a dozen or more programs in memory. Overall, it smoothed out performance and lag. Now, I won't doubt that faster processors and RAM will help continue to reduce to stutter and lag, but overall more RAM is a huge benefit to Linux in general.