yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] bamsbamx:
Motley, i checked 'disable hardware overlay' option.... Frameskips have been reduced a lot!!!! Thanks for the idea, i didnt remind it :D

Does Have this checked drain more battery???
[Nexus 4 Original Android Development] cmikeh2:
I've used the toggle before on other kernels and did not see a noticeable difference in battery life. However, and this may be the result of the ROM I'm using (AOKP nightly releases), but I have had difficulties with that toggle sticking to checked so if the stuttering does return that would be the first thing I'd look at.

On a similar note, I am not seeing any stuttering in all usage cases that I have tested (Netflix, Play Movies, YouTube, Vevo, Video Player, MX Player).
[Nexus 4 Original Android Development] yumcax:
Can someone explain like I'm 5 how to check binning? Where / when do I run dmesg?
[Nexus 4 Original Android Development] TranceWulf:
Restart, wait for it to finish booting, then run "adb shell "dmesg | grep acpuclk"". Should spit out the relevant lines.
[Nexus 4 Original Android Development] Holo_:
The S4 chipset in the N4 is looking more like a pro everyday thanks ;)
[Nexus 4 Original Android Development] danielsf:
_motley just a quick question about SoC binning, on the kernel side can you see the GPU voltage table? If so, are there different voltages for different binned chips please? Thanks :)
[Nexus 4 Original Android Development] aventu:
hey motely, the aokp team is testing a new kernel with a 50Mhz step :eek:

http://xdaforums.com/showpost.php?p=35474848&postcount=743
[Nexus 4 Original Android Development] yurilebbie:
Wow interesting that you could beat Franco himself.

Thanks motley for your great work.
[Nexus 4 Original Android Development] ctfrommn:
The Franco kernel was only running at 1296mhz.
[Nexus 4 Original Android Development] yurilebbie:
#5 which is franco is at 1512
[Nexus 4 Original Android Development] ctfrommn:
Didn't see that.....real world usage tells a very different story though, and I like Motley's kernel. Francos latest is beyond impressive.
[Nexus 4 Original Android Development] 0.0:
Just wondering, will the smartassv2 governor or any other similar governors be added?

Sent from my Nexus 4
[Nexus 4 Original Android Development] aventu:
I think it became a bit obsolete with Project Butter.

I really liked the old Butter method from an older build with 1GHz core0 and a flexible core1 at 304Mhz idle. I haven't seen any performance issues.
[Nexus 4 Original Android Development] efan3719:
just installed this kernel. not really interested in performance boosts. this phone is already stupid fast. i'm really just trying to find the best battery life. looking forward to testing this one out.
[Nexus 4 Original Android Development] 0.0:
I'm having a hard time figuring out which governor to use. To all the users, which has been better or which is better: ondemand or interactive?

Sent from my Nexus 4
[Nexus 4 Original Android Development] UZ7:
I would test it out for a few. Pretty much with Ondemand when an app needs power it goes and gives it max frequency so there is no delay or it will have instant response then gradually slow down when its not being used all the way down to idle mode. With interactive its a little efficient in that once it hits max frequency after an app is loaded it will load another one before the cpu frequency goes down to idle making it a little efficient rather than ramp up ramp down ramp up etc... it has its pros and cons, supposedly thats suppose to save battery but at the same time if you stay too long at a high frequency it kinda negates the battery saving. Its suppose to have better performance than ondemand and because it ramps down a little slower when theres multiple tasks then battery use will be a bit more. But I would test it out first if its to your liking. Some people prefer other governors over others based on preference.

:good:
[Nexus 4 Original Android Development] rlaw:
I favor smoothness and performance, so I use interactive.
[Nexus 4 Original Android Development] 0.0:
I've tried ondemand for a couple of days, then I tried interactive. I can't distinguish the difference in them. What do you use?

Sent from my Nexus 4
[Nexus 4 Original Android Development] UZ7:
Well currently I'm using the default ondemand/sio combo that this kernel has and its been pretty good to me so far averaging 15~ hr battery and 3-4hr on screen time with mild use. There is no doubt the processor is pretty fast so even downclocking the CPU you won't notice much difference in performance if you're only doing stuff like social media apps (fb, instagram, twitter, etc...) if browser and games you may see a difference in response and load time but barely noticeable. Between governors its going to be about efficiency (how it loads/multitasks between the threads) or battery life (if its aggressive or slow or whatever, the longer it stays at a higher frequency the more battery it will take up).

