Rom Manhattan By Gnufabio

[matiu]

dopo tre settimane di AOKP (milestone 1 e 2) ieri mi son deciso a passare a questa rom.. bhe, che dire... personalizzazioni fantastiche ed il launcher integrato mi piace tantissimo, e sara' anche un po presto per dirlo ma mi pare che la durata della batteria sia aumentata abbastanza.. qualcuno ha notato questa cosa?

usi il kernel stock di quella ROM o il franco?

[Anf3t4m1n]

secondo me la durata batteria e' migliore su mnhattan..poi tutto e' molto influenzato anche dalle app\servizi in background che si usano e dal kernel.che kernel usavi su aokp?sempre il franco come scritto in firma?
ps piccolo OT dall tuo avatar mi pare di conoscerti di vista.suoni\suonavi tekno?fine OT

franco kernel sia prima che con questa rom...

cmq SI! suonavo tekno! ci conosciamo per caso? magari ci siam beccati a qualche festa

[betalaga]

Sert cosa e il governor Wheastley?

Inviato dal mio Galaxy Nexus usando Tapatalk

[sert00]

franco kernel sia prima che con questa rom...

cmq SI! suonavo tekno! ci conosciamo per caso? magari ci siam beccati a qualche festa

sicuramente non ti ricordi,ci conoscevamo di vista almeno 8 anni fa...io ero appena 16enne!ora basta prima che qualcuno mi riprenda per questo ot!risp in mp in caso!piccolo il mondo!

Sert cosa e il governor Wheastley?

Inviato dal mio Galaxy Nexus usando Tapatalk

e' un nuovo governor ,per lo piu un ondemand patchato per non essere troppo aggressivo quando da freq. alte per chiusura di task necessita uno "scalaggio" a freq minori.il tutto abbinato secondo me alla stabilita dell'ondemand stessoe' uno dei migliori governor di questo momento anche sembra reagire bene col c4 state che non so se lo sai ma e' abilitato nei kernels solo da pochi giorni!franco l'ha incluso nella build 13,subito dopo che ezekieel,l'autore del post sotto,l'ha scoperto come attivare (nei kernel stock il c4 non e' attivo,o comunque non a schermo spento.)e permesso che altri lo usassero nei propri kernels (e' uno dei power settings piu potenti)

ti riporto qualcosa,molte cose sono tecniche quindi a grandi linee vai con quello che ti ho detto.

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).

Test Total Time Time in C4 (CPU0/CPU1) C4 Usage % Time in C4 (CPU0/CPU1) Avg. Time in C4 (CPU0/CPU1)
================================================== ================================================== ================================================== =====
Opera Mini Browser + WiFi (performance) 1420000 587354 / 608606 52875 41% / 43% 11.1 / 11.5
Music playback FLAC (performance) 3040000 2886900 / 2886183 97582 95% / 95% 29.6 / 29.6
Music playback MP3 (performance) 3620000 3489926 / 3491311 100254 96% / 96% 34.8 / 34.8
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Opera Mini Browser + WiFi (Wheatley) 1990000 1084741 / 1117786 89655 55% / 56% 12.1 / 12.5
Music playback FLAC (Wheatley) 2180000 2051667 / 2054291 117353 94% / 94% 17.5 / 17.5
Music playback MP3 (Wheatley) 2750000 2621303 / 2624050 138625 95% / 95% 18.9 / 18.9

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.

[edge86]

Domanda...volevo provare questa Rom...sono andato su Xda, per la rom nessun problema ma le x Gapps c'é solo il link di megaupload (pace all'anima sua) quindi da dove le scarico???

Inviato dal mio Galaxy Nexus usando Tapatalk

[thay]

Domanda...volevo provare questa Rom...sono andato su Xda, per la rom nessun problema ma le x Gapps c'é solo il link di megaupload (pace all'anima sua) quindi da dove le scarico???

Inviato dal mio Galaxy Nexus usando Tapatalk

http://www.multiupload.com/GRVLKHFNT5
In 1 pagina trovi i link x download adesso controllo che siano funzionali

[edge86]

Domanda...volevo provare questa Rom...sono andato su Xda, per la rom nessun problema ma le x Gapps c'é solo il link di megaupload (pace all'anima sua) quindi da dove le scarico???

Inviato dal mio Galaxy Nexus usando Tapatalk

Trovateeee....tutto ok

Inviato dal mio Galaxy Nexus usando Tapatalk

[Anf3t4m1n]

mostruoso.. dopo 13h e 30 minuti sto ancora all 85% di batteria.. l'ho usato poco per essere, ma MAI ero arrivato a quest' ora con piu del 30%.. sia in idle che a schermo acceso la batteria non va giu

[betalaga]

ok set ho capito..... più o meno... un altra cosa... cosa si intende per IVA nel kernel glados?
Il mio telefono supporta fino a 110/125
Anche sul mio con il 125/125 non si avvia....


Inviato dal mio Galaxy Nexus usando Tapatalk

[simone87stilo]

mostruoso.. dopo 13h e 30 minuti sto ancora all 85% di batteria.. l'ho usato poco per essere, ma MAI ero arrivato a quest' ora con piu del 30%.. sia in idle che a schermo acceso la batteria non va giu

Io sto testando da oggi la buil20 di aokp con kernel franco e devo dire che dopo una telefonata di 75 minuti la batteria è scesa solo del 2% (dal 31 al 29) A me non è mai successo, con rom stock questa andava giu che era un piacere!