sergy330
13/12/11, 00:53:43
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?id=com.mhuang.overclocking&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?id=com.darekxan.voltagecontrol&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5kY XJla3hhbi52b2x0YWdlY29udHJvbCJd)
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.
Continuará...
NOTA: Traducción propia, he tratado en la medida de lo posible que se entienda todo, espero que me perdonéis si algo no está del todo claro, pero hay tecnicismos que no tienen traducción pura.
AGRADECIMIENTOS: droidphile (XDA)
TUTORIAL REALIZADO EXPRESAMENTE POR ZADOCK (http://www.htcmania.com/member.php?u=448396)
[/SIZE]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.
Parámetros y ajustes
Solo voy a poner éstos para Ondemand, Conservative, SmartassV2, Lulzactive e Interactive ya que son los governors más utilizados.
Diferentes governors tendrán diferentes parámetros, pero es fácil entenderlos. Normalmente un governor tendrá:
Tiempo/frecuencia de muestreo (Sampling Time/Rate): medido en µs y según la cual la función de muestreo determina la frecuencia para "sondear" y decidir si la misma debe ser reducida o incrementada. Algunos governors tendrán diferentes tiempos de muestreo tanto para aumentar como disminuir.
Umbrales (Thresholds): medidos en porcentaje. Cuando la carga de la CPU alcanza este punto, el governor aumenta o disminuye la frecuencia de la misma.
Hay muchos otros parámetros, pero todos están relacionados de alguna manera con estos dos, principalmente.
Antes de seguir, personalmente, recomiendo el uso de la aplicación NSTools (https://play.google.com/store/apps/details?id=mobi.cyann.nstools&feature=search_result#?t=W251bGwsMSwxLDEsIm1vYmkuY 3lhbm4ubnN0b29scyJd), gratis en la Play Store.
1. ONDEMAND
Parámetros
sampling_rate: medido en µs, es la manera en que el kernel revisa el uso que está teniendo la CPU y tomar decisiones sobre qué hacer con la frecuencia. Valores altos significa que se muestrea con menos frecuencia la CPU.
up_threshold: medido en porcentaje. Cuando la carga de la CPU alcanza este punto, el governor aumentará la frecuencia de la CPU. Valores altos significan menos capacidad de respuesta y valores más bajos al revés, pero a costa de más batería.
powersave_bias: el valor por defecto es 0. Establecer un valor alto llevará al governor hacia frecuencias más bajas. Úsalo si quieres que la CPU pase el menor tiempo posible en frecuencias altas. Una mejor alternativa podría ser hacer UC (underclock) a una frecuencia menor en vez de usar este parámetro.
sampling_down_factor: en su forma simple, sampling_down_factor determina cada cuanto la CPU debe permanecer en las frecuencias altas cuando esté realmente ocupada. El comportamiento por defecto es un cambio rápido a las frecuencias más bajas. Por defecto el valor asociado a este parámetro es 1, pero al elegir un valor mayor hace que actúe como un multiplicador ( 2=x2, 3=x3, 70=x70, etc.) del intervalo en el que se re-evalúa la carga de la CPU, cuando está en su frecuencia más alta. Esto mejora el rendimiento. Esta modificación no tiene efecto sobre bajas frecuencias y cargas de la CPU. Ayuda a que la CPU se mantenga siempre en frecuencias altas cuando tiene una carga alta.
Ejemplos de configuración
Batería
Para obtener un ahorro de batería, selecciona valores altos de up_threshold y sampling_rate. De esta manera los muestreos se harán con menos frecuencia, lo mismo que las subidas/bajadas de frecuencia.
up_threshold = 95
sampling_rate = 120000
sampling_down_factor = 1
Rendimiento
Para obtener mayor rendimiento, selecciona valores bajos de up_threshold y sampling_rate. De esta manera, el muestreo y las subidas/bajadas se harán más a menudo.
up_threshold = 70
sampling_rate = 50000
sampling_down_factor = 2
LULZACTIVE
Parámetros
inc_cpu_load: en la versión anterior este parámetro estaba fijado en 60. Actualmente es configurable por parte del usuario. Es la frecuencia a la cual el governor escala en la CPU hacia arriba/abajo. Si la carga es menor que el número que hemos fijado, la CPU baja de frecuencia y al revés si la carga es mayor.
pump_up_step: número de "escalones" (cada escalón es una frecuencia: 100 mhz, 200 mhz, etc.) que aumenta la frecuencia cuando la carga es mayor que inc_cpu_load.
pump_down_step: número de escalones que disminuye la frecuencia cuando la carga es menor que inc_cpu_load.
screen_off_min_step: pasos en la tabla de frecuencias para ser usados cuando la pantalla está apagada. Ejemplo: si las frecuencias disponibles son 1600, 1400, 1200, 1000, 800, 400, 200, 100 (L0 a L7) y el screen_off_min_step=5 entonces 100, 200 y 400 (L5 a L7) serán usadas mientras la pantalla está apagada dependiendo de la necesidad.
up_sample_time: tiempo de muestreo para bajar la frecuencia de la CPU (valores entre 10.000 y 50.000).
down_sample_time: tiempo de muestreo para subir la frecuencia de la CPU (valores entre 10.000 y 100.000).
Ejemplos de configuración
Batería
Esta modificación hace que se aumente gradualmente la frecuencia de la CPU y se disminuya rápidamente.
inc_cpu_load = 90
pump_up_step = 1
pump_down_step = 2
up_sample_time = 50000
down_sample_time = 40000
screen_off_min_step = 5
Rendimiento
Esta modificación hace que se aumente la frecuencia de la CPU rápidamente y baje de forma gradual.
inc_cpu_load = 60
pump_up_step = 4
pump_down_step = 1
up_sample_time = 10000
down_sample_time = 70000
screen_off_min_step = 5
Equilibrio entre batería y rendimiento
Esta modificación hace que se muestree más a menudo y se suban 4 escalones sobre la frecuencia actual, pero solo cuando se alcanza el 90% de carga de la CPU. La CPU baja de frecuencia de manera normal.
inc_cpu_load = 90
pump_up_step = 4
pump_down_step = 1
up_sample_time = 10000
down_sample_time = 40000
screen_off_min_step = 5
SMARTASSV2
Parámetros
awake_ideal_freq: es la frecuencia hasta la cual la CPU sube rápidamente al encenderse la pantalla (estando anteriormente apagada). Después de esto la subida es menos agresiva.
sleep_ideal_freq: es la frecuencia hasta la cual la CPU baja rápidamente cuando la pantalla se apaga. Después de esto, la bajada es menos agresiva.
up_rate: es la mínima cantidad de tiempo que se pasa en una frecuencia, antes de subirla. (Ignorado por debajo de la awake_ideal_freq ya que el governor necesita aumentar rápidamente la frecuencia cuando está por debajo de este parámetro).
down_rate: es la mínima cantidad de tiempo que se pasa en una frecuencia, antes de bajarla. (Ignorado por encima de la sleep_ideal_freq ya que el governor necesita bajar rápidamente la frecuencia cuando está por encima de este parámetro).
max_cpu_load: lo mismo que la up_threshold en otros governors.
min_cpu_load: lo mismo que la down_threshold en otros governors.
ramp_down_step: es la frecuencia que se establece cuando se baja de la frecuencia ideal. Un valor 0 deshabilita este parámetro. Cuando se está por encima de la frecuencia ideal siempre bajaremos a ésta.
ramp_up_step: es la frecuencia que se establece cuando estamos por encima de la frecuencia ideal. Un valor 0 deshabilita este parámetro.
sleep_wakeup_freq: es la frecuencia a elegir cuando salimos del modo "sleep". Cuando ponemos un valor 0 no tiene efecto.
Ejemplos de configuración
Batería
awake_ideal_freq = 500000
sleep_ideal_freq = 200000
sleep_wakeup_freq = 500000
max_cpu_load = 85
min_cpu_load = 70
ramp_up_step = 200000
ramp_down_step = 200000
up_rate = 48000
down_rate = 49000
Rendimiento
awake_ideal_freq = 800000
sleep_ideal_freq = 200000
sleep_wakeup_freq = 800000
max_cpu_load = 75
min_cpu_load = 45
ramp_up_step = 0
ramp_down_step = 0
up_rate = 24000
down_rate = 99000
CONSERVATIVE
Parámetros
down_threshold: ya descrito en los otros governors.
up_threshold: ya descrito en los otros governors.
sampling_down_factor: ya descrito en los otros governors.
sampling_rate: ya descrito en los otros governors.
freq_step: medido como en porcentaje de la máxima velocidad de la CPU, define cuánto se incrementará la velocidad de la CPU cada vez que ésta alcance el valor de up_threshold.
Ejemplos de configuración
Batería
Selecciona un valor bajo para freq_step para ahorrar batería.
up_threshold = 95
sampling_rate = 120000
sampling_down_factor = 1
down_threshold = 40
freq_step = 10
Rendimiento
Para nada es irónico el configurar un governor Conservative para obtener un mayor rendimiento.
up_threshold = 60
sampling_rate = 40000
sampling_down_factor = 5
down_threshold = 20
freq_step = 25
INTERACTIVE
Parámetros
hispeed_freq: el valor por defecto es scaling_max_freq.
go_hispeed_load: va a la velocidad más alta cuando la carga de la CPU es igual o superior a este valor (similar a up_threshold en otros governors).
min_sample_time: la cantidad mínima de tiempo que pasamos en una frecuencia antes de bajarla.
timer_rate: frecuencia de muestreo usada para incrementar la velocidad de la CPU.
Ejemplos de configuración
Batería
go_hispeed_load = 95
hispeed_freq = 1000000
min_sample_freq = 10000
timer_rate = 40000
Rendimiento
go_hispeed_load = 80
hispeed_freq = 1400000
min_sample_freq = 40000
timer_rate = 20000
¿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?id=com.mhuang.overclocking&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?id=com.darekxan.voltagecontrol&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5kY XJla3hhbi52b2x0YWdlY29udHJvbCJd)
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.
Continuará...
NOTA: Traducción propia, he tratado en la medida de lo posible que se entienda todo, espero que me perdonéis si algo no está del todo claro, pero hay tecnicismos que no tienen traducción pura.
AGRADECIMIENTOS: droidphile (XDA)
TUTORIAL REALIZADO EXPRESAMENTE POR ZADOCK (http://www.htcmania.com/member.php?u=448396)
[/SIZE]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.
Parámetros y ajustes
Solo voy a poner éstos para Ondemand, Conservative, SmartassV2, Lulzactive e Interactive ya que son los governors más utilizados.
Diferentes governors tendrán diferentes parámetros, pero es fácil entenderlos. Normalmente un governor tendrá:
Tiempo/frecuencia de muestreo (Sampling Time/Rate): medido en µs y según la cual la función de muestreo determina la frecuencia para "sondear" y decidir si la misma debe ser reducida o incrementada. Algunos governors tendrán diferentes tiempos de muestreo tanto para aumentar como disminuir.
Umbrales (Thresholds): medidos en porcentaje. Cuando la carga de la CPU alcanza este punto, el governor aumenta o disminuye la frecuencia de la misma.
Hay muchos otros parámetros, pero todos están relacionados de alguna manera con estos dos, principalmente.
Antes de seguir, personalmente, recomiendo el uso de la aplicación NSTools (https://play.google.com/store/apps/details?id=mobi.cyann.nstools&feature=search_result#?t=W251bGwsMSwxLDEsIm1vYmkuY 3lhbm4ubnN0b29scyJd), gratis en la Play Store.
1. ONDEMAND
Parámetros
sampling_rate: medido en µs, es la manera en que el kernel revisa el uso que está teniendo la CPU y tomar decisiones sobre qué hacer con la frecuencia. Valores altos significa que se muestrea con menos frecuencia la CPU.
up_threshold: medido en porcentaje. Cuando la carga de la CPU alcanza este punto, el governor aumentará la frecuencia de la CPU. Valores altos significan menos capacidad de respuesta y valores más bajos al revés, pero a costa de más batería.
powersave_bias: el valor por defecto es 0. Establecer un valor alto llevará al governor hacia frecuencias más bajas. Úsalo si quieres que la CPU pase el menor tiempo posible en frecuencias altas. Una mejor alternativa podría ser hacer UC (underclock) a una frecuencia menor en vez de usar este parámetro.
sampling_down_factor: en su forma simple, sampling_down_factor determina cada cuanto la CPU debe permanecer en las frecuencias altas cuando esté realmente ocupada. El comportamiento por defecto es un cambio rápido a las frecuencias más bajas. Por defecto el valor asociado a este parámetro es 1, pero al elegir un valor mayor hace que actúe como un multiplicador ( 2=x2, 3=x3, 70=x70, etc.) del intervalo en el que se re-evalúa la carga de la CPU, cuando está en su frecuencia más alta. Esto mejora el rendimiento. Esta modificación no tiene efecto sobre bajas frecuencias y cargas de la CPU. Ayuda a que la CPU se mantenga siempre en frecuencias altas cuando tiene una carga alta.
Ejemplos de configuración
Batería
Para obtener un ahorro de batería, selecciona valores altos de up_threshold y sampling_rate. De esta manera los muestreos se harán con menos frecuencia, lo mismo que las subidas/bajadas de frecuencia.
up_threshold = 95
sampling_rate = 120000
sampling_down_factor = 1
Rendimiento
Para obtener mayor rendimiento, selecciona valores bajos de up_threshold y sampling_rate. De esta manera, el muestreo y las subidas/bajadas se harán más a menudo.
up_threshold = 70
sampling_rate = 50000
sampling_down_factor = 2
LULZACTIVE
Parámetros
inc_cpu_load: en la versión anterior este parámetro estaba fijado en 60. Actualmente es configurable por parte del usuario. Es la frecuencia a la cual el governor escala en la CPU hacia arriba/abajo. Si la carga es menor que el número que hemos fijado, la CPU baja de frecuencia y al revés si la carga es mayor.
pump_up_step: número de "escalones" (cada escalón es una frecuencia: 100 mhz, 200 mhz, etc.) que aumenta la frecuencia cuando la carga es mayor que inc_cpu_load.
pump_down_step: número de escalones que disminuye la frecuencia cuando la carga es menor que inc_cpu_load.
screen_off_min_step: pasos en la tabla de frecuencias para ser usados cuando la pantalla está apagada. Ejemplo: si las frecuencias disponibles son 1600, 1400, 1200, 1000, 800, 400, 200, 100 (L0 a L7) y el screen_off_min_step=5 entonces 100, 200 y 400 (L5 a L7) serán usadas mientras la pantalla está apagada dependiendo de la necesidad.
up_sample_time: tiempo de muestreo para bajar la frecuencia de la CPU (valores entre 10.000 y 50.000).
down_sample_time: tiempo de muestreo para subir la frecuencia de la CPU (valores entre 10.000 y 100.000).
Ejemplos de configuración
Batería
Esta modificación hace que se aumente gradualmente la frecuencia de la CPU y se disminuya rápidamente.
inc_cpu_load = 90
pump_up_step = 1
pump_down_step = 2
up_sample_time = 50000
down_sample_time = 40000
screen_off_min_step = 5
Rendimiento
Esta modificación hace que se aumente la frecuencia de la CPU rápidamente y baje de forma gradual.
inc_cpu_load = 60
pump_up_step = 4
pump_down_step = 1
up_sample_time = 10000
down_sample_time = 70000
screen_off_min_step = 5
Equilibrio entre batería y rendimiento
Esta modificación hace que se muestree más a menudo y se suban 4 escalones sobre la frecuencia actual, pero solo cuando se alcanza el 90% de carga de la CPU. La CPU baja de frecuencia de manera normal.
inc_cpu_load = 90
pump_up_step = 4
pump_down_step = 1
up_sample_time = 10000
down_sample_time = 40000
screen_off_min_step = 5
SMARTASSV2
Parámetros
awake_ideal_freq: es la frecuencia hasta la cual la CPU sube rápidamente al encenderse la pantalla (estando anteriormente apagada). Después de esto la subida es menos agresiva.
sleep_ideal_freq: es la frecuencia hasta la cual la CPU baja rápidamente cuando la pantalla se apaga. Después de esto, la bajada es menos agresiva.
up_rate: es la mínima cantidad de tiempo que se pasa en una frecuencia, antes de subirla. (Ignorado por debajo de la awake_ideal_freq ya que el governor necesita aumentar rápidamente la frecuencia cuando está por debajo de este parámetro).
down_rate: es la mínima cantidad de tiempo que se pasa en una frecuencia, antes de bajarla. (Ignorado por encima de la sleep_ideal_freq ya que el governor necesita bajar rápidamente la frecuencia cuando está por encima de este parámetro).
max_cpu_load: lo mismo que la up_threshold en otros governors.
min_cpu_load: lo mismo que la down_threshold en otros governors.
ramp_down_step: es la frecuencia que se establece cuando se baja de la frecuencia ideal. Un valor 0 deshabilita este parámetro. Cuando se está por encima de la frecuencia ideal siempre bajaremos a ésta.
ramp_up_step: es la frecuencia que se establece cuando estamos por encima de la frecuencia ideal. Un valor 0 deshabilita este parámetro.
sleep_wakeup_freq: es la frecuencia a elegir cuando salimos del modo "sleep". Cuando ponemos un valor 0 no tiene efecto.
Ejemplos de configuración
Batería
awake_ideal_freq = 500000
sleep_ideal_freq = 200000
sleep_wakeup_freq = 500000
max_cpu_load = 85
min_cpu_load = 70
ramp_up_step = 200000
ramp_down_step = 200000
up_rate = 48000
down_rate = 49000
Rendimiento
awake_ideal_freq = 800000
sleep_ideal_freq = 200000
sleep_wakeup_freq = 800000
max_cpu_load = 75
min_cpu_load = 45
ramp_up_step = 0
ramp_down_step = 0
up_rate = 24000
down_rate = 99000
CONSERVATIVE
Parámetros
down_threshold: ya descrito en los otros governors.
up_threshold: ya descrito en los otros governors.
sampling_down_factor: ya descrito en los otros governors.
sampling_rate: ya descrito en los otros governors.
freq_step: medido como en porcentaje de la máxima velocidad de la CPU, define cuánto se incrementará la velocidad de la CPU cada vez que ésta alcance el valor de up_threshold.
Ejemplos de configuración
Batería
Selecciona un valor bajo para freq_step para ahorrar batería.
up_threshold = 95
sampling_rate = 120000
sampling_down_factor = 1
down_threshold = 40
freq_step = 10
Rendimiento
Para nada es irónico el configurar un governor Conservative para obtener un mayor rendimiento.
up_threshold = 60
sampling_rate = 40000
sampling_down_factor = 5
down_threshold = 20
freq_step = 25
INTERACTIVE
Parámetros
hispeed_freq: el valor por defecto es scaling_max_freq.
go_hispeed_load: va a la velocidad más alta cuando la carga de la CPU es igual o superior a este valor (similar a up_threshold en otros governors).
min_sample_time: la cantidad mínima de tiempo que pasamos en una frecuencia antes de bajarla.
timer_rate: frecuencia de muestreo usada para incrementar la velocidad de la CPU.
Ejemplos de configuración
Batería
go_hispeed_load = 95
hispeed_freq = 1000000
min_sample_freq = 10000
timer_rate = 40000
Rendimiento
go_hispeed_load = 80
hispeed_freq = 1400000
min_sample_freq = 40000
timer_rate = 20000