APOLO [new 3-31/3.26.1][VOLTAJES PERSONALIZADOS][(SpeedMod + Undervolting+BLN+UNDERCLOCK+CONSERVATIVE y muchos Governors más) SÓLO ICS +TUTORIAL HÁZTELO TU MISMO

[emiliodeputas]

pedestre, con el valor que has puesto a 20 y que estaba a 5, que haces, que haga mas o menos saltos?

[ggutierp]

 Cita: Originalmente Escrito por partisano

Mi móvil es de los del movimiento 15M jaja.

Sí, estoy ahora con el SetCPU y funcinoando correctamente. He metido la Beta 3 nueva y he puesto el lulzactive, de momento cero problemas .

Quiero darle 2 ciclos a la Beta 3 y otros 2 a la 16, crees que me dará tiempo antes de que hagas más kernels? jajaja. A ver si así comprobamos si consumen más los voltajes internos o los ARM.

A mi se me congelaba con el setCPU también, ayer probe cargar el conservative con el System Tuner y no me dio problemas, claro, solo puedes cambiar el governador cuando la pantalla se apaga y durante la llamada... pero al menos se mostró más estable.

[pedestre]

 Cita: Originalmente Escrito por emiliodeputas

pedestre, con el valor que has puesto a 20 y que estaba a 5, que haces, que haga mas o menos saltos?

EDITO: si tiene que ver con el tamaño del salto que va a hacer para cambiar la frecuencia

The freq_step parameter changes the size of the frequency step that the governor uses to change CPU frequency in either direction. By default this setting is 5, which means the governor will change the CPU frequency by five percent of the maximum or minimum frequency each time it changes frequencies. If you set this value to 100, the governor will behave exactly like the ondemand governor and immediately increase to the highest speed.

Después de leer esto si que a lo mejor no es buena idea moverlo a 20 aunqeu en teoría ayuda a un mejor rendimiento.

 Cita: Originalmente Escrito por ggutierp

A mi se me congelaba con el setCPU también, ayer probe cargar el conservative con el System Tuner y no me dio problemas, claro, solo puedes cambiar el governador cuando la pantalla se apaga y durante la llamada... pero al menos se mostró más estable.

Pues no se, a mi el SetCPU me va bien con el conservative y con los otros. Eso si hay que tener cuidado que es muy fácil poner una frecuencia máxima errónea y entonces zas, se congela

Cuando alguna vez me dio problemas lo solucioné como explicaba dos post atrás.

Slds

[oscar_GT]

A mi lo que me pasa es que el setcpu en el reinicio no me deja puesto el conservative y me pone ondemond, aun que en la lista esta conservative y esta marcada la opción set on boot. Aparte de las congelaciones que he tenido.

[ggutierp]

Quizás es muy pronto... pero el ExtremeV2 me bloqueaba el equipo cada 5 minutos y en ocasiones ni siqueira iniciaba, acabo de instalar la nueva versión (ExtremeV2 con Governadores) y le puse el SmartassV2 desde el boot, despsués de hora y media de uso tratando de cargar el CPU aún no se ha congelado =)

[pedestre]

 Cita: Originalmente Escrito por ggutierp

Quizás es muy pronto... pero el ExtremeV2 me bloqueaba el equipo cada 5 minutos y en ocasiones ni siqueira iniciaba, acabo de instalar la nueva versión (ExtremeV2 con Governadores) y le puse el SmartassV2 desde el boot, despsués de hora y media de uso tratando de cargar el CPU aún no se ha congelado =)

Si, creo que es muy pronto y en esta seguro que los voltajes están bien. Los revisé dos veces.
Ojalá tengas suerte

Slds

[emiliodeputas]

 Cita: Originalmente Escrito por pedestre

EDITO: si tiene que ver con el tamaño del salto que va a hacer para cambiar la frecuencia

The freq_step parameter changes the size of the frequency step that the governor uses to change CPU frequency in either direction. By default this setting is 5, which means the governor will change the CPU frequency by five percent of the maximum or minimum frequency each time it changes frequencies. If you set this value to 100, the governor will behave exactly like the ondemand governor and immediately increase to the highest speed.

Después de leer esto si que a lo mejor no es buena idea moverlo a 20 aunqeu en teoría ayuda a un mejor rendimiento.

