yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Android Development] thracemerin:
It was a while ago and I can't find the article anymore, so it's possible I misunderstood or don't remember, it's also entirely possible that I'm just nuts and made the whole thing up. If I had to bet I'd go with the nuts.

Either way, mpdecision seems to hotplug better (though considerably more aggressively than some may prefer) than most in kernel implementations and at a lower resource cost.
[Nexus 4 Android Development] sirxdroid:
Strange, isn't it? You'd think that an in-kernel impl would get to turn cores on/off a lot faster than an outside process that needs to get some CPU time to run. I haven't looked but I'm wondering whether mpdecision runs at a higher nice level.
[Nexus 4 Android Development] thracemerin:
It runs under a different user/group than most processes run by the kernel (probably because it's userspace rather than in kernel), so it's possible that it's prioritized in one way or another, but if it were that simple you'd think someone would have figured it out and used that for their own hotplugging routine. I dunno, I'm no expert and the material regarding mpdecision seems to be mostly about how much people hate it and discussing ways to disable it rather than actually talking about how it works.
[Nexus 4 Android Development] sirxdroid:
Haters are just jealous :)

FWIW, I think the latest Franco hotplug does a very nice job. I tried some of his not so stellar builds between r111 and around r140 or so and I was starting to think there was something wrong with interactive in general and that ondemand was the magic governor, which was strange because interactive seems to work very well on the GNex and the N7. It goes to show that the SoC matters.
[Nexus 4 Android Development] thracemerin:
It does, and its probably better than auto hotplug, but the thing is he tied it tightly into his version of the touchscreen driver and the interactive governor which means that I'd have to implement those as well, and if updates come from upstream I'd have to wait for him to update or deal with rebasing them myself (not that I can't, but it's annoying and time consuming)
[Nexus 4 Android Development] sirxdroid:
I don't think you should uptake Franco's stuf if it locks you in. It's good to have variety and to keep your options open. I like the approach the Community Kernel took. I think your _m+ would do just fine if it supported mpdecision+ondemand and the auto hotplug for those who want to play with it. You can enable mpdecision in the ramdisk and then disable it in some other way if you expose a sysfs option to turn it off, e.g. kill the process and close the unix socket in the kernel that mpd uses, etc.
[Nexus 4 Android Development] Ace42:
Theoretically if mpd actually is a unique hot plug then why is there no interest in reverse engineering it? I've heard of devs hacking hardware drivers like in Cyanogen or porting ROMs to unsupported devices, but none want to modify mpd?
[Nexus 4 Android Development] thracemerin:
It comes as a binary, you'd have to decompile it to machine code, figure out what the hell the machine code actually means, then hex edit it to make the changes if you could actually figure out where/how to do that, its easier to write another hotplugging routine :)
[Nexus 4 Android Development] Ace42:
I'm kinda interested in using mpd now that you guys have said all this stuff, however is there any method that allows mpd to be on without the 1ghz touch boost?
[Nexus 4 Android Development] thracemerin:
Not that I'm aware of, but there have been attempts to reign in mpdecision by limiting its access to modify certain sysfs parameters, I don't know how far I can go with that before causing instability.
[Nexus 4 Android Development] funcrusher:
thracemerin is always involved in interesting discussion. :)

Semaphore uses mpd and I quite enjoy it.
[Nexus 4 Android Development] thracemerin:
If you can't learn something and have fun doing it, why bother? right?
[Nexus 4 Android Development] funcrusher:
I totally agree and really enjoy your posts.
[Nexus 4 Android Development] Kocai:
Finally managed to download the alpha build. Having no issues so far except setting the UV below 850mV, my phone would instantly crashed and stuck at the boot animation. Quite sure my phone could handle 750mV because I used Trinity kernel for a few days without any issue.

Edit: sorry I forgot that I flashed the alpha build on top on build 2. My bad.

Sent from my Nexus⁴
[Nexus 4 Android Development] thracemerin:
yeah, goo.im has been troublesome for the last couple of weeks, but i couldn't get the alpha to upload to devhost or android file host either.
[Nexus 4 Android Development] Kocai:
You don't have to answer this if you don't want to but I'm curious if you guys have to pay some sort of fee to goo.im? Also, molesarecoming once said that it'd only take him three minutes to upload from XDA build server to goo. Is XDA have some sort of collaboration with goo?

