yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] el_charlie:
I applied those settings too and still experienced some microstutters. The weird part is that on M1 there are NOT any microstutters or lag of any kind. I find 119 snappier for everything, even in games, but I can't stand any microstutter. It's a weird experience.

It happens more frequently when using twitter an tapping a link to open Chrome, you'll notice the stutter in the transition animation.

Cheers!
[Nexus 4 Original Android Development] sirxdroid:
Thanks! Does the stock/Franco kernel set different voltages depending on the CPU bin or they are all set the same regardless of the bin?
[Nexus 4 Original Android Development] alanwyl:
http://xdaforums.com/showpost.php?p=38744144
[Nexus 4 Original Android Development] blueren:
More so while opening the gallery or the camera. But hey! franco is probably already up to something as usual :D
[Nexus 4 Original Android Development] scream4cheese:
I think they're set based on it's bin. The kernel doesn't touch the voltages when installed.
[Nexus 4 Original Android Development] steviewevie:
Yes, slow uses one set of voltages, nominal uses another set, and fast/faster share a third set of voltages.

Sent from my Nexus 4
[Nexus 4 Original Android Development] hospital349:
Franco r119 is treating my device with absolute dignity & respect. :good:

The defaults wasn't quite doing it for me, I felt some mini-stutters. Nothing too drastic, mind you. I'm just really picky about performance. I have a need for speed.

I made the following changes to create a blazing fast experience w/fantastic battery life:

Hotplug Control > High load: 95, Medium load: 25, Low load: 50

Governor Control > timer_rate: 25000, min_sample_time: 50000

Taste the difference. :cyclops:
[Nexus 4 Original Android Development] Tarun95:
Not sure they actually can handle different voltages based on their type. I have a slow type and I uv'ed all by 150mv and its running great.
[Nexus 4 Original Android Development] gharrrrrr:
I still don't understand what these "microstutter" complaints are. This is a quad core, 2 gbs ram PHONE. If it "stutters" for a second I don't take notice because it's certainly not long enough to be concerned about. Talk about first world problems.

Sent from one device or another.
[Nexus 4 Original Android Development] sirxdroid:
OK, but Francisco says that 114 is an invalid value. Is it an invalid value in the fKu app only or in the kernel too? If it's invalid for both, then the kernel uses an invalid default value :)

Same for the saturation, the default value returned by the kernel is 80 but it shows up as 0 in the app.
[Nexus 4 Original Android Development] hospital349:
No complaints here, I f*cking love Franco Kernel... but this wasn't occasional, this was apparent and quite regular whilst scrolling through apps.

...and yes, this is a quad-core device we're talking about here. I wouldn't expect anything less than close to zero stutters. For me, this is the point of Kernel & ROM development. Speed and battery optimizations.

All I can say is: not everybody is the same as you. Some people actually give a sh*t about these 'first world problems'. ;)
[Nexus 4 Original Android Development] Net.silb:
Even if it was a hexa-core 8gb ram phone, the micro stutters would still exist. It's all a matter of adjusting the tunables and balancing between battery life and performance.

No micro stutters = less battery life

More micro stutters = more battery life
[Nexus 4 Original Android Development] thebryceee:
Is it okay for medium load to be 25 and low load 50? I thought it'd be the opposite.
[Nexus 4 Original Android Development] :
Equating stutters and battery life is really spreading lies, I get similar battery life between kernels (Franco, Harsh, Stock PA), I'm not a special case either so I think you should stop with such misleading statements
[Nexus 4 Original Android Development] nachordez:
Surely you mean medium 50, low 25 :p

Sent from my Nexus 4, stock, Franco's last nightly
[Nexus 4 Original Android Development] hospital349:
Nope. The way I wrote it was correct. I want my cores to switch on quickly and to offline sooner. The stutters I talk of disappear and I'm experiencing fantastic battery life. Probably going to hit around 5 hour SOT at this rate. Medium usage. Plenty of streaming, internet and some gaming.

I was using Trinity for a while until recently. I found the performance to be better, but battery to be a little less than Franco. However, I'm finding r119 (with my current settings) to be on par with Trinity's performance, but with battery life still intact. :good:

This is obviously my own personal experience of r119, but hey, that's what these threads are for: projecting your own personal experiences, reporting bugs and giving thanks.

