Ovecome 4.1

[anassagora]

assolutamente! in memoria il programma non consuma proprio niente,

Certo che consuma! pensa ad un programma come il meteo che sta cercando aggiornamenti. Ed è solo un esempio banale questo.

invece il fatto di killarlo ti fa usare processore inoltre magari 10 minuti dopo riavvi la stessa app che invece di essere in ram deve essere caricata dalla flash con relativi consumi maggiori e minore velocita';

Hai risparmiato 10 minuti! che resti in ram, rallenta l'avvio di altre app e l'intero sitema.

senza contare che magari e' un demone e 10 secondi dopo che il programma lo ha killato il sistema lo fa ripartire usando ancora batteria, e il ciclo si ripete con uno che killa e il sistema che lo riavvia.

Devi, appunto, settarlo correttamente! se ti interessa che quell'app continui "a rannare" la metti nella "ignore list" e il killer non la chiuderà più. Altrimenti neghi all'app il backround

Ne parliamo in un altro thread, e oramai e' assodato che i task killer non servono assolutamente a nulla, entrando in conflitto con la gestione della ram di android.

Questa appunto è la tua/vostra personale opinione e come tale va rispettata ma non per questo va identificata come "veritas"

il file in oggetto e' stato dichiarato che viene periodicamente cancellato dal sistema appena la carica raggiunge il 100% (c'era un articolo sul blog)

In verità, non avviene su tutti i device, e su tutte le versioni di android.

e io mi riferivo al fatto che cancellare lo storico della vita della batteria non e' mai un bene a parer mio, anche se non era inerente visto che questo file non conserva lo storico totale ma solo quello dall'ultima ricarica al 100% riportando i tempi e percentuali d'uso da parte delle applicazioni.
Che poi in caso di flash gli effetti del file danneggiato potrebbero far indicare al sistema cose strane, non vol dire che il file lo si debba cancellare a priori, secondo me si agisce solo dopo aver assodato che il problema e' cominciato immediatamente dopo il flash. Ma in ogni caso secondo quanto detto la situazione si sistemerebbe subito dopo il raggiungimento del 100% di carica.

Probabile ma, di certo, non costa nulla assicurarsene la rigenesi intervenendo manualmente dopo un flash.
Inoltre mi riquoto:

Il file, oggetto dell'azione di wipe, contiene esclusivamente informazioni come la carica massima e minima, il voltaggio, i tempi di ricarica e affini. Proprio per questo si parla di ricalibrazione.

Quindi non c'è alcun collegamento con la storia della batteria.

Sono oramai sicuro che sia il kernel a consumare di piu; ho potuto fare un breve confronto tra la 2.3.6 con il kernel stock e con il kernel della overcome4.0.0 (che sta anche nella 4.1.0) e propendo sempre per un errore di selezione del clock quando il kernel pensa di usare 600mhz, come appunto dicevo nel thread della overcome 4.0.0.

Concludendo: sono soddisfatto di come va adesso il tab, prestazioni vicine al massimo mai visto e consumi piu che acettabili.

Non so che rom e quali setting di undervolt e/o overcloking tu stia usando, ma la stessa opinione me la sto facendo io. Tuttavia credo anche, che abbiano sopravallutato la 2.3.6 e per questo non hanno lavorato molto nell'ottimizzazione di questa versione con il loro kernel, limitandosì dunque ad un semplice "rimpachettamento".

[nikko63]

Originariamente inviato da nikko63
Con quale app eseguivi l'undervolt della cromed? Voglio riprovare a fare qualcosa per migliorare la durata della batteria, grazie.


Inviato dal mio GT-P1000 usando Androidiani App

Voltage Control

Grazie lupo, ma non dicevi che con la 2.3.6 voltage control non funge?


SGT P1000
GB 2.3.6
Kernel overcome

[lupoalba]

Grazie lupo, ma non dicevi che con la 2.3.6 voltage control non funge?


SGT P1000
GB 2.3.6
Kernel overcome

Con la cromed non ne voleva sapere di andare...

[nikko63]

Con la cromed non ne voleva sapere di andare...

Ecco, infatti mi pareva di ricordare che l'avevi scritto. Hai provato anche con la cromed ed il kernel overcome?

[lupoalba]