Sent from my Nexus⁴
[Nexus 4 Android Development] thracemerin:
I don't personally pay anything for goo.im and as far as I know they don't require it for hosting. I believe they rely on donations, advertising and the $10 sponsor thing that lets you get faster downloads and no waiting, but that's a 1 time for life thing. Given the sheer number of downloads and uploads they must get daily, I bet it's hella expensive to operate it.

I don't think XDA and goo.im are officially affiliated but a lot of the sites that support android development and the like have some sort of link.
[Nexus 4 Android Development] Remoteconcern:
Haha, I didn't realise my offhand comment would spark such a debate. I like this thread, and continuing thanks for your replies, thraceramin.

Mpdecision clearly hotplug the best, and is the fastest, yet I think the two second input boost is rather excessive and does waste battery. Ideally someone could imitate the hotplug function without that, and use it with this kernel as I think the motley interactive governor boost is quite good and customisable. Unfortunately I can't write a hotplug governor otherwise I'd give it a go myself after observing mpdecision in a lot of situations.
[Nexus 4 Android Development] buster041284:
has anybody got a mirror for the new Alpha Build it will just not download off goo it keeps freezing Firefox

Edit google chrome worked after a bit of messing about
[Nexus 4 Android Development] rokK0:
http://db.tt/vJ0tUl18
[Nexus 4 Android Development] meangreenie:
yeah there is, +motley inert power hal zip

..but it, at least on other mpd kernels, brought lock-screen/screen on lag.. but was fine after a few seconds.

here
[Nexus 4 Android Development] thracemerin:
New Test Build in Post 4, its the same as the latest Alpha except that I reverted the additional msm_hsic_host patches I added between B6 and B7 to see if it solves some of the connectivity issues. Please test if you were having some connection weirdness and let me know if this solves it.

Happy Flashing! :victory:
[Nexus 4 Android Development] veyka:
So far this new wip gives faster data speed than b7 or the previous wip. Hitting proper DC HSDPA speeds again, i though it was the change in modem (flashed 54) that caused the speed decrease, but it was at about the same time as B7 and the new patches.
[Nexus 4 Android Development] thracemerin:
Something in that new patch set was causing an unusual number of USB bus resets for no apparent reason, I'd say that was the problem.
[Nexus 4 Android Development] thracemerin:
I have trouble testing 3G connectivity issues because my office is in the basement of a server room that could easily be used as a bunker to withstand a pretty severe bombing onslaught and my apartment seems to have a built in faraday cage. So even on the best days I have data drops and complete signal loss, etc... fairly regularly due to those conditions.
[Nexus 4 Android Development] sirxdroid:
It's summer, spend more time outdoors :) Oh wait, don't! Who's going to work on the kernel then? :)
[Nexus 4 Android Development] thracemerin:
I wouldn't know it's summer, my office is in the air path for the server coolers so it's freakin freezing down here.
[Nexus 4 Android Development] ckret:
i am not sure if its placebo but my phone feels faster with the new beta

the apps close and open faster.. overall it feels better
[Nexus 4 Android Development] thracemerin:
There should be some improvement from using the gcc 4.8.1 toolchain instead of the gcc 4.7.3 toolchain, I feel it too, but it's hard to say whether its placebo or not. There would be additional improvement if we could build the kernel with the SLUB allocator and 4.8.1, but for some reason nobody can get a linux 3.4 based android kernel to boot unless it's switched to SLAB so we'll see if Linaro addresses the situation soon.
[Nexus 4 Android Development] caliban2:
Never had data-drops or any other (software-caused) problems with my data-connection, can't help with that. But yeah, phone feels snappier with latest wip. Now I come back here and read the last posts -> when does it stop being a placebo-effect? :D
[Nexus 4 Android Development] thracemerin:
Like I said there should be some real improvement, it's just hard to measure how much is actual improvement and how much is improvement I think should be there because I switched from 4.7 to 4.8, I don't think it's all placebo.

Plus, I managed to get multiple Antutu scores on the latest wip that are quite a bit worse than on b7, now I don't believe in benchmarks really, but it's just confusing me.
[Nexus 4 Android Development] thracemerin:
On a completely unrelated note, the new GMail app is available and I really like it: http://www.androidpolice.com/2013/0...ith-slide-out-navigation-and-brand-new-inbox/
[Nexus 4 Android Development] rokK0:
A compliment to the dev. Really very good the new alpha kernel. Much faster than the b7. Wireless delay, hardly available. Keep it up and thank you for your work.