Everyone has their own vision of how they want their device to run. After experiencing beastly performance with Trinity, my expectations soared high. Surprisingly, Franco raised the bar yet again, so it seems. :)
[Nexus 4 Original Android Development] itsaizy:
How to find what type of binned is my processor.? I want to try UV a bit.
[Nexus 4 Original Android Development] jan.ringas:
I just experienced a sudden reboot with the phone just sitting next to me. I'm running the latest nightly (119), the last_kmesg is as follows

ret_fast_syscall+0x0/0x30)
[74253.703337] Thread-1328 R running 0 17362 173 0x00000001
[74253.704070] Backtrace:
[74253.704466] [<c0899b18>] (__schedule+0x0/0x5e4) from [<c089a234>] (schedule+0x38/0x78)
[74253.704863] [<c089a1fc>] (schedule+0x0/0x78) from [<c00c2060>] (futex_wait_queue_me+0xf8/0x120)
[74253.705107] [<c00c1f68>] (futex_wait_queue_me+0x0/0x120) from [<c00c2bdc>] (futex_wait+0x184/0x250)
[74253.705473] [<c00c2a58>] (futex_wait+0x0/0x250) from [<c00c4228>] (do_futex+0xe8/0x9f8)
[74253.705870] [<c00c4140>] (do_futex+0x0/0x9f8) from [<c00c4bd0>] (sys_futex+0x98/0x174)
[74253.706267] [<c00c4b38>] (sys_futex+0x0/0x174) from [<c0010b80>] (ret_fast_syscall+0x0/0x30)
[74253.706481] Thread-1328 R running 0 17376 173 0x00000001
[74253.707244] Backtrace:
[74253.707640] [<c0899b18>] (__schedule+0x0/0x5e4) from [<c089a234>] (schedule+0x38/0x78)

No errors detected
Boot info:
Last boot reason: watchdog
[Nexus 4 Original Android Development] steviewevie:
Indeed, the binning is only a guideline. Someone with a "faster" processor might well find out it doesn't UV as well as someone else's "slow" processor. You have to experiment for yourself because each processor is different.

Sent from my Nexus 4
[Nexus 4 Original Android Development] farmerbb:
The default Franco kernel values are the same ones that are the default on the Optimus G (which are somewhat different from the Nexus 4 defaults). Only LG's kernel devs know the reasoning behind why they chose the default values, and I don't think that the gamma interface is fully understood by our devs at this time. What the different values do and how the "valid" ones were come up with was mostly determined by guesswork and independent research (they're more like "known good" values, if my understanding is right).

Because Franco's updater app doesn't recognize the kernel defaults as "valid", it just shows them as 0 as kind of a failsafe, even though the values aren't actually at 0.
[Nexus 4 Original Android Development] steviewevie:
http://xdaforums.com/showthread.php?p=35566840

Sent from my Nexus 4
[Nexus 4 Original Android Development] wathefak:
You can find the command here

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

Edit: steviewevie beat me to it
[Nexus 4 Original Android Development] sirxdroid:
Thanks for the explanation. If these defaults are from the LGOG, do you happen to know what the Google defaults are in the stock N4 kernel? Just curious to see the difference.
[Nexus 4 Original Android Development] Utini:
so I am still using r111 with stock 4.2.2 on fast with -125mV.. looks fine altough I am not sure how to find out how to stress test the UV :/

franco app seems decent as well :)
[Nexus 4 Original Android Development] Banished Angel:
Download Antutu benchmark and run it. If you can get through the bench without any crashes your voltages are fine.
[Nexus 4 Original Android Development] hospital349:
...or even better, use Stability Test

You can keep your phone stress-testing through as many cycles as you wish until you are completely satisfied that all your frequency steps are 100% stable. I usually leave the Classic Test running for about 10 minutes and then I know my voltages are A-OK. :good:
[Nexus 4 Original Android Development] paaaulo:
I'm not really convinced if undervolting is such a great battery saver. Do you really find a noticeable difference?
[Nexus 4 Original Android Development] Utini:
but this will only test the max frequenz? but not do a stress test for lower mhz ?
[Nexus 4 Original Android Development] farmerbb:
The thing is... the Nexus 4 defaults seem to use certain values that can't be set in the Franco kernel. So you can't actually set Google's defaults without actually reverting back to the stock kernel.

