Governor/Scheduler/Radio/RIL/Tcp

governor + scheduler & radio + ril + tcp

15/01/11
- egy 32 Gb-s nexus 5-ös "fedélzetén" továbbra is a nexus vonalon...
lollipopon, screw'd droidon, leginkább code_blue kernellel (idáig nekem a 777 tetszik a legjobban, szerintem smoothabb, mint a 793)...
szerintem a 806 valamiért nem okés! egy másik n5-re próbáltam feltenni a fent említett rommal (stock helyére), és a beállítások fc-zik... 777-tel párosítva gond nélkül sikerült!

hagytam a "gyári" blu_active - fiops párost - az üzemidő bámulatos, bár mintha pöppet lassabb lenne, mint egy stock (van másik készülék a közelben, van mihez hasonlítani); bár ha nem látnám a stockot, meg nem mondanám, hogy lassabb!

az uber is ígéretes kernel, de nekem most valahogy sokat akar - nem számoltam, de tényleg rengeteg governor és scheduler elérhető, így értelemszerűen borzasztóan sok párosítás kipróbálható lenne... valahogy nem értem mi a cél ezzel - oké, szabad kezet ad a felhasználónak, de őszintén szólva nekem nem lenne kedvem annyit próbálgatni, míg találok egy valóban jó párost! pláne, hogy a code_blue alapból nagyon jó...

aki a kernel beállításokkal szeretne (mélyebben!) játszani, annak a trickster - en kívül van egy újabb megoldás is... 
mégpedig az ukm (universal kernel manager) + synapse programpáros... az ukm-et recoveryből kell telepíteni, utána mehet a synapse a playből (ukm nélkül nem működik!) - természetesen root szükséges hozzá!
nagyon részletesen be lehet állítani a kernelt ezekkel a programokkal - aki nem akar ennyire belemélyedni, az használja továbbra is a trickstert...

gpu governorok:
powersave, ondemand, performance...
amikor a gpu nincs használatban, akkor 150 MHz-n "pörög"...
beállítható 307, 384 és 512 MHz - ezek elérhető maximum frekvenciák!

- a powersave csak a 307 MHz-s frekvenciát használja...
- az ondemand dinamikusan lépked 307 MHz, és az általunk beállított maximális frekvencia között...
- a performance a 307 MHz-s frekvenciát nem használja, ellenben azonnal az általunk beállított frekvenciát (logikusan a 384, vagy az 512 MHz-t) fogja használni...



fontos pontosítás!!!
a governorok nevében az x (pl ondemandx) NEM a hotplugging képességet jelenti, hanem "csak" annyit, hogy screen off-nál a maximális frekvencia limitált!

jellemzően a 2.0-ás (és egyéb továbbiak, pl 2.1, 3.2 stb.) governorok már hotplug-képesek...

a nagy kérdés és dilemma a továbbiakban az, hogy a governorok leírásában jelzik-e (egyáltalán kell e jelezni) a verziószámot, vagy alapból a legfrissebb, legfejlettebb verzió kerül bele?
intellidemand-ból, ondemand-ból, wheatley-ből, interactive-ból és pegasusq-ból biztos van 2.0 és a fölötti verzió, míg a hotplug és a sakuractive biztos hogy hotplug-képes!
(logikus lépés ezek alapján, hogy miért maradnak ki a friss kernelekből az 'x'-es változatok...)

az oldalon az alábbiak találhatóak sorrendben:

- leírások:
  - néhány alapfogalom tisztázása;
  - governorok;
  - schedulerek;
  - értékelések, tippek, javaslatok, ötletek, vélemény;
- radio, ril, tcp;
- beállítás és program tippek;
- read ahead buffer size

leírások

az alábbiakban röviden, és egy egyszerű felhasználó szemszögéből is érthetően fogalmazva bemutatom a címben említett kernel-összetevőket, melyek különböző - a play store-ból letölthető, vagy megvásárolható (legismertebb az ingyenes, magyarul is tudó trickster mod (nem minden telót támogat, a legtöbbet igen), fizetős pl a trinity kernel toolbox) - programokkal beállíthatók-módosíthatók a kernelekben...
(ezek a beállítás-módosítások csak rootolt készüléken érhetőek el!)

sokszor nem  szaknyelvet használva, néha felületesen fogalmazok (elkerülve ezzel rengeteg szakmai fogalom megmagyarázását), mert célom inkább az, hogy laikusként is érthető legyen a mondandó, feltételezve, hogy a többség nem (linux) programozó és (mobil)telekommunikációs szakember egyszerre...

aztán ha vkinek felkelti az érdeklődését a téma, az rengeteg infot fog találni először is az xda-n, de egy keresőt használva a neten is, főként angol nyelven...

