Kernel: Parte fundamental de un programa, por lo general de un
sistema operativo, que reside en
memoria todo el tiempo y que provee los servicios básicos. Es la parte del
sistema operativo que está más
cerca de la
máquina y puede
activar el
hardware directamente o unirse a otra capa de
software que maneja el hardware.
Son dos diferentes maneras en que la CPU del movil programa sus actividades
CFS: Completly Fair Scheduler o síndrome de fatiga crónica. Este es el valor de planificación de Linux, como su nombre indica se trata de dar el maximo equilibrio para cada proceso que se ejecuta en el movil, y que tratará de dedicar el mismo porcentaje de CPU a cada proceso. Cuando un proceso necesita mas CPU que los otros en el movil, el núcleo del kernel tratara de compensar la diferencia, dedicando más energía a otros procesos.
En general, más consistente, se usa cuando se desea un rendimiento constante o que los núcleos de BFS no funcionan bien en el movil. Puede ir más suave que un núcleo de BFS en el uso general. HTC utiliza como nucleo CFS habitualmente ya que es más estable que la BFS.
El CFS es más adecuado para la multitarea. Se puede experimentar problemas de rendimiento cuando se utilizan actividades pesadas de la CPU como juegos de alta definición, ya que está tratando de mantener los otros procesos en el fondo igual a la que está acaparando la CPU que seria el juego. Estaria diseñado el núcleo del kernel para manejar el escuchar música a pasar a enviar un SMS , y seguido navegar por la web con un desfase mínimo entre tareas.
BFS: controla los procesos de manera diferente. En lugar de tratar cada tarea al mismo nivel y tratar de dedicar un porcentaje igual de CPU a cada proceso le dará al proceso en primer plano una prioridad mucho mayor. Y tampoco intenta compensar otros procesos después de darles el uso igualitario de la CPU.
Por lo general un poco más rápido, pero algo mas inconsistente . El rendimiento general es más rápido , pero no ira tan suave como el nucleo CFS
Otra forma de decirlo, el CFS es más cercano a una línea plana, si se dibujara un mapa de rendimiento el CFS tendría menos cumbres y más consistencia. Con BFS, habría picos más altos con las lecturas más rápidas y reducir hasta crestas mas bajas con lecturas mas lentas
Con BFS se obtienen mejores resultados en el proceso intensivo de la CPU, lo que normalmente hace que tenga mayores puntuaciones de referencia (el famoso benchmark). Sin embargo, ya que sólo dedica el mínimo de la CPU a los procesos de fondo podria experimentar retraso al cambiar rápidamente entre las diferentes tareas. Estaria mas dedicado a mantener el juego en alta definicion que los otros procesos que haya en segundo plano por ejemplo, eso si el juego deberia ir como un cohete.
SVS - Escala de tensión estática. El Núcleo de HTC por defecto es la SVS.
Escala de tensión estática ses que cada frecuencia de la CPU usa un conjunto, cantidad predefinida de energia para mantener esa frecuencia. Cuanto mayor sean los MHz, y cuanto mayor sean los mV, mas energia se utiliza.
En esencia, la SVS usa una tabla de donde x = frecuencia de voltaje Y
Por ejemplo, la tabla VDD un núcleo SVS puede tener este aspecto:
128MHz=950mV
245MHz=975mV
384MHz=1000mV
----------------
998MHz=1300MHz Aqui se ve que cuanto mas Mhz , mas mV y mas gasto
HAVS - Escala híbrido de tensión adaptativa
HAVS no es un valor conjunto de VDD para cada frecuencia. Por el contrario, utiliza una amplia serie. Esto significa que la frecuencia de voltaje x = yz, en función de un elemento de tercera - la temperatura.
La tabla VDD puede tener este aspecto:
código:
= 128MHz 875-950mV
= 245MHz 900-975mV
= 384MHz 950-1000mV
----------------
998MHz = 1225-1300MHz
Dado que la serie se inicia mas bajo en HAVS que con SVS, bajo ciertas circunstancias, los mV será menor, lo que hace de HAVS tener el potencial para tener un mejor consumo de batería.
Básicamente cambia el voltaje del movil a fin de que la vida de la batería dure.
2WAY: Permite grabar llamadas
NO2WAY: No permite grabar llamadas
GOVERNORS
Performance
El regulador de rendimiento esta incrustado en el núcleo y hace que el procesador funcionen a la máxima velocidad de reloj sin importar la carga de trabajo, situa la velocidad mas alta entre los limites de scaling_main_freq y scaling_max_freq
Ondemand
Incrementa/Reduce dinámicamente la velocidad de reloj de la UCP dependiendo de la carga del sistema, configura la frecuencia en funcion de la velocidad, para esto el procesador debe ser capaz de cambiar de frecuencia rapidamente.
Conservative
Similar a ondemand, pero más conservador (los cambios de velocidad son más suaves), este governor, como el ondemand escala la velocidad dependiendo de uso actual. Se diferencia en que su comportamiento configura el procesador de forma mas uniforme en lugar de saltar al valor maximo cuando hay alguna carga. Este comportamiento permite un mayor ahorro de bateria.
Powersave
Hacer funcionar el procesador a la velocidad mínima, lo contrario que performance y lo configura a scaling_main_freq.
Da prioridad a las frecuencias bajas, de forma que la aplicación cambiará a la mínima frecuencia posible en base a la necesidad. Es el mejor si queremos ahorrar algo de batería. Pero este Scaling conserva casi todo el tiempo la frecuencia más baja, por lo que normalmente no será válido para usarlo como Scaling por defecto.
Userspace
Velocidades de reloj configuradas manualmente por el usuario
Interactive
Este governor esta diseñado para cargas de trabajo sensibles a la latencia
(Latencia: lapso necesario para que un paquete de información viaje desde la fuente hasta su destino, una baja latencia es que que el tiempo de respuesta ante una peticion es muy baja por lo que aumenta el rendimiento)
Este kernel responde mejor a la necesidad de acelerar la CPU cuando es necesario.
Tiene saltos de frecuencias mas estables y obtiene muestreos de carga mas consistentes.
Alta prioridad para aumentar la frecuencia de carga.
Interactive-X
Versión modificada del interactive con sleep + código de raíz . Puede trabajar por debajo de los 300 mhz , lo que hace es reducir en reposo su frecuencia al minimo, todo lo demas es lo mismo que el interactive, pero hace un mejor escalado al salir del reposo asi que tiene el mismo rendimiento del interactive pero mejor consumo de bateria
Smartass
Se basa en el concepto de el governor interactivo, pero su codigo fue reescrito y mejorado ademas de usar una especie de perfil en donde mantiene en Off la frecuencia minima (aunque puede ajustarse).
Permite establecer el máximo de frecuencia de la CPU cuando la pantalla está apagada (para ahorrar batería),
Permite establecer frecuencia a partir de la CPU cuando se despierta de teléfono (para acelerar el proceso de despertar),
Permite establecer / cambiar casi todos los aspectos del governor.
SmartassV2
Nuevo kernel da mas rendimiento, rápidez y estabilidad al equipo, es una versión mejorada de "smartass", como el smartass escala el procesador segun la carga de trabajo que tenga el aparato pero con mayor precision, y permite al CPU escalar todas las frecuencias desde la más baja a la más rápida dependiendo de lo que ocurra. Básicamente escalara de acuerdo a las necesidades reales del sistema, aunque incorpora una curva más agresiva para cuando entre/salga del reposo.
LightassV2
Es un nuevo governor, ideal para ahorrar batería, controla los procesos adecuadamente y ayuda a tener una mejor autonomía de batería.
Scary
Un nuevo governor escrito sobre la base de Conservative con algunas características de Smartass, utiliza la escala del governor Conservative. Por lo tanto, pasa la mayor parte de su tiempo a bajas frecuencias, tiene una curva de escalada más lenta que el “Ondemand” pero también tiene elementos del “Smartass” que contiene una velocidad de subida muy rápida. Consigue mejor vida de la batería con un rendimiento aceptable.
BrazilianWax
Muy similar al smartassV2 con un comportamiento mas agresivo por lo que tiene mas rendimiento pero menos ahorro de bateria
SavagedZen
Ajusta la frecuencia de sleep a 384 MHz sin tener en cuenta lo configurado, a excepción de "Userspace" no importa el gobernador que se establece, la CPU siempre se mantendrán dentro de los límites de las velocidades máxima y mínima que se establece, esta basado en el Smartass y con modificaciones para obtener mejor duración de batería y rendimiento, tiene mejor balance entre rendimiento y ahoro de bateria que el BrazilianWax
Min/max
Este governor trata de minimizar los saltos de frecuencia / cambios los cuales provocan los picos de tensión / cambios que agotan mas la bateria , seria una adaptación del governor “Conservative” pero con mejor rendimiento.
Smoothass
Es el intermedio entre Interactive y Smartass, es mas como el Smartass original pero connfigurado para un escalado más rápido, es decir más rendimiento y menos ahorro de batería.
Lagfree
Basado en el Ondemand y muy optimizado para el ahorro de bateria, la frecuencia del micro va subiendo y bajando progresivamnete en vez de saltar directamente a la maxima frecuencia cuando es requerida
Lazy
Al parecer es una variante del Ondemand que hace saltos de frecuencia mas lentos (un parámetro adicional 'min_timeinstate' ) lo que permite algo de ahorro de batería (evitando que el procesador consuma ciclos con chequeos) y da estabilidad al correr aplicaciones como juegos y reproductores de audio y video.
Lulzactive
Basado en los governors Interactive y Smartass
Versión anterior de este governor: Cuando la carga de trabajo es mayor o igual al 60%, la frecuencia de la CPU sube a la escala siguiente, pero cuando la carga de trabajo es inferior al 60%, la escala de frecuencia de la CPU bja al paso inferior. Cuando la pantalla está apagada, la frecuencia está bloqueado a la frecuencia mínima de escala mundial.
Nueva versión de este governor: Aparecen tres parámetros configurables por el usuario: inc_cpu_load, pump_up_step, pump_down_step. A diferencia de la versión anterior, éste ofrece un mayor control para el usuario. Podemos establecer el umbral en el que gobernador decide escalar arriba/abajo. También podemos definir número de pasos de frecuencia para ser omitidos al escalar arriba y abajo
Intellidemand
Otro governor basado en ondemand. A diferencia de que algunos usuarios creen, este governor no es el reemplazo para el Daemon OC (Teniendo governors diferentes para sleep y awake). Intellidemand se comporta diferente según el uso GPU. Cuando GPU está realmente ocupado (juego, Gps etc) el intellidemand se comporta como ondemand. Cuando GPU 'funciona en vacío' (mejor dicho moderadamente ocupado), intellidemand limita la frecuencia máxima para un paso dependiendo de las frecuencias disponibles en tu dispositivo/kernel para ahorrar batería. Esto se llama modo de navegación. Podemos ver algunos 'rastros' del gobernador interactivo aquí. La decisión de escala de frecuencia es tomada basada durante el tiempo que funciona en vacío la CPU. Para resumir, esto es un Ondemand inteligente que entra en modo de navegación para limitar la frecuencia máxima cuando GPU al ralentí y (sale del modo de exploración) se comporta como ondemand cuando GPU no está ocupado; para ofrecer un rendimiento para juegos etc. Intellidemand no salta con mayor frecuencia cuando la pantalla está desactivada.
Sobre hacer overclock o underclock:
1- El problema de llevar frecuencia al máximo posible, hace que el celular se sobrecaliente y que el microprocesador falle y que provoque reinicios como mal menor, el calor es el peor enemigo de los componentes electrónicos sumado a que la batería dure muy poco.
2- Es conveniente poner los valores máximo y mínimo relativamente cerca entre ellos , porque sino el móvil al encender la pantalla hace que la frecuencia del procesador escale del mínimo a un valor cercano del máximo de frecuencia rápidamente, haciendo que se gaste mucha batería en el proceso, y posibilidades de que se produzcan lags.
3- Sobre el "Set on boot" o "Aplicar al arranque" sirve para volver a los valores que modificaste cuando reinicias el móvil. No es recomendable seleccionar esa opción cuando estén haciendo pruebas y aun no se ha encontrado una estabilidad ideal, porque si por ejemplo aumentamos mucho la frecuencia y se producen reinicios , si se tiene marcado el Set on boot se seguiría teniendo problemas al reiniciar el móvil y quizás no lo puedas desactivar al entrar en la rom, por eso es conveniente marcarlo después de comprobar que el governor con sus nuevas frecuencias van bien.
4- No es recomendable usar los "profiles" o "Perfiles" ya que es mejor que los Governors administren el modo de uso de las frecuencias , a no ser que el usuario tenga un gran control y conocimiento en el uso de los "perfiles".
5- Sobre mejores governors On demand y SmartassV2 tienen buen equilibrio entre rendimiento y batería. Para obtener un rendimiento máximo usar performance, pero la batería durará menos.
Para conseguir que la batería dura más se puede usar el conservative o mejor el Powersave pero no podra el móvil trabajar al maximo, es recomendable para tareas que exijan poco.
6- Para cambiar el governor de un kernel o se hace desde la rom, o con aplicaciones que hay en el Googleplay como el SETCPU que es el más conocido
7- Sobre el governor a usar depende de lo que priorices: rendimiento o batería. La elección mas común sería un governor que tenga un equilibro entre las dos opciones.
8- Respecto a la eleccion de governors diferentes para el móvil encendido y apagado, a veces genera problemas para sacar el movil del estado de suspension o generar un "sleep of death" debido a que los governors trabajan con frecuencias diferentes por tener limitada la frecuenciencia maxima
9- En cuanto al tema de los lags si se coge un governor y se configura con frecuencias muy altas y bajas la velocidad del procesador subirá y bajará del máximo al mínimo constantemente, forzando al máximo la potencia del procesador para ganar en velocidad (pero generando más calentamiento y, potencialmente, más inestabilidad). Por el contrario, si optamos por governors tipo "smartass", "conservative" o "on demand" con frecuencias no tan extremas, obligaremos al procesador ira algo mas lento pero mas seguro y con más estabilidad.
10- Al elegir la frecuencia mínima el problema es que disminuirás el consumo de batería, pero quizás no consigas despertar el móvil al intentar sacarlo del estado de suspensión.
11- Sobre como tener una rom fluida teniendo cuidado que la batería aguante se puede usar un rango sobre los 460 a 998 mhz cuando la pantalla está encendida y uno de 245 mhz a 500 mhz más o menos cuando la pantalla está apagada. Usar un SmartassV2, On demand, o un conservative si se quiere priorizar algo más la batería.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Funcionamiento y características de los I/O Schedulers
Que son los I/O Schedulers:
I/O Schedulers
Estos son los organizadores de los comandos que salen y entran al kernel.
Cual es el próposito de los Schedulers?
1- Minimizar la latencia de busqueda en el disco
2- Priorizar los pedidos de I/O de los procesos (1° Plano, 2° Plano, etc)
3- Otorgar el ancho de banda suficiente para cada proceso
4- Garantizar que algunos pedidos sean resueltos antes de un tiempo maximo
Tipos de Schedulers:
1) Noop
Gestiona todas las peticiones siguiendo el método FIFO (First In First Out), es decir, las primeras en llegar son las primeras en ser atentidas. Lo mejor es usarlo con dispositivos de almacenamiento que no dependen de movimientos mecánicos para acceder a los datos como las memorias tradicionales. La ventaja aquí es que las unidades flash de los dispositivos 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.
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) CFQ
Completely Fair Queuing (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 dicen que el escaneo de medios tarda bastante en completarse usándolo. 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.
3) 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.
4) Deadline
Lo que busca es minimizar la latencia de I/O o la necesidad de una petición, el tiempo en ejecutar la petición. Se consigue mediante 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 para reducir la latencia de peticiones I/O.
El mejor planificador para acceder 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.
5) 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.
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).
COMENTARIOS
¿ Caul es el mejor Scheduler? No hay ninguno mejor que otro. Depende del que le de el usuario y las aplicaciones y tareas que tengas en ejecución. Lo mejor es probar los diferentes schedulers y ver el comportamiento del móvil. Sin embargo, considerando un rendimiento general, batería, fiabilidad y menos retardo, se piensa que primero SIO > Noop > Deadline > VR > BFQ > CFQ, considerando que todos los schedulers se puedan modificar y que el tipo de almacenamiento es una memoria flash.
Para cambiar los Scheduler , o se hacen desde la misma rom o con aplicaciones del GooglePlay como el Voltage Control.