To me ondemand is fast enough as a default governor so that being said if interactive is any faster then you won't really notice it because it pretty much does the same thing, only difference is how it manages apps and loading it for a particular core or thread. I think you will see a slight difference in benchmarks in terms of one having a little higher number but the difference would also come from battery life on use. So if you multitask a lot, interactive will be more efficient but depending on the load of that particular app it will drain a little more if it stays at a higher frequency. As opposed to Ondemand, it'll probably spike up several times but wont be as seamless as interactive, but in all reality though its hard to distinguish unless you've had both of them for several days and you can only tell the difference between the behavior and how it does things.

With my older phone I tested various governors and the battery saving ones usually had less response time and a little chuggy but during low load and idle it was one of the best in saving battery life. So really if one gave you better battery life I would probably just go with that :D
[Nexus 4 Original Android Development] keda:
I find build 38 with cpu capped at 1.4 ghz to be more battery friendly. yesterday I got 22 hr standby with almost 4hr screen time still 27% left. I had to downgrade from build 48 due to battery problem.
[Nexus 4 Original Android Development] _motley:
It's great to score nicely on the benchmarks, but benchmarks can be misleading. There isn't much room on this device when it starts to throttle due to heat. When throttling begins, the benchmark app will report a lower frequency than the max freq the user has set and scores will suffer. I have a "nominal" CPU. and can still hit over 18k on Antutu without any special cooling for my device. The built in UV (and extra tad of UV I apply beyond that with voltage control) is what keeps the device from throttling during these testing runs. Kernels that don't UV are going to suffer on benchmarks unless they raise the throttle temp. There seems to be much more room on this device to UV than there is on most devices.

Interesting...I'm not sure this will show any benefit since code that has to execute at this freq will take a long time, thus keeping the device awake longer. I would be concerned about SOD's, screen off streaming etc., but maybe it is smart enough to ramp up to avoid it. Seems way to aggressive to me, but we'll have to wait to see how it goes and see what the real world testing shows.

As long as project butter is operational (PowerHAL/mpdecision), it's best to use OnDemand or Interactive. I don't like to throw in stuff unless I have tested them and feel that actual value is being added. Otherwise, it's just bloat.

Sounds about right for a fast chip since I have already built in a safe amount of UV into the kernel (it's staggered for nominal vs fast just like they did in the stock kernel). If you phone crashes when you go lower than 1000mV, then it just can't handle it. It doesn't have anything to do with mpdecision though...just needs more juice to be stable. For a fast chip, 1000mV is -150mV from the stock "fast" table. In theory, faster chips may be able to UV a bit more, but this may not be the case in the real world. That's why the fast and faster chips currently share the "fast" table. You can still use custom voltage control to lower to whatever is stable for you...so there is really no need to add a faster table at this time.

For higher quality vids, its probably just better to use MX Player or another equivalent player that uses proper hw acceleration. If you turn this setting on, it's possible it could cause issues for other apps.

For the guy that was on the faux kernel and still stuttering on that vid using MX with hw+ , I can't help with that. I would point that out to him in his thread.
[Nexus 4 Original Android Development] _motley:
Good numbers. What was happening in build 48 that was different? Any specifics would be appreciated.

Thx
[Nexus 4 Original Android Development] UZ7:
Pretty good so far, going to test more the rest of the day for stability. :good:

@PVS Fast

---------- Post added at 11:06 AM ---------- Previous post was at 11:00 AM ----------

Actually I also thought build 38 had good battery and I stayed on that one till 48 came out but when I tested out 48 (w/ 41 fixes) it had more response/snappy feeling but that was due to the touchboost tweak but so far I've been using 48 since release and it has been pretty good throughout the day.
[Nexus 4 Original Android Development] _motley:
Here is my last run from build 48 to compare. This is with my sub-par "nominal" CPU...lol. It's nice to have decent scores, but I wouldn't sacrifice for battery.

About battery and the comments about the previous builds, maybe I should try to bring back the commit where I only allowed one core to be "buttered" instead of two. It felt less smooth to me, especially after screen on, so I reverted. Was everyone else having the same feeling in that build, or couldn't you tell the difference?
[Nexus 4 Original Android Development] dwang:
Previous versions were laggier than 48.

I want battery life as much as anybody but not at the sacrifice of performance.
[Nexus 4 Original Android Development] _motley:
Thx for the input. My feelings exactly.

Nobody wants cookies with only a half stick of butter;)
[Nexus 4 Original Android Development] ptesmoke:
or half a cup of milk lolol
[Nexus 4 Original Android Development] Harsh:
Its already added at codeaurora, check this :).. maybe you can add bit more for ppl with better chips.