(külön köszönetem Rátkay Tamásnak a számomra már túlzottan (rég tanultam már a távközlést!) szakmai szövegek fordításáért, és néhány fogalom elmagyarázásáért!

köszönetem még az xda-s kernelfejlesztőké, és a néhány olyan hozzáértőé, aki megosztja a tudását, tapasztalatait az ottani olvasókkal - névsort nem írnék, mert sokan is vannak, meg biztos, hogy ki is maradna vki...
egy kivételt teszek csak, mégpedig renaud-val, mert őt még a kernelfejlesztők is kiemelkedő tudásúnak tartják maguk közt!)

két fogalom mindjárt magyarázatra is szorul kezdésként:

- elsőként a sod (sleep of death), amikor a telefon képernyője nem felébreszthető, csak akku ki-be + reboot segít...

sok kernelnél ezt az alacsonyabb frekvenciákhoz tartozó feszültségértékek növelésével "próbálták" megoldani - tapasztalataim szerint csak ezzel nem orvosolható a dolog, ennél sokkal összetettebb problémáról van szó... sok függ a schedulertől, de még a használt rom-tól is - nincs "tuti" megoldás, hogy melyik rom-governor-scheduler trió esetén fog bekövetkezni, avagy épp elmaradni...

- a másik a hotplug(ging), vagyis többmagos prociknál alacsony cpu terhelés mellett az egyik mag lekapcsol a kisebb fogyasztás érdekében (ez kezdetben csak kikapcsolt képernyőnél volt megoldott, mostanra néhány példány erre képernyőhasználat mellett is képes...)

governorok

(ondemand, ondemandx, ondemand plus, sleepy, conservative, scary, lionheart, lionheartx, wrexy, dancedance, performace, powersave, intellidemand, intellidemand 3.2+, lagfree, lazy, adaptive, adaptivex, min-max, userspace, hotplug, hotplugx, abyssplug, pegasusq/d, pegasusq 2.0, nightmare, interactive, interactivex, interactivex v2, dyninteractive, asswax, smartass v2, smoothass, brazilianwax, savagedzen, skywalker, lulzactive, sakuractive, zenx, wheatley, tsmx, hyper, aggressivex, gallimaufryx, ktoonservative, badass, fantasy, solo, zzmoove, AMPlug)

(magyarán vezérlők - viszont valójában csak a vezérléshez szükséges adatokat tartalmazzák...)

ondemand – a fejlesztők által legkedveltebb vezérlő, mert régóta a „piacon” van, magyarán igen alaposan megismerték, letesztelték...

lényege, hogy a frekvenciát azonnal az engedélyezett legmagasabbra emeli, amint erre szükség van... ha az adott feladatot a cpu elvégezte, fokozatosan csökkenti a frekvenciát a legalacsonyabbra beállított értékre...

ebből adódóan a legfinomabb (értsd ezalatt az oly kedvelt, és magyarra nem igazán lefordítható 'smooth' kifejezést), legsimább élményt, teljesítményt adja, cserébe nem igazán kíméletes az akkuval (a frekvencia sokszor szinte „pattog” a minimuma és maximuma közt – ez leginkább multi-taskingnál fordul elő)...

ondemandx – gyakorlatilag megegyezik az ondemand-del, annyit kivéve, hogy kikapcsolt képernyőnél a frekvencia 500 MHz-ben maximalizálva van... ezzel némileg akkukímélőbb annál...

(mindkettő teljesítménye erősen függ a használt schedulertől...)

ondemand plus - ondemand és interactive alapokra épül, a középutat megcélzó darab: egyensúly teljesítmény és üzemidő közt...

sleepy (korábban solo néven futott) - arighi által módosított ondemand (eredetileg sgs2-re készült, arra optimalizált), ondemandx elemekkel "feljavítva"...

conservative – ez is ondemand verzió: lassabban állítgatja a frekvenciát annál, így kíméletesebb az akksival, viszont a finomsága is kevesebb...

scary – a conservative egyik továbbfejlesztése: közepes frekvenciáról indít, vizsgálva, hogy alacsonyabb, vagy magasabb frekvenciára van-e szükség, majd ezek alapján választ (ennek a bővebb leírásához ki kéne tárgyalni a threshold fogalmát) ... kikapcsolt képernyőnél 245 MHz-n maximalizálja a frekit, és ha az magasabb ennél, akkor a minimumot 120 Mhz-re állítja... gyakrabban használ alacsonyabb frekvenciákat, kímélve ezzel akkut, miközben a teljesítmény az átlag feletti...

lionheart – a samsung conservative alapokon nyugvó fejlesztése, átírt értékekkel, annál sokkal agresszívabb frekvenciamenettel, előtérbe helyezve a teljesítményt, az üzemidő rovására...