Es que creo que justo eso es el "espiritu" del conservative. Llevo un rato leyendo explicaciones sobre governors, configuraciones y demás. El conservative parece ser un ondemand con la frecuencia de salto bajada ( a 5 ) y el la máxima frecuencia de sleep tocada ( no se si a 200 o 500 ). Poniendolo a 20 haces justo el efecto contrario al deseado, deberías mantenerlo en 5. Los otros 2 valores, el load_h y load_l o como se llamen recomiendan para ganar en batería sin perder demasiado en rendimiento 80-30 u 80-35.

He estado leyendo el tema de los scheduler también y me he enterado de unas cuantas cosas. Mas o menos, por asi decirlo aunque no creo que sea demasiado exacto, el scheduler se encarga de como se gestiona el trabajo. Una mejor gestión del trabajo mejora el rendimiento del móvil, y un trabajo mejor gestionado requiere menos tiempo de procesado, por lo tanto uso de frecuencias mas bajas, lo que provoca también aparte del aumento de rendimiento una mejora en el consumo de batería. Leyendo una explicación de cada uno viene a decir que el que viene por defecto ( cfq ) teóricamente es bueno, pero en android al ser una maquina virtual y no se que más cosas no funciona demasiado bien. Tanto noop ( que debe ser el mas simple, sin prácticamente gestión, todo procesado tal y como llega sin ningún orden ) y deadline son bastante mejores, pero sobre todo destaca el VR ( que dice que es el mejor aunque algo inestable ) y el SIO.

Ponen los scheduler como tanto o mas importantes incluso que los governors. En futuras versiones si puedes incluye esos dos y probamos a ver como van.

[pedestre]

 Cita: Originalmente Escrito por emiliodeputas

Es que creo que justo eso es el "espiritu" del conservative. Llevo un rato leyendo explicaciones sobre governors, configuraciones y demás. El conservative parece ser un ondemand con la frecuencia de salto bajada ( a 5 ) y el la máxima frecuencia de sleep tocada ( no se si a 200 o 500 ). Poniendolo a 20 haces justo el efecto contrario al deseado, deberías mantenerlo en 5. Los otros 2 valores, el load_h y load_l o como se llamen recomiendan para ganar en batería sin perder demasiado en rendimiento 80-30 u 80-35.

He estado leyendo el tema de los scheduler también y me he enterado de unas cuantas cosas. Mas o menos, por asi decirlo aunque no creo que sea demasiado exacto, el scheduler se encarga de como se gestiona el trabajo. Una mejor gestión del trabajo mejora el rendimiento del móvil, y un trabajo mejor gestionado requiere menos tiempo de procesado, por lo tanto uso de frecuencias mas bajas, lo que provoca también aparte del aumento de rendimiento una mejora en el consumo de batería. Leyendo una explicación de cada uno viene a decir que el que viene por defecto ( cfq ) teóricamente es bueno, pero en android al ser una maquina virtual y no se que más cosas no funciona demasiado bien. Tanto noop ( que debe ser el mas simple, sin prácticamente gestión, todo procesado tal y como llega sin ningún orden ) y deadline son bastante mejores, pero sobre todo destaca el VR ( que dice que es el mejor aunque algo inestable ) y el SIO.

Ponen los scheduler como tanto o mas importantes incluso que los governors. En futuras versiones si puedes incluye esos dos y probamos a ver como van.

Gracias emilio, ya me había dado cuenta de que lograba el efecto contrario. El valor no me lo he inventado,es el que lleva el thouravout, pero no hay problema lo dejamos en 5 para la próxima.

En cuanto a los schedulers, yo lo que he leído no coincide mucho con lo que has visto tu. Casi todos recomiendan el cfq y también le dan mucha menos importancia que al cambio de governor. De todas formas creo (digo creo porque no tengo el voltaje control y no lo puedo ver) que están disponibles el deadline y el noop.
Viendo el código deberían estar disponibles estos dos schedulers. Del VR y el SIO no tengo noticias la verdad, es la primera vez que los oigo. Si me entero como ponerlos los pongo, no hay problema.

Slds

[purpleplanet]

 Cita: Originalmente Escrito por pedestre

No desvirtuas el tema para nada, el phenomenal encaja perfectamente con este hilo ya que son la cosas similares y comparar es natural. Parece que en el otro hilo no opinan igual, en fin. Yo no puedo postear porque se monta un pollo si lo hago, así que mejor no lo hago.

Al tema:

El extremev2 es inferior al phenomenal. ese lo busqué a posta como ya hice en Ginger. Hay alguna ARM 25mv por encima pero las internas son 25 o 50 mv menores. Ligeramente menor en el bus y en GPU. Lo demás igual