For me its same as you "NOMINAL" CPU :highfive:...
[Nexus 4 Original Android Development] _motley:
Thanks. This was added one day ago...I need to go back and see what else they have done:) Good to see the nice folks at Aurora busily working!

For those that have "faster" chips and are wondering what this means...Not much really since the "fast" and "faster" already share a table in this kernel that is already undervolted. The stock faster table when released will be 1125mV (unless they change it) and my fast and faster shared table is currently 1050mV. We'll probably tweak a bit in the next release to add the the "faster" table just to stay in line with what will eventually be released in the stock kernel. Need to decide on the offset from fast though...probably just a hair lower for faster.

P.S. if you haven't been around in a couple days, see post #2.

http://xdaforums.com/showpost.php?p=34825979&postcount=2
[Nexus 4 Original Android Development] rlaw:
http://imgur.com/a/pxycr

My voltage table changed. How?
[Nexus 4 Original Android Development] siberian85:
So far I have seen great battery life

With this kernel
[Nexus 4 Original Android Development] rlaw:
Nevermind, I got it sorted out. Strange bug with faux123 app. Was also the reason I wasn't able to set my voltage lower before, it wouldn't allow me to. That's what I meant by not being able to go under 1000mV for 1.512GHz - I didn't have the option to, not that I had been able to test my device lower than point. I had thought that might have been mpdecision related but I see now it was a bug with the app.

I have been able to test it out now, though. 987.5mV is the absolute lowest my phone can handle. 700mV for 304MHz seems to be a hard coded limit, though, cos that sucker ain't budgin'.

I wonder if the guy with the faster binning who said he couldn't go lower than 1000mV for 1.512GHz is experiencing the same bug I am with the faux123 app or if he meant his device couldn't handle it?

Edit: oh and I've gotten great battery life with this kernel, too! 42% battery left with 12hr45mins off the charger and 3h3m of screen on time. I use the codefireX ROM with this.
[Nexus 4 Original Android Development] yumcax:
Wow, I'm getting some crazy awesome under volting with this kernel.

http://www.imgur.com/IeEOs.png

And here's the Antutu results:

http://www.imgur.com/1E8Rk.png

My cpu is binned Fast. I wish there was a lower minimum voltage than 700mV, I feel like since phones could handle it...
[Nexus 4 Original Android Development] meangreenie:
wow, what are your settings that you get 20000 on 1296mhz?
[Nexus 4 Original Android Development] 0.0:
im getting a yellowish screen with this kernel. will it disappear as time goes on?
[Nexus 4 Original Android Development] wurzelsepp3:
It's in the feature list but does it really work??

Up untill now there is no Kernel with working USB-OTG, and there are even specualtions that the hardware doesn't support ist at all.
[Nexus 4 Original Android Development] pnut22r:
+1

Thank you to the previous poster who quoted the op, I already read that. But I wanted to know if anyone had any real life experience with it working. As this poster mentioned, I haven't heard of anyone who has it working.
[Nexus 4 Original Android Development] _motley:
Nothing has changed in the area of GPU, panel, color adjustments etc. Are you using some other method to control colors?

Sorry guys, I copy and pasted the base post from the N7 kernel as missed that tidbit in the edit. I will fix it now.
[Nexus 4 Original Android Development] SleemLDJ:
Confusing
[Nexus 4 Original Android Development] 0.0:
nope, nothing. its weird...im trying out this other kernel, and the yellowish screen goes away :confused:
[Nexus 4 Original Android Development] _motley:
Interesting. That's faux's app right? I have been using System Tuner and the min/max look correct there as I would expect. I do see the min frequency jump up peridically in System Tuner due to the powerhal 1.026GHz on touch (project butter). Does faux's reset kernel replace the powerhal back to the stock version? I wonder if you have some conflicting pieces and parts after flashing his kernel and then this one. This kernel is much closer to stock than his and I have only tested with the stock powerhal library.
[Nexus 4 Original Android Development] kaiowas82:
Is this working on cm or does it meet repacking?