lionheartx – némileg átírt lionheart, ötvözve a smartass governor alvó üzemmódjával...

wrexy - conservative módosítás, hasonlatos a lionheart-hoz, viszont az alacsonyabb frekvenciákat részesíti előnyben úgy, hogy ez lehetőleg ne menjen a teljesítmény rovására...

dancedance - snuzzo munkája; conservative alapokon, attól eltérő beállítási értékekkel (melyek inkább a lionheart-ra jellemzőek), és a wheatley-hez hasonló "alvás" beállításokkal...

performance – a telefon folyamatosan az elérhető maximális frekvenciát használja (abból kiindulva, hogy a felhasználóknak a teljesítmény/finomság fontosabb az üzemidőnél)...

powersave – az előbbi ellentéte: az elérhető legalacsonyabb frekvenciát használja a készülék...

intellidemand – (intelligens ondemand) ha a gpu (nem a cpu!) nagyon leterhelt (játék, navigáció), akkor ondemandként viselkedik, ha a gpu kevésbé terhelt, vagy épp tétlen, akkor a frekvenciát eggyel alacsonyabb szintre veszi vissza, kímélve ezzel az akkut... (kikapcsolt képernyőnél nem használja az elérhető max frekvenciát...) játékhoz ajánlott...

intellidemand 3.2+ - anarkia által továbbfejlesztve, többmagos procikra optimalizálva, egyenlőre én még csak az ak kernelekben találkoztam vele (ott csak intellidemand néven található meg a programokkal) ... 

lagfree – optimalizált ondemand: sokkal finomabban vált frekvenciát, nem hagy ki egyetlen frekvencialépcsőt sem, kevesebbszer használja a max frekvenciát, ezzel kímélve az akkut... (videozásnál a kép szaggathat emiatt...)

lazy – ezekeel (glados kernel fejlesztője) által optimalizált ondemand: van egy meghatározott idő, míg a cpu alacsonyabb/magasabb frekvenciára kapcsol az éppen használtról (ezzel csökkentve az ondemand-nál említett pattogást)... ezen kívül egy opcióval kiválasztható, hogy kikapcsolt képernyőnél a cpu a megadottak közül mindig a magasabb frekvenciát használja...

adaptive és adaptivex – egy teljesítményorientált ondemand változat...

min-max – vagy a legalacsonyabb, vagy a legmagasabb frekvenciát használja...

userspace – a felhasználó maga állíthatja be a frekvenciákat egy erre alkalmas szoftver segítségével (szervereknél és asztali gépeknél használatos igazán, mobilon nem nagyon...)

hotplug – igen hasonlatos az ondemand-hez, ám annál sokkal precízebben használja a frekvencia visszaléptetésnél a kernelben található frekvenciatáblát...

képes 'hotplug(ging)'-ra, vagyis a nem használt cpu mago(ka)t lekapcsolja...

hotplugx – fejlesztett hotplug, optimalizált alvási móddal...

abyssplug – akkubarátabb hotplug... (az abyss romokból portolva - ilyen custom rom van pl sgs2-höz, note-hoz...)

pegasusq/pegasusd – ondemand alapú, négymagos/kétmagos procikra optimalizált, a samsung által kifejlesztett, hotplugging képes governor... (a 2 magosra a gokhanmoral nevű fejlesztő írta át, az ő siyah nevű galaxy s2-re készült kernelében megtalálható...)

aktív képernyő esetén nem kapcsolja le az egyik magot, ha az nincs kihasználva! (kivéve, ha ezt a kernelbe nem írták bele...)

pegasusq 2.0 – ez már lekapcsolja a második magot, ha az nincs kihasználva...

nightmare – egy módosított pegasusq governor, mely kevésbé agresszív - ez persze a teljesítmény rovására megy, de kedvezőbb üzemidővel...

mivel nem hotplug-képes, ezért sod előfordulása szinte kizárt...

interactive – gyorsabban emeli az órajelet a maximumra, mint az ondemand, másrészt sokkal érzékenyebben reagál annál; ennek következtében sokkal többször fut maximális órajelen a cpu... beállítható, hogy mennyi ideig tartson egy -egy frekvenciát, kiküszöbölve ezzel az ondemand-nál említett „pattogást” (pl a képernyő bekapcsolásakor feltételezhető, hogy a felhasználó vmit csinálni fog, így ehhez azonnal egy magasabb frekvencia áll a rendelkezésére, kvázi gyorsabban fog reagálni a készülék)...

ezzel természetesen jobb teljesítményt biztosít, mint az ondemand (talán a legkiemelkedőbbet a governorok közt), viszont az üzemidő elenyészően különbözik csak...