Certo che consuma! pensa ad un programma come il meteo che sta cercando aggiornamenti. Ed è solo un esempio banale questo.

esempio non calzante: e' un programma in esecuzione e non congelato in cache, anche il task killer non migliorerebbe la situazione.

Hai risparmiato 10 minuti! che resti in ram, rallenta l'avvio di altre app e l'intero sitema.

Non risparmi nulla: congelato in ram non consuma, il refresh viene fatto su tutta la ram a priori, dati presenti o assenti.
Non rallenta nulla: se serve ram il sistema scarica la cache come farebbe il task killer senza la necessita' del task killer.
Storia ben diversa si avrebbe se l'app richiesta fosse la stessa che sta gia in ram: l'avvio sarebbe molto piu rapido e si consuma meno energia. Le cache sono state inventate proprio perche i dati richiesti sono spesso gli stessi, e anche noi siamo ripetitivi: apri la posta e controlli, chiudi e parcheggi il tab, riapri la posta e controlli, richiudi e invii un sms...riapri e mandi una mail. Se tutto questo risiede in cache, non solo e' piu veloce, ma consuma anche meno che leggerlo da flash. E il sistema e' stato sviluppato proprio su questi principi, quindi ne tiene ben conto.

Devi, appunto, settarlo correttamente! se ti interessa che quell'app continui "a rannare" la metti nella "ignore list" e il killer non la chiuderà più. Altrimenti neghi all'app il backround

Ergo: se ti interessa quella app il task killer non ti serve; se non ti interessa l'app la disinstalli e non aggiungi un programma a consumare risorse ed energia. Che a livello di efficienza e' una manciata di gradini al disopra.

Questa appunto è la tua/vostra personale opinione e come tale va rispettata ma non per questo va identificata come "veritas"

Non del tutto vero: un processo che gira per killarne altri e liberare ram, occupa risorse; che per quanto vogliano essere poche saranno sempre un fattore peggiorativo sia per le prestazioni che per il bilancio energetico.

In conclusione: il sistema sa gia fare di base tutto quello che fa un task killer, ma lo fa quando necessario risparmiando risorse; un task killer gira in continuazione sprecando risorse e per di piu intralciando il sistema.

In verità, non avviene su tutti i device, e su tutte le versioni di android.

Non e' specificato che sia esclusivo di determinate versioni.

Probabile ma, di certo, non costa nulla assicurarsene la rigenesi intervenendo manualmente dopo un flash.
Inoltre mi riquoto:

certo: ma cancellarlo a priori senza che vi sia il problema e' un operazione ridondante, chi vuole puo farla, ma questo non implica che la batteria o il sistema funzionino meglio, serve solo ad evitare l'eventualita' che il ciclo di batteria iniziato col sistema vecchio possa indicare cose strane col sistema nuovo fino alla successiva ricarica.

Quindi non c'è alcun collegamento con la storia della batteria.

Si vero, ma lo si e' appurato solo qualche giorno fa, altrimenti si pensava che li dentro di fosse lo "storico vita" della batteria.

Non so che rom e quali setting di undervolt e/o overcloking tu stia usando, ma la stessa opinione me la sto facendo io. Tuttavia credo anche, che abbiano sopravallutato la 2.3.6 e per questo non hanno lavorato molto nell'ottimizzazione di questa versione con il loro kernel, limitandosì dunque ad un semplice "rimpachettamento".

Resto ancora con Overcome 4.1.0
A detta loro hanno ottimizzato la gestione dell'energia di ram e touch, tolto qualcosa di inutile, cambiato qualcosia nel menu a tendina e messo il kernel della 4.0.0, ma non e' molto distante da una 2.3.6 stock a cui si sostituisce il kernel con quello overcome 4.0.0.
Allo stato attuale sto con
scaling 100-1000, governor ondemand, sampling 66667, up threshold 90, ignore nice load e power bias 0
100Mhz 800mV
200Mhz 825mV
400Mhz 925mV
600Mhz 1125mV
800Mhz 1125mV
1000Mhz 1225mV
1200Mhz 1400mv (questo si attiva solo nel profilo "in carica")
A questa maniera in una giornata mediamente pesante di 18 ore di tab staccato dal caricatore riesco a fare (circa)
5 ore in deep sleep
7 ore a 100Mhz
3 ore tra 200-400-600Mhz
1 ora a 800Mhz
2 ore a 1000Mhz

