venerdì 10 gennaio 2014

KT SGS4 - Un Kernel per Galaxy S4


In seguito agli articoli sul Kernel scritti da Klaas, ho pensato di fare una recensione di un kernel sviluppato da Ktoonsez (nello specifico farò riferimento alla sua versione per Samsung Galaxy S4, nota anche come KT-SGS4), il cui utilizzo viene spesso consigliato per prolungare la durata della batteria del dispositivo.

Prima di entrare nel merito di impostazioni consigliate e performances ottenute, ritengo interessante elencare le caratteristiche principali di questo kernel:
  • Linux kernel 3.4.67
  • App ”KTweaker” (che, grazie ad un’interfaccia intuitiva ed al relativo widget, facilita notevolmente la configurazione ed il controllo del kernel)
  • CPU Overclocking
  • CPU Underclocking
  • Scelta del Governor
  • Scelta dello Scheduler I/O
  • Gestione dei voltaggi
Per il download dell’ultima versione, è possibile fare riferimento direttamente al thread ufficiale su XDA.
Per l’installazione di questo kernel è necessaria, oltre ai privilegi di root, anche una recovery modificata (ho personalmente testato sia la TWRP che la CWM che la PhilZ Touch, e non ho mai avuto nessun problema).
Come si può intuire dalle caratteristiche precedenti, la gestione del kernel avviene interamente attraverso l’app KTweaker, che, attraverso un’interfaccia grafica davvero molto semplice ed immediata, permette la più completa configurazione di ogni parametro.
E’ inoltre disponibile anche un widget, utile per apportare rapidamente modifiche temporanee alle frequenze massime della CPU.


Analizzando le impostazioni generali, a livello di SCHEDULER I/O, questo kernel offre all’utente le seguenti possibilità (per approfondire l’argomento vi rimando all’articolo sul kernel):
CFQ, BFQ, VR, SIO, NOOP, DEADLINE, ROW, FIFO, FIOPS

Per quanto concerne il GOVERNOR, le opzioni disponibili agli utenti sono svariate (per quanto riguarda le tipologie NON citate nell’articolo di Klaas, fornirò una breve descrizione di quelle che, a mio avviso, sono le più interessanti):
  • Intellimand
  • Wheatley
  • Ondemand
  • Interactive
  • Smartassh3
  • Asswax (governor basato su interactive)
  • Conservative
  • Ktoonservativeq: governor basato su Conservative, che tuttavia riesce a garantire una buona qualità delle performances grazie ad una variabile in stile “hotplug” relativa agli altri core.
  • Userspace
  • Powersafe
  • Pegasug
  • Performance: questo governor blocca la CPU del telefono alla massima frequenza. La motivazione di questa scelta è dettata dal fatto che si intende velocizzare l’esecuzione di ogni singolo processo, in modo da potere ricondurre il prima possibile la CPU ad uno stato di consumo minimo.
  • Badass: la CPU viene limitata ad un livello base di 918Mhz. In caso di sovraccarico il limite verrà innalzato automaticamente a 1188Mhz. Se questa modifica non dovesse ancora rivelarsi sufficiente, il governor toglierà ogni limitazione, permettendo alla CPU di raggiungere la frequenza massima.
  • Abyssplug: governor basato su Hotplug (che a sua volta è basato sull’Ondemand).
  • Slp
  • Adaptive
  • Dancedance: governor basato su Conservative, simile a Lionheart nel modo di scalare le frequenze verso l’alto, con tuttavia un migliore risparmio energetino nella “sleep mode”.
  • Nightmare
  • msm-dcvs: governor che offre una gestione dinamica della frequenza di clock, capace di passare rapidamente da uno stato di risparmio energetico ad uno di massimizzazione delle prestazioni.
L’app KTweaker, inoltre, permette anche di apportare modifiche aggiuntive sia al governor che allo scheduler, in modo da poterli adattare ancora meglio alle proprie esigenze.

Se per caso, di fronte ad un ventaglio così ampio di possibili modifiche, vi sentiste spiazzati e disorientati, non disperate in quanto, essendomi già disperato io prima di voi, posso evitarvi una buona dose di ricerche riportando di seguito anche quelle che sono le impostazioni consigliate dallo stesso Ktoonsez, in modo tale da poter sfruttare al meglio le potenzialità offerte da questo Kernel:
  • General
    • governor = ktoonservativeq
    • scheduler = bfq
    • Min Mhz = 189
    • Max Mhz = 1998
    • Governor Adjustments
      • sync_extra_cores=1
      • touch_boost_cpu = 1242
      • touch_boost_cpu_all_cores=1
      • up_threshold = 80
      • sampling_rate = 40000
      • sampling_rate_screen_off = 90000
      • disable_hotplugging_chrg = 1
  • Voltages
    • Ridurre la CPU du 50mV
    • Ridurre la GPU di 75mV
  • Extras
    • Screen OFF Profile Mhz = 486
    • Disable Screen Off Mhz Call = Enabled
    • Screen OFF Profile Sched = noop
    • GPU Max Mhz = 504
    • Screen OFF GPU Max Mhz = 200
    • GPU governor = simple
    • Internal Read Ahead = 2048
    • External Read Ahead = 2048
Per cercare di dare una panoramica completa, ho effettuato due benchmark, uno con la CyanogenMod 10.2 e kernel cyano, e il secondo, sempre con la CM, ma con il kernel KT-SGS4. 



Come si può vedere dalle immagini riportate, il kernel di KToonsez fornisce un risultato nettamente più basso rispetto a quello di default e questa differenza è ovviamente dovuta alla spinta verso il risparmio energetico che abbiamo dato al Kernel attraverso le impostazioni viste in precedenza. In base alla mia esperienza diretta posso però dire che questa grande differenza non si nota assolutamente durante l’utilizzo giornaliero (il dispositivo si dimostra infatti sempre fluido e scattante), mentre l’aumento della durata della batteria è più che evidente.
Relativamente a questo aspetto infatti, ho notato un netto miglioramento non solo rispetto alla versione “base” CyanogenMod 10.2, ma anche rispetto al firmware Stock di Samsung. Prima mi vedevo costretto a ricaricare il dispositivo mediamente ogni 20 ore (con la CM “pura” erano scese a 12), ora invece la durata media della batteria, grazie anche al grande risparmio energetico in fase di standby, si è estesa a circa 30 ore. Concludo infine con una carrellata di screenshot che, a mio avviso, possono evidenziare il livello di ottimizzazione della batteria che questo kernel è in grado di realizzare sul Galaxy S4.
Nel caso specifico, il test è stato fatto, come si può notare, con il dispositivo in low-use.