[RELEASE] ShinTo Kernel v31a001
[ Enhancements included in ShinTo Kernel ]
–== ShadowLED ==–
By linking the Note 3’s RGB LED to the different activities of the OS, we can know in real time what is going on, even when the screen is off, and the phone is seemingly “deep sleeping”.The brightness of the led light is proportional to the instant workload; the brighter the color, the higher the workload.
BLUE: All things related to WIFI networking activity [Upload/Download].
GREEN: All things related to internal “SD” (MMC0) activity [Read/Write].
RED: All things related to external “SD” (MMC1) activity [Read/Write].
You can disable ShadowLED if you go to ShinTo Features in Synapse app.
–== ZRam ==–
RAM is a precious resource that we can never have enough.
ShinTo Kernel uses state of the art functionality to intelligently manage and optimize RAM for peak performance.
Our NOTE 3’s, running Samsung’s Android Kit Kat (4.4.2), have a huge amount of background apps and services that, most of the time, sit idle waiting for some event to fire.
All these background apps and services are sapping precious RAM, and some will never do anything.
ShinTo Kernel uses ZRam very moderately (only 256Mb) to compress sleeping background processes and apps to free precious RAM for other interactive processes (the ones most important to YOU).
The compression ratio achieved is at least 3:1 (256->85) and up to 4:1 (256->65) while not affecting performance or battery at all, as the size of the compressed RAM is only 256Mb (do not go above that!).
Some people would argue that there’s no need for this as we have plenty of ram but from my experience with ShinTo Kernel, the more “free” ram, the more apps you can have in ram, even if they are not currently active and this amounts to a better multitasking and more fluidity.
The final argument is that even Google have activated ZRam in their Android and Chrome OS.
I have included a very nice, simple and clean app called “ZRAM Status”
You can disable ShadowLED if you go to ShinTo Features in Synapse app.
–== UKSM ==–
UKSM by KernelDedupe.org is a state of the art intelligent memory management system that achieves great ram saves by using two techniques:
(1) ZeroPages
When we launch an app, most of the time the app will allocate more (or a lot more) memory than it really needs. The extra memory is allocated exclusively, zeroed and sits idle till the app decides to use it.
That could happen sometime in the future or never…
ShinTo’s UKSM kernel service detects these kind of “ZeroPages” and intelligently remaps them to the ZeroPage manager and then frees those pages of ram.
Once the process really asks for these “ZeroPages”, the ZeroPage manager takes care of everything.
All this is transparent to the normal user’s workflow and it doesn’t affect performance or battery life.
As a matter of fact it might enhance battery life and performance as a lot more can fit in ram so there’s less wasted time and energy fetching data from SD (MMC0).
That should also help with multitasking fluidity.
My daily workflow can see up to 400Mb of ZeroPages, which means about 400Mb of ram saved and allocated to running processes that need them.
(2) SamePageMerge
There are some processes that create many copies of the same memory contents (same pages).
Some of these (same page) content’s never change so it is a waste of memory.
One clear example could be a web browser.
ShinTo’s SamePageMerge manager detects these identical pages and “merges” them, so they only occupy one page instead of many.
If a process needs to change the contents of one of these “identical” pages, the SamePageMerge manager detects that and takes care of everything.
All this is transparent and seamless, with no performance or battery penalty.
I routinely hit about 50.000 pages (around 200Mb saved) (50.000 * 4k) and have hit about 90.000 pages with heavy loads.
To disable UKSM you need to issue the following command with root :
echo 0 > /sys/kernel/mm/uksm/run
–== DriveDroid ==–
“DriveDroid allows you to boot your PC from ISO/IMG files stored on your phone. This is ideal for trying Linux distributions or always having a rescue-system on the go… without the need to burn different CDs or USB pendrives.”
ShinTo Kernel includes the necessary patch and functionality to be able to switch from CD to USB mode, so you could create rescue USB keys directly on the mounted image in DriveDroid.
For people that are in the tech support and have to reinstall different operating systems or boot recovery cds, it is a godsend as they don’t need to have different usb keys, cd, dvd, etc…
It’s a great tool and I recommend everyone to check it!!!
To know more about DriveDroid | DriveDroid XDA Forum
–== Fix / Performance Enhancement / NEW STUFF ==–
This new release of ShinTo Kernel includes the following :
- TRUWATCH Stability Watchdog for “init.d”: ShinTo Kernel will now watch you system and check for stability issues the first couple of minutes after you’ve booted up. If there’s any kind of grave instability that causes the system to reboot or misbehave, on the next reboot, ShinTo Kernel will NOT load any scripts in init.d to give you the chance to troubleshoot & fix. If your system is stable past the 2 minute mark, then on next boot it will launch again all scripts in init.d
Enable/Disable from the comfort of Synapse. - ShinTo Kernel is now 100% independent of your busybox or your /system partition.
- Enhanced GPU BW for even more fluidity.
- Fixed permission issues “cannot share picture” that some were having. (Yeah cool! xD)
- Recoded all Synapse scripts to be totally /system independent and use ShinTo Kernels busybox.
- Increased boot up speed by up to 17 seconds compared to previous version; still a work in progress.
- Included same version of PrecoGov due to popular demand.
Please, let me repeat myself by saying that this is an ALPHA version of very early code and it is not yet even remotely close to where I want it to be, so if your “holy SOT” is not as high as previous versions, please use Interactive and be happy! - Added latest updates from F2FS source.
- Patched ShinTo Kernel to latest available 3.4.105
- Included enhancements to cpu/memory/scheduler/futex/arm management code.
- Fixed the led failing for notifications once ShadowLED is turned on.
- Completely rewrote ShinTo Kernel init sequence to be on the defensive and more resilient to edge configurations/roms or init.d “Wild Wild West”.
- Fixed ShinTo Kernel installer not deleting ShinTo’s old init.d scripts. Now you should have a pristine & free init.d forever (ShinTo Kernel will not use it for it’s things).
- A lot more stuff that right now I don’t remember…
It is compiled with latest available LINARO Toolchain GCC 4.9.3 compiled by the great Christopher83
hey man THANKS A LOT! with the other version my phone wan’t boot up, now boot and i can try your kernel!
high five from italy
Grazie, il mio piacere!
Hope you’ll like it and it will perform well for you.
CIAO!
you are AMAZING!!! your kernel work really perfectly! it’s incredible becouse i have tried about 7 kernel’s but they aren’t work how i like! and i find your kernel becouse an guy’s talk about on xda but i don’t never an post, and i think people need to say what fantastic job you have do!
i have the last question’s, there is an FAQ for various kernel setting (or what you like for performance/battery), becouse i think it’s important for guys not have familiarity with kernel settings!
CIAO!! 😀
Grazzie for such nice and encouraging words.
I don’t have a specific faq setting as I am constantly changing stuff and flashing to test.
It all depends on what you want to achieve, if more battery life or more fluidity or a balance.
I recommend you do a backup of your phone and okay with different settings.
Enjoy!
Ok man i have too much to work!
i have some question for you (ideas for kernel and other) but for don’t write here too much i want talk with you in ptv, it’s possible? (i dont have twitter haha)
You can catch me at XDA forum in the ShinTo Kernel thread.
I wonder, why exactly the minimum frequency for gpu seems to be 320mhz? I can’t set it lower in Synapse. Changing USB mode from UMS (that I had set on earlier kernel) to MTP results in error “SOptionList has failed – device or resource busy” – irrespectively of the usb cable being connected. Nevertheless usb state was changed to MTP. Now I can’t change it back to UMS. I have 2 original Samsung chargers and I have set charging speed to 2100mA in Synapse, with ignoring dangers and so on, but unfortunately it does not work and still tops up at 1800mA (as Galaxy Charging Current informs me and charging log confirms). Same happens on both chargers (different cables too).
Gpu drops to 200Mhz in reality but you see it reflected as 320.
Thank you for reporting the Synapse problem with ums setting. Close Synapse and try again to change it back.
When you set up 2100 as maximum charging current that current won’t be effective until the screen is off. When screen is on the charging current will be 1800 mA as per every single kernel out there. Charging current can also be affected by the quality of the USB cable.
Try the following : load GCC, turn the screen off. Wait about two or three minutes and then turn screen on and immediately refresh GCC. What do you see as charging current?
OK on GPU. Closing Synapse, restarting the phone and resetting Synapse data did not help. As to the charging – I meant whole charging cycle from about 10% up to about 90% as reported in charging log – it measures charging rate and writes the result every 5 minutes . GCC was only for verification in the middle of charging process – turn the screen on, unlock, start GCC (from killed state) and check. It’s not that I’m very bothered by this as the difference would be less than 20% anyway but I like to have stuff working as they should. It’s a bit disappointing really, I had Note 2 and when connected to my PC usb port I could charge it at 1500-1700mA and now in the same port (though the cable is USB 3 and not USB 2 variety) I get less then 1000mA, changing cable to the old USB 2 does not change the charging speed anyway.
The Synapse USB MODE happens in my case when I select PTP, but when I exit synapse and load it again I can select other options.
Will check “Charging log app” to see if I have the same results.
As per the disappointment, you can always uninstall ShinTo Kernel, install a kernel that works for you and be happy with it.
Nah, you misunderstand 🙂 I never got the charging speed to go higher than 1800 on any kernel nor did I ever get more than about 1000mA from my usb port on any kernel – it seems that the way they are all written it just isn’t possible – though on Note 2 it worked fine. It was a wishfull thinking on my part. I would not uninstall ShinTo kernel as it is superior to any other I tried in any way that I can test 🙂 So don’t worry, you have a convert in me. I will test USB mode further later.
Are you empirically sure it is not working?
If so, then I will have to look into the inherited code and do my own assessment as I also like my battery to charge as fast as possible… Am not too worried about it’s lifespan as I can buy a new one for 10e.
I’ll make some time now to do a log run and collect information from the charging process and see what are the real values as reported by the charging chip.
Would like to get to the bottom of this…
So, I did a test run and collected the info from system log (/proc/kmsg).
Data here is filtered with grep for Inow.
From the data that the managing chip is spewing out, it seems to be charging with 2.100mA in my case…
root@hlte:/sdcard # grep Inow ampers.log
[ 6065.850514] [CeK!] :: sec_bat_get_battery_info: Vnow(4225mV), Inow(450mA), Imax(460mA), SOC(91%), Tbat(264)
[ 6080.693182] [CeK!] :: sec_bat_get_battery_info: Vnow(4146mV), Inow(450mA), Imax(460mA), SOC(91%), Tbat(264)
[ 6092.831231] [CeK!] :: sec_bat_get_battery_info: Vnow(4331mV), Inow(1200mA), Imax(2100mA), SOC(91%), Tbat(264)
[ 6112.873899] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(91%), Tbat(269)
[ 6116.424920] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(91%), Tbat(269)
[ 6116.999108] [CeK!] :: sec_bat_get_battery_info: Vnow(4335mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(268)
[ 6117.555534] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(268)
[ 6118.262637] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(268)
[ 6118.928447] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(268)
[ 6119.696504] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(267)
[ 6120.334986] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(267)
[ 6120.966556] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(266)
[ 6121.747787] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(266)
[ 6122.382924] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(266)
[ 6122.611965] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(264)
[ 6123.247360] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(92%), Tbat(263)
[ 6123.869735] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(263)
[ 6124.452858] [CeK!] :: sec_bat_get_battery_info: Vnow(4335mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(263)
[ 6125.161220] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(261)
[ 6125.793141] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(261)
[ 6127.001649] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(260)
[ 6127.649611] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(260)
[ 6128.497047] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(259)
[ 6129.528563] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(258)
[ 6130.176583] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(258)
[ 6130.924765] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(93%), Tbat(257)
[ OMITTIED ]
[ 6338.025048] [CeK!] :: sec_bat_get_battery_info: Vnow(4335mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6339.272803] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6339.909783] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6340.707181] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6341.337523] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6341.974663] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6342.598499] [CeK!] :: sec_bat_get_battery_info: Vnow(4332mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6343.236765] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6344.458927] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6345.072046] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6345.762723] [CeK!] :: sec_bat_get_battery_info: Vnow(4335mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6346.535177] [CeK!] :: sec_bat_get_battery_info: Vnow(4335mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6347.166160] [CeK!] :: sec_bat_get_battery_info: Vnow(4335mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6347.790243] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(2100mA), Imax(2100mA), SOC(100%), Tbat(217)
[ 6348.905112] [CeK!] :: sec_bat_get_battery_info: Vnow(4300mV), Inow(450mA), Imax(2100mA), SOC(100%), Tbat(216)
[ 6358.604901] [CeK!] :: sec_bat_get_battery_info: Vnow(4300mV), Inow(450mA), Imax(2100mA), SOC(100%), Tbat(216)
[ 6360.483055] [CeK!] :: sec_bat_get_battery_info: Vnow(4335mV), Inow(1000mA), Imax(1000mA), SOC(100%), Tbat(216)
[ 6380.533843] [CeK!] :: sec_bat_get_battery_info: Vnow(4333mV), Inow(1000mA), Imax(1000mA), SOC(100%), Tbat(217)
I stand somwhat corrected 🙂 I have looked through a log and Imax is correctly set to 2100, only Inow is rarely that number, it varies from 1000 to 2100. I have not checked kmsg before and relied on Battery Monitor Widget Pro history log – it shows values sampled in intervals and averaged on 5 minutes basis – the max that it ever showed me (checked over 2 months worth of data) was 1768mA. It seems that my chargers are not up to snuff or… I don’t know what. Nothing wrong on the kernel side since it sets 2100 correctly.
Is it possible to increase charging rate for USB 3 connector in PC? Mine can handle 1500+, tested for over a year on my Note 2 and I prefer charging out of PC.
Have you ever tried to actually OC GPU in our Snapdragon? I have read reports that it does not work and I have never had any gains in performance on other kernels that had that option. Is it possible to do or the hardware is factory limited?
Will look into the USB3 thing, but right now I’m severely strapped for time.
The only way to be 100% sure of the mA that the charging chip is requesting and getting delivered would be to use a measuring station that you plug the phone to, and it would give you all the data in real time… I think some time ago I saw a gadget of the sorts in DX (DealExtreme) that you would plug between the phone’s usb port and the charger.
I’ve worked extensively on the GPU part and I came to the same conclusion as you.
I bet it’s on the FW side that must be hardcoded for the Adreno 330… the gut feeling is that anything above 487 gets cut to 320…
I did increase the backend bus for the gpu (which it seems no one bothered to analyse?) so that might help…
I just need to do this for some reason… honestly I don’t really know at all why:D
YOUR KERNEL IS AWESOME!!!!!!!! It gets updated frequently, it has all the mods and tweaks that are important while having some tweaks (or should I call them revolutionary features?) that make this kernel unique:D the precognition gov is something really good that I have not seen on any other note 3/Nexus kernels:D This governor is awesome! Pls keep up the good work since right know your kernel is the very best available hence i will defientely miss you support and features when swithing devices:D
anyway thanks again for developing such a great kernel, for sharing it and for implementing features that really make differences!!!
I thank you for such encouraging and kind words!
Just be warned that PrecoGov is still in very ALPHA stage and a lot of things are not yet implemented. I mean it is just dealing with about 15% of the stuff it should be, so it is not the best choice for every workload out there and it will drain more battery.
Some ppl don’t read and keep pounding me with that, so most probably PrecoGov will be taken out of the next release.
Hence why your words are encouraging 🙂
Maybe it’s just me but most of the other governors are causing my note 3 to overheat when playing casual games… (except ondemandplus)while my it is just doing fine with the precog governor:D
But there are two questions left:
1. your prev. aswer seems to imply that i could even better performance and battery life with different governors… do you have any suggestions? I already checked several release notes but I did not find any direct suggestion regarding the governor.
2. where does that name come from? Was it once an insider joke or something like that? would be very interesting to know!:)
Thanks for your quick response (previous one)
Well no I don’t have any specific recommendations because I haven’t found a governor that adapts to all the different workloads and most of the “exotic” ones are basically a copy of conservative with varying degrees of added code / ideas / tweaks that revolve around the same old principle.
PrecoGov aims at flipping the problem around by infusing (real) intelligence into it (not even 5% there for now) and adapting precisely to the Note3 ”s owner.
Who knows maybe I will succeed or maybe I will crash and burn, but either way it’s a great way to learn C for Kernel.
PrecoGov comes from Precognition Governor and the name of PreCog.me comes from a time ago when I did some hacking to improve the response time and I name it “Precognition UltraBoost”
It has to do in a way with AI and robotics 😉
Well, very interesting to know where the precognition governor’s name comes from but that wasn’t the name explanation I intended to ask for… (I read my comment again and I noticed: well, you did not tell which name you want to have explained:D *facepalm* sry:) )
Actually I was interestedI where the name ShinTo comes from….
(sry for my misleading prev. comment:/)
It is explained at the beginning of every ShinTo Kernel post, the where & the why.
I swear I read the content of this site several times but I somehow did not notice your little info part at the very beginning…. I must have been toooo excited:D but unfortunately that’s where misunderstandings and mistakes come from:(
I’m using Precog governor and it works great, battery life is incredible – I get 16 hours of SOT on standard battery (granted it’s mostly reading documents in pdf or on the intraweb but still…) over 2-3 days. If anyone does not believe I can send them screenshots 🙂
However it does it, this kernel just wakes the phone the moment I press the home or power button – almost no wait time like I had on other kernels. I love the leds reporting activity for accessing memory and internet. The only (very small) problem is in some games that occasionally stutter for few seconds but it have more to do with my temperature limits (65C for core) then precog config 🙂
All in all – Great Work !!
Thx.
Ocasional stutter in games can be PrecoGov getting confused when you go from say 1 or 2 cores to 4 cores then the load gets spread evenly so it thinks the phone is less busy and tried to scale down to save battery.
That will change in the future by doing things in a very different way… 😉
No, that’s not it – it’s like the game for 3-5 seconds decides to play with 10-15 fps while at other time it works fine. But I tested it out in the last few hours and it is thermal related. All other things being constant, once I incresed max temp back to 85C the stutters were gone. The phone is much hotter but the game works smooth. If you want to test it, its Eufloria HD (HD version is only available from HumbleBundle so I would have to send it to you) – great game on it’s own 🙂
hi..i’m on f2fs now.just wanted to ask,if i wanted to flash a new rom,will it be flash as ext4 or f2fs?
Depends on the rom; usually the rom has to format system to ext4.
To avoid any surprises, I’d advise you to convert to ext4 prior to flashing another kernel/rom.
ok..thanks for the info..
Sometime Phone goes screen of and dont on ;-; i must remove battery for work:/ any fix ?
Run with stock voltage and core clocks (no overclocking or undervolting) and try again.
I never cheange it ;-; i stay only on stock kernel settings
Hi for some reason when I try to overclock it wont go above the stock speeds. I’m using set CPU and I also tried Hyperdrive tweaks. Any advice on what I’m doing wrong? Thank you.
Use the included Synapse to unlock the higher bands.
Thank you. Excellent work!
You welcome!
Expect something revolutionary very soon 😉
I’ve flashed the latest Shinto Kernel on my Note 3 Tmobile, Im running Hyperdrive Rom 7.1 I change the file system to f2fs but my mistake was to select “fix permissions” on the twrp recovery after re booting my baseband is gone. Cant receive or send sms or calls. Please any idea how to solve issue?
Restore nandroid especially efs partition and if that doesn’t help then head over to xda and ask for help.