interactivex – imoseyon által továbbfejlesztett, és finomított beállításokat tartalmazó interactive, mely a felhasználó által beállított legalacsonyabb frekvencián tartja a cpu-t kikapcsolt képernyőnél...

interactivex v2 – ez már lekapcsolja az egyik magot, amint a képernyő lekapcsol...

dyninteractive – ez is egy továbbfinomított interactive (dinamikusabb reagálással)...

asswax - interactive alapokon nyugszik... (ha lesz több infom, posztolom!) sio ütemezőt ajánlják mellé...

smartass v2 – erasmux fejlesztette, interactive alapokon nyugvó governor, mely folyamatosan egy ideális frekvenciához (ki és bekapcsolt képernyőre ezek külön értékek) való igazodásra törekszik; az elérhető frekvenciák teljes skálája elérhető mind ki, mind bekapcsolt képernyőnél...

smoothass – smartass továbbfejlesztés, annál jóval agresszívabb, viszont kiemelkedő az üzemideje...

brazilianwax – ez is smartass továbbgondolás; agresszívabb frekvenciahasználat, jobb teljesítmény, rövidebb üzemidővel...

savagedzen – smartass alap, a brazilianwax-nál jobb üzemidő/teljesítmény arány...

skywalker - savagedzen módosítás; gyors, smooth... (eredetileg a jedi kernelben jelent meg sgs2-re...)
screen off esetén azonnal deep sleep-be küldi a procit, screen on esetén viszont a magasabb frekvenciatartományt használja inkább...

lulzactive – tegrak által fejlesztett governor, az interactive és a smartass kettős ötvözete, rengeteg frekvenciabeállítási lehetőséget kínálva a felhasználónak (mikor emelje/csökkentse az órajelet)...

(ezzel nagyon-nagyon óvatosan!!! nehéz jól beállítani! ha nem sikerül, nagyon hamar lemeríti az akksit!)

sakuractive – nagyon hasonló az ondemand-hoz, de másképp használja a frekvenciatáblát...

a 2.0 már lekapcsolja az egyik magot, ha annak működése szükségtelen, és erre nem csak alvás közben képes, hanem akár bekapcsolt képernyővel történő használat mellett is!

zenx – az android developer alliance (bbedward & purian23) fejlesztése... hotplug képes, és ez képernyőhasználat mellett is igaz – ha a cpu használat egy adott szint alá esik adott ideig, akkor lekapcsolja a második magot, majd ha nagyobb teljesítményigény jelentkezik (adott ideig), akkor újra engedélyezi annak működését...

wheatley (a glados-os ezekeel munkája) - ennek megértéséhez pár dolgot tisztázni kell:

egy cpu működésének alapesetben 4 állapota van, ezeket c0 - c3 közt nevezték el (c0 az aktív állapot, c3 a deep sleep)...
(annyit még tudni kell, hogy egy proci sosem tétlen! még c3-ban is folyamatosan fut egy, a prociba beégetett 'üres' parancs - ez lehet annyi, hogy 'fuss, fuss...', vagy egy egyszerű művelet, pl 'mennyi 2+2?, mennyi 2+2?'... ez mindaddig fut, míg vmi feladatot végre nem kell hajtania - ha azzal kész, ismét jön az 'üres' parancs...)
az Intel kitalált egy 5.-ik állapotot, ez lett a c4, deeper sleep (angolul c4 state) - ez esetben még az 'üres' parancs sem fut, csak annyi energiát kap a proci, hogy az utolsó parancsot ne 'felejtse el'... igen jelentős energia-megtakarítás érhető el így!

ondemand alapokon, cél a c4 (deeper sleep) állapot elérése minél többször, figyelembe véve, hogy egyes esetekben ez problémát okozhat, így ilyenkor mellőzve azt... csak többmagos procikkal szerelt telókhoz jó!

(nem néztem túlzottan utána, de információim szerint ezt a c4-es állapotot csak az Intel mobilplatform procijai képesek "használni"...)

tsmx - slukk által visszaportolt governor nexus 7-ről...

hyper - pongster konyhájából... korábban kenobi néven ismert, igen gyors és nagy teljesítményre képes, sgs2-re optimalizált...
ondemand alapokon, néhány ondemandx részlettel gazdagítva, igen hamar deep sleep-be "küldi" a procit, és eközben 500 MHz-ben maximalizálja a frekit...

aggressivex - moddolt conservative, screen off-nál hotplug képes...

gallimaufryx - moddolt ondemand, screen off-nál hotplug képes...

ktoonservative - ktoonesz fejlesztése; kicsit ondemand, kicsit conservative... amint az egyik cpu mag visszalép a frekvenciaskála 2. fokára, azonnal lekapcsolja azt (legtöbbször csak az egyik magot kapcsolja le)... inkább teljesítménypárti (a performance-ra hajaz), az akkuval nem bánik túl kezesen...