El extreme es difícil de decir, los ARM son mayores en el Apolo, sin embargo las internas son menores (en general). El GPU y el bus son menores ligeramente en el Apolo. Es difícil decir sin probar cual da menos consumo.



Gracias, ya nos cuentas si notas diferencia con el conservative

Un saludo

Si,ya me fije que resurrection fight quería ponerte a caldo porque decía que estabas publicitando ahí tu kernel,personalmente creo que no tuvo una actitud correcta, yo creo que en estos desarrollos lo mejor es cooperar,compartir ,y mejorar porque así nos beneficiamos todos.Probaría el phenomenal para comparar,pero me da una pereza.....jaja.

Enviado desde mi GT-I9100 usando Tapatalk 2

[pedestre]

 Cita: Originalmente Escrito por danisimo1

Si,ya me fije que resurrection fight quería ponerte a caldo porque decía que estabas publicitando ahí tu kernel,personalmente creo que no tuvo una actitud correcta, yo creo que en estos desarrollos lo mejor es cooperar,compartir ,y mejorar porque así nos beneficiamos todos.Probaría el phenomenal para comparar,pero me da una pereza.....jaja.

Enviado desde mi GT-I9100 usando Tapatalk 2

Pues no te digo nada de los privados tan educados que envía, pero bueno hay gente que mejor no tenerla en cuenta, así que de momento mis aportaciones (mejores o peores) las pondré en otros hilos donde uno se encuentre agusto.

Slds

[emiliodeputas]

Sacado de XDA:

what's a I/O Scheduler?

There is not so much offer when it comes to I/O Schedulers and the improvements aren't nearly as visible as choosing a gung ho governor but trust me they are there. Just to name one improvement you could see is for example the opening and closing of applications.

Noop:

Noop isn't actually that bad. It's a simple I/O Scheduler and when it comes to Android, the simplest the better.
I think in G1 one known "tweak" was to set Noop as default 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:

Well, like Ondemand is to governors, CFQ is to I/O Schedulers. It's the most balanced one, aiming to perform well in most scenarios. However, in Android since things work differently, it's not the most suitable I/O Schedulers. There are many tweaks spreaded throughout XDA for improving this baby. 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:

Deadline is actually quite popular along with BFQ. It is used in some known kernels for example Netarchy's for Nexus S. However, even though it's better than CFQ for Android devices it still falls short in comparison with VR. 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.


VR:

VR is a very good I/O Scheduler with Deadline elements. Probably the best for MTD Android devices and it's used also in known kernels such as IntersectRaven's for Nexus One. It's probably the one who can score the most in benchmarks but it's also one of the most... unstable. Its performance fluctuates, it can peak above average or it can go below it. But when it peaks... it's the best. 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.


BFQ:

Here it is, the wrongly assumed best I/O Scheduler which happens to be the most popular one. It's based in CFQ but it has an inferior performance than VR or Simple, even if it's BFQv2 (although it seems to perform well in USB transfers rate). BFQ has a lot of algorithms to make sure each process gets a fair slice of bandwidth (Budget Fair Queueing). Too much overhead.



Here's my assessment of all the schedulers that I know:
SIO> NOOP> Deadline > VR > BFQ > CFQ

In benchmarking tests, the tests normally consists of testing the time it takes for a contiguous I/O transfer from 1 point to another. NOOP excels at that because it won't let itself get interrupted to perform another I/O task. This would mean that in real life testing, NOOP will let a long arduous task to finish while at the expense of UI functionality (you will get UI lags)

