[ DEBATE ] Gobernadores OnDemand, OndemandX, Intellidemand, Lazy, Lagfree

[YossYGalaxy]

GOBERNADOR ONDEMAND

Este gobernador tiene como principal característica que ante aumentos en la carga cambia la velocidad de la CPU rápidamente a la velocidad máxima establecida por el usuario (podemos decir que tiene un gatillo que impulsa la velocidad a la velocidad máxima fijada por el usuario). Cuando la carga disminuye, este gobernador disminuirá gradualmente la frecuencia de la CPU a través de los diferentes pasos de frecuencia del kérnel hasta que se asiente en la frecuencia mínima o hasta que el usuario ejecute una tarea que requiera un nuevo aumento en la frecuencia. Destaca la fluidez y capacidad de repuesta que se logra con este gobernador aunque a veces, en su configuración por defecto, se queda un poco corto en cuanto al ahorro de batería.


Es importante saber que el gobernador OnDemand escala su velocidad en un contexto de cola de trabajo (work queue); es decir, una vez que la tarea que dispara la rampa de velocidad del reloj ha terminado, OnDemand intentará moverse de nuevo a la velocidad de reloj mínima, pero si el usuario ejecuta otra tarea que desencadena una rampa OnDemand, la velocidad volverá al máximo. Esto ocurrirá con frecuencia si el usuario es multitarea, teniendo implicaciones negativas para la duración de la batería.


OnDemand es normalmente el gobernador elegido por los fabricantes de smartphones ya que está muy probado, por lo que es muy fiable, y garantiza el rendimiento y fluidez en los teléfonos; aunque sea en detrimento de la duración de la batería.




GOBERNADOR ONDEMANDX

Básicamente es un OnDemand con perfiles diferentes para pantalla encendida y apagada. Cuando la pantalla está apagada la frecuencia máxima está limitada a 500 mhz. Se supone por ello que este es un gobernador OnDemand con un mejor trato para la batería.




GOBERNADOR INTELLIDEMAND

El gobernador Intellidemand también es conocido como Ondemand Inteligente (de Faux) y como su nombre indica es otro gobernador basado en el OnDemand.

El Intellidemand se comporta de manera diferente según el uso de la GPU. Cuando la GPU está muy ocupada (juegos, mapas, ...) se comporta como el OnDemand; mientras que si la GPU está desocupada (idle) o poco ocupada este gobernador limita la frecuencia máxima, dependiendo de la tabla de frecuencias disponibles en nuestra configuración, e incluso llega a apagar un núcleo para así ahorrar batería. A este modo se le denomina "modo de navegación"

La decisión de un aumento de frecuencia se basa en el tiempo desocupado de la CPU: un tiempo ocioso bajo (<20%) de la CPU ocasionará un escalado hacia arriba desde la frecuencia actual. Los escalados hacia abajo se producen en pasos equivalentes al 5% de la frecuencia máxima.

En resumen, este es un Ondemand Inteligente que entra en Modo Navegación cuando la GPU está al ralentí y (saliendo del Modo Navegación) se comporta como OnDemand cuando la GPU está ocupada para poder ofrecer buen rendimiento en juegos y demás.




GOBERNADOR LAZY

Este gobernador de Ezekeel es básicamente un OnDemand con un parámetro adicional (min_time_state) que especifica un tiempo mínimo en el que la CPU permanecerá en una frecuencia antes de cambiar a otra (de ahí lo de lazy = perezoso). El gobernador Lazy permite tomar muestras de la carga de la CPU con mayor frecuencia (con la consiguiente mayor flexibilidad y mejora en la respuesta) pero sólo cambia de frecuencia después de completar el tiempo mínimo establecido, eliminando las inestabilidades que originan los cambios rápidos de frecuencias en el gobernador OnDemand.
Lazy tiene también otro parámetro característico: screenoff_maxfreq. Cuando está activado hace que el gobernador seleccione siempre la máxima frecuencia cuando la pantalla este apagada.




GOBERNADOR LAGFREE

Lagfree es muy similar a OnDemand. La principal diferencia es que el gobernador Lagfree está optimizado para reducir el consumo de batería. Las frecuencia de la CPU sube y baja con suavidad, a diferencia del OnDemand que salta a la frecuencia máxima demasiado a menudo.

Lagfree también es similar al SmartassV2 pero, en vez de basado en Interactive como éste, basado en Conservative: cuando el dispositivo se despierta salta directamente a una frecuencia de CPU determinada y a partir de ese momento se comporta de manera similar al Conservative. Lagfree no se salta ningún paso de frecuencia cuando escala arriba o abajo. Hay que tener en cuenta por ello, que si se produce una necesidad repentina de potencia, lagfree no la podrá proporcionar, ya que tiene que escalar desde la frecuencia actual a la máxima a través de todos los pasos intermedios. Además se ha observado que la bajada de frecuencias también se produce de una forma bastante lenta (le lleva más de un segundo el paso de una frecuencia a otra)

De esta forma, se puede concluir que este gobernador reduce el lag despues del encendido de la pantalla mejorando la experiencia en este sentido, pero luego es lento a la hora de seguir escalando frecuencias hacia arriba después de ese salto inicial y muy lento para escalar frecuencias hacia abajo.

Algunos usuarios informan de que la reproducción de video da algún tirón con este gobernador.




GOBERNADOR HYPER