---------- Post added at 03:40 PM ---------- Previous post was at 03:27 PM ----------

Yes its working
[Nexus 4 Original Android Development] apascual89:
Good to see you back Motley! Just to report working great on Paranoid Android
[Nexus 4 Original Android Development] italia0101:
What app is that btw?
[Nexus 4 Original Android Development] lnfound:
https://play.google.com/store/apps/details?id=eu.chainfire.perfmon
[Nexus 4 Original Android Development] ibegary:
That would explain why SetCPU would jump to 1026 minimum (for project butter). Since the system will be at a higher minimum clock then the battery life is impacted correct?
[Nexus 4 Original Android Development] _motley:
Thanks for the feedback, great to see you over here. Yeah, it's been awhile:o

Yes, that is it. They kick it up to 1026 on screen input and then it settles down after a brief moment once you stop touching (well that sounded kinda funny haha). It does impact battery a bit since it doesn't wait for the governor to handle the request for input, but I will vote to keep that buttery feel that made Jellybean a step above ICS and previous version of Android.
[Nexus 4 Original Android Development] italia0101:
Awesome app thanks ! . just wondering .. What's the reason for only two cores working when it most games... Like gta3
[Nexus 4 Original Android Development] terranox:
Im install your kernel, i will report

Enviado desde mi Nexus 4 usando Tapatalk 2
[Nexus 4 Original Android Development] tpboi:
Flashed your kernel and undervolted using the table included. Ran stability test app. Never crashed or restarted. Very smooth so far, will report back if anything came up.
[Nexus 4 Original Android Development] jaxenroth:
Couldn't get to boot on cm, i thought i read it was compatible?

___

Sent from my Phone...
[Nexus 4 Original Android Development] _Opiate_:
Kernel needs to be repacked for CM. You can find what you need in faux's thread. Page 42
[Nexus 4 Original Android Development] _motley:
Did you use the any kernel zip or the boot.img flash? The latter definitely won't work since the whole ramdisk is replaced with the aosp version. You should not need to repack if using the any kernel zip, at least one would hope they use the same ramdisk offset as stock. I will take a look later at the CM ramdisk if it doesn't work.
[Nexus 4 Original Android Development] ptesmoke:
Getting the crack flash fever again. Just wondering what your running motley...stock rooted?
[Nexus 4 Original Android Development] yumcax:
The test was at 1.5 GHz, it just shows that for side reason (throttling? It never got particularly hot...)
[Nexus 4 Original Android Development] ptesmoke:
I'm at the same UV as you. My chip is binned "faster" .

Gonna go even lower tomorrow and test.
[Nexus 4 Original Android Development] yumcax:
If you can, post your CPU binning to this poll:

http://poll.pollcode.com/qars3c
[Nexus 4 Original Android Development] jacklebott:
That's the results page, how do you actually contribute? Also, surprising amount of "Fast"
[Nexus 4 Original Android Development] yumcax:
Whoops, fixed it.
[Nexus 4 Original Android Development] j.llorente:
My cpu spy said that 1026mhz is used more than other. My use is: 1512,1026 and deep sleep. Other frequency is used insignificantly
[Nexus 4 Original Android Development] UZ7:
What governor are you using? Sometimes the governor is set to only use certain speeds at certain states, low, mid, high. Other times it could be the program set not to use a lot of power. From my use it was either 300, 1GHz or 1.5GHz but that could also depend on the load and it could be 1ghz 2 cores vs 300 4 cores etc... so it will also depend on the tweaks on the kernel.
[Nexus 4 Original Android Development] j.llorente:
I'm using ondemand. But...1026mhz use is more more more than others, and I can't choose 300mhz with incredicontrol. I push 300mhz but after a lot of seconds frequency rise to 1026. At other forums(htcmania and htcspain) I can see other kernels that works correctly(photo attached) https://dl.dropbox.com/u/357276/Screenshot_2012-12-17-07-33-49.jpg

