[hairam]

Originalmente Escrito por Broquen

Bueno, y como lo prometido es deuda, aquí están las capturas de anoche.

Las tres primeras son con slp (retocado, eso sí) y las segundas son con hyper. Las capturas son seguidas (bueno... consecutivas, mejor dicho. No son seguidas pq me llegó algún whatsapp y tuve que volver a empezar el bench después de responder)

[/spoiler]

Los valores (en pruebas, de hecho no sería una buena combinación aún pq tengo que afinar más el consumo) los llevo así:

[spoiler]


Ya lo he dicho más de una vez, pero lo que ando buscando es rendimiento, que quede claro. Poniendo el perfil equilibrado del Apolo se conseguiría algo más de batería. Lo digo pq si alguien NO busca más rendimiento que NO pruebe a poner estos parámetros.

Y aunque ya hay algún hilo por xda y por aquí (hay uno muy bueno de @YossYGalaxy) que hablan de estos parámetros, hay cosas que no aparecen o la explicación es demasiado técnica (aparte de que salvo el hilo de yossi, casi toda la información buena está en inglés), por lo que intentaré explicar lo que es cada parámetro de la forma más sencilla que sea capaz (centrándome en slp, hay otros parámetros en otros gobernadores pero no los voy a explicar todos por tiempo y por no repetir).


Parámetros del gobernador slp:

(Click para mostrar/ocultar)

Lo primero que hay que tener en cuenta, aunque la mayoría ya lo sabréis, es que un procesador no trabaja siempre a la misma frecuencia. La frecuencia a la que está en un momento dado o cómo sube o baja se puede "configurar".
Con estos valores lo que hacemos es variar el comportamiento del procesador y básicamente (y para andar por casa) será más ágil o menos, consumirá más o menos, etc. en función de lo que especifiquemos aquí.
Como ya he dicho voy intentar explicar un poco los parámetros que se pueden tocar en slp con el Configurador Apolo pq es lo que uso yo (aunque se puede hacer de más formas, como a través de scripts). Hay otros buenos gobernadores dependiendo de las necesidades de cada persona, pero en mi caso busco fluidez máxima sin derrochar demasiada batería. Me gusta que el teléfono sea rápido a 200MHz y a 1200MHz y el gobernador que más me gusta por agilidad y consumo es slp.

• up_threshold: Es lo "cargado" que tiene que estar el procesador para poder subir de frecuencia (un 95% significa que hasta que el procesador no esté "cargado" de trabajo al 95% no subirá a la siguiente frecuencia).
• up_th_at_min_frq: Lo mismo que lo anterior, pero sólo para cuando se encuentra en la frecuencia mínima (en este caso normalmente 200MHz). Este valor es clave en slp, ya que permite tener más agilidad cuando el teléfono parte del reposo al permitir subir antes y además puede evitar lags.
• freq_step: Cuando el procesador sube de frecuencia (alcanza el up_threshold o el up_at_min_frq) este valor le dice cuánto debe subir (en porcentaje de la velocidad máxima). Por ejemplo, si ponemos un 10 y nuestra frecuencia máxima es 1200MHz, cuando tenga que subir, lo hará en saltos de 120MHz (10% de 1200MHz).
• sampling_down_factor: Es un multiplicador que aumenta el tiempo que pasa entre muestreo y muestreo del scheduler, de forma que no tome la decisión de bajar demasiado rápidamente cuando el procesador está a frecuencias altas.
• hotplug_freq_1_1: Valor al que se encenderá el segundo núcleo (aunque está condicionado por más factores).
• hotplug_freq_2_0: Lo mismo que antes, pero para apagar el segundo núcleo.
• cpu_up_rate: Antes de subir de frecuencia, este número indica la cantidad de veces que se comprueban las condiciones, dando más estabilidad a la CPU y evitando que suba, por ejemplo, por un pico de trabajo puntual.
• cpu_down_rate: Lo mismo pero "pabajo"
• sampling_rate: Es la cantidad (en microsegundos) de tiempo que pasa entre medición y medición a la hora de calcular si se suben o se bajan frecuencias.
• down_differential: Este factor se utiliza para calcular la bajada de frecuencia cuando disminuye la carga del procesador desde la frecuencia máxima (después de pasar el resultado de multiplicar sampling_down_factor por el sampling_rate en microsegundos). Lo que se intenta conseguir es una bajada de frecuencia eficiente pero no demasiado brusca, para que el procesador no tenga que volver a subir de nuevo enseguida (por ejemplo, si cerramos un juego en el que el procesador estaba trabajando a 1200MHz y nos ponemos a mirar la galería de fotos -para lo que vamos a suponer, se necesitaría que la CPU trabajase a 500MHz- este factor se encarga intentar "predecir" esos 500MHz de forma que no tenga que bajar a 200MHz para después tener que volver a subir enseguida evitando trabajo, lags, y más cálculos).
• sampling_rate_min: Mínimo en microsegundos para volver a efectuar un muestreo.
• ignore_nice_load: Ignora la carga que provocan los procesos de baja prioridad para el scheduler a la hora de tomar decisiones. Es decir, estos procesos suelen estar en segudo plano y se deja de lado que tarden más o menos tiempo en completarse, por eso no interesa que hagan subir la frecuencia del procesador por ellos mismos.

Y bueno... Después del tochacoquetecagas, allá cada cuál si os metéis a tocar estas cosas. Lo que no os podré decir ni yo ni nadie es "cambia esto así o asá para ganar batería o rendimiento", ya que cada parámetro tiene su lógica pero también depende, en muchos casos, de los valores de alguno de los otros parámetros. Lo normal es ir probando poco a poco, cambiando una cosa cada vez (y aún así es muy difícil de medir la mayoría de las veces).
He intentado ser claro y hablar para que todo el mundo lo pueda entender, pero es inevitable que haya definiciones o conceptos algo densos. En todo caso espero que alguien encuentre algún interés en tanta información "técnica".

Ahora si, que veo mas cerca la "despedida". Un trabajo para recordar