El gobernador HYPER (en sus primeras fases menos avanzadas conocido como hyper) es un gobernador agresivo, inteligente y suave. Está optimizado para SGS2. Dispone de un montón de parámetros ajustables, basados en el gobernador OnDemand y OnDemandX.






Tu Kernel y tú: kernel, gobernadores y schedulers

[YossYGalaxy]

PARÁMETROS ONDEMAND

down_differencial: es un factor utilizado para calcular de forma indirecta el escalado hacia abajo del gobernador OnDemand. Se introduce básicamente para evitar que en algunos casos se produzca un efecto ping-pong de escalados abajo-arriba con el consiguiente aumento de consumo. Este parámetro actúa como un factor que previene escalados demasiado agresivos hacia frecuencias bajas.
Los valores que puede tomar este parámetro son enteros positivos. Los valores más altos retrasarán el escalado hacia abajo. Normalmente no son necesarios estos valores altos ya que por la estructura del algoritmo en que interviene este parámetro ya se producen varios redondeos al alza que hacen que la CPU normalmente esté "sobrada" utilizando este gobernador.

freq_responsiveness: es la frecuencia de respuesta. Cuando la frecuencia está por debajo de la frecuencia de respuesta, el valor de "up_threshold" será el mismo que el establecido para "up_threshold_min_freq" y en caso de escalado se saltará a este valor sin pasar por los valores intermedios.

freq_step: define cuanto (en % de la máxima velocidad de la CPU) incrementará o disminuirá el gobernador la velocidad de la CPU cada vez que la carga de la CPU llega a un umbral. De este modo el valor 0 bloqueará la CPU a una velocidad independientemente de la carga mientras que 100 es el valor adecuado para un gobernador OnDemand.

freq_step_suspend: sustituye al anterior parámetro cuando la pantalla está apagada.

io_is_busy: este parámetro tiene que ver con el comportamiento y la reacción cuando la pantalla está apagada. Un valor 1 puede resultar beneficioso para una reacción más rápida pero puede causar aumento en la frecuencia.***No he podido concretar más***

ignore_nice_load: si este valor es 1 el sistema no tendrá en cuenta los "procesos con prioridad alterada por nice" para cambiar la velocidad del procesador: será útil activar esta opción si no importa el tiempo que se tarden en completar estos procesos. ***Ahora habría que saber cuáles son estos procesos con prioridad alterada***

powersave_bias: modifica el comportamiento del gobernador OnDemand para ahorrar más energía al reducir la frecuencia de destino en un porcentaje especificado. El valor 0 proporciona la mejor relación entre el rendimiento y el consumo energético. Si se quiere primar la eficiencia energética introduciento un valor distinto el gobernador reducirá la frecuencia objetivo en un porcentaje de 1/10 del valor asignado.
Por ejemplo si el gobernador elige una frecuencia objetivo de 2 GHz y power_bias=100 el gobernador solicitará sólo 1,8 GHz. Una mejor alternativa en la mayoría de los casos sería simplemente hacer underclock (aunque no sea exactamente lo mismo).

sampling_down_factor: este valor actúa como multiplicador inverso para reducir la frecuencia de muestreo de utilización de la CPU (sampling_rate) cuando el procesador está realmente ocupado y está a la frecuencia máxima. Por ejemplo sampling_rate=10.000 con sampling_down_factor=2: el scheduler tomará muestras de utilización de la CPU cada 20.000 microsegundos. De esta forma se aumenta el tiempo que la CPU está a frecuencias altas cuando está realmente ocupada. Esto mejora el rendimiento mediante la reducción de los gastos generales de la evaluación de la carga y ayudando a la CPU permanecer en su frecuencia más alta cuando está ocupada, en vez de producir un efecto ping-pong en la velocidad. Este parámetro no tiene ningún efecto sobre el comportamiento a bajas frecuencias y bajas cargas de CPU.
Los valores que puede tomar este parámetro son enteros positivos. El valor 1 hace que no haya diferencias de muestreo a frecuencia maxima.

sampling_factor_suspend: sustituye al anterior parámetro cuando la pantalla está apagada.

sampling_rate: frecuencia de muestreo en microsegundos.

sampling_rate_min: establece una frecuencia de muestreo minima.

up_threshold: cuando la carga de la CPU llega a este punto, la frecuencia de la CPU escalará hacia arriba. Está medido en porcentaje de 1 a 100. Mayor valor significa menos capacidad de respuesta y valores más bajos corresponden a mejor respuesta repercutiendo en el gasto de la batería.

up_threshold_min_freq: este será el umbral de escalado cuando la CPU esté a la mínima frecuencia. Será muy bajo para lograr un escalado rápido hasta que se alcance el valor que se haya establecido para la frecuencia de respuesta (freq_responsiveness). Este valor se alcanzará saltándose todos los pasos intermedios que haya.

up_threshold_suspend: sustituye al umbral de escalado hacia arriba (up_threshold) en el caso de que la pantalla esté apagada.

[YossYGalaxy]

TWEAKS ONDEMAND


BATERÍA
up_threshold: 95
sampling_rate: 120000
sampling_down_factor: 1
down_differential: 5


RENDIMIENTO
up_threshold: 70
sampling_rate: 50000
sampling_down_factor: 2
down_differential: 15

[raffles496]

Gracias por la información es muy útil.
Saludos desde México. B-)