badass - nem találtam infot, hogy mi az alapja... megszünteti a hirtelen maximális frekvenciára történő, rövid idejű "felugrásokat"... (ha lesz még infom, posztolom!)

fantasy - dinamikusan használja a frekvenciatáblát a cpu használat függvényében...

solo - pongster nevű fejlesztő konyhájából... (amint lesz több infom, posztolom!)

zzmoove - zanezam munkája; az sgs1-re, mialwe által készített 'smoove' governor portolása először sgs3-ra, aztán más készülékekre...
conservative alapokra épült, annál gyorsabb frekvencia skálázással felfelé; akkubarát, a ktoonservative hotplug fejlesztésének módosításával, így most már minden magot le tud kapcsolni...

AMPlug - gnexen az askp kernelben fog megjelenni a közeljövőben... amint lesz róla bármi infom, posztolom...

az 'x' végződésűek mindenben megegyeznek a sima verziókkal, a különbség csak annyi, hogy ezeknél kikapcsolt képernyőnél a frekvencia maximuma limitált...

többmagos procival szerelt készüléket természetesen ajánlott hotplugging képes governorral használni - a 2.0 és e feletti verziók már tudják ezt (ondemand 2.0 és 2.1, intellidemand 3.2, interactive 2.0, wheatley 2.0, pegasusq 2.0, + a hotplug és a sakuractive biztosan)...
kérdés, hogy leírásokban feltüntetik e a verziószámot, vagy alapértelmezés, hogy a legfrissebb, legfejlettebb darabok kerülnek be a kernelekbe...

melyiket használjam? önmagában egy governor semmit sem "garantál", nagyon sok múlik a "párjául" választott schedulertől is...



schedulerek

jelen esetben egy nevet meg kell említenem, mert megkerülhetetlen a linux (és így a linux alapú android) kernelek tekintetében - Jens Axboe-nek (továbbiakban JA) hívják az úriembert... az alább bemutatandó schedulerek egy részének is ő a fejlesztője...

mi is a scheduler - szó szerinti fordításban ütemező, és ez pontosan le is írja mire való:
a cpu-khoz beérkező utasítások, feladatok (ezek adatcsomagokként kerülnek a procihoz) - legyen ez egy ütemezett feladat, pl facebook frissítés x óránként, vagy egy azonnali kérés, pl elindítunk egy alkalmazást; és természetesen nem megfeledkezve a rendszer működéséhez szükséges folyamatos, általunk "nem látható" feladatok - végrehajtási sorrendjét hivatott megszabni (ütemezni) egy scheduler... 
legegyszerűbben úgy lehet ezt elképzelni, mint sorbanállást a pénztárnál - ezt a klasszikus verziót nevezzük 'fifo'-nak (vagy fcfs-nek), vagyis a sorban első fog először fizetni (fifo - first in first out; fcfs - first come first serve)... 
ezt lehet "bonyolítani" - például a sor elejére vesszük, akinél max 5 termék van, vagy pl ha vki nagy tételben vásárol 1-2 dolgot, azt rövidebb idő alatt elintézik a pénztárnál; a többiek meg addig várnak -, a felhasználó és a rendszer igényeinek figyelembevételével...
(ezek természetesen nagyon leegyszerűsítő példák voltak, de az elv megértéséhez remélem segítség volt...)

fontos szempont, hogy olvasási feladatnak minősül a felhasználó által küldött parancs (pl el kívánunk indítani egy alkalmazást)!

fifo - ez a fentebb is említett "legegyszerűbb" ütemező; elsőnek érkezett utasítás lesz elsőként végrehajtva, mindenféle vizsgálat vagy mérlegelés nélkül;

noop - JA fejlesztése, gyakorlatilag ez is a fifo alapelvét használja, néhány kiegészítéssel a gyorsabb működéshez (méret, prioritás stb. szerint sorrendet készít), flash memóriákhoz optimalizálva...

deadline - JA 2002-ben kifejlesztett linuxhoz készült ütemezője - ebben a feladatok lejárati határidejük szerint kerülnek végrehajtásra... a feladatokat 2 sorba rendezi, aszerint, hogy írás vagy olvasás a végrehajtandó művelet, és minden egyes feladat elvégzése után vizsgálja, melyik sor következik - az olvasási prioritást élvez...
(alapértelmezésben az olvasási feladat végrehajtásának határideje 500 ms, míg az írásé 5 s...
a milliszekundumos formátum a pontosság miatt van - 501 ms már idő túllépés, míg ha ezt 0,5 s-nek tekintjük, akkor ott az 1 ms "nem értelmezhető" hibának, "csak" a 0,6 s, ami jelentős különbség...)
adatbázisokhoz ajánlják elsősorban...
2013 áprilisában osmosis, a franco team tagja optimalizálta, javította - jelentősen javult...