Getippt von meinem zivi
[Nexus 4 Android Development] FeintDoxx:
[MENTION=4303511]thracemerin[/MENTION] so as far as data drops have been going. They seem like they're less data drop with the .54 modem. Maybe it was more along of radio problems. Either I love this kernel and since there's no LTE around my area for the Nexus it won't matter if I'm on .54 radio. Keep up the good work man!
[Nexus 4 Android Development] Remoteconcern:
Can anyone post a mirror of the latest alpha? Goo isn't working at the moment.
[Nexus 4 Android Development] thracemerin:
Yes, m_plus_anykernel_422_build_wip-83cd6cf.zip - 5.30 MB
[Nexus 4 Android Development] Remoteconcern:
Thanks. Will report back if I find any bugs.
[Nexus 4 Android Development] thracemerin:
There was definitely something not entirely right with that additional patch set I added for the msm_hsic issues, as far as the modems I flashed .54 at about the same time as B7 so something seemed off, but I can't say whether it was the modem or the patches yet, I'm doing some testing now. I have LTE here but, the .33 and .27 modems cause my RIL to crash constantly and I have an LTE mobile hotspot for times when HSPA just won't do.
[Nexus 4 Android Development] Oops...:
Latest wip is great. No problems so far. Definitely snappier than B7...
[Nexus 4 Android Development] FeintDoxx:
Ahh okay. I still see what you mean by a bit off. There's still some data drop but not like before. I can't say .54 radio was better with b6 as I didn't try .54 until now. But as far as data drops go. B6 had less data drops than B7.
[Nexus 4 Android Development] thracemerin:
The latest test build is back to the B6 patches and my issues (other than the ones from where i live/work that i talked about earlier) seem to be more or less completely gone on both the .54 and .48 modems, so definitely something wrong with those patches.

Like I said before, tracking down mobile data issues is so difficult because mobile data relies on so many variables that are entirely external to the device. The fact that the N4 uses a really crappy setup for it's 3G connectivity (essentially an external modem plugged into a USB port) makes it even harder since it has a unique set of problems that don't exist on other devices.
[Nexus 4 Android Development] Remoteconcern:
Hmm. I got 10% drain overnight in airplane mode, with no difference in set up apart from B7 vs new WIP. No wakelocks. Will test further.
[Nexus 4 Android Development] thracemerin:
Weird, my drain is unchanged.
[Nexus 4 Android Development] FeintDoxx:
Well which ever it may have been there seems to be a slight improvement. Regardless of which I can't wait for the next build.
[Nexus 4 Android Development] Ace42:
New alpha is performing better for me even with all cores allowed and 1.6ghz :beer:
[Nexus 4 Android Development] Remoteconcern:
What theme/app is that? That looks the way I feel Settings should look. Holo Dark is beginning to look really outdated, while all these clean, bright and colourful Holo Light apps (Music, Books, Gmail) look incredible.

Sorry for off-topic.

Just to further my point about battery drain, it's specifically the phone radio usage that has increased.
[Nexus 4 Android Development] Ace42:
https://play.google.com/store/apps/details?id=com.tillaz.theme.HoloLight
[Nexus 4 Android Development] Kocai:
Anyone edit their build.prop for network connectivity? I've been doing it since last Saturday and I find my download and upload quite significantly increase. I follow this post: http://xdaforums.com/showpost.php?p=5123531&postcount=46
[Nexus 4 Android Development] iowabeakster:
HI guys,

I have been using the last build that motley put out, until yesterday. I found no reason to change or replace it (some of that might just be laziness). An init script, "One Script to Rule them all" (folks here probably know what I am talking about) did all my desired tweaks for me.

I am just not much of a kernel tweaker. All I do is to enable "force fast charge" and to boost headphone output a bit for when I am riding my motorcycle (the sound needs to blast through my modified safety earplugs and compete with wind noise). I really think that is all that did (it's been a long time). And if the default UVing that motley did gave me a little better battery life, than that is all good too.

LTE came to my neighborhood this week and I did a factory reset yesterday so that it would stick on reboots.

Anyhoo... so I figured I should get with the program and move on to thracemerin's builds. (Thanks for keeping the development alive!!... even if I am slow to arrive)

1. I asssume that the "one script to rule them all" is still completely compatible with all of latest builds?

2. Being a "kernel simpleton" who leaves almost everything at default, are there any specific builds that would be better, or I should avoid?

It probably does not matter, but I use Team Asylum rom (CM 10.1 based).

Thanks for any advice.
[Nexus 4 Android Development] Remoteconcern:
Good to have you here :)