SIO on the other hand will perform badly at benchmarking as it gets pre-empted when the contiguous tasks takes more than 0.5secs (for synchronous tasks as benchmarking tools perform a synchronous I/O task from one point to another) to another more important task like UI interrupt (when you're scrolling) or Kernel interrupt (when your kernel needs to perform garbage collecting or swap memory etc)

The 0.5 secs can be tuned in the SIO tuneables though, but I would think 0.5 secs for synchronous tasks and 5 secs for async tasks is pretty good to maintain a balance between long/short tasks enabling a smoother experience in Android.




No me pidais que traduzca porque posiblemente entendais menos que en inglés. Lo importante basicamente es el orden que pone al final. En los detalles del VR lo ponen como el mejor pero inestable, por eso en la clasificación lo ponen por detrás de otros más estables.

[pedestre]

 Cita: Originalmente Escrito por emiliodeputas

No me pidais que traduzca porque posiblemente entendais menos que en inglés. Lo importante basicamente es el orden que pone al final. En los detalles del VR lo ponen como el mejor pero inestable, por eso en la clasificación lo ponen por detrás de otros más estables.

OK , miraré de meter el VR y el SIO, en teoría los otros están ya disponibles.

¿Podeis verifiarlo? Me da mucha pereza buscar el Voltaje Control.

Gracias Emilio por tu ayuda

[partisano]

 Cita: Originalmente Escrito por pedestre

Viendo el código deberían estar disponibles estos dos schedulers. Del VR y el SIO no tengo noticias la verdad, es la primera vez que los oigo. Si me entero como ponerlos los pongo, no hay problema.

El SIO creo que era el que venía por defecto en la Narkdroid RcX4. Yo usaba ese y el VR (por lo que había leído en el hilo de xda sobre planificadores de CPU).

Edito: acabo de comprobarlo en el Voltage Control. Los planificadores disponibles son noop, deadline y cfq.

[pedestre]

 Cita: Originalmente Escrito por partisano

El SIO creo que era el que venía por defecto en la Narkdroid RcX4. Yo usaba ese y el VR (por lo que había leído en el hilo de xda sobre planificadores de CPU).

Decidido, a meter nuevos schedulers


Menos mal que esto iba a ser un speedmod, juas juas juas

En fin creo que todo es para mejor. Entre todos vamos aportando ideas y mejorando el kernel.

GRACIAS!!

Enviado desde mi GT-I9100 usando Tapatalk

[oscar_GT]

 Cita: Originalmente Escrito por pedestre

OK , miraré de meter el VR y el SIO, en teoría los otros están ya disponibles.

¿Podeis verifiarlo? Me da mucha pereza buscar el Voltaje Control.

Gracias Emilio por tu ayuda

Así es, están noop, deadline y cfq.

[pedestre]

Gracias apu por comprobarlo.

Me va como un tiro el lulzactive, hoy estoy consiguiendo unos consumos flipantes en gran parte por la rom de klander, pero creo que el lulzactive tb tiene algo que ver. Estoy pensando dejarlo como governor por defecto y ya puestos poner el SIO como scheduler tb por defecto.

¿qué pensáis ?

Enviado desde mi GT-I9100 usando Tapatalk

[partisano]

 Cita: Originalmente Escrito por pedestre

Gracias apu por comprobarlo.

Me va como un tiro el lulzactive, hoy estoy consiguiendo unos consumos flipantes en gran parte por la rom de klander, pero creo que el lulzactive tb tiene algo que ver. Estoy pensando dejarlo como governor por defecto y ya puestos poner el SIO como scheduler tb por defecto.

¿qué pensáis ?

I approve!

[emiliodeputas]

 Cita: Originalmente Escrito por pedestre

Gracias apu por comprobarlo.

Me va como un tiro el lulzactive, hoy estoy consiguiendo unos consumos flipantes en gran parte por la rom de klander, pero creo que el lulzactive tb tiene algo que ver. Estoy pensando dejarlo como governor por defecto y ya puestos poner el SIO como scheduler tb por defecto.

¿qué pensáis ?

Enviado desde mi GT-I9100 usando Tapatalk

Si consideras que es lo mejor dale duro. Yo tengo que cambiar de rom porque noto que no tengo los consumos que debería. El lulzactive por ejemplo me lagea mas que el ondemand o tu conservative retocado. El consumo aun no puedo juzgarlo porque tengo recien puesto el kernel. Has tocado algun valor del lulzactive con setcpu o lo llevas por defecto.

[pedestre]

 Cita: Originalmente Escrito por emiliodeputas

Si consideras que es lo mejor dale duro. Yo tengo que cambiar de rom porque noto que no tengo los consumos que debería. El lulzactive por ejemplo me lagea mas que el ondemand o tu conservative retocado. El consumo aun no puedo juzgarlo porque tengo recien puesto el kernel. Has tocado algun valor del lulzactive con setcpu o lo llevas por defecto.

Lo llevo por defecto y con underclock a 1000. No noto nada de lag
Te recomiendo la rom de klander, es estupenda.

Slds

Enviado desde mi GT-I9100 usando Tapatalk

[pedestre]

 Cita: Originalmente Escrito por pedestre

Lo llevo por defecto y con underclock a 1000. No noto nada de lag
Te recomiendo la rom de klander, es estupenda.

Llevo 14 horas de uso, 2 hr de pantalla y me queda el 65%. Ahí es nada

Slds

Enviado desde mi GT-I9100 usando Tapatalk