This commit from Franco's github is where he changes the kernel defaults from the Nexus 4 to the Optimus G settings.
[Nexus 4 Original Android Development] hospital349:
I don't think UV has a great impact on battery, but heat, yes. :good:
[Nexus 4 Original Android Development] Zflash:
With the 119 kernel I suddenly had 2 sleeps of death this afternoon. I'm going back to 117 to eliminate any kernel related issues, but it is the only thing changed since this morning (117->119).
[Nexus 4 Original Android Development] hospital349:
It stress tests all available frequencies. Even the lower ones. :)

Features:

- Classic StabilityTest for unrooted devices (sufficient to check your device's stability)

- Scaling StabilityTest for rooted devices (useful to test undervolting, overclocking and underclocking settings)

- CPU + GPU StabilityTest for unrooted devices (test both the stability & accuracy of your SoC's CPU and GPU)

- Native MFLOPS estimation (linpack / linpackc) either per core or combined

- Background Mode (StabilityTest can now run in background and with the screen turned off, except for the CPU/GPU mode)

- Dual & Quadcore support
[Nexus 4 Original Android Development] Ok_Kaleidoscope5109:
Is this typical "I feel I get similar battery life" or did you actually run a controlled battery test? Right. Once again anecdotal evidence with no objective test
[Nexus 4 Original Android Development] Utini:
well... 125mv for 15 minutes.. still stable.. maybe I should try -150mV :o
[Nexus 4 Original Android Development] 309041291a:
What is "Pegasus" governor? I've read a few things about it, mainly about good battery, do you plan to add it (if possible)?

Sent from my Nexus 4
[Nexus 4 Original Android Development] hospital349:
Even with a 'controlled battery test', we have very little control over: random received calls (that may vary in length, etc), any kind of wakelock (that again vary in length and the impact they have on battery) and even signal strength (that can raise/lower at any time and inflict drain on battery). - I'm sure there are many other factors that I have forgotten to mention.

I would love to create strict battery tests for many of the N4 Kernels. It's just a shame that even if we really try to control our devices to accurately replicate our usage, in the end, our devices inevitably control our battery, not us. :cyclops:

---------- Post added at 09:05 PM ---------- Previous post was at 09:00 PM ----------

Give it a shot. Make sure your voltages aren't set on boot, just in case your phone doesn't like -150mV. Also, try taking a few pictures at -125mV & -150mV. Sometimes undervolting can cause intermittent issues with video and picture quality, causing hardware to not work as it should. As long as your voltages are stable and they aren't causing quality dips, you're good to go. :good:
[Nexus 4 Original Android Development] Gugus38:
That's strange, I just had a SOD.. may have been caused by 384mhz screen off...

Any idea ?

Will try to raise to 486
[Nexus 4 Original Android Development] mitchdickson:
You could provide a log, you know.

Sent from my iPad 4
[Nexus 4 Original Android Development] BrandoHD:
It's not about a controlled test, it's about people using their devices the way they want to use it and making their observations that battery life is better, the same, or worse

If you are so obsessed with controlled battery tests, you should run them, because your rants are as baseless as the very thing you rant about

Sent from neXus 4 using Tapatalk 2
[Nexus 4 Original Android Development] miguepereira77:
I'm not an expert... But I think it's more a Samsung device governor not for n4

At least I used it with my s2 , siyah kernel vsync and row scheduler, damm fast and smooth

Enviado desde mi Nexus 4 usando Tapatalk 2
[Nexus 4 Original Android Development] drawde40599:
Nm.....
[Nexus 4 Original Android Development] steviewevie:
I thought that Franco used his own values though, not from LG?

Sent from my Nexus 4
[Nexus 4 Original Android Development] gharrrrrr:
" 25: Pegasusq/Pegasusd

The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.

Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, withtheir priority values ​​arranged (priority willbe used by the task scheduler, which then decides which process to run next).

To ensure that each process has its fair share of resources, each running fora certain period and willeventually stop and then again placed in the queue until itis your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed."

xdaforums.com/showthread.php?t=1736168

Sent from one device or another.
[Nexus 4 Original Android Development] Utini:
Alright so -125mV runs finer for 10 minutes and also does pictures in HDR / Flash.. lets try -150mV :)

@edit: -150mV for 15minutes stress test.. no problems.. -175mV? :D:D
[Nexus 4 Original Android Development] hospital349:
You've got nothing to lose. :)
[Nexus 4 Original Android Development] combatdeity:
Data could corrupt, make sure you have backups for recovery.
[Nexus 4 Original Android Development] deltatux:
Still getting micro-stutters with the new hotplug driver. I had to change the interactive governor's timer_rate to 12000 to compensate, but that, I hope doesn't adversely affect my battery life too much. I balance that out by capping the suspend frequency to 594 MHz, don't see why it needs to run higher than that. Background events don't need that speed anyways.

deltatux
[Nexus 4 Original Android Development] eep2378:
You can always revert back to r111 :D
[Nexus 4 Original Android Development] franciscofranco:
Interesting thresholds, going to test.

Random crap in the kernel scheduler, so the watchdog triggered a reboot.

Its for Exynos devices - so no.
[Nexus 4 Original Android Development] hospital349:
I'm enjoying them immensely. If you find them to your liking, maybe you can use them as inspiration or refine them to suit your needs. :)

As always, thanks Franco. I always come back to your work. :good:
[Nexus 4 Original Android Development] sirxdroid:
Thanks a lot. This color stuff is a lot more complicated than it should be.
[Nexus 4 Original Android Development] franciscofranco:
Its a nice approach. The only problem is that it will keep onlining cores every 2 seconds if we keep interacting with the device because the load will always be greater than 25%. I might have to counter it somehow like decreasing hi_speed_freq to 702MHz, we don't need it on max anymore.
[Nexus 4 Original Android Development] Ok_Kaleidoscope5109:
Well yeah I don't doubt Franco's kernel should be better in battery life. I was never arguing that it wasn't.

Screen drain in general is the biggest drain for most people who have the phone on a lot. It obviously won't if you don't use it. Screen drain is different if you're playing Ingress which uses GPS and 3G, in which case Screen drain may play a lot less of a role. However, in all the 6 hrs SOT people are claiming, it's pretty obvious screen drain is the largest factor in battery use. If not then it would've died a lot earlier say if you were playing GTA.

As for Anandtech, the browser test doesn't touch screen but so what if it never affects mpdecision? The point is a 3G test to see how much 3G and the screen take up in terms of battery, or wifi if its a wifi test. There's SOME testing of the browser because a browser test doesn't idle at 384mhz. I ran perfmon while running a browser test and I frequently saw 3 cores on, with at least 1 core at 1ghz if not sometimes 2. This was on r111. It could be worse with mpdecision.

But I think my main point was that all these SOT screenshots mean nothing because people are doing different things. My point was that Anand achieved 6 hours SOT doing a wifi test, so that 6 hours IS possible on stock kernel. Perhaps Franco will get better times doing the same test, but no one's tested. But if we are to discuss SOT, we need a controlled benchmark, say having everyone run the same tests Anandtech runs.
[Nexus 4 Original Android Development] jan.ringas:
So that means that particular reboot had nothing to do with your kernel but was something that can happen from time to time no matter what kernel? Just asking as I'm trying to "learn" to read last_kmsg etc. Thanks for your response!
[Nexus 4 Original Android Development] thebryceee:
After thinking about it, that would make sense for those threshold settings to online and offline the cores quickly.
[Nexus 4 Original Android Development] Ok_Kaleidoscope5109:
No the issue with subjective impresssions is that it causes people to make up BS statements. Some of this was revealed when Franco told us about placebo tests or commits he reverted in his test kernels. In those cases it showed how stupid people are with the placebo effect of a new kernel.

If we are to believe everyone's impressions then you know there's a lot of false things being spread. My point is to take people's claims with a grain of salt especially if it's just some bs like today I got better battery life than yesterday. Thus r119 > r118. I'm not saying r119 is not > r118. It could be or it could not be, but nothing you have said even supports that, if you were to base it off of one day of use. That's especially because daily usage patterns are different, etc.

You're right. Everyone can be happy if they want here, but when people are using other's opinions and observations as facts that one kernel is better than the other, then it goes down a slippery slope. That's why you see phone reviewers doing controlled tests. Otherwise their reviews are as good as me saying the iPhone 5 rules all phones.

---------- Post added at 02:36 PM ---------- Previous post was at 02:34 PM ----------

Odd I tried this and found nothing stuttering. Maybe I'm not noticing the stutter correctly? Could you perhaps give me more cases where microstutter happens so I can try it out? I'm on Nightly 0407 and r119. Are there videos of microstutter for me to see?

Uhm... If you don't notice it, don't dismiss it. I don't notice it either, but if it's a problem we should hear more about it and have more information. Microstutters should not exist on a phone like this. You highlighted this with the specs. This is a thread full of curious people wanting to know more about this phone, so if you don't care, you can get out.
[Nexus 4 Original Android Development] franciscofranco:
I would need to see the entire log, only that snippet is not enough.
[Nexus 4 Original Android Development] Nocturnal86:
Please give updates on how it and your tweaks to it works. If it improves SOT or any time I would love to know as im sure many other users would like to aswell. Thanks Franco!
[Nexus 4 Original Android Development] jan.ringas:
Unfortunately that was the whole content of my last_kmesg. Was surprised about the short file, as well.
[Nexus 4 Original Android Development] mjehan:
Decreasing the hi_speed_freq to 702 MHz brings back the stutter :(
[Nexus 4 Original Android Development] franciscofranco:
Then 1026 it is.
[Nexus 4 Original Android Development] franciscofranco:
No no, I don't give any updates on battery life, my usage is not typical as my device is always plugged in for development.
[Nexus 4 Original Android Development] drawde40599:
Your settings do make huge difference , not sure about battery but for how fast 119 is with your settings I don't even care :D

these settings make it feel like pre 4.2.2 Franco kernel :D loving it

Thanks for sharing
[Nexus 4 Original Android Development] thebryceee:
At 1350 I don't see any
[Nexus 4 Original Android Development] hospital349:
I definitely think the idea is worth experimenting with. The immediate onlining of core(s) definitely helps my device to react quicker and feel snappier. This does pose a problem, as you mentioned already. However, for me, it doesn't have a dramatic effect on battery life.

I don't know if it's at all helpful, though it's definitely an 'idea':

Could the thresholds be set up to work with all 4-cores online all the time, when screen is on? - (I recall you experimented with this in older versions of your kernel). The thresholds could determine when the CPU frequency steps-up, instead of when each core is onlined, (as they'll already be active when the screen is on). Does that make any sense - Stop me if I'm talking nonsense. I'm no kernel dev. :cyclops:

Either way, good luck dude. :good:

EDIT: Actually, ignore my stupidity. You've been there, done that, bought the t-shirt, had an orgy and woken up with a hangover the following morning. I'm sure you probably don't want to go back there, ever again. :silly:
[Nexus 4 Original Android Development] mjehan:
1026 MHz reduces stutters and at 1350 MHz they are hardly noticeable. Of course ideal would be 1512 MHz but then the battery would not last long.
[Nexus 4 Original Android Development] franciscofranco:
I didn't understand. What you can you to mimic 4 cores always on its very simple: first_level to 0 and third_level to 100. The current code is more powerful than it looks, you can determine exactly how you want the cores to behave based on system load. You can even run it always 1 core if you want. The only thing that you can't do because the algorithm is not smart enough is to run with 2 cores only or 3 cores only, but you can do the extremes. Anyway I'm enjoying the 25 second level and 50 third level, coupled with 1026MHz hi_speed_freq its very nice. I posted this settings on Grouper and they rejoiced.
[Nexus 4 Original Android Development] Testraindrop:
Yeah have that too since a couple version...

Franco I saw on github that you limited some log sizes a few weeks back? Could it be related to that?
[Nexus 4 Original Android Development] franciscofranco:
Try this: 1026MHz hi_speed_freq with 95 go_hispeed_load.
[Nexus 4 Original Android Development] franciscofranco:
Yes its my fault :D
[Nexus 4 Original Android Development] ÜBER™:
How about turning the input_boost off and keeping the hsf 1512. That way when just touching the screen it doesn't push it to the hsf.

Sent from my Nexus 4
[Nexus 4 Original Android Development] franciscofranco:
Sure, lets try it.
[Nexus 4 Original Android Development] mjehan:
Much better now :) ... The stutter has almost gone. Still the performance at 1350 Mhz with 99 go_his speed_load is almost perfect.
[Nexus 4 Original Android Development] hospital349:
That makes sense. Yeah, it's what I do sometimes. Talk sh*t which makes a ton of sense to me at the time, only to reflect on my words and realise they make absolutely no sense at all. Good times! ;)

I'm glad you like them. Cheers for your praises!
[Nexus 4 Original Android Development] franciscofranco:
What I'm testing now is 90 first_level, 25 second, 50 third, 1512MHz hi_speed_freq, 99 go_hispeed_load and 0 input_boost. But I'm running a newer kernel than all of you though.