[Official Thread] UC-Kernel !!! Last Version V05

[-DM-]

[Official Thread] UC-Kernel !!!

Cos'è? L'UC Kernel è un kernel mod sviluppato appositamente dal Team UtterChaos per l'i9003. Costantemente aggiornato (alla versione v05 abbiamo 5 release in 15 giorni) apporta nuove migliorie costantemente.




Changelog delle attuali versioni:

[ disclaimer/WARNING ]

THE KERNEL IS STILL IN TESTING... PROCEED WITH CAUTION! U HAVE BEEN WARNED!

WE ARE NOT TO BE HELD RESPONSIBLE IF U DAMAGE UR PHONE / SPILL UR COFFEE / MISS UR ALARMS / ANY OTHER CALAMITY/MISHAP


[ features/changelog ]
[ v04 onwards ] Overclock upto 1.1Ghz
[ v03 onwards ] kernel now compressed using LZMA
[ v03 onwards ] enabled support for EXT4 file system (had missed that one in v02)
[ v03 onwards ] updated CWM (by amit) to latest version (24-11)
[ v03 onwards ] kernel will now show custom bootlogo (if enabled by user); and allow users to place their own logo (if they want or revert to logo in kernel) [ DETAILS HERE ]
[ v03 onwards ] added support for userinit scripts:
if sd-ext is mounted then it will execute /sd-ext/userinit.sh & shell scripts in /sd-ext/userinit.d/ folder
also scripts in /data/local/ will be executed... it will execute /data/local/userinit.sh & shell scripts in /data/local/userinit.d/ folder
[ v02 onwards ] shifted to TinyRCU kept it as default
[ v02 onwards ] enabled support for various file systems
EXT3
JBD
RFS
JFS
NTFS (with R/W)
[ v02 onwards ] TUN/TAP now integrated into kernel
[ v02 onwards ] enabled support for various network file systems
NFS (client/server)
CIFS
[ v02 onwards ] optimized kernel for size
[ v02 onwards ] enabled LZMA/GZ2/LZO compressing support for ramdisk
[ v02 onwards ] bumped jHash to v3
[ v02 onwards ] increased VM MAX READAHEAD to 512KB
[ v02 onwards ] corrected "current kernel" string in CWM app & Tweaks app
[ v01 onwards ] Universal CF-Root and CWM for I9003 Gingerbread by amit.bagaria
[ v01 onwards ] CPU Governors
InteractiveX
Savaged-Zen
SmartAssV2
BrazilianWax
Smoothass
Lagfree
Smartass
Scary
MinMax
Interactive
[ v01 onwards ] I/O Schedulers
BFQ-v2-rc1
V(R)
SIO

I Download:

UC-Kernel v09 all version

UC-Kernel v08 both version

UC-Kernel v06 XXKPQ
MD5 Sum:c084022c2d9f5ac88e0dd4cb244cd166

UC-Kernel v04 XXKPQ
MD5HASH: 33b9af1408fe3fed1b6a00effc69806d

XXKPQ STOCK Kernel
MD5HASH: 2ae4b0e635ab21a64c6ea68ca42cdf0c

Altri download:
xda-developers - View Single Post - [KERNEL][SGS-SCL][Dt:03/Dec]{v05} Team UtterChaos Kernel (UC-Kernel)[XXKPQ]

FAQ:
xda-developers - View Single Post - [KERNEL][SGS-SCL][Dt:03/Dec]{v05} Team UtterChaos Kernel (UC-Kernel)[XXKPQ]


Disclaimer: Ne io ne il forum di Androidiani.com ci riteniamo responsabili di possibili danni causati al vostro Hardware. Ogni operazione è potenzialmente pericolosa e invalida la garanzia.

Guida all'installazione:


- download il file kernels .tar (stock o UC che sia)
- controllare il md5hash del file per essere sicuri dell'integrità dello stesso
- riavviare il terminale in Download Mode
- connetterlo al PC via USB
- avviare ODIN
- controllare che il terminale sia riconosciuto da ODIN
- click su PDA e selezionate il file scaricato
- click su start
- dopo il flash il terminale si riavvia
- kernel installato


Link Thread originale:
[KERNEL][SGS-SCL][Dt:03/Dec]{v05} Team UtterChaos Kernel (UC-Kernel)[XXKPQ] - xda-developers

