Os dejo este post que vi en este foro .......
GOVERNORS
Primeramente vamos a hablar de los governors más conocidos, los que suelen incluir la mayoría de los kernels. Un kernel no tiene por que incluir todos estos, eso depende del desarrollador. Son los siguientes:
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Smartass
8) SmartassV2
9) Intellidemand
10) Lazy
11) Lagfree
12) Lionheart (*)
13) LionheartX (*)
14) Brazilianwax (*)
15) SavagedZen
16) Userspacce
17) Powersave
18) Performance
(*) Los menciono pero no voy a hablar de ellos, ya que no se suelen utilizar.
1) Ondemand
Es el governor por defecto en la mayoría de los kernels stock. Uno de los objetivos principales del Ondemand es que cambia a la máxima frecuencia tan pronto como haya actividad en la CPU para asegurar la capacidad de respuesta del sistema, para que se entienda funciona en plan “lo importante es el rendimiento aquí y ahora”. Por lo tanto, escala a la máxima frecuencia cuando la CPU está trabajando y decrece gradualmente cuando la CPU se va quedando más libre. A pesar de que muchos consideran Ondemand como un governor fiable, se queda a mitad de camino entre ofrecer un buen rendimiento del teléfono y un ahorro de batería.
2) Ondemandx
Este governor se supone que es mejor que el Ondenand en cuanto a gasto de batería. Cuando la pantalla está apagada, la frecuencia máxima está limitada a 500 mhz. Aunque Ondemand es el governor por defecto en varios kernels y es considerado como seguro y estable, el soporte para Ondemand/OndemandX depende de la capacidad de la CPU para hacer rápidas variaciones de frecuencia.
3) Concervative
Es un Ondemand más lento que escala frecuencias más lentamente para ahorrar batería. Funciona como aquel, al ajustar dinámicamente las frecuencias según la utilización del procesador. Sin embargo, el Conservative aumenta y disminuye la velocidad de la CPU más gradualmente. Más fácil de entender, este governor aumenta la frecuencia de la CPU paso por paso (100mhz>200mhz>400mhz>etc), y salta a la frecuencia más baja cuando la CPU entra en idle (1000mhz>100mhz).
4) Interactive
Se puede considerar con un Ondemand rápido. Al ser más rápido gasta más batería. Tiene las siguientes ventajas:
Escala frecuencias de manera más consistente, debido a que los otros governors hacen su muestreo de carga de la CPU en un contexto de espera (primero uno, hasta que no acabe con ese no pasa el siguiente), pero el Interactive asigna unos tiempos a cada muestreo haciéndolo más consistente.
Mayor prioridad para el incremento de frecuencia de la CPU, dando así un mayor beneficio al incremento de rendimiento.
5) Interactivex
Es un Interactive con un perfil de arranque. Más ahorro de la batería que el Interactive.
6) Lulzactive
Está basado en los governors Interactive y Smartass y es uno de los más usados.
Versión antigua
Cuando la carga de la CPU es igual o superior al 60%, el governor hace que la CPU aumente hasta la siguiente frecuencia. Cuando la carga es inferior al 60%, el governor hace que la CPU disminuya hasta la frecuencia anterior a la que está. Cuando la pantalla está apagada, la frecuencia es la mínima a la que esté configurada la CPU.
Versión nueva
Existen tres nuevos parámetros configurables: inc_cpu_load, pump_up_step y pump_down_step. Esto dota de más control por parte del usuario. Podemos establecer el umbral en el que governor decide escalar hacia arriba o hacia abajo. De la misma manera, podemos fijar el número de frecuencias que se saltará hacia arriba o hacia abajo. Por ejemplo: cuando la carga esté por encima del 60% pasar de 200mhz a 800mhz.
Otro ejemplo
Considerad los siguientes parámetros:
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
Si la frecuencia actual=200mhz, cuando la CPU tenga una carga del 70% escalará 2 frecuencias hasta llegar a los 800mhz.
Si la frecuencia actual=1200mhz, cuando la CPU tenga una carga menor al 70% bajará 1 frecuencia hasta llegar a los 1000mhz.
7) Smartass
Es el governor resultante de que Erasmux reescribiese completamente el código del Interactive. El principal objetivo es optimizar la duración de la batería sin comprometer el rendimiento. Aun así, el gasto de batería es algo mayor que el SmartassV2 dado que la frecuencia mínima con la pantalla encendida es mayor que las frecuencias utilizadas con la pantalla apagada. Salta a la máxima frecuencia en intervalos de tiempo muy cortos, y esta operación la repite continuamente.
8) SmartassV2
Es la Versión 2 del Smartass original de Erasmux. Otro de los favoritos de mucha gente. El objetivo de este governor es el de utilizar la frecuencia ideal, y subir de forma bastante agresiva hasta esa frecuencia, para después bajar más suavemente. Usa diferentes frecuencias ideales para perfiles de pantalla apagada/encendida, llamados awake_ideal_freq y sleep_ideal_freq. Este governor baja de frecuencia de CPU muy rápidamente (para alcanzar cuanto antes la sleep_ideal_freq) mientras la pantalla está apagada, y sube de frecuencia de la CPU rápidamente hasta la awake_ideal_freq cuando la pantalla se enciende. No hay un límite superior de frecuencia mientras la pantalla está apagada (a diferencia del Smartass). Por lo tanto, el governor tiene disponible todo el rango entero de frecuencias para usarlas durante los estados de pantalla apagada/encendida. El lema de este governor es un equilibrio entre rendimiento y batería.
9) Intellidemand
Intellidemand, o también conocido como Intelligent Ondemand es otro governor basado en el Ondemand. El Intellidemand original se comporta de manera diferente según el uso de la GPU. Cuando la GPU está realmente ocupada (por juegos, Maps, benchmarking, etc) Intellidemand se comporta como un Ondemand. Cuando la GPU está “idling” (al ralentí, por así decirlo), o no tan ocupada como antes, Intellidemand limita la frecuencia máxima en función de las frecuencias disponibles del dispositivo/kernel para ahorrar batería. Esto se denomina modo de navegación. Podemos apreciar aquí algunos aspectos del governor Interactive. La frecuencia con la que se toman las decisiones de escalar hacia arriba está basada en el tiempo de inactividad de la CPU. Un tiempo de inactividad bajo (<20%) hace que la CPU aumente la frecuencia actual. En resumen, se trata de un Ondemand inteligente que entra en el modo navegación para limintar la frecuencia máxima cuando la GPU entra en inactividad, y se comporta con un Ondemand cuando la GPU está ocupada para ofrecer rendimiento para juegos, por ejemplo. Intellidemand no salta a la frecuencia más alta cuando la pantalla está apagada.
10) Lazy
Este governor creado por Ezekeel es básicamente un Ondemand con unos parámetros adicionales min_time_state para especificar el tiempo mínimo que la CPU está en una frecuencia antes de subirla/bajarla. La idea es eliminar cualquier inestabilidad causada por el rápido cambio que usa Ondemand. Lazy también tiene un parámetro screenoff_mazfreq que cuando está activado hará que el governor siempre seleccione la máxima frecuencia cuando la pantalla está apagada.
11) Lagfree
Lagfree es similar al Ondemand. La única diferencia es que no está optimizado para mejorar el gasto de batería. La frecuencia aumenta y disminuye suavemente, a diferencia del Ondemand. Lagfree no omite ningún escalón en la frecuencia mientras la aumenta o la disminuye. Hay que tener presente que si hay un requerimiento repentino de energía Lagfree no puede satisfacerlo ya que tiene que pasar por todas y cada una de las frecuencias. Algunos usuarios han reportado que la reproducción de vídeo usando Lagfree da algunos pequeños tirones.
12)Lionheart 13) LionheartX 14) Brazilianwax
15) SavagedZen
Es otro governor basado en el SmartassV2. Logra un buen equilibrio entre rendimiento y batería, en comparación con al Brazilianwax.
16) Userspace
En lugar de determinar automáticamente las freuencias, deja a los usuarios elegirlas.
17) Powersave
Bloquea la frecuencia máxima a la mínima frecuencia. No se puede usar como un perfil de pantalla encendida o incluso apagada si la frecuencia mínima es demasiado baja.
18) Performance
Ajusta la mínima frecuencia a la máxima frecuencia. ¡Úsalo mientras haces un benchmarking! :P
PREGUNTAS
P. “Muy bien, basta de explicaciones. Dime qué governor es mejor para rendimiento y cual es mejor para la batería.”
R. Lulzactive y SmartassV2 para un equilibrio entre rendimiento y batería. Para tareas ligeras, Lulzactive debería ser mejor en cuanto a batería, y para tareas más pesadas, Lulzactive debería ser mejor para rendimiento también. Para obtener un rendimiento máximo usa un Ondemand retocado o un Conservative, pero nunca te quejes de la batería entonces. NOTA: no es fácil hacerse con el Lulzactive. Si no estás seguro de cómo configurarlo sigue leyendo los siguientes posts.
P. “Casi lo olvido, ¿cómo puedo cambiar los governors?"
R. La mejor manera es usando un script en init.d si tu kernel está preparado para ello. Otra opción, mucho más fácil, es usando aplicaciones como NSTools, Voltage Control, Pimp my CPU, etc.
P. “¿Cómo se qué governor es el mejor para mí?”
R. Depende de lo que necesites según el uso que le des al teléfono a diario: rendimiento o batería. La mejor elección es un governor que tenga un equilibro entre las dos opciones. O modificar un governor para obtener un mayor rendimiento en detrimento de la batería. Siempre podemos recargar la batería: en el coche cuando vamos al trabajo, en casa por la noche. Lo que no podemos es recargar el rendimiento. Si, como lo oyes. Prueba a disfrutar del teléfono, no le pongas barreras con tal de que gaste menos y te dura la batería 2 o 3 días. Si la batería te aguanta desde que te levantas hasta que te acuestas dale caña.
P. “Bien, he elegido me governor favorito para cuando se enciende la pantalla y otro para cuando se apaga. ¿Por qué el teléfono no se enciende al salir del reposo? Tengo que reiniciarlo pulsando el botón power durante unos 10 segundos…¿He tenido un SOD (sleep of death)?”
R. Si. No uses dos governos distintos para pantalla apagada/encendida si ambos tienen limitada la frecuencia máxima para la pantalla apagada. ¿No lo has entendido?
Ejemplo de mala combinación (pantalla encendida/apagada): OndemandX-SmartassV2.
Ejemplo de buena combinación: Ondemand-SmartassV2, Lulzaactive-SmartassV2.
P. "Noto cierto lag con un governor. Por ejemplo cuando hago scroll en el menú de aplicaciones o en el navegador web, etc. Me encanta este governor y no me digas que use otro…¿Puedo deshacerme del lag?"
R. Si…puedes. Básicamente lo que tenemos que hacer es que el governor muestree con menos frecuencia cuándo bajar la velocidad de la CPU. Incrementar el tiempo de muestro para bajar la frecuencia hace que la CPU esté durante más tiempo en una misma frecuencia antes de disminuirla. Esto podría eliminar el lag.
P. “Ok, quiero modificar el governor según mi uso habitual, porque no estoy a gusto con la configuración predetermianda.”
R. Se pueden modificar los governors usando un script en init.d, por ejemplo: /sys/devices/system/cpu/cpufreq/name-of-active-governor/name-of-the-paramater-to-tweak. La manera más fácil y cómoda, sin duda, es usando la aplicación NSTools, la cual permite ajustar los parámetros de todos los governors que lo permitan.
P. “Voy a elegir como frecuencia mínima 100 mhz porque mi kernel me da la opción. Espero que no haya nada malo en hacer esto.”
R. ¡Espera! Posiblemente desees no usar la frecuencia mínima de 100 mhz con la pantalla apagada/encendida por tres razones:
100 mhz consume más batería que 200 mhz. Según los test, 100 mhz consumen 1W/Ghz y 200 mhz consumen 0,7W/Ghz.
En 200 mhz se pueden hacer las mismas tareas más rápidamente que en 100 mhz y entrar antes en reposo.
Ojo: esta frecuencia mínima es la mejor para el SGS II. En el Motorola Milestone por ejemplo es 550 mhz. En el SGS no lo sé.
P. “¿Cómo hacer mi teléfono más ágil? Me importa la duración de la batería…”
R. Selecciona un rango de 500 mhz a 1200 mhz cuando la pantalla está encendida y uno de 200 mhz a 500 mhz cuando la pantalla está apagada. Usa un Performance o un Conservative/OndemanX modificados. La respuesta del teléfono será excelente y no te preocupes…un mínimo de 500 mhz con la pantalla encendida no gasta tanta batería como piensas.
I/O SCHEDULERS (I/O = Imput/Output)
P. “¿Para qué sirve un I/O Scheduler?”
R.
Reducir al mínimo la latencia de búsqueda del disco duro.
Dar prioridad a las operaciones de I/O de algunos procesos.
Asignar más espacio en disco para los procesos en ejecución.
Garantizar que ciertas peticiones se ejecutan antes de un tiempo límite.
Para entenderlo de una forma más simple: el kernel controla los accesos al disco usando un I/O Scheduler (Scheduler = planificador).
P. “¿Qué metas persigue cada I/O scheduler para tratar de conseguir un equilibrio?”
R.
Equidad (que cada proceso tenga su parte asignada de acceso al disco).
Rendimiento (tratar de atender las solicitudes que se encuentren en primer lugar, haciendo la búsqueda más rádida).
Tiempo real (garantizar que las solicitudes son atendidas en un tiempo dado).
1) Noop
Gestiona todas las peticiones siguiendo el método FIFO (First In First Out), o dicho de otra forma, las primeras en llegar son las primeras en salir/ser atentidas. Lo mejor es utilizarlo con dispositivos de almacenamiento que no dependen de movimiento mecánico para acceder a los datos (si, como nuestras tarjetas flash). La ventaja aquí es que las unidades flash no requieren un reordenamiento de las múltiples peticiones I/O, a diferencia de los discos duros normales.
Ventajas
Sirve las peticiones I/O con un menor número de ciclos de la CPU (¿mejora de la batería?).
Es el mejor para unidades flash.
Buen rendimiento en los sistemas db.
Inconvenientes
La reducción en el número de ciclos de la CPU es proporcional a la pérdida de rendimiento.
2) Deadline
El objetivo es minimizar la latencia de I/O o la necesidad de una petición. Esto se logra medianta una política de “todos contra todos”, para ser justos entre múltiples peticiones de I/O. Se utilizan 5 colas de espera para reordenar las solicitudes entrantes.
Ventajas
Se acerca bastante a un planificador a tiempo real.
Excelente en la reducción de latencia de peticiones I/O.
El mejor planificador para el acceso a bases de datos y consultas.
El requerimiento de “ancho de banda” de un proceso (el porcentaje de CPU que necesita) se puede calcular fácilmente.
Al igual que Noop, es un buen planificador para memorias flash.
Inconvenientes
Cuando el sistema está sobrecargado, la elección de procesos se puede volver impredecible.
3) CFQ
Completely Fair Queuing (o dicho de manera cutre “cola completamente equitativa”) mantiene una cola de procesos estable, repartiendo el porcentaje necesitado de la CPU en partes iguales entre todas las peticiones I/O. El intervalo de tiempo asignado a cada cola depende de la prioridad del proceso primario.
Ventajas
Considerado el mejor ofreciendo un equilibrado rendimiento I/O.
El más fácil de configurar.
Excelente en sistemas multiprocesador.
El mejor rendimiento del sistema en bases de datos, después de Deadline.
Inconvenientes
Algunos usuarios reportan que el escáner de medios tarda bastante en completarse usando CFQ. Esto podría deberse a que la distribución del uso de la CPU se reparte equitativamente entre todas las operaciones I/O durante el arranque y no se conceden prioridades.
Jitter (el peor caso de retardo) puede llegar a ser alto debido a la cantidad de tareas que necesitan acceso al disco.
4) BFQ
En lugar de asignar intervalo de tiempo como CFQ, BFQ asigna como unos “presupuestos” estimativos. Garantiza el disco para el proceso activo hasta que el presupuesto expira. El presupuesto asignado a un proceso varía con el tiempo como una función de su comportamiento. (la traducción deja mucho que desear, si alguien la puede hacer mejor que me lo comente por PM).
Ventajas
Se cree que es muy bueno para la tasa de transferencia de datos vía USB.
Se cree que es el mejor scheduler para la grabación de videos de HD y video streaming (por el menor “jitter” en comparación con CFQ y los otros).
Es considerado un scheduler I/O muy preciso.
Alcanza alrededor de un 30% más de rendimiento que CFQ.
Inconvenientes
No es el mejor scheduler para hacer benchmarking.
El mayor “presupuesto” asignado a un proceso puede afectar a la experiencia de usuario y aumentar la latencia (retardos).
5) SIO
Es un scheduler I/O simple cuyo objetivo es mantener unos consumos mínimos y lograr un escaso restardo al atender solicitudes. Sio es una mezcla entre Noop y Deadline. No existe un reordenamiento de las peticiones.
Ventajas
Simple, muy seguro.
Minimiza la necesidad de atención de las solicitudes.
Inconvenientes
Velocidades lentas de lectura en memorias flash, en comparación con los otros schedulers.
La velocidad de las lecturas secuenciales en memorias flash tampoco es buena.
6) V(R)
A diferencia de los otros schedulers, las peticiones síncronas y asíncronas no se tratan de forma separada. La siguiente solicitud en ser atendida será la que más cercana esté a la última atendida.
Ventajas
Quizás es el mejor para benchmarking porque en el mejor de sus comportamientos el rendimiento es mejor.
Inconvenientes
Los resultados de las variaciones de rendimiento pueden ser que esté por debajo del promedio a veces.
Menos fiable y más inestable.
PREGUNTAS
P. “¿Cuál es el mejor I/O Scheduler?
R. No hay ninguno mejor que otro. Depende del uso que le des y las aplicaciones y tareas que tengas en ejecución, usa diferentes schedulers. Es lo mejor que te puedo decir. Sin embargo, considerando un rendimiento general, batería, fiabilidad y menos retardo, se piensa que SIO > Noop > Deadline > VR > BFQ > CFQ, considerando que todos los schedulers son modificables y el almacenamiento usado es una memoria flash.
P. “¿Cómo puedo cambiar los I/O Schedulers?”
R. Con aplicaciones como NSTools o Voltage Control por ejemplo, ambas en el Market.
Veloz46
16/05/12, 02:11:50
Post numero 2 para los de tapatalk:
http://www.subemania.com/?di=Z7W2
¿Qué son los gobernadores?
Los gobernadores serían los encargados de gestionar el uso de las frecuencias de la CPU. Dicho de otro modo, es el que decide cuándo utilizar la frecuencia máxima (en el Galaxy SII por defecto es de 1200Mhz) para sacar todo el rendimiento de nuestro "bicharraco", las intermedias (1000/800/500Mhz) o cuándo trabajar al mínimo (200Mhz).
Diferentes tipos de gobernadores y sus características:
1) lazy:
Este gobernador de ezekeel es básicamente un gobernador ondemand con un parámetro adicional min_time_state para especificar el tiempo mínimo que la CPU se mantiene en una frecuencia antes de escalar hacia arriba/abajo. La idea aquí es eliminar cualquier inestabilidad causada por el rápido cambio de frecuencia del ondemand. El gobernador Lazy escanea más frecuentemente que el ondemand, pero cambia de frecuencia sólo después de completar min_time_state en un paso. Lazy también tiene un parámetro de screenoff_maxfreq que puede ser configurado para especificar la frecuencia máxima con la pantalla apagada.
2) lulzactive:
Este gobernador de tegrak está basado en los gobernadores interactive y smartass. Es uno de los gobernadores favoritos.
Versión vieja: cuando la carga de trabajo es mayor o igual al 60%, el gobernador escala hacia arriba la cpu hasta el siguiente paso más alto. Cuando la carga de trabajo es menor al 60%, el gobernador escala hacia abajo la cpu hasta el siguiente paso más bajo. Cuando la pantalla está apagada, la frecuencia está bloqueada a la frecuencia mínima de escalado.
Nueva versión: tres parámetros adicionales configurables por el usuario: inc_cpu_load, pump_up_step, pump_down_step. Este gobernador ofrece mayor control para el usuario. Podemos configurar el umbral en el cual el gobernador decide si escala arriba/abajo. También podemos configurar el número de pasos de frecuencia.
También puede fijar el número de pasos de frecuencia que hay que saltar mientras escanea arriba y abajo.
3) lagfree:
El gobernador Lagfree es similar a ondemand. La diferencia principal es su optimización para llevarse mejor con la batería. Lagfree no se salta ningún paso de frecuencia mientras escala arriba o abajo. Recuerde que si hay un requerimiento para un repentino gasto de energía grande, lagfree no puede satisfacerlo mientras eleva la cpu a través de cada paso de alta frecuencia desde el actual. Algunos usuarios han reportado problemas de tirones en la reproducción de vídeo utilizando Lagfree.
4) smartassV2:
Versión 2 del gobernador smartass original de erasmux. Otro gobernador favorito para mucha gente. Este gobernador escala hacia abajo muy rápido cuando la pantalla está apagada y escala hasta 500Mhz muy rápido cuando la pantalla está encendida. No hay límite de frecuencia superior cuando la pantalla está apagada. El objetivo de este gobernador es buscar la "frecuencia ideal", y aumentar gradualmente de una manera más agresiva hacia esta frecuencia y menos agresiva después. Utiliza diferentes frecuencias ideales cuando la pantalla está apagada o encendida, es decir, awake_ideal_freq y sleep_ideal_freq. Garantiza un equilibrio entre rendimiento y batería.
5) ondemandx:
Básicamente es un gobernador ondemand con un perfil de suspensión/despertar. Este gobernador es un ondemand con mejor comportamiento con la batería. Cuando la pantalla está apagada, la frecuencia máxima son 500Mhz.
6) intellidemand: Intellidemand o también conocido como el "ondemand inteligente" de Faux, es otro gobernador basado en "ondemand". A diferencia de lo que algunos usuarios creen, este gobernador no es el equivalente a "OC Daemon" (Teniendo distintos gobernadores para suspensión y despertar). El comportamiento original de "intellidemand" es diferente según el uso de la GPU. Cuando la GPU está muy saturada (con juegos, mapas, benchmarks...) el comportamiento de intellidemand es como el del gobernador "ondemand". Cuando la GPU está inactiva o con un uso muy moderado, "intellidemand" limita la frecuencia máxima a un paso dependiendo de las frecuencias disponibles en tu kernel/teléfono para salvar batería. Esto se conoce como el modo navegación. Podemos ver algunos "rastros" del gobernador "interactive" aquí. La decisión de escalar la frecuencia está basada en el tiempo de inactividad de la CPU. Un menor tiempo de inactividad (<20%) hace que la CPU escale hacia arriba desde la frecuencia actual. El escalado descendente de frecuencia ocurre en los pasos = 5% de la frecuencia actual. En resumen, se trata de un "ondemand inteligente" que entra en modo de navegación para limitar la frecuencia máxima cuando la GPU está inactiva y se comporta como "ondemand" cuando la GPU está muy ocupada, ofreciendo un buen rendimiento para juegos y similares. "Intellidemand" no salta a la frecuencia más alta cuando la pantalla está apagada.
7) lionheart:
Lionheart es un gobernador "conservative" modificado por Knzo. Permite modificar el umbral mínimo y máximo y la menor frecuencia de muestreo disponible en el "conservative". Lo que busca este gobernador es la capacidad de respuesta extrema y el rendimiento, a costa de la batería. Cuando se trata de suavidad (sin considerar la descarga de la batería), un "conservative" ajustado ofrece mayor suavidad en comparación con un "ondemand" afinado. Esto podría ser la razón del nacimiento de Lionheart.
8) brazilianwax:
Similar al gobernador smartassv2. Más agresivo incrementando la frecuencia, por lo que ofrece mejor rendimiento y por lo tanto, menos batería.
9) SavagedZen:
Otro gobernador basado en smartassv2. Logra un buen equilibrio entre rendimiento y batería en comparación con savagedzen.
10) smartass:
Versión inicial de smartassv2. Dispone de un límite de frecuencia con la pantalla apagada. No se comporta tan bién con la batería como smartassv2 ya que la frecuencia mínima con la pantalla encendida es mayor que la frecuencia utilizada mientras la pantalla está apagada.
11) conservative:
Un ondemand más lento el cual escala despacio para salvar batería.
12) userspace:
En lugar de determinar automáticamente las frecuencias, permite al usuario configurar las frecuencias.
13) powersave:
Bloquea la frecuencia máxima a la frecuencia mínima. No se puede utilizar con la pantalla encendida o incluso con la pantalla apagada (si la frecuencia mínima de escalado es demasiado baja).
14) ondemand:
El gobernador por defecto en la mayoría de kernels originales. Es lo mismo que ondemandx pero sin perfiles de suspensión/despertar. A pesar de que muchos de nosotros consideramos que éste es un gobernador fiable, carece de ahorro de batería y el rendimiento es el que viene configurado por defecto.
15) performance:
Establece la frecuencia mínima como la máxima. Utiliza este gobernador para realizar los benchmarks!
16) Interactive:
Es considerado como un ondemand más rápido. Más ágil, menos batería. En lugar de realizar muestreos en cada intervalo como ondemand, éste determina la manera de escalar la cpu cuando sale de reposo. Es un ondemand inteligente por las optimizaciones de estabilidad.
17) Interactivex:
Es un gobernador Interactive con un perfil para despertar. Mejor comportamiento con la batería que el Interactive.
¿Cómo cambiar el gobernador?
Una vez que nos decantamos por un gobernador entre la gran variedad existente, vamos a explicar cómo cambiarlo.
Se pueden cambiar de varias formas, una de ellas es utilizando scripts, pero voy a explicar la manera más sencilla a mi juicio, que es mediante la utilización de aplicaciones disponibles en el Market. Hay bastantes aplicaciones para este cometido, pero voy a citar las más conocidas.
- SetCPU
Link al Market (
https://market.android.com/details?i...clocking&hl=es)
Descarga gratuíta en su hilo oficial de XDA (
http://forum.xda-developers.com/showthread.php?t=505419)
http://www.subemania.com/?di=667C
Simplemente tenemos que pulsar en "scalling" y nos saldrá la lista de gobernadores disponibles que nos ofrece nuestro kernel, ya sólo queda elegir el que más nos guste. También podemos variar la frecuencia máxima y mínima a la que trabajará nuestra CPU. Cuando hayamos terminado, si queremos que las modificaciones que hemos hecho se apliquen al reiniciar el terminal debermos marcar la casilla "Set on Boot". Existen más opciones en esta aplicación pero no las citaré ya que se alejan del cometido de este manual y ya existen otros tutoriales específicos para utilizar SetCPU.
- Voltage Control
Link al Market (gratuíta) (
https://market.android.com/details?i...yLDEsImNvbS5kY XJla3hhbi52b2x0YWdlY29udHJvbCJd)
http://www.4shared.com/get/jY3Aionp/...eme_v4910.html
http://www.subemania.com/?di=4D2P
Para cambiar el gobernador con Voltage Control pulsamos en "CPU Governor" y elegimos el gobernador que más nos interese. También nos permite elegir la frecuencia máxima y mínima a la que trabajará nuestra CPU. Si queremos mantener nuestra configuración al reiniciar el teléfono marcamos la tecla "menú > Save as boot settings". Esta aplicación tiene la ventaja respecto a SetCPU que no se queda en memoria. Existen más opciones pero no las mencionaré al alejarse de la temática.