1. Yeah, totally compatible.

2. Hmm. Maybe try build 6 for now (you can flash straight if you're on latest motley already, otherwise get cm version of build 1 and then flash build 6. Build 7 has some 3g issues.

3. See above, but should be fine.

If your tweaks don't work, come back and post what you want and I can knock up a script for you but I'm sure they'll be fine.
[Nexus 4 Android Development] iowabeakster:
Thanks alot. I did need to flash Build 1 because I did use the stock CM kernel to ensure that LTE was working correctly after the system reset and before I got too comfortable and got everything else all set-up.

Everything seems fine so far. The script enabling kernel tweaks is working as expected. (although I should have saved a copy of my old script before the system reset)

Got a few more ROM mods that I want to do with the addon.d scripts... if I can remember (which I also should have saved before wiping... grrrr.... I am so stupid).

Thanks again.
[Nexus 4 Android Development] veyka:
Tried them, they did nothing, they can't make your data connection go faster than the mast or the phone supports and everything is normally automatically negotiated, forcing it could have unexpected side effect or just do nothing.
[Nexus 4 Android Development] rlaw:
[MENTION=4303511]thracemerin[/MENTION]

You asked me a few days ago to compare dynamic fsync on vs fsync completely off. Maybe it's just placebo but the latter feels a slight bit faster than the former. I tested it by opening a bunch of apps and clearing em from memory in multitasking view. Eye test says fsync off is faster than dynamic fsync on.
[Nexus 4 Android Development] thracemerin:
Faux has added a bunch of patches and fixes to dynfsync since _motley merged the initial iteration, the problem is that they don't play well with regular fsync, but I can probably work it out.
[Nexus 4 Android Development] Remoteconcern:
Hey guys,

My final hotplug values are as follows:

Disable_load_threshold - 100

Enable all load - 550

Enable load threshold - 240

Min sampling rate - 20

Sampling periods - 20

I think one of those values might actually be the default but I forget which one, possibly sampling_periods. Anyway, these values do not impact smoothness subjectively (I don't run benchmarks) and they appear to have a minor increase in battery life. I've been busy this week and so my usage has not been comparable or steady but I seem to be getting approximately 20-30 minutes more screen on time across a whole discharge. Not much, but still good :)
[Nexus 4 Android Development] imsonica:
B7... Thank you

:)
[Nexus 4 Android Development] rlaw:
Feels smoother than the stock settings I had. :confused:
[Nexus 4 Android Development] Remoteconcern:
These are less aggressive settings, so it's probably placebo. Unless the less jerky online of cores means that it's smoother somehow...
[Nexus 4 Android Development] veyka:
Cores do seem to be jerking on and off a lot less now, and as we always get two cores at the high speed freq on touch anyway I haven't noticed any UI slowdown, may need to tweak the load values a little as it still sometimes seems to loop a bit.
[Nexus 4 Android Development] thracemerin:
Post 3
[Nexus 4 Android Development] UgoBoss:
Sorry maybe for the nooby question but I just wanted to do an init.d script but I have not any init.d folder in my system... I've searched in the zip of my rom (Xylon 2.7.3) in /system/etc and here it is ! The init.d folder ! So I just went to my phone, into /system/etc but no init.d folder in it.. Does someone have a solution please ?

Thanks :)
[Nexus 4 Android Development] Remoteconcern:
Yes, there's a solution. Make the folder! And then set the permissions like this.

Make sure you have busy box in system /xbin although it's probably already there :)
[Nexus 4 Android Development] UgoBoss:
Thank's for the reply ! :)

But I just don't understand one thing, the init.d folder was in the zip of the rom but it is not in system...
[Nexus 4 Android Development] Remoteconcern:
I can't explain that, but don't worry about it. Hopefully it works anyway, it should.
[Nexus 4 Android Development] UgoBoss:
Thank's, I hope it works !
[Nexus 4 Android Development] sirxdroid:
Maybe it doesn't get created because it's empty in the zip? I've seen others put a 'placeholder' file in init.d in the zip I guess just to force the directory to get created.
[Nexus 4 Android Development] ch96li:
For those of you undervolting here's a link to a table with very useful information about what voltages people have been able to maintain. Personally I find it saves me a whole lotta work and I can push the voltages down much further than say a -100mV across the board. https://docs.google.com/spreadsheet/ccc?key=0AnlqtEwFJwR6dE55WkZYSThEM3U4SGtKMVl2V1VqMmc#gid=0