[-DM-]

Governor e Scheduler

Viste le continue richieste ho fatto un po di ricerche vediamo un po cosa vogliono dire:

I/O Scheduler:


NOOP is a simple I/O scheduler without overhead that tries to do each I/O transaction as it comes (FIFO). When a group of transactions is detected, it will try to merge it together to make batches of transactions (makes the whole transaction faster). NOOP doesn't have starvation detection, hence if an I/O transaction takes a painfully long amount of time, it will still continue to do it rather than switch the CPU into doing something else e.g. GUI interrupts (i.e. scrolling lists, flicking screens). All other schedulers also have the "merge" feature. NOOP is the only one that makes the "merge" feature its only feature.

CFQ is a complex I/O scheduler that tries to determine the address space of the transaction and applies a cost algorithm in that if the address is close together, it will group them up and perform them. It also tries to make the transaction incremental (i.e. reading/writing through address incrementally so that the disk spindle needs to wind down the least in conventional platter hard disks) The problem is, our flash devices have very little delta between reading a far reaching address space (than the one currently being written/read) or a closer one as it doesn't rely on spindle/rotations. Hence, having this costing algorithm adds overhead and slows down the overall transaction. CFQ has a lot of algorithms to make sure each process gets a fair slice of time on I/O transcations. Too much overhead.

Deadline has a starvation detector and is simple enough that it doesn't have all the overhead of doing rotational/costing disks algorithm. However, reads are done 2x more likely than writes as it has a algorithm based on weights in that reads must be done first if both a read and a write is detected. It has a 2:1 ratio of read to write weights coded into the scheduler (that can be tweaked - writes_starved, will include it in the next version of system_tweak). Hence it's not a fair scheduler.

SIO is Simple I/O that tries to implement a NOOP type scheduler that has starvation detection. Hence, long I/O transactions will be preempted and given CPU time only after other faster transactions are completed, guaranteeing smoothness. Also, it doesn't have overhead of calculating costs. Also, it has a fair number of writes to read, guaranteeing that all transactions are equal.

BFQ has a lot of algorithms to make sure each process gets a fair slice of bandwidth (Budget Fair Queueing). Too much overhead.

V(R) tries to make sure that each transaction has a weight associated with it, being R. And if the seek is reversed, the R will be multiplied by a penalty making it less likely to be processed. Not for flash drives as reverse seek in a flash drive is just as fast as a forward seek.

In sostanza, quando si parla di I/O è determinante capire quanti cicli della cpu (o tempo) vengono dedicati all'I/O. Il primo, NOOP, sostanzialmente non fa altro che andare avanti fino a che non arriva un interrupt, questo però potenzialmente rallenta l'applicazione che ha richiesto l'I/O che non viene più eseguita in modo concorrente. E' quello che da i risultati più alti nei benchmark ma è anche quello concretamente meno veloce.
CFQ è quello più complesso ed equo. Ha diversi algoritmi per determinare costi delle transizioni e generare la coda con le priorità ma non è particolarmente ottimizzato per android se non in casi specifici.
SIO è quello che da prestazioni più bassi ai benchmarkin quanto interrompe i trasferimenti ogni 0.5s per favorire il CPU BOUND, comunque è quello probabilmente più prestante come esperienza d'uso (della serie, non importa se il file è scritto in 3s o 1, l'importante è che l'app non lagghi).
BFQ fa tanto overhead, vuol dire che fa lavoro inutile, calcoli per determinare cosa fare e come, non utili direttamente all'I/O, meglio lasciarlo stare.
VR è indicato come non adatto per i flash drive quindi meglio non usarlo. Deadline invece è uno scheduler semplice con non troppo overhead ma non è equo, probabilmente c'è il rischio che qualche processo ha l'accesso all'I/O una volta ogni morte di papa.

Ho trovato questa linea guida.

SIO> NOOP> Deadline > VR > BFQ > CFQ


Governor