sio  - a noop és a deadline keresztezése, az egyik legstabilabb, egyszerű felépítésű ütemező...

sioplus - amint lesz pontos infom, posztolom!

cfq (completely fair queuing, vagyis teljesen egyenrangú besorolás) - JA munkája; egyenrangúként kezel minden beérkező feladatot, ezért lagolás előfordulhat a használatakor... (alapértelmezésként a linux ezt használja...)

bfq - gyakorlatilag készít egy ütemtervet/időbeosztást a feladatok ismeretében (ez természetesen használat közben állandó, folyamatos újratervezést igényel), aztán ha egy feladat ebbe nem fér bele, azt átugorja, hátrébb sorolja... (gyorsabb, mint a cfq...)
(ebből most az 6. verzió a legfrissebb - bfqv6, de bugos, így sokszor fagy, összeomlik a rendszer... egyenlőre a v5 a stabil, reméljük a v6-ot mihamarabb javítják - még nincs javítva! 13/5/19)

row (read over write, vagyis olvasás az írás előtt/felett) - mint a neve is mutatja, előre veszi a felhasználó által adott utasítások teljesítését... médiafogyasztáshoz előnyös, adatátvitelnél és appok telepítésénél viszont érezhetően visszaesik a teljesítménye...
2013 áprilisában osmosis, a franco team tagja optimalizálta - jelentősen javult...

v(r) - Aaron Carol fejlesztése, benchmark teszteknél előnyös, viszont nem stabil a véletlenszerűen érkező feladatok ütemezésekor (pl ha egyszerűen csak használni kívánjuk a telefont - hisz a telefon szemszögéből véletlenszerű, hogy épp telefonálni akarunk, zenét akarunk hallgatni, vagy játszani stb.)... deadline-ra épül, és minden végrehajtásra váró feladatot az utolsótól lévő távolságához viszonyítva rangsorol...

(igazság szerint a telefonoknál, a flash memóriák miatt is, a deadline-nak, a bfq-nak, a cfq-nak és a v(r)-nek semmi értelme, mert ezen eszközöknél olyasmik alapján ütemez, amik itt - a felépítésük, és a felhasználói környezet miatt - értelmetlenek...)

zen - az android developer alliance (purian23 & bbedward) fejlesztése, ez is igen egyszerű felépítésű...
fcfs alapra épül, az egyenrangúság alapján lejárati időket rendel a végrehajtásra váró feladatokhoz; ezen felül megegyezik a noop-pal...

fiops (fair i/os per second vagy fair in out performance scheduler) - ez a legfiatalabb ütemező (2012-es), linux oprendszerről portolva... gyakorlatilag egy flash memóriát kezelő eszközökhöz optimalizált, módosított cfq, amelyet a lehetőségekhez képest azért leegyszerűsítettek... talán a leggyorsabb ütemező...

anticipatory - 2 tényre épít: a lemezen történő keresés lassú, és hogy az írás bármikor megtörténhet, de közben mindig van olvasási feladat - így az olvasást az írás elé/fölé helyezi...
stock kernelben nem engedélyezett; jellemzően szerverekben használatos...


értékelések, tippek, javaslatok, ötletek, vélemény...

kezdéshez...

kernelcsere - jelenleg a leginkább ajánlott metódus, hogy rakjuk újra a romot is...
magyarán rom, gapps, kernel sorrendben flasheljük a zippelt fájlokat a recoveryből... (ha esetleg supersu-t is innen kell, akkor nézzünk utána, hogy a rom készítője mit javasol! általában ezt kell utoljára, a rom-gapps-kernel hármas után negyedikként flashelni... de! ez nem szentírás, elképzelhető, hogy a rom előtt, elsőként a supersu flashelendő! de mint mondtam, a rom telepítésének leírásában ott lesz, milyen sorrend ajánlott!)

értékelések:

-

radio, ril, tcp

radio - gyakorlatilag egy firmware (firmware - ami nem sorolható sem a szoftver, sem a hardver kategóriába, de igen nehéz ma már elkülöníteni egy szoftvertől - gyakorlatilag az eszközvezérlésért felelős "program"), mely a készülék hálózattal való kapcsolatát "vezérli" - e nélkül sem adatkapcsolatunk, sem hálózati csatlakozásunk nem lenne...

az android frissítéseivel általában új radio-t is kapunk, ez azonban régiónként (országonként, földrészenként) eltérő - egy 4 betűből és 1 számjegyből álló kóddal különböztetjük meg őket...

