[KERNEL][3.4.x][JB] K^Kernel 3.4.x per JB 4.2.2 e JB 4.3

Ragazzi un problema... È la seconda volta (mi capitò con la v1.5) che quando vado ad aggiornare il kernel (i 2 wipe>flash>2 wipe>fix permission) il cell non si avvia rimanendo nella schermata di caricamento e costringendomi a fare un restore. I kernel scelti sono sempre exuv. Soluzioni??

Quote:

---

Originariamente inviato da Leorocky

I consigli in questo caso sono soggettivi, in base a cosa ti serve.
Se necessiti di più RAM perche usi tante app contemporaneamente allora sacrifichi i video a 720p e metti la versione 390mb altrimenti le altre due versioni.
Per la CPU se sei inesperto puoi lasciare tutto di default in quanto il kernel e già super prestante!


Colgo l'occasione, il kernel v1.6 è perfetto si va sempre in meglio.
Complimenti!
:D

---

ok, grazie provero a mettere la 370mb.. per i valori di cpu allora provo a lasciarli di default, in caso li cambiassi e li mettessi come i tuoi andrebbe ancora meglio? cioe 245-1401 mhz

Quote:

---

Originariamente inviato da Niko89

Ragazzi un problema... È la seconda volta (mi capitò con la v1.5) che quando vado ad aggiornare il kernel (i 2 wipe>flash>2 wipe>fix permission) il cell non si avvia rimanendo nella schermata di caricamento e costringendomi a fare un restore. I kernel scelti sono sempre exuv. Soluzioni??

---

Niko' qualcosa non mi convince in cio' che dici. I kernel di chris sono sempre due per ogni utilizzo RAM, uno UV e l'altro EX UV. prova l'UV per prima. Si mi e' successo qualche volta. Ho dovuto togliere la batteria e riavviare. Posso dirti che per me dipende dalla Recovery, Io uso la TWRP

Quote:

---

Originariamente inviato da pierm

Niko' qualcosa non mi convince in cio' che dici. I kernel di chris sono sempre due per ogni utilizzo RAM, uno UV e l'altro EX UV. prova l'UV per prima. Si mi e' successo qualche volta. Ho dovuto togliere la batteria e riavviare. Posso dirti che per me dipende dalla Recovery, Io uso la TWRP

---

Ho la cwm non so che versione è.. Come posso aggiornarla? La flasho direttamente...

Quote:

---

Originariamente inviato da Niko89

Ho la cwm non so che versione è.. Come posso aggiornarla? La flasho direttamente...

---

Credo che ci siano stati degli aggiornamenti il thread e' questo prova li e dopo vedi un po'
https://www.androidiani.com/forum/sa...bandabase.html

Quote:

---

Originariamente inviato da simo993

ok, grazie provero a mettere la 370mb.. per i valori di cpu allora provo a lasciarli di default, in caso li cambiassi e li mettessi come i tuoi andrebbe ancora meglio? cioe 245-1401 mhz

---

Ho lasciato appunto tutto di default dato che per l'uso che ne faccio io va benissimo, ma niente ti vieta di provare altre combinazioni e trovarne di tuo gradimento.

"timer slack controller"
Christopher buongiorno,
vorrei riportarti alcune mie considerazioni sul funzionamento del timer slack controller, sperando di aver capito bene e di non essere fuorviante.
Allora partiamo dal concetto che ho cambiato ROM -> Slimbean + k^k v.1.6.
Ecco i risultati:
acceso stamattina il cell battery 100%
vado in deep sleep per circa 30" con tutti i widget che sai accesi connessione wi fi ecc.bla bla bla
cosa succede?
sblocco il cell e mi accordo che la batteria e' al 100% e il deep sleep al 82% . Questo non e' mai successo, io ho avuto sempre un deep sleep al 65% (Nota: non ho tolto nessun widget come mi hai consigliato)
Ora la mia conclusione e' la seguente:
secondo me dipende proprio dal time slack controller, cioe' dovrebbe funzionare in modo inversamente proporzionale. Nel senso che ad un consumo ridotto di batteria , quindi drain battery minore, corrisponde un deep sleep elevato. Perche' se ho capito bene, il meccanismo tende a ridurre al minimo la funzione di gruppi di apk. La cosa che non ho capito e' l'algoritmo che decide quale gruppo formare? perche' da quel che leggevo del tizio creatore di questa magia, le apk non decidono e non sono a conoscenza di chi viene controllata o no.
Ho capito bene? o rimandato?
thanks sempre

Quote:

---

Originariamente inviato da pierm

