Hi guys
Release 0.4 http://forum.xda-developers.com/showpost.php?p=45243784&postcount=48
New in this release is USB Fast Charging support (must be enabled via new kernel interface, see post for details)
Da_G said:
Old version 0.3 http://forum.xda-developers.com/showpost.php?p=45202710&postcount=28
Old version 0.2. http://forum.xda-developers.com/showpost.php?p=45198825&postcount=25
Old version 0.1! http://forum.xda-developers.com/showpost.php?p=45186352&postcount=18
Click to expand...
Click to collapse
Some of you might remember me from a time long ago and a galaxy far away!
I built/maintained dagkernel on release day for the Note 1, bringing root+overclock+recovery on day one of release
Well, recently my home was burglarized and all of my electronics taken. I took a very big ol hit that made me a sad panda Along with this stuff was my fancy-pants Alienware M18X laptop (minus the power brick, so they can't use it!) - which had all my source codes and development enviornments on it.
Rather than cry over spilt milk (really, I cried for a week! ) I decided I would re-build my development enviornment and crank out a new kernel for Galaxy Note, which is the most powerful computing device I currently have! (I am developing on an old school core 2 duo w/1GB RAM that sure feels slower!)
So, build enviornment is set up and the first build is done. Which is simply a re-built ramdisk and kernel from AT&T source. Using the newest available prebuilt toolchain from Google. I won't release this version as pretty much nothing is changed. But I wanted to get my dev enviornment up and running A first release with actual, substantial changes should be available within the day.
Support will include 4.1.2 stock ROMs (for the S-Pen love), CM, and whatever else I might support (suggestions?!)
GPU/CPU overclock will be supported, with the separate interfaces for overclocking each via an app. Hopefully I can actually push the app out this time around, it stayed internal only last time (although all frequencies and voltages were changable via boot script)
I took a look at the existing 4.1.2 kernels floating around and noted that most of them neglected some patches I made to Samsung's original source that did some funky things like re-set CPU1 (the second CPU) to stock speeds after toggling it off (for power saving)
As a result, the performance of these kernels is probably not quite what it should be after the first CPU shuts off (which happens almost immediately after android is done booting fully, when the load demand on the CPU(s) die)
Of course, my source will be public as it has been since day 1 and anyone is welcome to source my patches without asking. Viva la developers!
May your Galaxy Note run faster than this pos Dell desktop I'm using real-soon-now(tm)
Reserved for the use of the futures.
Reserved for the use of the futures.
Cool beans. Looking forward to this
Sent from my SAMSUNG-SGH-I717 using XDA Premium 4 mobile app
Welcome back
Sent from my SAMSUNG-SGH-I717 using XDA Premium 4 mobile app
Da_G!!!!!! Welcome back
2$HAYNE
Yes, welcome back Da_G. I'm sure there are a ton of us that remember your great work. Looking forward to some more.
Sent from my SAMSUNG-SGH-I717 using Tapatalk 4
Sorry to hear about your stuff!
I'm glad you're still able to churn out things like this though! Keep up the good work!
Welcome back! I loved your old stuff back in the day. Bring on the awesomeness!
Sent From My JellyBeanSandwiched Galaxy Note
ROM: Jellybean Sandwich w/ Hotcakez 1.8ghz kernel
Extras: Viper FX audio engine w/ Buzz Launcher
Sorry for the loss! But I'm glad you're back
Sent from my SAMSUNG-SGH-I717 using xda app-developers app
Sorry to hear of your trouble but glad to hear you're back on your Note development...a big plus for us! Welcome back Da_G!
Very sorry for your break in. Seems the world is full of d-heads. Glad nothing more than stuff was affected.
Welcome back. Of course we remember you. You're one of the first, and best at this Note stuff. Looking forward to seeing what you can put together. Let us know what you need from us.
Do your thing, man and welcome back!
you dont know me, but your reputation precedes you and I am aware of your quality of work.
I will send you a big welcome back
Welcome back :good:
I will have a first release out shortly. Just testing the impact of mpdecision on cpu performance.
For reference at OC to 1.83ghz/performance gov I was able to pull 9556 on antutu benchmark with performance gov and mpdecision disabled, ~6320 prior to overclocking. GPU is at 300MHz.
With ondemand gov and mpdecision enabled, looking around 8550. Lets try with performance gov and mpdecision enabled now...!
These scores seem about on par from what I remember from the first go-round I don't yet have the configuration sysfs interfaces set up.
Wow u know ure stuff n that really sucked about ur belongings but glad ure back in the community! I don't own a i717 but love to see all the roms u guys provide brings envy (in a good way) since my t879 has disappeared lol but good luck n the guys look very excited ure back... Lucky them cheers :beer:
Sent from my SGH-T879 using xda premium
Da_G said:
I will have a first release out shortly. Just testing the impact of mpdecision on cpu performance.
For reference at OC to 1.83ghz/performance gov I was able to pull 9556 on antutu benchmark with performance gov and mpdecision disabled, ~6320 prior to overclocking. GPU is at 300MHz.
With ondemand gov and mpdecision enabled, looking around 8550. Lets try with performance gov and mpdecision enabled now...!
These scores seem about on par from what I remember from the first go-round I don't yet have the configuration sysfs interfaces set up.
Click to expand...
Click to collapse
Awesome bro. How is the battery life? You going to put this out tonight?
Here is a first version, in TWRP/CWM compatible zip file. It is set to 1.83Ghz/300Mhz OC ondemand by default, with mpdecision left enabled. You should be able to use a tool like system tuner to change cpu frequencies and governors. I did not yet enable init.d support for a script in /etc/init.d to change frequencies on boot. It is on my to-do
This build is for 4.1.2 Stock/TW-based ROMs and most likely won't work on CM. Again, that's coming soon
As for battery life, I really don't know yet. I haven't had the phone disconnected from the computer during development, and this computer is so much slower than my old one I don't dare waste time doing things like that just yet. You guys try and let me know
I am thinking about 4 distinct releases,
High Power 4.1.2/Stock and CM
Power Save 4.1.2/Stock and CM
That way I can make one for balls-out speed and one for day to day use. I'm a fan of speed since I have an external battery charger and 4 batteries.
Da_G said:
Here is a first version, in TWRP/CWM compatible zip file. It is set to 1.83Ghz/300Mhz OC ondemand by default, with mpdecision left enabled. You should be able to use a tool like system tuner to change cpu frequencies and governors. I did not yet enable init.d support for a script in /etc/init.d to change frequencies on boot. It is on my to-do
This build is for 4.1.2 Stock/TW-based ROMs and most likely won't work on CM. Again, that's coming soon
As for battery life, I really don't know yet. I haven't had the phone disconnected from the computer during development, and this computer is so much slower than my old one I don't dare waste time doing things like that just yet. You guys try and let me know
I am thinking about 4 distinct releases,
High Power 4.1.2/Stock and CM
Power Save 4.1.2/Stock and CM
That way I can make one for balls-out speed and one for day to day use. I'm a fan of speed since I have an external battery charger and 4 batteries.
Click to expand...
Click to collapse
Seems like everything is running a-ok. I'm using it now Going to test it for the next couple days and see how it runs
Feels a little sluggish to me right off the bat. Tweaking the speed/governor with an app brings it right up to snappiness. Not too bad for a first run on an entirely new(to me) anciently slow computer, though. Only gets better from here
Sent from my SAMSUNG-SGH-I717 using xda app-developers app
Related
TEAM n0ob FIRST RELEASE!
Ok after my OverClock How-To, I decided to play with overclocking and see what exactly can be gained from stock Max regulator Voltage (1.3v). I have found that at stock you can get up to around 1.13ghz. It is slightly faster than what pershoots kernel runs (38400khz).
As persiansown says, the standard stock voltage is set to 1275, and the regulator is maxed at 1.3v.
What Kind of gains will you see?
You will notice a difference in games like Asphalt, that use a lot processor. You will notice a decrease in battery life as well. Your linpack scores will vary from about 8.5-9.5 depending on your chip.
I have included pershoots undervolting, 21MB ramhack, and audio hack as well. Several optimizations, following in the footsteps of the Ivan/intersectRaven Kernels. (You could say we KANGED pershoot and just added two frequencies above his)
The frequencies in the kernel from 1113300-1152000 are at stock voltage(1.3v), and I have included the relevant source files. As such they "should" be safe. You never know though! The frequencies below this are Undervolted down to .925v!
This is using SLUB allocator and Deadline IO scheduler.
The recommendation of Team n0ob, is to use set CPU to set your phone to a frequency below 1.11ghz unless you need the extra power for something. Otherwise your battery life will suck and you will stress your processor for no reason.
This is confirmed working on CM-5.0.6-N1.
WARNING!!! THE LONG TERM EFFECTS OF OVERCLOCKING YOUR PROCESSOR CAN INCLUDE:
1. SHORTENED PROCESSOR LIFE
2. OVERHEATING
3. REDUCED BATTERY LIFE
4. BRICKED (IE DEAD DEVICES)
Mod edit: removed link, till source is link to kernel.
I ask that if you notice anything funny that you flash to a more tested kernel and notify this board immediately. This kernel is at stock voltage, but the increased speeds could have adverse effects. Please let us know if you notice any.
Team n0ob takes no responsibility for any damage that may occur to your device.
Credits: pershoot( thanks for the hard work), Kmobs (same), intersectRaven, Ivan (for beginning optimization trend), Rotohammer(experimental random/music/start fix), Cyanogen for awesome roms (whose source this is pulled from), chris soyars, and coolbho3000, Koush for the anykernel updater.
Team n0ob Testers: jlevey, DAMNiaTX Hell! (Thanks)
Following pershoot, I recompiled the Kernel with VFPv3 Optimizations.
resync to 2.6.33.3, old wifi drivers as everyone has problems with the new ones.
Lowered minV to 925. maxV is still 1.3. Voltages are increased to 1.3 only on the 2 frequencies above pershoots 1.113ghz. The other frequencies are undervolted similar to the Kmobs and or the Pershoot values.
Well, by "lowering processor life", how exactly long will my processor last? Does it depend on my phone? My uses? Im all in it for overclocking, and im very aware of said risk.. But processor life I'm not educated in..
Eclair~ said:
Well, by "lowering processor life", how exactly long will my processor last? Does it depend on my phone? My uses? Im all in it for overclocking, and im very aware of said risk.. But processor life I'm not educated in..
Click to expand...
Click to collapse
Not drastic. Not concrete figures but I've heard figures like instead of something like maybe 6 years, you may get 4-5 years. The processors are designed to last so long that even things that harm them typically still leave them outlasting the upgrade cycle of the user. It depends on the silicon in your phone as well.
Also, Gr8Gorrilla, does this include CM's latest commits from a day or two ago that fixes the pink cam tint issue?
No telling really. It shouldn't be much different than stock. However, as soon as I say that someone will install this brick the phone and blame me. So I am using it and I have a two year contract with T-mobile, I figure it should make it that far.
This is basically pershoots kernel plus 38400 khz. (pershoot in no way endorses this kernel). Take that for what it is worth. The top three voltages 1113, 1132, & 1152, are at stock voltage (1.3v).
I resynced my repo last night before compiling this.
Damn nice kernel is all I have to say
Gr8gorilla said:
I resynced my repo last night before compiling this.
Click to expand...
Click to collapse
Ok thanks! Definitely flashing this now!
Stock voltage is actually 1.275v. The processor is, however, rated to handle 1.3v (it was originally going to ship at 1.3v, but qualcomm decided to have it ship at 1.275v instead)
Gr8gorilla said:
No telling really. It shouldn't be much different than stock. However, as soon as I say that someone will install this brick the phone and blame me. So I am using it and I have a two year contract with T-mobile, I figure it should make it that far.
This is basically pershoots kernel plus 38400 khz. (pershoot in no way endorses this kernel). Take that for what it is worth. The top three voltages 1113, 1132, & 1152, are at stock voltage (1.3v).
Click to expand...
Click to collapse
I also am on a 2 year contract with TMobile, hopefully mine last that long also. Might as well flash this, blah..
persiansown said:
Stock voltage is actually 1.275v. The processor is, however, rated to handle 1.3v (it was originally going to ship at 1.3v, but qualcomm decided to have it ship at 1.275v instead)
Click to expand...
Click to collapse
I stand corrected. I should have said stock max regulator voltage. I will update the OP.
thanks Gr8gorilla
I'm definitely gonna try this out. I've been using intersect's and ivan's, just jumping back and forth. Good to see that there's another kernel out there to play with. Thanks Team n0ob!
Gr8gorilla said:
I have included pershoots undervolting, 8mb ramhack, and audio hack as well. The experimental Rotohammer fix for the headphone jack is compiled in as well, along with several optimizations, following in the footsteps of the Ivan/intersectRaven Kernels. (You could say we KANGED pershoot and just added two frequencies above his)
Click to expand...
Click to collapse
Does this have everything else that the default cyanogenmod's kernal has? (i just want to know if I am going to loose anything from cyan to this kernal)
INeedYourHelp said:
Does this have everything else that the default cyanogenmod's kernal has? (i just want to know if I am going to loose anything from cyan to this kernal)
Click to expand...
Click to collapse
Yes that is correct.
Nexus FireBall 1.15GHz.
I will be also flashing this kernel update to 1.15 GHz tonight. I want to try and optimize my nexus one to its fully potential capabilities. : )
Updated, Changed Kernel optimizations. Since this kernel follows pershoot, he recommends if you are on 5.0.6 to flash the VFPv3 optimized version.
VFP works great
Hi guys when i unzip their 4 files i know the ko and zimage but the other 2 files do i need to install them too?? and how? thanx in advance.
The other two files are the source files. They there so you can research what changes I have made in the voltage and frequencies and also you could compile this on your own if you want.
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
tassadar898 said:
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
Click to expand...
Click to collapse
Its possible, but there are differences in the softkeys, charging hardware, and nfc at the minimum, so it will take a little work to port that over entirely. What would be better is for one of our current kernel modders to add some of the features of the SIYAH kernel over to their own.
I plan on pulling in 100 MHz support.
He doesn't have that much more, other than extremely experimental features that if you read the thread, tend to break.
Gokhan is quite talented, but he's also VERY aggressive - if you're more careful, you don't have to go through long beta periods with lots of broken releases like he does.
He also released source code for older kernels as megapatches, and now releases as straight full-source tarball drops. It makes separating the good from the bad EXTREMELY difficult.
As far as features he has that I don't currently:
1) 100 MHz support - I plan on this one, it's a fairly high priority as part of my current power management research
2) Crazy wacky alternative governors - these are a great way to somehow combine lag and poor battery life all in one
3) Charge current control - not possible on our devices, we have a different (very crippled) charger IC
4) Touchscreen stuff - I have seen no reports of people having touchscreen issues. If it ain't broke don't fix it.
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Entropy512 said:
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Click to expand...
Click to collapse
Would it be possible to get past the wakelock issue if you could program that the BLN shuts off after, say 30min, or user defined? That would work in my case but not sure if everyone universally would like it that way. Just a thought...
Hey Entropy nice to see you here! In siyah you can control the GPU voltage for undervolting. I currently do it using the Tegrak kernel module and I reduced the minimum step of 160 mhz to 750mv down from 950mv. I've noticed a nice bump in battery life. In his 2.1 beta version he also has this available feature
SiyahKernel v2.1 - not released yet -
Time to break some records... both performance-wise and battery-wise...
Overclocking part is optimized and bus frequency selection is modified.
User customizable frequency levels. you still have 8 steps, but you will be able to customize them. wanna change 100 to 150 as 100MHz is not stable on your device? wanna change 1400 to 1304 and 1600 to 1504? or increase 1600 to 1696?
User customizable bus frequency selection. no more overheating. if you are a battery freak, just set it to minimum and your device will last more than ever.
Based on Update3 sources...
Thanks for developing for us!!
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Thanks! I look forward to testing. If you need a guinea pig let me know.
Entropy512 said:
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Click to expand...
Click to collapse
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
AndreiLux said:
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Click to expand...
Click to collapse
Yeah, I figured as much, which is why it's pretty low on my priorities list
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
Click to expand...
Click to collapse
It says that nowhere. HTC claimed they had 90 days and that is a GPL violation. Easy enough to Google that one. It kind of bit them in the ass though - http://thread.gmane.org/gmane.linux.kernel/1048027 and https://freedom-to-tinker.com/blog/sjs/htc-willfully-violates-gpl-t-mobiles-new-g2-android-phone
After much media pressure they backed down and released sources in only 7 days.
GPLv3 gives an explicit 30-day grace period for resolving violations, but the kernel is not v3, it's GPLv2.
I really should stop pointing Gokhan towards fixes since he's a one-way street.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Click to expand...
Click to collapse
Yup - If someone else wants to port his more aggressive features they can try - it's just not coming from me.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
Click to expand...
Click to collapse
I'll have to look into that - As of a few weeks ago, the AT&T I777 sources were new enough that I9100 kernels (including Siyah) started to be based off of them. The question is - while Update2 to Update3 is a big improvement, is I777 to update3 such an improvement?
I'll have to check those out tonight and diff them.
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Looking forward to see the update being incorporated.
AndreiLux said:
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Click to expand...
Click to collapse
I'm going to start this over the next week - I've split update3 into what should be separate independent patchsets by component (touchkey, audio, wifi, etc.)
Last one is likely going to be the machine-specific ARM stuff - because that means rewriting the clock control patches completely.
*********
I've read on several ROM forums that only certain apps utilize or dual cores. go to sys/devices/system/cpu/cpu1 there is a file there. When using one of the above said apps it populated cpu1 with freq folders etc, changes that one file from 0 to 1 enabling it. without one if these apps there is no freq tables for cpu1.
****my question: using Linux and cpu i ran speed tests. Over 70 tests in total. There is zero performance difference in using one app versus another versus cm performance cpu menu. I understand how it looks like two cores are only utilized from certain apps looking at the folders. However it does not change performance at all. Tests show same speed any way to control cpu. Also feels the same. Is there really a difference our is it monkey say????
Also in my tests i found using "VR" versus sio or noob or cfq to be the fastest. I didn't feel a difference however changing i/o setting.
Sent from my SGH-I717 using xda premium
Their are claims that Intel’s internal handset testing has shown multi-core implementations running slower than single core, however they did not cite any particular chip. If you take a look a lot of handsets on the market, when you turn on the second core or having the second core there [on die], the [current] leakage is high enough and their power threshold is low enough because of the size of the case that it isn’t entirely clear you get much of a benefit to turning the second core on. In some of the use cases they cited, having a second core is actually a detriment, because of the way some of the software engineers have not implemented their thread scheduling properly.......
That being said, one could argue the concept that a single core chip, running a slight overclock, would produce a far better result, than a dual core application. But again, thread scheduling detracts from any governor efforts anyway...IMHO....g
Hum. I would have to agree then that in our case and in my tests dual core doesn't help nor hinder performance results but does appear to reduce battery life. Now these are my tests using two different programs to test performance and using combo of setcpu/system pro/Cm10 performance built in/Tasker to control cpu. I have done enough testing to know that on cm10 roms dual core, or so the sys files indicate, is of zero performance upgrade and appears to drain battery faster.
Sent from my SGH-I717 using xda premium
Yes ...I agree with your findings.
I suppose it's safe too say then, when using the AOSP rom source, within it's normal configuration, that unless development is done beyond the current schedules, the stated performance is well ....overstated ??
Of course , CM is in a constant state of change, and I suppose that after they are finished with the functional repairs, they may focus more on the kernel.
I'd be very interested to see your same tests against another kernel, say flappjaxxx latest JB build.
I do know that he, and several other developers have made some great improvements to the source kernels, and although there will likely always be bugs present, after running my own evaluation of them, the governors are functional and do make at least a perceived difference.
But as you stated, albeit at the cost of battery life.
I choose not to overclock, as I feel that the marginal reward , as proven by your testing , and by testing from several reputable sources, is simply not worth the risk ...g
I agree Greg, i will test other kernels... Samsung ROM is probably the only one i won't test... I also don't overclock, i do under clock at work and screen off using Tasker for battery life. That does help greatly. I'll post back after testing different kernels tonight.
Sent from my SGH-I717 using xda premium
troyolson92 said:
I agree Greg, i will test other kernels... Samsung ROM is probably the only one i won't test... I also don't overclock, i do under clock at work and screen off using Tasker for battery life. That does help greatly. I'll post back after testing different kernels tonight.
Sent from my SGH-I717 using xda premium
Click to expand...
Click to collapse
Excellent....
And I suppose, since this is the Premier development site, that it would be of great value to the community if you could perhaps publish your results here ?
These aspects of the android OS have been of great interest to me for some time.
Without doubt, many other users would enjoy this information as well in forming their decision regarding roms, kernels etcetera.
Thanks to you, for your inspiring thread. I look forward to the forthcoming information ....g
Ok with out posting tons of pics i tested all available kernels (new). Results were the same. No real difference in single core versus dual core...
The following pics show how to know whether the second core is online or not and my results and how i tested this time around... I was more through the first time but results the same.
Sent from my SGH-I717 using xda premium
troyolson92 said:
Ok with out posting tons of pics i tested all available kernels (new). Results were the same. No real difference in single core versus dual core...
The following pics show how to know whether the second core is online or not and my results and how i tested this time around... I was more through the first time but results the same.
Sent from my SGH-I717 using xda premium
Click to expand...
Click to collapse
I am posting pictures for first time hope this turns out.
What do you use to disable the second core? Read this with some interest. Would like to try this with ics Rom. With oc'ing fRom 1.56 to 1.72 i see a consistent jump of 300-400 in my antutu scores. Currently on flapjaxx ics b4.
I know it is just a score, but is your score indicative of the cm builds? It just seems really low.
Here is my 'stock 1.56 speed' with ondemand governor. Want to a get a single core sample.to compare with it.
How interesting ....
I can say that both of your posted results lead toward our initial assumptions, that indeed we are seeing a consistent draw against the systems cores with little or no improvement upon activation of the second core.
Some Time ago, shortly after my note arrived, I began some simple tests with low speed dual core activation. My thought process was simply this.
Slow speed dual core operation (both cores running in the 650mhz range ) would ideally produce a faster process response.
My initial results were favorable, as I had a noticeably quicker device during screen transitions, and even in several multitasking functions.
I even went so far as to create a small script to handle this function for me. I'm no developer, and ultimately I didn't possess the programming skills I needed to complete and implement my script into an actual, flash worthy modification. And based on what we are seeing here , the results provided would indicate that my attempt is flawed due to chip current leakage, if the cores are allowed to ramp to high, and perhaps even the use of improper source schedule interference.
I'm so busy these days, I simply haven't time to explore the low speed theory further at this point.
But perhaps with your test bench already set, a simple test using my concept could be carried out??
As we know, CPU [current] thresholds are plagued by voltage bleeding at maximum CPU frequencies, but the thought has just occurred to me that [current ] bleeding is highly controllable when the CPU is driven at lower voltage inputs. And too combine a reduced frequency with reduced voltage over a multiple core platform, could, or should balance the loss and equal the output levels.
Are you up for another test ??
If so ....I suggest the following parameters.
Core "0" at 600/700 MHz
Core "1" at 600/700 MHz
Governor at "interactive "
Voltage at "-24Mv"
Then we'll see if the theory holds water.
P.S. thanks gents, I'm enjoying the heck out of this thread ......g
Mad383max, look at your folders from my pics to tell if two cores are running. Typically on after market roms one core is running until you enable the second from other software like from my pics.
Will test at lunch. I like this lower voltage idea. If i were a betting man i would guess with speeds you proposed and two cores i would guess similar to higher results. Let's see....
Sent from my SGH-I717 using xda premium
troyolson92 said:
Mad383max, look at your folders from my pics to tell if two cores are running. Typically on after market roms one core is running until you enable the second from other software like from my pics.
Will test at lunch. I like this lower voltage idea. If i were a betting man i would guess with speeds you proposed and two cores i would guess similar to higher results. Let's see....
Sent from my SGH-I717 using xda premium
Click to expand...
Click to collapse
Agreed......
I'm excited to see the results....and thank you !!...g
I have to reflash ROM so pics might be a little awhile. I messed up some things and somehow lost my Google account. reflashing gapps and ROM didn't fix it.
Anyway results were 2600 something at 700 both cores underclocked 25... Slightly more than half of normal speed at slightly less than half clock speed... For kicks i tried 1.5 clock speed undervolted 75 (most my phone will go without lockups) and got 5k results. Best yet.
You are on to something. Less voltage = more speed. I now need to try single core undervolted. Give me couple hours for pics etc.. Got to get phone working with Google again and spend time with wife. She hates me on the phone.
Sent from my SAMSUNG-SGH-I717 using xda premium
No worries Troy. ...
Take all the time you need.....
I do appreciate the excellent testing you have undertaken. I know that the results are going to benefit the community.
And i am highly intrigued by your first run under the parameter set you've chosen...
It's leading down the exact path that i suspected. ..
I'll talk with you soon. ...g
A few additional items that I have failed to consider during my testing, could weigh heavily on our testing results and should be considered during testing.
They are, battery power levels, charger connection and type....(wall/PC), and rom power save levels.
I do know that the android OS will adjust itself during varying power levels, much like our setting the CPU to UC/UV settings, only on a much smaller scale.
I feel its important that we are able to control the input levels in the following way...
Battery to full charge, with no charger connection, and if the cable is needed we use a non powered port. Next would be controlling the rom power settings if the rom contains them, as found in most GB and ICS builds.
If these baselines are met, we should be able to greater rely on the mark scores we are seeing. These variables could explain why we continue to see so many peaks and valleys in scores when two users share the same builds, on like devices.....(speculation)..
Additionally, are we able to control the background processes to the extent, they will remain constant for testing?
Sorry for the rant.....Im just concerned about the ability to quantify our findings once testing is complete.
Ive started some tests on my end as well, and certainly do not want to give you the impression that I expect you to do all of the work.
After all, you did ask first....lol and I feel like Im dumping this effort into your lap.
And please forgive my pathetic punctuation in this post, as my keyboard of choice decided to fail tonight....g
Battery does effect performance greatly.... Also noticed none of the apps to test are very repeatable. Fluctuation seemed to be about 100.
Having issues up loading pics from phone, I'm away from laptop for a few days.
In the end i found -12 v single core to provide the best battery and performance that was equal to dual core. I tried over under voting many differences.... over voting did nothing, under voting a little made small preformance improvements. I believe some of fluctuations are related to app, battery, etc.... In the end it's too say dual core has no speed improvement. I would be cool to test an app that it's specifically for dual core. I am better off without the second core speed is same anyway, and battery is much better. There is definitely voltage leakage..
Let me know what y'all find in your tests....
Sent from my SAMSUNG-SGH-I717 using xda premium
Outstanding !!
I appreciate the hard work !!
So it seems we are better off using the note running a single core and about 12mv under volt.
And I'm of the belief that our second core is rather pointless...unless it can be proven that the second core is absolutely needed to perform a function.
And so far, I haven't found anything I use that requires activation of the second core.
I'll continue my tests, but the way it looks now, Intel is right, and Samsung pushed a dual core chip to this device for nothing more than a market share increase. As it is quite clear that the device does "not " need it to function well, and at a Very respectable speed.
Now we have a quad core version, and I highly question the motivation behind that move, beyond marketing as well.
These statements may offend some, and folks will certainly disagree, but if you want a great running device and great battery life, you need a single core chip ...IMHO ....g
Agreed Greg. Someone will get upset when they do thirty own tests and realize what we see, and what you said, good marketing by Samsung. Numbers don't lie and i did tests as controlled as possible. Even my battery shows in the picks... A true second useful core would have easily bested the single core results. Plus undervolting tella the bigger story...
I must say though. It had been very useful.. My battery life is so much better now!!!
For me the only true performance gain had been from v6 supercharger.
Sent from my SAMSUNG-SGH-I717 using xda premium
Fyi: same exact results using cm9 versus cm10. Neither ROM benchmarks faster than the other as of 9/16 cm9 and 9/15 cm10 builds. Dual core zero performance upgrade.
Tried quadrant again and result very up to 20% back to back so that app is useless to me.
Can someone try a Samsung based ROM. I'm curious add to a difference in roms. just use antutu benchmark and set cpu however you wish to whatever you wish just report cpu clock speed, type of test, and results
Sent from my SAMSUNG-SGH-I717 using xda premium
Out of town this week Troy, but i'm gonna bump it for ya...g
Development Goals:
- stability
- energy savings due to more efficient algorithms (whether theoretical or not is unimportant)
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
- all improvements should require MINIMAL user interaction (e.g. you don't need to do anything except flash the kernel or at the very least use SetCPU or the like to set fixed options)
- stability
Latest Kernel Here
20130625_10XX:
- updated with fix for more recent 4.1.2 Sense ROMs (should fix camera issue)
*unsure if this becomes incompatible with older 4.1.2 Sense ROMs though
20130602_07XX:
- NTFS support
- compiled using 4.8 linaro compiler
- improved workqueue queueing
- sleeper improvements
- responsiveness patches to the frequency controllers
20130531_09XX:
- fixed earpiece volume during calls
20130528_17XX:
- more optimizations (see GitHub)
20130527_18XX:
- more ARM implementations (see GitHub)
20130527_10XX:
- ARM implementations of kernel algorithms (see GitHub)
20130527_09XX:
- compiler optimization flags
20130526_22XX:
- initial version
- uses Linaro compiler
You can find my kernels at:
intersectRaven's Kernels
GitHub is at:
intersectRaven's GitHub
FAQ or something like that:
1.) Camera doesn't work!
- Try this fix from Golv here. This usually occurs on older ROMs.
*Latest 20130625_10XX version should solve this without flashing older camera libs.
Reserved 2
Reserved 3
Nice to see ir taking interest in the One. Truly a great dev
Sent from my Nexus 4 using Tapatalk 4 Beta
Uhhh nice to see you here
intersectRaven said:
Development Goals:
- stability
- energy savings due to more efficient algorithms (whether theoretical or not is unimportant)
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
Click to expand...
Click to collapse
Could you please expound on your statement that undervolting is relatively pointless?
From my experience, undervolting
1. Improves battery life because of lower wattage (Voltage * Amperage = Wattage). Even with a really bad binned CPU, it can still make a difference.
2. Cooler operation. This means longer component life - especially important as this phone is very difficult to repair. Battery is sandwiched so the cooler we can keep the device, the longer the battery will last. (Battery longevity practices could be a topic of it's own)
3. It's Fun! Haha. But seriously. I love to tinker. How low can you go??? It's fun seeing a 25% decrease in voltage and it still run stable
I really like your approach with the rest of your points though. We should have a stable kernel that doesn't have to be tuned or tweaked at all. This however, only suites the majority. The minority may want more. I'm currently in the process of making a kernel with as few restrictions as possible. Except that I will put a ceiling on the maximum voltage (1.25v for the cpu)) because I discourage overvolting beyond spec.
Anyway, thanks for the work. The One is Awesome!
m0nz said:
Could you please expound on your statement that undervolting is relatively pointless?
From my experience, undervolting
1. Improves battery life because of lower wattage (Voltage * Amperage = Wattage). Even with a really bad binned CPU, it can still make a difference.
2. Cooler operation. This means longer component life - especially important as this phone is very difficult to repair. Battery is sandwiched so the cooler we can keep the device, the longer the battery will last. (Battery longevity practices could be a topic of it's own)
3. It's Fun! Haha. But seriously. I love to tinker. How low can you go??? It's fun seeing a 25% decrease in voltage and it still run stable
I really like your approach with the rest of your points though. We should have a stable kernel that doesn't have to be tuned or tweaked at all. This however, only suites the majority. The minority may want more. I'm currently in the process of making a kernel with as few restrictions as possible. Except that I will put a ceiling on the maximum voltage (1.25v for the cpu)) because I discourage overvolting beyond spec.
Anyway, thanks for the work. The One is Awesome!
Click to expand...
Click to collapse
Should have put a qualifier there huh? Anyways, it's pointless from a no tweaking perspective since undervolting may not work for some chips and could cause more trouble (random restarts and the like) than it's worth. It's fun for a tweaker (like when I did something like that for the N1) but not for someone who's the flash and forget type. :fingers-crossed:
Thanks
P.S you missing the ":" on the http link
Really glad to have you here iR. Missed your kernels from my nexus one days with those hybrid AVS kernels.
Camera is buggy
Sent from my HTC One using xda app-developers app
chourmovs said:
Camera is buggy
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
The camera will problably need som librarys, like most other kernels, I think. There is a zip for this in other threads (couldn't find it right away)
chourmovs said:
Camera is buggy
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
What is the problem exactly? Also, is this a custom Sense ROM or stock Sense? Just mentioning that it is buggy doesn't actually help me solve it since there are no bugs in my phone.
Sorry
I m on last ardh by mike86 and when I launch camera, it stuck on black canvas then I ve to hard exit
Sent from my HTC One using xda app-developers app
Intersect my man. Nice to see u in the HTC one forums!
Sent from my HTC One using xda app-developers app
Camera troubles
If somebody have problems with the camera, use the camera Fix from here:
http://forum.xda-developers.com/showthread.php?p=41712563
The bug is due to the old source code, released by HTC
If you are using a ROM based in 1.29.xxx.16 like the most of the new custom Roms flash just after the kernel.
Are the old camera libraries, that works with the Custom kernels.
chourmovs said:
Sorry
I m on last ardh by mike86 and when I launch camera, it stuck on black canvas then I ve to hard exit
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
Can you try the link posted below by Maikeu and get back to us whether it fixes the issue?
Maikeu Locatelli said:
If somebody have problems with the camera, use the camera Fix from here:
http://forum.xda-developers.com/showthread.php?p=41712563
The bug is due to the old source code, released by HTC
If you are using a ROM based in 1.29.xxx.16 like the most of the new custom Roms flash just after the kernel.
Are the old camera libraries, that works with the Custom kernels.
Click to expand...
Click to collapse
Posted this in the second post here for future reference.
HI, after fashing this kernel , i cannot hear any sound from call dial ,
008325 said:
HI, after fashing this kernel , i cannot hear any sound from call dial ,
Click to expand...
Click to collapse
Thanks for the heads up! Missed that in my testing. :silly:
*Uploading a fix now.
intersectRaven said:
Thanks for the heads up! Missed that in my testing. :silly:
*Uploading a fix now.
Click to expand...
Click to collapse
Thank you very much i really like this kernel , smooth , cold , save battery
This is loosely based on CTXz's kernel. I just wanted a little more from it. I'm using it on my "Nook". Hence the name.
So may I present to you.....
Nuki - Kernel
Install:
Just flash this through TWRP recovery. I use 2.8.7.0. It'll do it's own wipes.
It's built for the "Nook" version. But should work for any WiFi only ROM.
My preferred tuner for the kernel is Kernel Audiutor . But others should work also.
Changelog
V1.1 - Ubertec and Linaro toolchains
Enabled KSM and tweaked
init.d support
Selinux permissive
V1
OC to 1344mhz
Intelliplug 3.9
govs added - lionheart, pegasusq, conservativeX, darkness, nightmare.
Shedulers - sio, vr, zen. I haven't been able to get "row" to compile without errors.
Frandom
Lots of tweaks/optimizations
Downloads:
Nuki-V1.1-Linaro
Nuki-V1.1-Uber
Nuki-V1
Stock-OG1-Nook-Kernel
Thanks to
@CTXz
@laufersteppenwolf
@friedrich420
And the ton of other git's I went through to get this.
XDA:DevDB Information
[Kernel] Nuki-Stock-T230NU, Kernel for the Samsung Galaxy Tab 4
Contributors
engine95
Source Code: https://github.com/engine95/Degaswifi-CPU-tweaks.git
Kernel Special Features:
Version Information
Status: Stable
Stable Release Date: 2015-10-17
Created 2015-10-17
Last Updated 2015-10-17
reserved
Mine! Will post feedcack! :fingers-crossed:
@engine95 - awesome. Gonna test it out and let you know
Looking good. Confirm working looking the SM-T230NU......should work on SM-T230 as well.
Well done. I hope it works good for you all!
Just a little update.
I'm trying to work on the GPU now, and it's proving very interesting. This GC1000 GPU treats the cores as being separate. Meaning one is for 2d @ 416mhz the other is for [email protected]
It looks like our possible freq's are 533, 624, 702. And maybe one close to 800 according to the specs.
The problem I see happening, is that we'll be locked into whatever freq I build into it. Meaning there isn't a way to change it through a kernel tuner.
So far, I havent had any luck OC'ing either of them. But we'll see what happens.
V1.1 is in OP See read changelog
Still no luck with OC GPU. But theres 2 builds: Linaro and Ubertec toolchains. Let me know which one you like/prefer.
Enjoy
Nice
so what's the point?
new features?
overclocked?
emoboy (Official Name!)
Nice
so what's the point?
new features?
overclocked?
Click to expand...
Click to collapse
I don't know you. So I don't know if this is sarcastic or not. So I'll play this answer in the middle.
Read the change log and look at the git. Almost everything here has been reworked, updated and/or added. Oc is the only thing I haven't touched. Yet.
@engine95 - for me, my tablet runs smoother on the linaro build.
Nice update and thank you.
g_ding84 said:
@engine95 - for me, my tablet runs smoother on the linaro build.
Nice update and thank you.
Click to expand...
Click to collapse
Thanks
On my past kernels, Ubertec seems to usually run faster. While Linaro runs smoother. But on this tab, it's harder to tell. So Thanks for letting me know. :good:
I am impressed with a lot of the optimizations that "Sammy" has already build into this. Source code I'm used to changing is already in it. And this thing sleeps like a baby.
It's too bad Marvell/Vivante/Sammy has throttled this CPU/GPU so much according to the specs. I mean, for a low-end setup it could be a lot better. But then, it would probably lose battery.
I'm not going to add anymore "stuffs" to it, as I think we have a good selection now. What is in it should satisfy " battery thru performance" depending on the settings people choose.
I haven't even looked a OC CPU yet. All I've tried so far is GPU and that hasn't gone well.
These will be the next things I'll work on. Unless......"SQUIRREL!"
forgive my ignorance, normally i would use the googles and xdas to educate myself before asking such a question, however, I have basically given up on this tablet.....so does your development of this kernel bring the tab 4 7" owners any close to getting an aosp build, this tablet is useless running TW?
edit: upon review, my post was thankless but i am very thankful for you doing what you do for this tablet, it so needs the attention!
gammaxgoblin said:
forgive my ignorance, normally i would use the googles and xdas to educate myself before asking such a question, however, I have basically given up on this tablet.....so does your development of this kernel bring the tab 4 7" owners any close to getting an aosp build, this tablet is useless running TW?
edit: upon review, my post was thankless but i am very thankful for you doing what you do for this tablet, it so needs the attention!
Click to expand...
Click to collapse
Its all good. No worries.
Unfortunately, no. It just improves on stock.
Im new to Samsung, so its all a new learning curve for me. I am kinda shocked at how "low-end " this is for a mainstream tablet. I'd have thought it would be.....better.
T-230 with nuki v1.1 linaro. Working amazingly. Thank you much.
Thank you for this kernel! I've never even thought to use another kernel for this low-end device.
Mine was originally the Nook version as well but I have flashed the latest non-nook firmware and heavily modded it.
I'm using the Linaro version. Xposed is running with a few modules. tuning with Kernel Audiutor.
The device it running very well. smoother than normal. It's a bit warmer too. but we'll see about that though.
Uber variant. Makes a huge difference. Thank you!!!
Still using the linaro. I can't seem to make either of the CPU frequencies stop being max. (1344)
Any suggestions? I'll end up trying the Uber kernel in a moment.
brossovitch said:
Still using the linaro. I can't seem to make either of the CPU frequencies stop being max. (1344)
Any suggestions? I'll end up trying the Uber kernel in a moment.
Click to expand...
Click to collapse
When you reboot, you'll need to set min, manually. I don't know why.
Or, try a different gov. Lionheart and conservativex are my preference.
You may need to remove the set on boot option, then reenable it.
It shouldn't be sticking like that
Mhh, that all sounds very interesting. Possible I can test it this weekend.
CTXz kernel is my first choice all that last year, so I can test it against yours. Don't get me wrong it will be very interesting to see what's different.
Not to see what is better, I wish to see the difference. Every ROM has his specific use and modifications. So it is the science guy who wish to know it .
Will report later about it and CTXz I will be every time a fan of your work .