[KERNEL-ICS] GLaDOS by Ezekeel 4.0.3 / 4.0.4 V1.30

[scimitar]

Version 1.13 & 1.14 online:

GLaDOS-V1.14

• Override factory-set limitations for the MPU greatly increasing the OC potential.

GLaDOS-V1.13

• Added a safety feature to Color Control to prevent the color multipliers to be raised above the stock values.

Download (only for 4.0.3 ROMs):
http://goo-inside.me...DOS-GalaxyNexus

 

[scimitar]

Version 1.15 online:

GLaDOS-V1.15

• Added 1.4GHz MPU frequency slot.
• Added support to Color Control for disabling the safety preventing the color multipliers being raised above the stock values.

Download (only for 4.0.3 ROMs):
http://goo-inside.me...DOS-GalaxyNexus

 

[boshot]

Version 1.16 online

GLaDOS-V1.16
Fixed a bug and made some adjustments for Live OC.
Improvement for Color Control to work with the upcoming version of GLaDOS Control.
Added support for NFS V3.0 and V4.0 client and server (as modules).


Download:

Goo-inside.me Downloads - Browsing GLaDOS-GalaxyNexus

 

[mhz0015]

Gibt schon 1.17, leider gerade keinen Download Link parat, habs über die App Goo.inside-me geladen.

 

[scimitar]

Version 1.18 online:

GLaDOS-V1.18

• Added 1.6GHz MPU frequency slot.
• Fixed bug in Live OC of the min/max frequency values not being properly adjusted when changing the MPU OC value.

Download (only for 4.0.3 ROMs):
http://goo-inside.me...DOS-GalaxyNexus

 

[master84]

welchen governor nutzt ihr bei diesem kernel ? ich nehme hotplug

 

[scimitar]

GlaDOS Ver. 1.22 online:

GLaDOS-V1.22

• Fixed Sound Control issue with delayed touch control sounds and other sound glitches.

GLaDOS-V1.21

• Removed previous sound tweak and added Sound Control version 1.

GLaDOS-V1.20

• Added audio tweaks supporting changing the volume boost and enabling/disabling high performance audio.
• Added memcpy/memmove glibc functions improving performance of these memory operation.

GLaDOS-V1.19

• Fixed stability issues when changing the MPU OC value with LiveOC.

Download (only for 4.0.3 ROMs):
http://goo-inside.me...DOS-GalaxyNexus

 

[master84]

der kernel ist echt super habe deutlich bessere werte als mit dem franco, 2,5 std display an mit spielen und viel wlan transfer und dann habe ich noch 45% akku man sieht auch nicht wenn man das display an das der akku in 30sec takt nach unten geht.


nachmal die frage :

welchen governor nutzt ihr bei diesem kernel ? ich nehme hotplug

 

[mhz0015]

wheatley nutze ich

 

[master84]

Was genau macht der anders?

 

[mhz0015]

Ich habe einfach den Standard gelassen, nicht geschaut was der anders macht, aber 25 Stunden komme ich mit dem Akku, bei ca. 5 Stunden Display an.

 

[master84]

Der Kernel ist Sau geil 9 Std in der Nacht im standbye mit wlan und sync an und nur 2 % verloren

 

[ReTo]

kann mir jemand die einzelnen Governor Einstellungen erklären? Oder sehe ich das richtig Hot Plug> niedrigster Verbrauch , Wheatley !? , Performance > starker Verbrauch der Akkuleistung? Wäre wirklich dankbar

 

[mhz0015]

Hotplug - im Standby schaltet sich eine CPU ab, sprich er läuft nur noch mit einem Kern
Perfomance - sehr schnelle Taktung, sprich wenn Leistung benötigt wird, Taktet die CPU ohne verzögerung hoch
Wheatley - weis ich leider selber nicht
Ondemand - so ein zwischen Ding, spart Akku und Taktet nicht so schnell hoch
Powersafe - sehr langsame Reaktion der Taktung, dafür gute Akku Leistung
Interaktiv - ist ähnlich wie Performance, reagiert auf Apps kann man sagen, also wenn eine App was anfragt, wird hochgetaktet

öhm was gabs noch?

 

[Schnello]

Der Kernel Spez Gov "Wheatley'" soll lt. Dev der beste Mix aus Leistung und Akkuverbrauch sein. Bin aber selbst erst am Testen wie gut oder schlecht dieser ist.

V1.4 updated
GLaDOS-V1.4

• Added 'Wheatley' CPUfreq governor and made it default.

Ezekeel's commentary on V1.4

I have release GLaDOS V1.4 including my new CPUfreq governor 'Wheatley' which is the new default governor.

The previous benchmarks of the usage of the C4 state for different activities have shown that for 'light' tasks like browsing the internet, reading (for example emails or eBooks) and the average app the device spends about 40% of the time in C4 with acceptable average residencies of around 11ms. For more demanding tasks like games and video playback the C4 state is still being used however the efficiency is reduced due to the low average residencies of below 5ms (considering that the wakeup latency is 1.3ms).

I have run a few tests and as it turns out, for demanding tasks the efficiency of the C4 state is significantly reduced due to these low residency times (= large number of wakeups) to a point that the good old frequency scaling is indeed more efficient with larger battery savings. So unfortunately, relying on the C4 state alone for power savings for all tasks is not a good option.

However, unfortunately we also cannot simply use one the available standard governors since always try the minimize the frequency without taking account that this behaviour diminishes the efficiency of the C4 state since it hinders a proper race-to-idle. So taking advantage of this knowledge what a good governor should do, is using the maximum frequency whenever the C4 state is properly used with acceptable average residencies and only scale down when the average residencies get too low (or the C4 is not used at all, of course).

Building on the classic 'ondemand' governor I implemented this idea in my new Wheatley governor. The governor has two additional parameters:

target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.

allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.

I have run some benchmarks to make sure that Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly (as seen in the previous benchmarks).

For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.

So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.

Wheatley for governor!

 

[DAanDASja]

Bei mir läuft der Wheatley und letzte Nacht, wenn das GN nicht gerade im Deep Sleep war, war die CPU die meiste Zeit (ca. 80%) auf 1200Mhz getaktet. Das erscheint mir schon ein wenig zu viel des Guten.

 

[mhz0015]

Je nach Rom welches Ihr nutzt, kann man zum einen dort die Taktwerte einstellen, dann Setcpu, in der App von Glasdos Kernel und noch ein paar andere Apps, daher genau schauen das Ihr nicht überall Einstellungen vorgenommen habt, nutzt entweder nur Setcpu, oder nur den Glados Kernel um einen Standard Takt fest zulegen Profile könnt Ihr ja dann trotzdem mit Setcpu noch einstellen. Das kann z.B. eine Ursache für solch einen hohen CPU Takt sein (Verbrauch).

 

[DAanDASja]

Moin,
Hab nichts an den Einstellungen vom Kernel geändert, alles ist auf default.
Daran wirds also nicht liegen schätze ich mal.

 

[Schnello]

Kommt sogar beim Stock Kernel vor das mal ein Prozess hängen bleibt oder ist das Problem ständig? Bei mir geht er schon brav in den deep sleep. Teste aber auch erst ca nen Tag.

 

[DAanDASja]

Der deep sleep ist nicht das Problem. Von den 8h war er ca. 5h im deep sleep.
Jedoch war die CPU in den restlichen 3h die meiste Zeit auf 1200Mhz.