[Kernel] Franco Kernel V10 (04.04.2012)

Es gibt einen weiteren Kernelentwickler für's Note.
Franco.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 04.04.2012 V10
http://www.pocketpc.ch/galaxy-note-r...ml#post1375066
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 11.03.2012 V9
http://www.pocketpc.ch/galaxy-note-r...ml#post1353083
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 01.03.2012 V8
http://www.pocketpc.ch/galaxy-note-r...ml#post1345803
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 26.02.2012 V7
http://www.pocketpc.ch/galaxy-note-r...ml#post1342202
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 18.02.2012 V6
http://www.pocketpc.ch/galaxy-note-r...ml#post1336581
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Update 17.02.2012 V5
http://www.pocketpc.ch/galaxy-note-r...ml#post1335862
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 14.02.2012 V4
http://www.pocketpc.ch/galaxy-note-r...ml#post1333820
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 14.02.2012 V3.1
http://www.pocketpc.ch/galaxy-note-r...ml#post1333565
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 12.02.2012 V2
http://www.pocketpc.ch/galaxy-note-r...ml#post1332434
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

XDA Thread:
http://forum.xda-developers.com/show....php?t=1491428


Er macht dies schon länger, ist XDA anerkannter Entwickler und legt vor allem Wert auf Batterieschonung, bei maximal möglicher Performance (wer macht das nicht ;-))

Er hat den ondemand Governor getweakt, sowie den cfq Scheduler und meint, dass entgegen den Aussagen anderer Kerneldeveloper, ein getweakter CFQ besser sei.

Nun, schauen wir mal

Inhalte:

• * Initramfs with the usual stuff (root, CWM support, recovery etc)
• * Partitions properly mounted in the ramdisk to take the most out from the device
• * VM values tweaked up for maximum performance/battery
• * Ondemand governor properly tweaked - features 10k sampling rate for more fine grained samplings
• * CPU frequency transition latency decreased to 40k instead of stock 100k
• * I/O boosted - I feel this is the most important setting in the Android kernels
• * CFQ I/O scheduler by default - most of the Android kernel devs choose to work with deadline or other schedulers, but after deep testing a proper tweaked CFQ for flash devices proved me as the most reliable choice
• * CFS task scheduler properly tweaked for the best multi-tasking experience
• * CFS Autogroup added
• * TCP Veno congestion scheduler by default as its more suitable for this kind of devices
• * Kernel stripped of debug shit - the only debugs that stayed were: logcat, printk and kallysms (for Voodoo Louder support)
• * Hotplug fixed with arighi patches
• * Patched up to 2.6.35.13 from the mainline kernel channel
• * CRC32 library that is used by a lot of internal kernel mechanics completely patched up to the latest versions
• * Compiled with Tree RCU Fast No Hz for further battery savings
• * The usual Franco's magic
• * Lots lots more that I will remember later and add it back here...

Download:
http://minooch.com/franciscofranco/G....Kernel-10.zip

Wer will, kann nun auch das Franko Kernel App kaufen:
https://market.android.com/details?i...co.kernel.note

Achtung, man brauch vorher ein "sauberes Gerät".
Hatte man vorher andere Kernel's, Thunderbolt Scripts oder "zeugs" aus Custom ROM's, ... weg damit.

1. Zuerst eventuelle Profile von Set CPU, Voltage Control oder ... deaktivieren, damit sie beim Boot nicht geladen werden
2. Kernel Downloaden und auf die SD Karte kopieren
3. jBroid_Kernel_Cleaning_Script laden, auf die SD Karte kopieren und im Recovery (nicht über das CWM App) Flashen
4. Im Recovery bleiben und den Kernel Flashen (install zip from...)
5. Reboot und fertig.

Ein Test Wert??
Ich fahr gerade mit AbNo v3.7 ganz gut ...
hast ma Blick geworfen??

(Moin Großer ;) )

Mh ja, bin aber wieder zurück.
Das Gerät geht in den Deepsleep, aber nicht Sleep, sondern Koma.
Benchmarks sind sehr gut, smoothness auch, aber ... er muss noch ein wenig dran feilen.

Back to Abyss 3.7

Wir geben ihm mal die Zeit :-)

Danke!! (sagt auch mein Note ;-) )

Schalom der Reddy

Ja, es scheint aber ein sehr Erfahrener Kerneldeveloper zu sein.
Wir können als gespannt sein.

wie ein Flitzebogen ;)

lol, Koma ist gut! Hoffentlich ist Dein SGN danach kein Apalliker z.B. aufgrund einer O²-Insuff.
Danke für den Hinweis, weil dann machen wir da mal nen großen Bogen drum.