And...yes, this kernel have got 50mhz, that's incredible!
[Nexus 4 Original Android Development] UZ7:
Haha 50Mhz? thats awesome.. I miss low frequencies. My old phone had 192MHz and I remember using pandora for 2 hours and it stayed at those speeds meaning the app doesn't need that much power so I was hoping in future releases they have 300> :D
[Nexus 4 Original Android Development] JmPTaz09:
Been testing all the kernels and I'm back to Motley for smoothness and battery life. :beer: running great on AOKP.
[Nexus 4 Original Android Development] ptesmoke:
Stable...going lower tomorrow.
[Nexus 4 Original Android Development] dwang:
Agreed...

While I appreciate franco and faux's efforts at replacing powerhal and mpd with their own governors, i've found both kernels to be laggy compared to motley's kernel.
[Nexus 4 Original Android Development] jacklebott:
Probably because motley uses Linaro optimizations. Both faux and franco say it's too unstable to include in their kernels though :crying:
[Nexus 4 Original Android Development] UZ7:
Hmm not sure how to define "unstable" as I've used 38 and 48 on day one of its release and have not had any hiccups. Averaging 15~hr // 3-4hr on screen mild use. I'm testing franco's r15 atm but may be switching back to motley very soon :P we'll see.
[Nexus 4 Original Android Development] jacklebott:
And that's my argument as well, but they're dead set on not including Linaro optimizations...
[Nexus 4 Original Android Development] 0.0:
A friend of mine says faux is super smooth to him. I think all these kernels will pretty much have the same performance for now. Kernel development only started about a month ago. I never tried faux, but I tried this one and Franco's. Both seem roughly the same to me. We just have options, and that's good :)

Sent from my Nexus 4
[Nexus 4 Original Android Development] UZ7:
Yeah pretty much this phone itself is beast so its really hard to slow it down, if it does then its within coding and messing with certain features so its really hard to tell in comparison. My testing is usually from using it several days and just plain use it as I would a regular phone. If at one instance I get any issues or phone becomes unstable then thats when I report it and/or if it doesn't get attention then I move on :) love having the options though. :good:
[Nexus 4 Original Android Development] 0.0:
Its very tough to actually find issues now...nexus has the source, and its fast, like you said. I really don't think linaro does much for this phone. Maybe on single core phones, but not quad core with lots of RAM. I think management of the cores is the important thing now. The only kernel problem is stock. Stock sucks on all levels lol

Sent from my Nexus 4
[Nexus 4 Original Android Development] UZ7:
Haha yeah thats true, the roles have switch from being hardware limited to now software limited. Thinking by the end of this month early next month we will see a lot of software changes and optimizations or hopefully :fingers-crossed:, right now just getting used to the behavior of the phone. Still has a lot of raw power but so much unoptimized stuff.
[Nexus 4 Original Android Development] _motley:
I have built several kernels using the Linaro toolchain with compiler optimizations and also built the same kernel using the typical Google toolchain or Mentor Graphics toolchain (aka Code Sourcery). I have never experienced any stability issues caused by the Linaro toolchain. I would like to see information that supports this claim. If you build parts of the kernel with optimizations that causes problems (wifi etc.), this can easily be overcome by building those parts of the kernel without optimization. Since I have received my N4, I have not had one reboot or SOD running the stock kernel or on the custom Linaro-built kernel. Neither toolchain is more stable than the other. However, the 4.7 Linaro optimized toolchain can produce more efficient code than the 4.6 Google toolchain.

How beneficial these differences are can be argued, but the stability of the overall kernel shouldn't be. Just as a simple example, if the kernel has a function that executes 1 milliseconds faster using optimizations, this might not seem like a big deal. However, if this function is executing 1 million times per a day since it is involved in frequency management, then that is ~17 seconds saved per day for this one function.

Just my 0.02 :)
[Nexus 4 Original Android Development] richteralan:
Great explanation!
[Nexus 4 Original Android Development] morfic:
You ought to try Google's 4.7 even if it would only be to compare apples to apples.

Been using linaro for over a year now, for a long time Google stayed at 4.4.3 and there was no comparison to linaro's 4.5 and 4.6.

Both Google's 4.6 but especially 4.7 have come a long way, don't count them out.
[Nexus 4 Original Android Development] ptesmoke:
Hey motley :)

Any chance you might be merging in the new color settings? Basically it has Google and LG presets as well as gamma control.

I think its only avail in Franco and faux kernels right now. Here's the color thread...

http://xdaforums.com/showthread.php?t=2039607

Nexus 4 Color Settings [spreadsheet]