- Ondemand (CPU scala subito alla freq max dopo che la cpu ha raggiunto un certo carico)
- Conservative (CPU scala subito al max e scende pian piano fintanto che rimane un certo carico)
- OndemandX (Ha uno sleep code, manda al minimo la cpu quando è in sleep, scala lentamente il clock)
- Interactive (Presente nei nuovi kernel, ed è di default in alcuni ufficiali, simile a on demand ha una buona risposta)
- Smoothass (Simile a Smartass ma più aggressivo, ha un consumo di batteria migliore dello stock kernel)
- Smartass (Manda il telefono automaticamente in un profilo screen off, mantenendo la cpu al minimo quando il telefono è in idle)
- Userspace (Da non usare, è un modo per controllare direttamente la cpu)
- Powersave (Disponibile in alcuni kernel, tiene la cpu al minimo sempre)
- Performance ( Mantiene la cpu al massimo per tutto il tempo. Leggermente più performante dell'ondemand, ma si ciuccia la batteria)
- Always Max (vecchio nome di Performance)
- BrazilianWax (funzionalmente simile allo Smartass ma ha un cambio di frequenza più rapido)
- SavagedZen (è come lo Smartass ma con alcune modifiche apportate che gli consentono di ottenere sia buone prestazioni sia un consumo non eccessivo della batteria)
- Lagfree (Simile a ondemand. La differenza è l'ottimizzazione che lo rende maggiormente battery friendly. La frequenza diminuisce o aumenta gradatamente, a differenza di ondemand che salta al 100% troppo spesso. Lagfree non salta le frequenze durante lo scaling verso l'alto o verso il basso)
- SmartassV2 (E’ uno smartass modificato ed è uno dei governor più usati. Questo governor scala verso il basso la cpu molto velocemente mentre lo schermo è spento, e scala rapidamente verso l’alto fino a 500 mhz quando lo schermo si accende. Non c'è un limite superiore per la frequenza mentre lo schermo è spento. Questo governor mira a una "frequenza ideale", per cui scala in maniera più aggressiva nei confronti di questa frequenza e in maniera meno aggressiva dopo. Esso utilizza diverse frequenze ideali per lo schermo acceso e per lo schermo spento, che sono awake_ideal_freq e sleep_ideal_freq, garantendo così un equilibrio tra prestazioni e durata batteria)


LINK info sul funzionamento di alcuni sopra citati link

Per un uso prestazionale probabilmente è meglio lasciare ondemand, altrimenti non è male smoothass e smartass.
Alcuni governator non sono presenti o hanno nomi diversi, tipo SmartassV2

Pare che ci sia l'interactiveX buggato. Credo che il default sia l'interactive.

[marcbra]

cosa vuol dire riservato? per prendere il secondo post da aggiornare in caso di modifiche? comunque come mai negli screenshoots alla voce I/O scheduler è selezionato bfq? cosa vuol dire? potreste fare una scheda con i significati di tutte le voci presenti in I/O scheduler e governor e cosa cambia? grazie

[-DM-]

riservato per modifiche future
quello è uno screen preso da XDA
i governator della cpu in generale cambiano solo il tipo di transizione tra i vari stati della stessa, esempio passare di colpo allo stato successivo o solo dopo tot secondi... cmq non ho trovato un elenco completo

[djstewie]

-DM- mi meraviglio di te: il post già esiste da un bel po'.Potevi metterti daccordo con il suo creatore e magari modificare il primo post.

[marcbra]

ragazzi sono usciti i kernel v05-test4/5/6 con vari hack, io ho il test6 e già da antutu posso dire che fa 45 fps quel serpentone colorato...domani proverò il gaming

[odiolachimica]

Scusa ma non è sempre stato 45 fps il serpente di antutu? Ps nel v04 non c'era ancora l'oc per la grafica?


Inviato dal mio GT-I9003 usando Androidiani App

[-DM-]

no nel 04 no, solo nel 05 ma di 75mhz... quanti fps faccia quel test non ne ho idea

[marcbra]

No prima faceva 42-43 tranne con la DarkGenMod che faceva 46 ma poi andando a vedere i giochi faceva pena mentre gingerbread facendo 42-43 va molto bene nei giochi...


Inviato dal mio GT-I9003 usando Androidiani App

[-DM-]

-DM- mi meraviglio di te: il post già esiste da un bel po'.Potevi metterti daccordo con il suo creatore e magari modificare il primo post.

Ho chiesto e non e stato fatto (leggi di la non mi far linkare credo che a trovare un post sei capace)
Ho contattato un mod e non ha fatto niente Pertanto...
Thread ufficiali non ci sono.