o.k. Problem gelöst.
Man brauch ein sauberes Gerät.
Ich habe nun vorher das jBroid_Kernel_Cleaning_Script drüberlaufen lassen und siehe da.
Everything works fine.

Auf zum Langzeittest.

Zitat:

---

Zitat von spline

* TCP Veno congestion scheduler by default as its more suitable for this kind of devices

---

Wow... das erste mal, dass ich sehe, dass sich ein Kernel-Dev sogar dem Thema TCP congestion annimmt. Entweder weiss er wirklich, was er tut oder ist ein grenzenloser Übertreiber. Mal antesten. Aber auf jeden fall: Fett...!

Hatte trotzdem wieder koma statt deepsleep.
Schade.

Gibt ne V2. Habe die wieder runtergeworfen, laut XDA sind permanent beide Cores aktiv.

Also ich lese seit der V2 nur Lobgesang.
Das mit den 2 Cores ist kein Bug, sondern ein Feature.

Changelog:
#2

• * Conservative set as the default governor - gave it 10k sampling rate like I did on Ondemand and gave it a 80 up_threshold, a bit lower than the stock value. This will make the governor scale up a bit more often, making the system a lot snappier while maintaining a good battery balance
• * Added SLQB memory allocator - I usually tend to use SLUB, but I decided to give this one a try this time and it proved to be a great choice
• * Dynamic Hotplug disabled - we want the system to have both cores always enabled. This means two things, means it will help a lot for the race-to-idle (the fast we go into idle the more battery we can save), and it means the amount of overhead that was created during onlining/offlining cpu1 is gone since hotplug is a very costly process to the system
• * Power Management patches from the mainline kernel
• * EXT4 driver patched up a little bit
• * EXT4 write performance regression fixed (regression is when a newer introduced code fucks up, unintentionally, some other code, in this case the regression was fixed)
• * Lowmemorykiller driver patched up for a better memory management
• * Sleep of death issue should be fixed
• * Introduced VMAP_AREA_CACHE - for more information visit this old commit from me (commit)

Download:
http://minooch.com/franciscofranco/G...o.Kernel-2.zip

@Spline bitte um ne verständlich leichte Erklärung was das bringt, wenn Beide Cores aktiv sind?

Das sagt der Translator ;-)

Dynamische Hotplug deaktiviert - wir wollen das System zu haben, beide Kerne immer aktiviert. Das bedeutet zwei Dinge, bedeutet, es wird viel für die Race-to-Leerlauf (die schnell wir gehen in den Leerlauf der Batterie mehr wir sparen können) helfen, und es bedeutet, den Anteil des Overheads, die während Onlining / Offlining CPU1 ist weg erstellt wurde seit hotplug ist ein sehr kostspieliger Prozess, um das System

Das das ein Feature ist, war mir schon klar. Aber ich als LAie denke mir, dass 2 dauernd laufende Cores doch vermutlich auch mehr Energie brauchen.

Ich bin auch nur Laie, verstehe es aber so, dass es mehr Strom kostet, wenn oft deaktiviert und wieder aktiviert wird und auch der sonst nur eine Core nicht mehr soviel Overhead erleiden muss.

Nun, schauen wir mal. Auf jeden Fall ist der Kernel verdammt fix.

Das iss ma keine Google Übersetzung ... Danke

Die Theorie, die geäussert wurde und jetzt in Praxis erprobt wird (die User sind - deklariert - Testkaninchen), lautet so:
der zusätzliche Verwaltungs- und Benachrichtigungsaufwand (Overhead), der durch das Managen der Cores anfällt, ist unter bestimmten Szenarien unvorteilhaft. Dies, da, so die Annahme, anteilsmässig mehr Leistung im Overhead verschwindet als effektiv hinten raus kommt. D.h. der 2. Core wird aktiviert, der Batteriekonsum wird x-fach erhöht, die zusätzliche Leistungsausbeute ist aber nur x/y mal grösser, also weniger viel mal grösser, als mehr viel mal Batterie gezapft wird, also relativ gesehen. Die bekloppte Formulierung ist übrigens absichtlich so gewählt ;)
Um den Gedanken hinter der Sache nun zu vollenden: lässt man dauerhaft beide Cores aktiviert, zieht dies grundsätzlich mehr von der Batterie, ist klar. Aber, und dies gilt es als Testkaninchen zu erproben, ist durch den fehlenden Overhead - dynamisches (de-)aktivieren der Cores ist ja aus - die Leistungsausbeute relativ gesehen grösser als es der Batteriekonsum ist. Denn, und das ist das ominöse race-to-idle, je schneller das System eine anfallende Aufgabe erledigt hat, desto eher kann es in einen stromsparenden Modus fallen. Frage ist, ob das Volle-Pulle-Abarbeiten und früher fertig sein effektiv unter dem Strich weniger Stromverbrauch bedeutet pro Zeiteinheit wie das halbherzige Abarbeiten unter weniger Leistungsaufnahme, dafür während längerer Zeit. Und hier schliesst sich der Kreis, den unter bestimmten Szenarien (siehe oben ;) ) stimmt diese Annahme, unter anderen hingegen nicht.