a kód felépítése: xxyzn
xx - régió/hálózat,
y - megjelenés éve (pl l - 2012),
z - megjelenés hónapja (a - l: január - december)
n - verzió száma

országkódok (vagyis a fenti kód felépítésében az első 2 betű; nem teljes lista!):
ce - benelux államok;
dc - thaiföld;
dd - india;
dv - ausztrália;
dx - indonézia, malajzia, fülöp-szigetek, szingapúr, vietnam;
dz  - malajzia, szingapúr;
ja - dél-afrika;
jc - algéria, marokkó, nigéria, dél-afrika, tunézia;
jp - arab országok, algéria, egyiptom, irán, irak, kuvait, marokkó, nigéria, omán, pakisztán, szaúd-arábia, szíria;
jv - tunézia, törökország;
kr - korea;
sc - japán;
ug - észak-amerika;
uh - latin-amerika, karibi térség;
ui - brazília;
xe - bulgária, észtország, kazahsztán, lettország, litvánia, oroszország, ukrajna;
xx - ausztria, belgium, franciaország, magyarország, németország, egysült királyság;
xw - ausztria, belgium, franciaország, magyarország, németország, olaszország, skandinávia/északi országok, spanyolország, egyesült királyság;
zc, zs - kína, hongkong;
zh - hongkong;
zt - tajvan



ril - (radio interface layer) olyan, mint egy driver, mellyel az oprendszer a radio-t vezérli (pontosabban egy könyvtár)...

ha a radio és a ril passzol egymáshoz, csökken a fogyasztás, és nő a hálózati kapcsolat stabilitása... ha a készülék gyakran eldobálja a hálózatot, akkor jó eséllyel nem összeillő a radio és a ril...

ez könnyen leellenőrizhető a getril programmal - viszont ezzel csak ril-t lehet letölteni, ha az nem jó...

az aktuálisan használt radio verziót a beállítások > a telefonról > alapsáv verziója pont alatt láthatjuk...

aki többre kíváncsi, az a gyári tárcsázóba üsse be az alábbi kódot:

*#*#4636#*#*

itt láthatóvá válik a jelerősség, beállíthatjuk milyen hullámsáv legyen használva (ne állítsuk el!), kikapcsolhatjuk a rádiót, megnézhetjük a sim kártyán lévő telefonkönyvet, kiválaszthatjuk a preferált hálózattípust stb-stb...

(van itt még rengeteg statisztika, meg beállítási lehetőség az akkumulátortól a wifi-ig - ha nem tudjuk, mit állítunk el, inkább ne tegyük, vagy nézzünk utána fórumokon és kérdezzünk!!!)

fontos! a használt android verzió és a rádió közt nincs összefüggés, így használhatunk akár frissebb, akár régebbi rádiót is (a hozzávaló ril fontos!!!) - persze ajánlott a frissebb -, csak a megfelelő régió kiválasztására figyeljünk...

tcp (congestion avoidance algorithm, vagyis tcp torlódás elkerülő algoritmus)

tcp (transmission control protocol) -  az internet gerincét adó tcp/ip protokollcsalád tagja... (protokoll itt egyezményt, szabványt jelent...)
egy szg-n futó egyik program, és egy másik gépen futó másik program között egy adatfolyam megbízható, sorrendhelyes átvitelét hivatott biztosítani (a net legfontosabb szolgáltatásainak nagy része ezt használja, pl e-mail, www)... (a leírás forrása a wikipédia...)

adó és vevő adatcsomagokkal kommunikál egymással - arról hogy ezek a csomagok rendben megérkeznek-e, visszaigazolásokat (acknowledgement-eket) küldenek egymásnak... ha ezek a visszaigazolások valami hiba miatt feltorlódnak (teszem azt egymás után több jön, vagy nem megfelelő időben jön), akkor "lép működésbe" ez az algoritmus... a hibajavítást különféle elvek mentén lehet megközelíteni (pl ha x idő alatt érkezik y db visszaigazolás, vagy az adó vagy a vevő oldaláról tekintsük a dolgot)...

a technikai leírásoktól ezúttal eltekintenék, mert részletesen ki kellene fejtenem pár dolgot a megértéshez - ez szerintem egy felhasználónak borzasztó unalmas szakmai szöveg lenne, ami itt a blogon nem célom...

készült egy mérés, hogy melyik hibajavító algoritmus milyen válaszidő mellett, mekkora le-, illetve feltöltési sebességet "biztosít" (a méréseket ismételték, hogy vmiféle átlagot azért lehessen képezni, meg azért egy mérés nem mérés - a körülmények állandóan változnak):
válaszidő - ms; letöltési sebesség, feltöltési sebesség - Mbps