"timer slack controller"
Christopher buongiorno,
vorrei riportarti alcune mie considerazioni sul funzionamento del timer slack controller, sperando di aver capito bene e di non essere fuorviante.
Allora partiamo dal concetto che ho cambiato ROM -> Slimbean + k^k v.1.6.
Ecco i risultati:
acceso stamattina il cell battery 100%
vado in deep sleep per circa 30" con tutti i widget che sai accesi connessione wi fi ecc.bla bla bla
cosa succede?
sblocco il cell e mi accordo che la batteria e' al 100% e il deep sleep al 82% . Questo non e' mai successo, io ho avuto sempre un deep sleep al 65% (Nota: non ho tolto nessun widget come mi hai consigliato)
Ora la mia conclusione e' la seguente:
secondo me dipende proprio dal time slack controller, cioe' dovrebbe funzionare in modo inversamente proporzionale. Nel senso che ad un consumo ridotto di batteria , quindi drain battery minore, corrisponde un deep sleep elevato. Perche' se ho capito bene, il meccanismo tende a ridurre al minimo la funzione di gruppi di apk. La cosa che non ho capito e' l'algoritmo che decide quale gruppo formare? perche' da quel che leggevo del tizio creatore di questa magia, le apk non decidono e non sono a conoscenza di chi viene controllata o no.
Ho capito bene? o rimandato?
thanks sempre

---

Il nostro sistema ha tre raggruppamenti principali:
1) processi core
2) processi/app in primo piano
3) processi/app in secondo piano e non interattive

I vari processi/servizi di sync dei widget e delle app rientrano nel terzo raggruppamento, e proprio per quest'ultimo ho impostato delle temporizzazioni più alte:
- 100000000 ns = 100 ms in caso di sistema attivo
- 250000000 ns = 250 ms in caso di sistema sospeso

I primi due raggruppamenti, a sistema attivo conservano un timer slack di 0 ns per garantire le normali prestazioni ed efficienza, invece a sistema sospeso, ho fatto in modo di aumentare il timer slack anche per i processi core (50000 ns) e i processi/app in primo piano (100000 ns), sempre nell'ottica di limare il più possibile il consumo della batteria.
Naturalmente, tutto ciò andrà verificato nei prossimi giorni ed affinato fino a trovare i migliori settaggi. Con il buon KTulu stiamo cercando dei valori alternativi che potrebbero incrementare ulteriormente l'efficacia del controller, ringraziatelo sempre, mi raccomando, mi sta aiutando molto nei vari test del kernel pre-rilascio e messa a punto dello stesso...

Quote:

---

Originariamente inviato da Christopher83

Il nostro sistema ha tre raggruppamenti principali:
1) processi core
2) processi/app in primo piano
3) processi/app in secondo piano e non interattive

I vari processi/servizi di sync dei widget e delle app rientrano nel terzo raggruppamento, e proprio per quest'ultimo ho impostato delle temporizzazioni più alte:
- 100000000 ns = 100 ms in caso di sistema attivo
- 250000000 ns = 250 ms in caso di sistema sospeso

I primi due raggruppamenti, a sistema attivo conservano un timer slack di 0 ns per garantire le normali prestazioni ed efficienza, invece a sistema sospeso, ho fatto in modo di aumentare il timer slack anche per i processi core (50000 ns) e i processi/app in primo piano (100000 ns), sempre nell'ottica di limare il più possibile il consumo della batteria.
Naturalmente, tutto ciò andrà verificato nei prossimi giorni ed affinato fino a trovare i migliori settaggi. Con il buon KTulu stiamo cercando dei valori alternativi che potrebbero incrementare ulteriormente l'efficacia del controller, ringraziatelo sempre, mi raccomando, mi sta aiutando molto nei vari test del kernel pre-rilascio e messa a punto dello stesso...

---

scusa chris gentilissimo come sempre. Ma per capire con me stesso, non mi offendo, non c'entra niente quel che ho riportato?

p.s.
domanda OT: Mi puoi far sapere se il tuo kernel puo' essere montato sul dispositivo Lenovo P770, naturalmente si da per scontato che monti la CM ? Grazie

Quote:

---

Originariamente inviato da pierm

scusa chris gentilissimo come sempre. Ma per capire con me stesso, non mi offendo, non c'entra niente quel che ho riportato?

---

Sì Pierm, il tuo riscontro è molto utile per capire che il meccanismo offerto dal timer slack controller e dalla gestione dinamica del timer slack stanno funzionado. Era proprio quello che stavo cercando di spiegarti...
In pratica, aumentando il timer slack delle varie gerarchie dei processi, soprattutto a sistema sospeso, si dovrebbero limitare i risvegli (wakelock) e il deep sleep beneficia conseguentemente di una maggiore efficienza.
Perdonami se non sono stato chiaro.