08 septiembre 2015

La verdad sobre el Kernel y la duración de la batería

batería
Imagen de ElementalX
Cuando se trata de Kernels de Android, el tema de discusión en estos días es la vida de la batería. Pero hay muchos mitos en relación entre el núcleo y la vida de la batería. En un extremo, hay quienes hacen afirmaciones escandalosas acerca de los cambios radicales en la batería, horas de vida después de la instalación de un kernel. En el otro extremo están los que piensan que el núcleo no hace ninguna diferencia en absoluto en la vida de la batería. Y es que la verdad se encuentra en algún punto intermedio.
Antes de llegar a la "verdad" del asunto, quiero aclarar algunas cosas.
En primer lugar, el Kernel no drena la batería. Muchas veces, un usuario instala un kernel y luego informa poco después de que el kernel ha causado un gasto importante de la batería (y probablemente tiene sentido ya que el kernel no sirve y el desarrolador debe lamentarse por sus inútiles esfuerzos). Para demostrarlo, publican capturas de pantalla de aplicaciones de monitoreo de la batería que muestran el kernel como la principal fuente del drenaje de la batería. Esto es muy engañoso. En los dispositivos Android, el kernel proporciona un mecanismo para mantener el teléfono despierto, llamado wakelock. Los procesos que se ejecutan en el dispositivo (por ejemplo, aplicaciones y servicios) pueden pedir al kernel para un wakelock, y el cual está obligado a hacerlo. Así que sí, el núcleo técnicamente mantiene el teléfono despierto, por una aplicación o servicio que lo ha solicitado. Son estas aplicaciones y servicios que se portan mal y causan el consumo de la bateria, no el núcleo en sí.
Pero esto no quiere decir que el kernel no causa ningún gasto de la batería. Este trabaja y hace uso de la memoria, pero la cantidad de energía es muy pequeña en comparación con el sistema Android, aplicaciones y servicios. También hay casos especiales de hardware, tales como la función sweep2wake en el Nexus 5, que exige que el panel LCD permanezca encendido con el fin de trabajar. Esto drena más la batería que, si el dispositivo se encuentra en suspende con normalidad, pero aún así no causa un gasto excesivo  En el Nexus 5, sweep2wake añade más o menos 2% de drenaje en comparación si la pantalla se encuentra apagada. Debido a esto, hay un fuerte mito, alegando que sweep2wake y doubletap2wake es la causa de la descarga de la batería. En la gran mayoría de los dispositivos, excepto Nexus 5, el consumo de la batería de sweep2wake es insignificante, por lo general algo entre cero y 0,5% por hora, lo que haría un "costo" no más del 5% de uso de la batería en el transcurso de un día de trabajo. Una disyuntiva perfectamente aceptable para la comodidad.
La segunda cosa que quiero aclarar es ¿Cómo medimos la duración de la batería? Veamos el uso porcentaje por hora. Muchas aplicaciones de monitoreo de la batería puede dar esta estadística, pero hay que prestar mucha atención y establecer puntos de tiempo personalizados si quieres distinguir las estadísticas y realmente entender el uso de la batería. Si usted quiere medir y comparar, asegúrese de que lo hace en condiciones similares. Y debe hacerlo en un período de tiempo razonable, lo que significa días en lugar de horas. Si usted tiene algunas rutinas en los que utilice las mismas aplicaciones todos los días, esto sería una buena manera de probar y comparar. El monitor de la batería en el EX Kernel Administrador proporciona automáticamente las dos estadísticas, ahora voy a hablar: drenaje inactivo y drenaje activo.
batmon
Drenaje en inactividad es la descarga de la batería mientras la pantalla está apagada. Durante ese momento, el teléfono pasa la mayor parte de su tiempo en "sueño profundo o hibernación". A veces, se despierta para hacer una tarea, como la sincronización de correo electrónico o la comprobación de actualizaciones. Estos serían ejemplos de los sistemas, aplicaciones o servicios que "pide" al kernel para mantenerse despiertos o activos mientras realizan sus tareas. Si todo funciona correctamente, cuando terminan, el dispositivo se vuelve a dormir o hibernar. El Drenaje de inactividad se debe medir más de varias horas para obtener una imagen precisa. Un buen momento para medirlo es durante la noche mientras usted no está utilizando su dispositivo. En la mayoría de los dispositivos, la fuga de inactividad varía de aproximadamente de 0,2% por hora a 0,8% por hora en una configuración de valores con las opciones por defecto (es decir, sin medidas de ahorro en lugar de la batería) en una conexión normal WiFi. En algunos dispositivos, los optimizadores del kernel pueden rebajar un poco estos números. Por lo general en un intervalo de 0,1% a 0,3% de mejora sobre el stock. Como ya se ha mencionado, a veces características de hardware como sweep2wake pueden comer hasta aproximadamente la misma cantidad. Así que como podemos ver, un núcleo ofrece relativamente pocas mejoras. Otro factor que influye en el drenaje es la conexión ociosa a la red, particularmente conexión celular (datos). Una mala señal a menudo se traducirá en un poco de drenaje extra. Pero esto no debe causar drenaje excesivo durante el reposo, y sobretodo hacer una diferencia. Debo añadir que muchas de las medidas de ahorro de batería hacen poca diferencia en este caso. Si el drenaje de la batería se trata de más de 1% por hora, mira tus aplicaciones y servicios. Habrá un gran lote de cambios que causan un poco de drenaje extra esto Sucede con normalidad.
Drenaje activo es la cantidad de batería usada mientras que la pantalla está encendida. Es decir, mientras que usted está utilizando el dispositivo. Drenaje activo es, obviamente, mucho mayor que la inactiva. El teléfono está encendido, la pantalla está encendida, y se está haciendo una tarea utilizando la CPU, GPU, memoria, modem, wifi, disco, etc. el drenaje activo varía bastante de un dispositivo a otro. Muchas veces escuchamos acerca de "tiempo de pantalla". El Drenaje activo, medido en % por hora se puede ver en el tiempo de pantalla encendida. Drenaje activo de 12,5% por hora es muy bueno y será igual a aproximadamente 8 horas de tiempo de pantalla. Drenaje del 25% por hora te llevará alrededor de 4 horas de tiempo de pantalla.
Tiempo de pantala (hora) = 100 / drenaje activo (% por hora)
Esto no toma en cuenta la pequeña cantidad de uso de la batería mientras la pantalla está apagada. Suponiendo que el drenaje de inactividad es de aproximadamente 0,6% por hora, se perdería alrededor del 6% en diez horas, o alrededor de 14% en un período de 24 horas. Puedes restar a partir de 100 en la ecuación anterior.
Ahora estamos llegando a la verdad del asunto. ¿Qué influye en el drenaje activo? Muchas cosas...
Conexión de red (especialmente celular) hace la diferencia. Señal pobre significa que tiene que trabajar más para transmitir y recibir datos. El tipo de aplicaciones que estes utilizando hace la diferencia. Ejemplo, con un juego la tarjeta gráfica se utilizará de manera intensiva provocando mayor consumo de la batería que leer algunos de correo electrónico. El punto es que lo que haces con el dispositivo tiene total influencia en la vida de la batería. En pocas palabras: el drenaje activo puede variar de un usuario a otro, incluso con el mismo dispositivo!
cputimes_dark
Sin embargo, hay una parte del núcleo que tiene una influencia significativa sobre el drenaje activo, y por lo tanto puede tener un gran impacto en la pantalla a tiempo. Este es el gobernador de la CPU. Es por esto que los desarrolladores del kernel pasan mucho tiempo retocando gobernadores. Se trata de la utilización de frecuencias, que se puede medir con una aplicación como CPU Times. El gobernador controla la escala de frecuencias del CPU de acuerdo a la carga del sistema. Mientras que no está ocupado, la CPU se quedará en su frecuencia más baja, utilizando menos energía. Cuando hay alguna tarea que hacer, las frecuencias del gobernador del CPU suben hasta la velocidad en que la tarea se pueda completar más rápido y el usuario puede disfrutar de una buena experiencia. Un buen gobernante es sensible, respondiendo rápidamente a los cambios en la carga del sistema, para evitar lags, sino también de volver rápidamente a la frecuencia más baja para ahorrar energía.
Hay una idea llamada "race to idle" lo que sugiere que el gobernador debe llegar de inmediato hasta la frecuencia más alta por lo que las tareas se pueden completar lo antes posible y, en consecuencia, la CPU se pueden volver más rápidamente a un estado de energía más bajo. Pero con los procesadores modernos, puede haber una diferencia de tiempo insignificante para completar una tarea utilizando la frecuencia más alta disponible en comparación con una frecuencia en algún lugar en el medio. En otras palabras, puede ser un desperdicio de energía la subida hasta la frecuencia más alta cuando una frecuencia algo inferior puede completar la tarea esencialmente de la misma cantidad de tiempo, y volver a un estado de inactividad. La mayor frecuencia utiliza más energía que la frecuencia moderada, y puede haber un ahorro de batería muy reales cuando esto se repite miles o millones de veces por día. El truco es encontrar frecuencias que son "lo suficientemente rápidas" para crear una sensación de mayor fluidez para el usuario, sin estar constantemente el aumento gradual de la frecuencia más alta. Es suficiente decir que los gobernadores se comportarán de manera diferente, y tienen diferentes características de uso de la batería. Por lo tanto, el núcleo realmente tiene un impacto en la vida de la batería.
Hay otros aspectos del kernel que impactan la vida de la batería también. La principal de ellas es la programación de tareas, sobre todo en el aspecto donde las tareas se asignan a un núcleo de la CPU u otro. Esto significa que un CPU puede ser "despertado" para realizar una tarea o tareas y pueden localizarse en el mismo núcleo. Otro es hotplugging. Hay un costo de energía para poner núcleos de CPU prendidos o apagados. En muchos dispositivos, se oye sobre los males de mpdecision, un binario de código cerrado de Qualcomm que controla hotplugging y con frecuencia incluye una función de "touchboost" que anula el gobernador de la CPU. Muchos kernels personalizados desactivan mpdecision e implementan un controlador de hotplugging personalizado. Mi propia prueba ha encontrado que mpdecision y su touchboosting excesiva generalmente no tienen un gran impacto en la vida de la batería, y he dejado activada en la mayoría de mis granos. En algunos dispositivos recientes, como el Nexus 6 y el HTC One m9, no hay conexión en caliente durante el uso normal. Todos los núcleos de la CPU están en línea. No se puede decir que la programación de tareas, hotplugging y touchboost no tienen ningún impacto en la vida de la bateríaCreo que el impacto de estas optimizaciones es más evidente en los dispositivos más antiguos que son menos eficiente de la energía y tienen baterías más pequeñas.
Voy a mencionar rápidamente en uno más tema que siempre surge en las discusiones de la vida de la batería: undervolting. Una vez más, undervolting probablemente marcó la diferencia más grande en los dispositivos más antiguos. Dispositivos lanzados en el último año o dos son, en mucho, más eficientes de la energía, algunos incluso tienen la sintonización fina automática y el escalamiento del voltaje. Recuerdo trabajar en dispositivos MSM8960 que utilizaron el mismo voltaje para cada frecuencia de la CPU. En un caso así, undervolting podría hacer una gran diferencia. Dispositivos recientes ejecutan con voltajes mucho más bajos dejando menos espacio para undervolting.
Mucho más podría decirse sobre este tema, pero el punto principal que quería hacer es que el kernel hace, de hecho, una diferencia en la vida de la batería, pero dicha diferencia no suele ser tan dramática como a algunos les gusta pensar. Desde la perspectiva del núcleo, el gobernador de la CPU tendrá el mayor impacto en la vida de la batería. Por último, si quieres juzgar la vida de la batería, adoptar un enfoque científico. Trate de usar las mismas condiciones al hacer comparaciones, medir cuidadosamente, y darle un poco de tiempo.

Fuente: ElementalX.org
Traducido por: Traductor de Google
Edición y Corrección: Luis Guerra