cubic:
15  10,75  7,82
14  10,84  8,06

reno:
13  15,51  6,73
13  14,73  8,51

bic:
12  10,38  8,61
13  10,78  8,62

westwood:
11  17,65  8,30
13  13,28  8,29

highspeed:
13  10,76  7,94
16  14,42  8,52

hybla:
14  11,19  7,44
14  13,47  7,56

htcp:
14  13,24  7,03
15  10,85  8,00

vegas:
14    8,49  6,62
14  12,00  7,07

veno:
13   9,58  8,13
13   8,50  7,64

scalable:
18  12,01  8,73
14  13,96  8,23

lp:
14  14,90  8,68
14  13,44  8,72

yeah:
14  13,37  8,28
17  13,89  8,14

illinois:
13  12,93  8,24
16  13,97  6,46

ezek alapján leginkább a westwood, reno, lp és yeah (esetleg illinois, de ott a második feltöltési sebesség eredmény igen alacsony) közül érdemes választani...
tapasztalataim szerint a westwood érezhetően gyorsabb mindnél, viszont érdekes, hogy pl a chrome böngésző nem minden oldalt ezzel jelenít meg a leggyorsabban (hiába lassabb egy másik tcp algoritmus, mégis előbb, már betöltődés közben megjeleníti a weblapot)...

beállítás és program tippek:
- fényerő beállításához eddig a velis auto brightness-t használtam, de a héten egy ajánlás hatására kipróbáltam a lux auto brightness-t...
először az ingyenes változatot próbáltam, majd megvettem a fizetőst, mivel a precíz beállításokat csak ebben lehet elvégezni...
2-3 eltérő fényviszonyú helyzetben be lehet állítani, és meg lehet tanítani a progit, hogy mi tetszik nekünk; ezután szépen, fokozatmentesen állítja a fényerőt, azóta 1x sem volt gondom vele, hogy sötét, esetleg világos lenne képernyő - tudom, fizetős, de nagyon ajánlom!
(a gyári helyett mindenképpen ajánlott vmi külső progit használni, sokkal jobbak!)

- aki használ adaware blokkoláshoz programot, az találkozhat vele, hogy a progi biztonságos oldalakon (https jelzi ezt) ezt nem tudja megtenni - ez az android sajátossága, így lett megalkotva...

néhány beállítási tipp (figyelem! ezek a beállítások sajnos törlődnek egy wipeolás után, így ilyenkor újra be kell állítani...)
a beállítások a fejlesztői lehetőségek közt találhatóak (4.1.x alatt ez a beállítások alatt simán megtalálható, míg 4.2.x alatt a telefon menüpontban a build-re 7x rábökve lehetünk fejlesztők, majd ha ezt egyszer megtettük, akkor utána mindig ott lesz a beállításokban):

- gpu megjelenítés (gpu használat kényszerítése 2D rajzhoz)...
a cpu-ról levesszük a terhet, simább, gyorsabb megjelenítés lesz a jutalmunk, fogyasztásnövekedés nélkül... (magyarán ezt szokták hardveres gyorsításnak hívni...)

- 4xMSAA (multi sampling anti aliasing) kényszerítése
elsősorban játékosok figyelmébe ajánlom, mivel smoothabbá teszi azon játékokat, melyek ki tudják ezt használni... a teljesítményt némelyest csökkenti...
(számomra egyenlőre nem teljesen egyértelmű, működik-e ez a funkció a galaxy nexusban lévő chippel...
vagy csak program kérdése-e...)

és még egy beállítási ötlet:
(elvileg valahol az androidban gyárilag is beállítható, de én őszintén szólva nem találtam... trickster-ben biztos beállítható!)
trickster-ben a speciális címke alatt a nagyteljesítményű wifi (kikapcsolt képernyőnél a wifi sebességének tartása):
nyugodtan bekapcsolható, ha wifi közelben vagyunk - semmiféle fogyasztás-növekedést nem fog okozni, mivel ez deep sleep állapotra nem igaz! (magyarán csak a cpu c0, c1, c2 állapotában működik, c3-ban (ez a deep sleep), és értelemszerűen c4-ben (deeper sleep) nem! - az állapotokról bővebben a wheatley governor leírásában!)

kissé kifejtve - ha így is, úgy is használatban van a wifi (pl letöltünk épp), akkor a cpu nem lesz deep sleep-ben, magyarán a letöltésünk az elérhető legmagasabb sebességgel, rövid idő alatt fog megtörténni - nem pedig alacsony sebességen, hosszú ideig használva cpu-t...


read ahead buffer size (előolvasás buffer méret):

mostanság a legelfogadottabb, általános beállítás az 512...

a trickster mod-ban és a rom toolbox-ban biztosan módosítható az érték...