e rientrare a casa con il 20-40% di carica residua. La differenza pesante la fa il tempo di accensione del display, che ad oggi e' quello che consuma tra il 65 e l'85% della carica, tant'e' che ho fatto anche qualche prova in tal guisa cercando di ottimizzare la luminosita' per diminuire i consumi con controprova che la regolazione automatica non e' il massimo per basse o nulle illuminazioni esterne, ma da il meglio di se a medie e alte. Per questo attendo il 7.7 che dovrebbe avere un display amoled...speriamo!
Quello che ho notato passando dalla 2.3.3 e/o overcome 4.0.0 alla 2.36 e/o overcome 4.1.0 e' un netto aumento del tempo di processore a 100Mhz 600Mhz, come se adesso riuscisse a modulare meglio la richiesta di potenza di calcolo e invece prima andasse direttamente a 1Ghz, ma e' impressione mentre sto spostando troppi parametri che influiscono appunto su questo. Pensa che portare up threshold da 95 a 97% fa perdere al tab molta della sua reativita' perche lo costringe ad attendere un pochetto di piu prima di passare al clock superiore: ma in fin dei conti stiamo parlando di variare un parametro del 2%....
Oramai ho assodato, calcoli e tempi alla mano, che l'undervolt ha aumentato l'autonomia del 22%; inizio ad intuire che con i parametri del governor potrei fare altrettanto e tutto senza minare ne la stabilita' ne l'usabilita'. Me sto proprio a diverti'.

[lupoalba]

Ecco, infatti mi pareva di ricordare che l'avevi scritto. Hai provato anche con la cromed ed il kernel overcome?

onestamente non me lo ricordo.
ho sicuramente provato il kernel sulla cromed, ma non ricordo se ho provato ad undervoltare, e' stata una di quelle prove da 5 minuti che dopo che ti e' andata bene rifletti e dici " ma chi me lo ha fatto fare?, menomale che il tab non s'e' brikkato!" e poi scopri che cmq e' una cosa "normale"

[nikko63]

Originariamente inviato da nikko63
Ecco, infatti mi pareva di ricordare che l'avevi scritto. Hai provato anche con la cromed ed il kernel overcome?

onestamente non me lo ricordo.
ho sicuramente provato il kernel sulla cromed, ma non ricordo se ho provato ad undervoltare, e' stata una di quelle prove da 5 minuti che dopo che ti e' andata bene rifletti e dici " ma chi me lo ha fatto fare?, menomale che il tab non s'e' brikkato!" e poi scopri che cmq e' una cosa "normale"

Scusa, temo di non aver capito. "è una cosa normale".... Che intendi?


SGT P1000
GB 2.3.6 cromed
Kernel overcome

[Marco91]

Aggiornamenti di cosa?

nel senso una nuova versione della ROM

[nikko63]

Originariamente inviato da nikko63
Ecco, infatti mi pareva di ricordare che l'avevi scritto. Hai provato anche con la cromed ed il kernel overcome?

onestamente non me lo ricordo.
ho sicuramente provato il kernel sulla cromed, ma non ricordo se ho provato ad undervoltare, e' stata una di quelle prove da 5 minuti che dopo che ti e' andata bene rifletti e dici " ma chi me lo ha fatto fare?, menomale che il tab non s'e' brikkato!" e poi scopri che cmq e' una cosa "normale"

Mi sorge un dubbio. Attualmente ho la 2.3.6 cromed con il kernel overcome... E mi sa proprio di aver fatto una cosa inutile, visto che il motivo per cui sono passato alla 2.3.6 era per l'ottimizzazione dei consumi. In realtà solo ora capisco che è proprio il kernel modificato a consumare più energia. Quindi, a questo punto, tanto varrebbe finire l'opera flashando anche la rom 4.1.0.... Ma perché per quanto io ci provi, alla fine non riesco a restare con una stock?


SGT P1000
GB 2.3.6 cromed
Kernel overcome

[lupoalba]

Scusa, temo di non aver capito. "è una cosa normale".... Che intendi?


SGT P1000
GB 2.3.6 cromed
Kernel overcome

Intendo che e' una cosa che si fa normalmente, ma io non sapendo ho provato alla cieca per vedere cosa succedeva.