Kurzum: Francos Kernel versucht, anhand von optimierten Governors und Schedulern (I/O wie auch Taskscheduling), deaktiviertem Hotplugging mit race-to-idle und reduziertem Overhead, (gefühlt) gleichbleibende Leistung bei weniger Batterieverbrauch oder aber gleichbleibender Batterieverbrauch bei (gefühlt) besserer Leistung zu erreichen und dabei gleichzeitig gewisse Theorien in Bezug auf race-to-idle und hotplugging overhead zu untersuchen. Ich bin dabei mit an Bord, bis jetzt mit V1, ich teste V2 morgen dann. Bis jetzt keinerlei Beschwerden, nicht im Geringsten irgendwelche Hickser.

Du kannst es einfach besser Erklären.

Das ist durchaus auch für einen Laien verständlich, mit bissel rein denken. Danke @schago!!

Ich teste gerade die v2 ... werde aber sicher nur "gefühlt" Änderungen merken,
als Laien-Test-Kaninchen ;)

Schalom der Reddy

Zitat:

---

Zitat von spline

Mh ja, bin aber wieder zurück.
Das Gerät geht in den Deepsleep, aber nicht Sleep, sondern Koma.
Benchmarks sind sehr gut, smoothness auch, aber ... er muss noch ein wenig dran feilen.

Back to Abyss 3.7

---

Hattest du die V1 oder die V2 getestet?

Zitat:

---

Zitat von Reddy

... werde aber sicher nur "gefühlt" Änderungen merken,
als Laien-Test-Kaninchen ;)

---

Geht gar nicht mal darum, ob du was von der darunterliegenden Materie verstehst oder nicht. Sondern einfach nur: ohne Übertakten, ohne irgendwelche "Tweaking-Scripts" und dergleichen, tut das System schön und schnell und gut seinen Job und das unter im subjektiven Rahmen überhaupt "messbar" normalen Rahmen des Akkuverbrauchs von einem 1.4Ghz-Dualcore-Embedded-SoC-Gerät? Ja, gut, Franco sagen. Nein, auch gut, Franco sagen :D

Zitat:

---

Zitat von spline

Du kannst es einfach besser Erklären.

---

ich geb mir Mühe... :p

Edit: und bei xda mitlesend, bin ich je länger je mehr davon überzeugt, dass die Koma-Schläfer User-Sünden und nicht Kernelfehler sind. Wie bereits bei xda geschrieben: wenn alle anderen Kernel immer tun und nur dieser nicht, lässt sich streiten, ob es ein Kernelfehler ist oder nicht. Tut dieser offenbar hochoptimierte Kernel hingegen auf "sauberen" Systemen und auf "dreckigen" nicht, nunja, dann wirds mit der Argumentation zu Gunsten des Users etwas komplizierter ;)

Ich bin gerade unter RocketROM V22 am testen. Schon komisch, wenn auf einmal nur 3 governors angeboten werden und nicht mehr Dutzende wie bei Abyss (wobei die meisten wohl eh nie benutzt werden). Bin mal auf die Akkulaufzeit gespannt.

Also in der Ruhephase über Nacht braucht der Franco Kernel gut 3% mehr als der Abyss Kernel.
Iss aber nicht die WElle, wenn er sonst gut läuft, iss das ja voll ok.

Schönen Montag :)

Schalom der Reddy

Hab von Gestern Abend 21.30 bis heute Früh 7.00 knapp 4% Verbrauch (ohne Datennetz).
Das sind 4% in 9,5 Stunden.
Schlecht ist das nicht.

Meine Akku-Laufzeit ist immer noch sehr gering, liegt also wohl nicht am Kernel -> http://www.pocketpc.ch/samsung-galax...ml#post1332823

Mein abendliches Ritual ist am Note das Datennetz komplett zu kappen (APN rename) und die Synchronisation zu deaktivieren.