(I'm currently using Franklin Bernard's 3/13 voltage settings and my phone's been stable for...I can't even remember now :D)

EDIT: Credit where credit is due, I originally found this spreadsheet thanks to a post by batman368 on the old motley kernel thread
[Nexus 4 Android Development] thracemerin:
Thanks for digging this out. :good:

For those of you asking for lower undervolt values, I was playing with a build where I removed the safety limit completely and when you go below 600mV the stability of the device overall suffered a lot (I have access to both a Fast and Nominal device, both of which take undervolt reasonably well in my opinion), I don't think I want to do this because people like to push the limit and are likely to have bad stuff happen, especially if they don't turn fsync on before they mess with it. Not the final word on this, just some thoughts that are rattling around in my head about it right now.

Edit: before someone comes in and says "this is my device, let me screw it up if I want", I'm not insensitive to this argument, if you want to run your device at dangerously high OC with no thermal protection active, that's your business and I'm not here to stop you, but you have to remember that while I can say "do whatever you want I'm not responsible" that doesn't mean that I don't feel bad if you device catches fire and becomes a giant pile of charcoal. If you really feel the need to push the limits beyond what I consider to be safe, I can help you set something up to build yourself, but I am going to keep the limits of the official kernel within what most consider to be the safety margins.
[Nexus 4 Android Development] sirxdroid:
Thank you! That's a wise move. It protects against mistakes where someone might echo the wrong value to the virtual sysfs.
[Nexus 4 Android Development] gianton:
When flashing CM 10-1 nightlies which is the correct order?

1. Flash ROM=>Gapps=>m+ v1=>m+ v2=>reboot or

2. Flash ROM=>Gapps=>m+ v1=>reboot=>m+ v2=>reboot
[Nexus 4 Android Development] azrash:
I usually do route 1. And if you have flashed gapps before, you can skip flashing it again when updating to the next nightly. They have their own backup script. So just flash CM new.zip + kernels

Flowed from my Nexus⁴
[Nexus 4 Android Development] thracemerin:
I've been doing ROM => v1 => v2 without issue, only need to flash gapps if you wiped /system.

The reboot between v1 and v2 can't possibly do any harm (other than wasting the few seconds it takes to boot the system and then reboot back into recovery), but it also won't provide you with any benefit.
[Nexus 4 Android Development] gianton:
Thanks guys! Testing Franklin Bernard's UV settings from the link a few posts back and so far is running stable on my faster binned chip.

Also I'd like to thank veyka for his scripts!
[Nexus 4 Android Development] thunderger:
Thracemin, thank you for continuing motley's kernel. B2 runs well.

Is it possible that you merge some patches regarding filesystem, io perfomance and sheduling from linux 3.9? Also, it would be nice to have exfat support, experimental otg, more cpu and gpu overclocking, e.g. 1.72 and 1.84 ghz clock speed for cpu. Last but not least in Benchmarks this kernel has a very low integer perfomance. Perhaps you find the reason.
[Nexus 4 Android Development] gianton:
1st full charge with v2 on trailblazerz11's linaro CM 10.1 ROM. Easily stretched to 5+ SOT, great job and thanks both to motley and thracemerin.
[Nexus 4 Android Development] thracemerin:
I'll look at the 3.9 stuff.

In terms of OC of the CPU and GPU, if we want to go higher I think i'd have to tweak the thermal protection a bit, if we go too high on the OC there is a possibility it could heat up so fast that it would pass the safety limits for the chip before the emergency shutdown safety kicks in, I don't want anyone frying their chip.

What are we comparing the benchmarks to? stock, previous _motley, franco? I just want to see if the low integer performance is something I did to make it worse or something that just needs to be improved.
[Nexus 4 Android Development] rlaw:
The higher CPU overclocking is something only faux, to my knowledge, does with his 'turbo boost' implementation does. And I believe only cpu0 does it for single threaded processes.

I'm happy with the limited overclocking we have now.. Faux's kernel has proven to be a bit too finicky with all the different options he has and no matter how I've set it up, it's not provided better performance or smoothness for me than motley's. Indeed, motley's is the best kernel I've tried for performance and smoothness and it's above average in battery life as well.