Über Nacht lade ich immer das Gerät auf, sodass es eigentlich egal ist, da morgens immer 100 % angezeigt werden. Problematisch ist eher der Verbrauch am Tage.

Wer will, kann nun auch das Franko Kernel App kaufen:

https://market.android.com/details?i...co.kernel.note

Zitat:

---

Zitat von hamma

Gibt ne V2. Habe die wieder runtergeworfen, laut XDA sind permanent beide Cores aktiv.

---

Hast du denn schon das hier gelesen: http://forum.xda-developers.com/show....php?t=1494653

Zitat:

---

Zitat von spline

Wer will, kann nun auch das Franko Kernel App kaufen:

https://market.android.com/details?i...co.kernel.note

---

Womit dann die Kausalität hergestellt ist. Sch... Kommerz!

Gesendet von meinem GT-N7000 mit Tapatalk

Ich hab mit diesen Kernel Probleme. Mein Launcher ruckelt so vor sich hin, (SBP Shell 3D)
isser Hyperaktiv??
Bin wieder auf AbyssNote v3.8, da klappt das.

Zum Franko App

Anhang 91582Anhang 91583

Interessantes Thema, noch kann man wenig sagen...
Allerdings wird es sehr von der Anzahl der aktiven Hintergrunddienste abhängen, ob Akku gespart wird.

---------- Hinzugefügt um 19:23 ---------- Vorheriger Beitrag war um 19:22 ----------

Zitat:

---

Zitat von Reddy

Ich hab mit diesen Kernel Probleme. Mein Launcher ruckelt so vor sich hin, (SBP Shell 3D)
isser Hyperaktiv??
Bin wieder auf AbyssNote v3.8, da klappt das.

---

...dann verwende keinen Zusatzlauncher :p

... ich kann auch um Akku zu sparen mein Note ausschalten ....

da reicht dann der Stock Kernel, gell?

Also bei mir geht dieser Kernel hier recht zackig.
Ich merke das vor allem, wenn man den Browser oder Market mit der Zurücktaste schliesst (und dabei 5-10 mal drücken muss).
Bis zum Abyssplug Governor hatte ich da immer recht merkbare Hänger (verschlucker).
Seit Abyss 3.7 und bei dem Franko Kernel von vornherein, geht alles zackig.
Ich meine zu spüren, mit dem Franko ein wenig zackiger.

Moin, also ich kann von dem Kernel auch nichts negatives berichten, habe heute Nacht mal alles angelassen was ich sonst am Tage auch aktiviert habe, natürlich nicht gesurft usw. nur einfach angelassen und habe von 21 Uhr bis 5 Uhr 4% verbraucht, obwohl der Deepsleep bei dem Kernel ja nur 200Mhz ist.
So wie spline schreibt, gefühlt reagiert er n bisserl schneller.

Es gibt V3:

Changelog:
#3
* Patched 2.6.35.14
* Add RWSEM algorithm
* Add CIFS and TUN as modules to /lib/modules/
* Add MDNIE tweaks from SpeedMod
* Remove MALI tracking/debug (increased 1 fps on Nenamark 2 with this disabled)
* Some other small tweaks and optimizations
#1.1 - App changelog:
* Fix force close when opening the app without internet access
* Added TUN and CIFS modules loading on boot support
Download: http://minooch.com/franciscofranco/G...o.Kernel-3.zip (flashable with CWM recovery)

Es gibt V3.1:

Changelog:
#3.1
* Sleep of death fix and smooth scaling - I previously had patched the wrong file. cpufreq.c is not compiled for
this device since it has CONFIG_S5PV310_HI_ARMCLK_THAN_1_2GHZ defined
in the config.

http://minooch.com/franciscofranco/G...Kernel-3.1.zip


Edit by Spline
Changelog der V3
( Die 3.1 ist nur fehlerbereinigt)
Changelog:
#3
* Patched 2.6.35.14
* Add RWSEM algorithm
* Add CIFS and TUN as modules to /lib/modules/
* Add MDNIE tweaks from SpeedMod
* Remove MALI tracking/debug (increased 1 fps on Nenamark 2 with this disabled)
* Some other small tweaks and optimizations
#1.1 - App changelog:
* Fix force close when opening the app without internet access
* Added TUN and CIFS modules loading on boot support

Hui cool.
Mein Fazit nach 2 Tagen: Prädikat sehr gut
Akku nun in der zweiten Nacht 9 Stunden 2% Verbrauch.

Jetzt schau ich mir die 3.1 an.

Owei und wenn nun Abyss die 3.9 bringt oder Hardcore die 6. Version, dann hab ich wieder ein echtes Problem.