[ IDEA ] [cpu, i/o, gpu, tcp, hotplug, thermal, etc...]

[moludo]

Antes de nada decir que aun esta en proceso, y que aun hay cosas tanto por traducir como por mejorar, espero que tengais paciencia....muchas gracias!!

El objetivo de este hilo es aprender un poco más acerca de la configuración de los kernels y de sus parámetros.

Si queréis ver perfiles pasaros por este otro Hilo!!!

Viendo que por estos lugares no tenemos nada referente a las configuraciones de los diferentes governos que vienen en los kernels, me he decidido a terminar con esto y que todo el mundo pueda tener una noción básica al respecto.

Fuentes:
http://www.htcmania.com/showthread.php?t=360366
http://androidmodguide.blogspot.com.es

El hilo está dividido en tres partes (desde aquí se puede ir a cualquiera de ellas):
Governors (post actual)
-Definicion
-Comparativa
-Graficas

2.I/O Schedulers(2º post)
-Definicion
-Comparativa
-Graficas
3.Parámetros y ajustes (3er post)
4. Mas configuraciones del Kernel(4º Post)
-Hotplugin drivers
-Gpu Governors
-TCP Algoritms
-Gestor Termico
-ToolChains Etc...

No pretende ser un tutorial, ni un hilo en el que preguntar qué es un governor o un scheduler o para cómo se configura un kernel, etc. Simplemente es una guía para entender y tener claros algunos de los parámetros que nos brindan los kernels para poder configurarlos a nuestros gusto y exprimir al máximo el potencial de los mismos, y de nuestros teléfonos.


GOVERNORS

¿Qué son los governors?

Los governors son 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 OPO por defecto es de 2.5GHz) para sacar todo el rendimiento de nuestro "bicharraco", las intermedias (2.2, 1.9,1.7,1.5,1.4ghz etc...) o cuándo trabajar al mínimo (300Mhz).

Primeramente vamos a hablar de los governors más conocidos, los que suelen incluir la mayoría de los kernels. Un kernel no tiene por que incluir todos estos, eso depende del desarrollador. Son los siguientes:

1. OnDemand
2. OndemandX
3. Performance
4. Powersave
5. Conservative
6. Userspace
7. Min Max
8. Interactive
9. InteractiveX
10. Smartass
11. SmartassV2
12. Scary
13. Lagfree
14. Smoothass
15. Brazilianwax
16. SavagedZen
17. Lazy
18. Lionheart
19. LionheartX
20. Intellidemand
21. Hotplug
22. Wheatley
23. Lulzactive
24. AbyssPlug
25. BadAss
26. Pegasusq
27. LightassV2
28. HotplugX
29. MSM DCVS
30. Intelliactive
31. Adaptive
32. Nightmare
33. ZZmove
34. Sleepy
35. Hyper
36. SmartassH3
37. SLP
38. NeoX
39. ZZmanX
40. OndemandPlus
41. DynInteractive
42. Smartmax
43. Ktoonservative\KtoonservativeQ
44. Performance may cry (PMC)
45. Dance Dance
46. AbyssPlugv2
47. IntelliMM
48. InteractivePro
49. Slim
50. Ondemand EPS
51. Smartmax EPS
52. Uberdemand
53. Yankactive
54. Impulse
55. Bacon
56. Optimax
57. Preservative
58. Touchdemand
59. ElementalX
60. Bioshock
61. Bluactive
62. Umbrella_core
63. ConservativeX
64. Hyrdxq
65. DevilQ
66. Yankasusq
67. Darkness
68. Alucard
69. Hellsactive
70. Ragingmolasses
71. Virtuous
72. Sakuractive
73. InteractiveX v2
74. Alessa
75. GallimaufryX
76. AggressiveX
77. Tripndroid
78. Wrexy
79. Xperience
80. Stockdemand

(Click para mostrar/ocultar)

1) Ondemand

Es el governor por defecto en la mayoría de los kernels stock. Uno de los objetivos principales del Ondemand es que cambia a la máxima frecuencia tan pronto como haya actividad en la CPU para asegurar la capacidad de respuesta del sistema, para que se entienda funciona en plan “lo importante es el rendimiento aquí y ahora”. Por lo tanto, escala a la máxima frecuencia cuando la CPU está trabajando y decrece gradualmente cuando la CPU se va quedando más libre. A pesar de que muchos consideran Ondemand como un governor fiable, se queda a mitad de camino entre ofrecer un buen rendimiento del teléfono y un ahorro de batería.


2) Ondemandx

Este governor se supone que es mejor que el Ondenand en cuanto a gasto de batería. Cuando la pantalla está apagada, la frecuencia máxima está limitada a 500 mhz. Aunque Ondemand es el governor por defecto en varios kernels y es considerado como seguro y estable, el soporte para Ondemand/OndemandX depende de la capacidad de la CPU para hacer rápidas variaciones de frecuencia.


3) Performance

Ajusta la mínima frecuencia a la máxima frecuencia. ¡Úsalo mientras haces un benchmarking! :P

4) Powersave

Bloquea la frecuencia máxima a la mínima frecuencia. No se puede usar como un perfil de pantalla encendida o incluso apagada si la frecuencia mínima es demasiado baja.


5) Conservative

Es un Ondemand más lento que escala frecuencias más lentamente para ahorrar batería. Funciona como aquel, al ajustar dinámicamente las frecuencias según la utilización del procesador. Sin embargo, el Conservative aumenta y disminuye la velocidad de la CPU más gradualmente. Más fácil de entender, este governor aumenta la frecuencia de la CPU paso por paso (100mhz>200mhz>400mhz>etc), y salta a la frecuencia más baja cuando la CPU entra en idle (1000mhz>100mhz).

6)Userspace

En lugar de determinar automáticamente las freuencias, deja a los usuarios elegirlas.


7)Min Max Governor

Bien, este governor hace que el procesador tan solo trabaje en la minima op en la mas alta frecuencia, no utiliza frecuencias intermedias.


8) Interactive

Se puede considerar con un Ondemand rápido. Al ser más rápido gasta más batería. Tiene las siguientes ventajas:
Escala frecuencias de manera más consistente, debido a que los otros governors hacen su muestreo de carga de la CPU en un contexto de espera (primero uno, hasta que no acabe con ese no pasa el siguiente), pero el Interactive asigna unos tiempos a cada muestreo haciéndolo más consistente.
Mayor prioridad para el incremento de frecuencia de la CPU, dando así un mayor beneficio al incremento de rendimiento.


9) Interactivex

Es un Interactive con un perfil de arranque. Más ahorro de la batería que el Interactive.


10) Smartass

Es el governor resultante de que Erasmux reescribiese completamente el código del Interactive. El principal objetivo es optimizar la duración de la batería sin comprometer el rendimiento. Aun así, el gasto de batería es algo mayor que el SmartassV2 dado que la frecuencia mínima con la pantalla encendida es mayor que las frecuencias utilizadas con la pantalla apagada. Salta a la máxima frecuencia en intervalos de tiempo muy cortos, y esta operación la repite continuamente.


11) SmartassV2

Es la Versión 2 del Smartass original de Erasmux. Otro de los favoritos de mucha gente. El objetivo de este governor es el de utilizar la frecuencia ideal, y subir de forma bastante agresiva hasta esa frecuencia, para después bajar más suavemente. Usa diferentes frecuencias ideales para perfiles de pantalla apagada/encendida, llamados awake_ideal_freq y sleep_ideal_freq. Este governor baja de frecuencia de CPU muy rápidamente (para alcanzar cuanto antes la sleep_ideal_freq) mientras la pantalla está apagada, y sube de frecuencia de la CPU rápidamente hasta la awake_ideal_freq cuando la pantalla se enciende. No hay un límite superior de frecuencia mientras la pantalla está apagada (a diferencia del Smartass). Por lo tanto, el governor tiene disponible todo el rango entero de frecuencias para usarlas durante los estados de pantalla apagada/encendida. El lema de este governor es un equilibrio entre rendimiento y batería.


12)Scary Governor

Un nuevo governor basado en el conservative, pero con algunas caracteristicas del Smartass, pero se ajusta mas al conservative. Este governor , hace que con la pantalla pagada, reduzca las frecuencias hasta 120mhz, aunque tu telefono tenga como minima 300mhz, durante la pantalla apagada reducira esa frecuencia y rapidamenet cuando la enciendas volvera a la suya por defecto, por lo tanto es un governor que trata de mantener las frecuencias muy bajas, el objetivo de esto es tratar de conseguir unos mejores consumos, con un rendimiento bastante decente.


13) Lagfree

Lagfree es similar al Ondemand. La única diferencia es que no está optimizado para mejorar el gasto de batería. La frecuencia aumenta y disminuye suavemente, a diferencia del Ondemand. Lagfree no omite ningún escalón en la frecuencia mientras la aumenta o la disminuye. Hay que tener presente que si hay un requerimiento repentino de energía Lagfree no puede satisfacerlo ya que tiene que pasar por todas y cada una de las frecuencias. Algunos usuarios han reportado que la reproducción de vídeo usando Lagfree da algunos pequeños tirones.


14)Smoothass

Es lo mismo que es Smartass, pero MUCHO MAS agresivo a lo largo de todos los ambitos, lo que hace que tenga mejor duracion de bateria , y se puede llegar a aproximar hasta un tercio mas que con el kernel de stock


15)Brazilianwax

Parecido al smartassV2. Pero es mas agresivo en los cambios de frecuencia, lo que hace un mejor rendimiento , pero una peor autonomía.


16)SavagedZen

Es otro governor basado en el SmartassV2. Logra un buen equilibrio entre rendimiento y batería, en comparación con al Brazilianwax. Ajusta la frecuencia de sleep a 384 MHz sin tener en cuenta lo definido, 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 establecen.


17) Lazy

Este governor creado por Ezekeel es básicamente un Ondemand con unos parámetros adicionales min_time_state para especificar el tiempo mínimo que la CPU está en una frecuencia antes de subirla/bajarla. La idea es eliminar cualquier inestabilidad causada por el rápido cambio que usa Ondemand. Lazy también tiene un parámetro screenoff_mazfreq que cuando está activado hará que el governor siempre seleccione la máxima frecuencia cuando la pantalla está apagada.


18)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.


19)LionheartX

LionheartX esta basado en Lionheart, pero tiene algun que otro cambio en los valores ajustables y cuenta con un perfil de suspension basado en el governor Smartass.


20) Intellidemand
Intellidemand, o también conocido como Intelligent Ondemand es otro governor basado en el Ondemand. El Intellidemand original se comporta de manera diferente según el uso de la GPU. Cuando la GPU está realmente ocupada (por juegos, Maps, benchmarking, etc) Intellidemand se comporta como un Ondemand. Cuando la GPU está “idling” (al ralentí, por así decirlo), o no tan ocupada como antes, Intellidemand limita la frecuencia máxima en función de las frecuencias disponibles del dispositivo/kernel para ahorrar batería. Esto se denomina modo de navegación. Podemos apreciar aquí algunos aspectos del governor Interactive. La frecuencia con la que se toman las decisiones de escalar hacia arriba está basada en el tiempo de inactividad de la CPU. Un tiempo de inactividad bajo (<20%) hace que la CPU aumente la frecuencia actual. En resumen, se trata de un Ondemand inteligente que entra en el modo navegación para limintar la frecuencia máxima cuando la GPU entra en inactividad, y se comporta con un Ondemand cuando la GPU está ocupada para ofrecer rendimiento para juegos, por ejemplo. Intellidemand no salta a la frecuencia más alta cuando la pantalla está apagada.



21)Hotplug

El governor "Hotplug", escala las frecuencias de la cpu segun la carga del telefono, parecido a "Ondemand". Se amplia hasta la frecuencia mas alta cuando el “up_threshold” es sobrepasado, y reduce proporcionalmente cuando el “down_threshold” es sobrepasado. A diferencia de algunos governors, las frecuencias de destino se determinan accediendo directamente a la tabloa de frecuencias , en lugar de tomar un procentaje de la frecuencia maxima disponible.

La diferencia clave de este governor, es que desactivara las CPUs auxiliares cuando esten inactivas, y las reahabilirtara cuando sean necesarias. Esto se logra haciendo un promedio de carga en varios periodos de prueba. Si las CPUs estaban online o offline se basa tan solo en un periodo de prueba , asi no habra Hiperpaginacion. (Hiperpaginacion wiki)

Existen unas llamadas entrada SYSFS para "hotplug_in_sampling_periods" y para "hotplug_out_sampling_periods" que son las que hacen determinar si las cpus auxiliares deben estar online u offline. lo norma son de 5 a 20 periodos respectivamnete. De todas maneras tab encontraras entradas SYSFS estandar en los gvernors ondemand o conservative.

Obiamente, este governor tan solo estara disponible para telefonos con procesadores Multi-Core

22)Wheatley

En pocas palabras, este governor, esta basado en el "Ondemand", pero incrementa los tiempos de permanencia en el estado c4 de la cpu, y hace ahorrar mas bateria que el ondemand.


23)Lulzactive

Este gobernador de tegra, BAsicamente es como el governor "interactive" pero con algunas coass del "Smartass" y escala la frecuencia cuando la carga se incrementa por encima de un rango dado (60% en la versión original). Además, incluye un perfil de pantalla apagada.
Existe una versión modificada (LulzActiveQ) que incluye más parámetros de configuración.

24)Abyssplug

es una modificacion del Governor"Hotplug"


25)BadAss

BadAss elimina todas esas subidas rapidas a la maxima frecuencia. En un sistema tipico lo normal con badass es que no supere los 918mhz , y asi se mantiene frio y no consume mucha energia. PAra desencadenar un aumento de frecuencia el sistema debe ejecutar un bit a 918mhz con mucha carga de cpu, entonces la frecuencia se dispara a 1188mhz. Si esteo sige sin ser suficiente , el governor acelerara a tope. (esta transición no debería llevar más de 1-2 segundos , dependiendo de la carga de cpu que el sistema este experimentando). abdAss tambien considerara la carag de GPU. Si la GPu esta moderadamente ocupada omitira la priemra comprobacion y pasara a subir la frecuencia hasta 1188mhz directamente. Si la GPU esta a tope de carga , badASs deslimitara la CPU.


26)Pegasusq

Es un gobernador típico de dispositivos Samsung basado en OnDemand pero que es capaz de controlar el estado de los diferentes núcleos, procediendo a arrancarlos y pararlos automáticamente según convenga.


27)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. Lo ideal en este governor es usar las frecuencias Stock,


28) Hotplugx

Es una version modificada del governor Hotplug, esta optimizado para una mejor suspension con la pantalla apagada.

29: MSM DCVS

Una gama muy eficiente y amplia del reloj dinámico y escalas de Voltaje (DCVS) que aborda los modelos de uso de la espera activa a las necesidades medias y altas de nivel de procesado. Esto hace que la CPU del teléfono escale sin problemas las potencias bajas, de modo que va de menos a mas y rinde increíblemente rápido. Solo para ser utilizado por CPUs Qualcomm.MSM es el prefijo para el SOC (MSM8960) y DCVS es Reloj dinámico y Escalador de Voltaje. Tiene sentido, MSM- DCVS


30: IntelliActive

Basado en el governador de Google Interactive, con las siguientes mejoras:
1. Capacidad Auto-Boost para drivers de entrada(input), (No necesita asistente PowerHal)
2. Dos fases de programacion Al ralenti y ocupado, para prevenir los saltos directos ala mas alta frecuencia.
3. Comprueba las CPUs offline y cortocircuita algunos controles innecesarios para mejorar las rutas de ejecución de código . Por lo tanto , evita el Hotplugg CPU.

31: Adaptive

Este driver añade un governor con una politica de frecuencias dinamicas, diseñada para cargas de trabajo sensibles a la latencia y también para exigir rendimiento.
Este gobernador intenta reducir la latencia del reloj para que el sistema sea más sensible a las cargas de trabajo interactivas en bajo estado estacionario , pero para reducir el consumo de energía en el nivel de operación media, subir de nivel se llevará a cabo paso a paso para prohibirle al sistema ir a niveles de operaciónes máximas.


32:Nightmare

Un PegasusQ modificado, menos agresivo y mas estable. Un buen compromiso entre rendimiento y duracion de bateria. Además SoD es un programa de prevención , ya que por lo general no hace hotplug .

33: ZZmove

El governor ZZmove esta optimizado para un bajo consumo cuando la pantalla esta apagada, con particular atencion en limitaar los consumos de las apps en segundo plano cuando la pantalla esta apagada, porejmplo escuchando musica. ZZmoove no es un buen governor para jugar, se dedica a consevar bateria. Este governor esta en constante actualizacion y tiene muchos perfiles disponibles.

34: Sleepy

El governor Sleepy (conocido como "Solo") es un intento de lograr un buen equilibriio entre rendimiento y bateria. Esta basado en ondemand. Incluye algunos tweaks como la variable "down_sampling" y otras caracteristicas que se ajustan por el usuario. Sleepy es muy parecido al OndemanX.

35: Hyper

El governor Hyper(Conocido como el "Kenobi") es suave y agresivamente inteligente, esta basado en Ondemand y esta equipado con caracteristicas de los perfiles de suspension del OndemanX. Tiene la variable Fast_start_deep_sleep, y en modo de suspensión la frecuencia máxima es de 500mhz. Este governor esta mas orientado a la suavidad lo que quiere decir que es un buen governor para rendimiento, sin sacrificar mucho gasto de batería.

36: SmartassH3

El governor SmartassH3 esta designado para una buena duracion de bateria sin dejar de lado el rendimiento, haciendo unos buenos consumos,. Basado en SmartassV2. Esta programado para tener una mejor eficiencia en escalar las frecuencias( No sube hasta el máximo si no lo necesita) lo que potencialmente resulta en una mejor duración de batería.

37: SLP

Es una mezcla del PegasusQ y del ondemand. Por lo tanto, esta muy balanceado entre rendimiento y duracion de bateria.

38: NeoX

Una version optimizada del governor PegasusQ, pero con algunos tweaks extras para un mejor rendimiento. Esto significa un consumo mayor de bateria que el PegasusQ original.

39. ZZmanx

ZZManx es exactamente igual a ZZmove, pero se renombro porque DorimanX lo hizo en su version(Posiblememnte mayor rendimiento). De todas maneras, sigue sufriendo por denajo de el rendimiento ideal para juegos.

40. OnDemandPlus

Un governador basado en Ondemand e Interactive. Dota de un buen balance entre rendimiento y bateria.

41. DynInteractive

Un governor Interactive dinamico. Este gobernador se adapta dinámicamente, el tema es poseer frecuencias de la CPU dentro de sus parámetros basados ​​fuera de la carga del sistema.

42. Smartmax

Este es un nuevo governor mezcla entre ondemad y smartassv2. Por defecto esta configuarado para una buena duracion de bateria, por lo que no es un governor para jugar!

43. Ktoonservative\KtoonservativeQ

Una combinacion de Ondemand y conservative. Ktoonservative contiene un hotplug variable el cual determina cuando se enciende el segundo nucleo.El gobernador apaga el núcleo cuando se vuelve a la frecuencia de la segunda más baja de este modo nos da una manija en el segundo factor de rendimiento en nuestro comportamiento de la cpu.

44. Performance may cry (PMC)

Un governor basado en Smartmax excepto porque esta muy tubneado para una mejor duracion de la bateria. No es un governor para Jugar!!!

45. Dance Dance

BAsado en el governor Conservative , y con algunas caracteristicas del Smartass, escala acorde alas leyes del governor conservative. Asi que empezara desde abajo, cojera una muestra de la carga, si es por encima de la "upthreshold", subira tan solo una velocidad al momento, y bajara otra al momento. Capara automaticamnete la velocidad de Cpu con la pantalla pagada a 245mhz , si tu frecuencia minima es mayor, reseteara la frecuencia hasta 120mhz mientras la pantalla este apagada y la restaura cuando se despierta. osea que gasta la mayor parte de su tiempo en frecuencias bajas, la meta de esto es conseguir muy buenos resustados de nbateria sin deteriorar el rendimiento.

46. AbyssPlugv2

AbyssPlugV2 es un reescrito del Abyssplug original. Tiene arreglado el problema de que el governor solo ajustase el primer nucleo, pero ahora el governor controla todos los nucleos. Ha habido comentarios sobre la falta de estabilidad con este governor.

47. IntelliMM

Un reescrito sobre el antiguo governor MinMax, y tiene 3 fases de Cpu: Idle(Al relenti), Ui(carga media), Max(Al maximo). Ams o menos un Governor MinMax un poco mas inteligente.

48. Interactive Pro

Una nueva version modificada del governor Interactive que esta optimizada para telefonos como el OnePlusOne. Es mas eficiente que el interactive Original porque esta continuamente re-evaluando la carga de la CPu de ese modo permite a la Cpu escalar las frecuencias mas eficientemente.

49. Slim

Un nuevo governor que proviene del codigo de CM y del proyecto Slim. Un governor optimizado para el rendimiento. Encontrado en los telefonos mas nuevos como los OneplusOne. Si se detecta mucha actividad en la cpu este governr sera ideal para un buen rendimiento.

50. Ondemand EPS

Una vez más, una versión modificada de Ondemand y está optimizado para los nuevos dispositivos . Se basa en el semáforo Ondemand del kernel que se a optimizado para la vida de la batería y un mejor rendimiento que el ondemand tradicional.

51. Smartmax EPS

Un gobernador smartmax más reciente que se ha optimizado un poco para los nuevos dispositivos .

52. Uberdemand

Uberdemand es Ondemand con la característica de 2 fases que significa que tiene una capa suave a 1728 MHz para que la CPU no vaya directamente al máximo , hecho por Chet Kener

53. Yankactive

Un governor ligeramente modificado del "Interactive", hecho por Yank555.lu. Posiblemente mejor rendimiento que bateria.

54. Impulse

Una version mejorada del "Interactive" modificado por neobuddy89.Objetivo de tener un equilibrio entre la batería y rendimiento igual que "interactive" pero tiene algunos ajustes para ahorrar batería.

55. Bacon

Esto no es mas que un governor "interactive" pulido, denominado "Bacon", ya que es una adaptación del dispositivo bacon. Gracias a neobuddy89 . La mayoría de los ajustes son para el funcionamiento / mejoras de latencia

56. Optimax governor

Este se basa en ONDEMAND , como casi todos los gobernadores que han surgido de XDA . Contiene algunas mejoras desde LG , en particular el manejo de la freq, impulso por lo que aumentará a un nivel ajustado , casi como gobernador de HTC. tiene diferentes valores ajustables al gobernador HTC pero se comporta muy similar , los valores ajustables que viene con defecto son un poco más conservadores.
Lo cogí de kernel Uber de Cl3kener para Nexus 5 , donde cuenta con una gran reputación por la vida de la batería

57. Preservative governor

Esto se basa en la idea de que la CPU consumirá mucha energía cuando cambia la frecuencia. Se basa en el gobernador "conservative". La idea es que se quede en el paso especificado ( 702MHz seleccionado por el Bedalus creador)a menos que sea necesario. Notaras que ronda la freq 702 mucho, y que no va por encima demasiado, y sólo va a Frec min cuando No pasa nada en absoluto. Esto es muy beneficioso cuando usted está haciendo algo como leer, dejar la pantalla estatica o jugando a juegos muy ligeros que no necesitan mas rendimiento. El governor viene del nexus4.

58. Touchdemand

Touchdemand, esta bassado en Ondemand, pero esta modificado para el chipTegra3.(Solo Tablet). y tiene ajustes adicionales para la capacidad de respuesta de la pantalla táctil .

59. ElementalX

Si eres poseedor de un nexus, probablemente hayas oido hablar sobre el governor”ElementalX”. Lleva el nombre del kernel , elementalX se basa en “interactive” pero con algunos ajustes de rendimiento adicionales. Este gobernador se centra en el rendimiento y no en el ahorro de batería !

60. Bioshock

No es el juego, sino un governor hecho por Jamison904. Una mezcla entre “ConservativeX” y “LionHeart”. Mejor bateria y mas rendimiento!!

61. Blueactive

Un nuevo governor basado en “Interactive” con mejoras para la duracion de bateria. Este governor esta fuertemente centrado en hacer durar la bateria mientras rinde decentemente y hace un buen multitarea. No se recomienda para jugar.

62. Umbrella_core

Un nuevo governor basdo en “Interactive”, que se centra en la duracion de bateria y no en el rendimiento. Todavía se elevará a una frecuencia establecida , pero no se queda en las frecuencias altas por mucho tiempo. Los usuarios han informado comportamiento extraño con este gobernador

63. ConservativeX

Esencialmente, es una version menos agresiva del “Conservative”. Mas duracion de bateria , menos rendimiento.

64. HydrxQ

Simplemente un “Lulzactiveq” con tweaks para mejorar el rendimiento. (Gracias a tegrak)

65. DevilQ

Un “Pegasusq” agresivo , que mantiene el hotplug con un maximo de 2 nucleos hasta el offline.Este governor esta mejor optimizado para procesadores de cuatro nucleos.

66. YankasusQ

Yankasusq es otro “pegasusq” modificado pero incluye poder manejar las frecuencias con la pantalla apagada, y otras modificaciones, Posiblemente mejor duracion de bateria.

67. Darkness

Esta basado en “Nightmare” pero es mas simple y rapido, configuraciones basicas pero muy completo en estructura. Alucard actualizo “Nightmare” y consiguio mejorar la estabilidad. Hasta ahora muy estable en las pruebas.

68. Alucard

Una opcion muy recomendable, creado por Alucar_24.Por lo que se sobre el , es un governor basado en Intellidemand, de la familia de ondemand. Es un governor bastante equilibrado pero esta muy optimizado para conseguir una buena duracion de bateria sin perder rendimiento.

69. Hellsactive

Un gobernador intelliactive muy modificado por hellsgod que se ha ajustado para mejorar la vida de la batería . Hellsactive es menos agresivo en comparación con intelliactive por lo que la duración de la batería es más como el interactive original.

70. Ragingmolasses

Este governor, Ademas de tener un nombre increible es una mezcla entre el conservative y el ondemand, y las sclas de carga son tuneables. Esto significa que es un governor simple, rápido y eficiente manteniendo las frecuencias lejos de las mas altas si no son absolutamente necesarias. Incluye Gboost para una mejor experiencia con los juegos.


71. Virtuous

Establece su CPU máxima para cuando despierta y duerme, y cambia el gobernador cuando su dispositivo está despierto o dormido. Se ahorra batería reduciendo las frecuencias de la CPU mientras el dispositivo duerme, cuando se despierta automáticamente acelera de nuevo. O alternativamente se puede establecer la cpu. Se basa en smartassV2 (Utiliza 2 gobernadores, uno para dormir y otro para cuando esta despierto)

72. Sakuractive

Un hibrido agresivo de Ondemand y Hotplug, el cual parece que escala como ondemand, pero es un poco mas agresivo. Pero tiene acciones como las de Hotplug apagando nucleos.

73. InteractiveX v2

Diseñado por lmoseyon , el InteractiveX V2 se comporta como InteractiveX, y adicionalmente fuerza al nucleo 1 a mantenerse en conexion cuando la pantalla esta apagada.

74. Alessa

Un menos agresivo y más estable ondemand modificado por TeamMex. Un buen compromiso entre el rendimiento y la batería. Se puede utilizar con su governor hotplug. Por Favor tengan en cuenta que su trabajo sigue en curso.

75. GallimaufryX

Un Ondemand modificado que tiene dos etapas de conajustes de velocidad. Incluye el codigo de screen-off hotplugging de Imoseyon .

76. AggressiveX

Un conservative modificado pero con muchas modificaciones para incrementar el control de energia mientras guarda potencia. Tambien icluye el codigo de screen-off hotplugging de Imoseyon .

77. Tripndroid

En vez del Scheduler, esto es un governor CPU basado en Ondemand con mejoras extra para el rendimiento.

78. Wrexy
Wrexyen un governor basado en “Conservative”, es similar al “Lionheart”. Tiende a mantenerse al margen de las frecuencias más altas para favorecer las frecuencias más bajas, pero el rendimiento no se ve muy afectado .

79. Xperience

Un smartassv2 modificado para un mejor rendimiento y más suavidad.Creado por TeamMex.

80. Stockdemand

Un ondemand muy modificado para mejorar el rendimiento y la vida de la batería. Todavía es un governor bien equilibrado y que está diseñado para el uso diario.

Categorias:

Hay cuatro categorias para los governors.

1) Basados en Ondemand:
Trabajan bajo el principio “Aumentar bajo mucha carga(ramp-up on high load)” . El tiempo de ocupacion de la CPU se toma en cuenta para escalar las decisiones y aumentar las frecuencias.
Miembros: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree, PegasusQ, HYPER, Wheatley, Hotplug, HotplugX, AbyssPlug, AbyssPlugv2, Nightmare, Sleepy.

2) Basados en Conservative:
Trabajan viendo la preferencia del telefono para elegir la velocidad de cpu mas baja posible lo mas frecuentemente posible.
Miembros: Conservative, Lionheart, LionheartX

3) Basados en Interactive:
Trabajan bajo el principio “escalar la cpu cuando la cpu sale de bucles inutiles(make scaling decision when CPU comes out of idle-loop)”
Miembros: Interactive, InteractiveX, Intelliactive, Lulzactive, Luzactiveq, Smartass, SmartassV2, SmartassH3, Brazilianwax, SavagedZen, Dyninteractive.

4) Basados en Categoria "Unique" :
Estos no se encuentran en ninguna otra categoría anterior y/o poseen atributos únicos
Miembros: Userspace, Powersave, Performance, Min Max, ZZmove, MSM DCVS

5) Basados en categoria "Hybrid" :
Estos tienen la mezcla de dos (o mas) comportamientos de governors de Cpu.
Miembros: Smartmax, Dancedance, Performance May Cry(PMC), Ktoonservative, KtoonservativeQ


Algunas recomendaciones sobre governors

Metodo de valoracion:

Ideal - Este governor es simplemente el mejor (para la categoría ) , muy recomendable.
Muy Bueno - Este governor es muy bueno, se adapta bien para la mayoria de gente.
Bueno - Este governor esta bien, pero podria no ser apropiado para todo el mundo.
Requiere tunear - Estos governor, requieren tunearlos, no son para principiantes.


Si tu kernel, que no la rom, no tiene los cpu governors que están marcados como los "ideal", usa los que estén marcados como "muy bueno".

Ademas, si hay mas de un governor marcado como "ideal", elige el que tengas disponible. Si dispones de todos, elige uno XD

Para Rendimiento:

(Click para mostrar/ocultar)

Single-core:
- Performance - Ideal
- Min Max - Muy Bueno
- Interactive/InteractiveX - Ideal
- SmartassV2 - Ideal

Multi-core:
- Performance - Ideal
- Min Max - Muy Bueno
- Interactive/InteractiveX - Muy Bueno
- ZZMove/ZZmanX - Requiere tunear
- HYPER - Muy Bueno
- Lionheart/LionheartX - Ideal
- Intelliactive - Muy Bueno
- SmartassV2 - Bueno
- Wheatley - Bueno
- LulzactiveQ - Muy Bueno
- PegasusQ - Bueno

Para duración de bateria:

(Click para mostrar/ocultar)

Single-core:
- Powersave - Bueno
- Ondemand - Ideal

Multi-core:
- SLP/Sleepy - Muy Bueno
- Perfomance may cry (PMC) - Ideal
- Powersave - Bueno
- Ktoonservative(Q) - Muy Bueno
- Smartmax - Ideal
- ZZMove - Requiere tunear

Para equilibrar batería y rendimiento:

(Click para mostrar/ocultar)

Single-core:
- Interactive/Intelliactive - Ideal
- Ondemand/OndemandX - Stock, Ideal
- SmartassV2 - Muy Bueno

Multi-core:
- LulzactiveQ - Bueno
- Intelliactive - Bueno
- Interactive/InteractiveX - Muy Bueno
- Yankactive/YanksusQ - Muy Bueno
- Ondemand/OndemandX - Stock, Ideal
- PegasusQ - Ideal
- SmartassV2 - Muy Bueno
- NeoX - Muy Bueno
- HYPER - Ideal
- ZZMove/ZZmanX - Requiere tunear
- Dancedance - Bueno
- Ktoonservative - Muy Bueno
- Alucard – Muy Bueno

Para Juegos:

(Click para mostrar/ocultar)

Single-core:
- Interactive(X) - Ideal
- Performance - Muy Bueno
- Ondemand/OndemandX - Muy Bueno
- SmartassV2 - Ideal

Multi-core:
- Lionheart/LionheartX - Ideal
- Dancedance - Muy Bueno
- Intelliactive - Muy Bueno
- Yankactive - Bueno
- NeoX - Muy Bueno
- Interactive/InteractiveX - Ideal
- SmartassV2 - Muy Bueno
- Pegasus(Q/D) - Ideal
- Ondemand/OndemandX - Muy Bueno
- Hyper - Ideal
- Performance - Muy Bueno
- LulzactiveQ - Ideal
- Intellidemand - Bueno
- Ktoonservative - Muy Bueno
- ZZMove/ZZmanX - Requiere tunear

Otros governors de los que no se habla en esta sección, es porque o ya no se usan o no se adaptan bien a mucha gente, o han sido eliminados de los kernels.



Consumo de bateria por governor, numero de miliamperios justos.(Battery Drain)

(Click para mostrar/ocultar)

Preguntas

(Click para mostrar/ocultar)

P. “Muy bien, basta de explicaciones. Dime qué governor es mejor para rendimiento y cual es mejor para la batería.”

R. Lulzactive y SmartassV2 para un equilibrio entre rendimiento y batería. Para tareas ligeras, Lulzactive debería ser mejor en cuanto a batería, y para tareas más pesadas, Lulzactive debería ser mejor para rendimiento también. Para obtener un rendimiento máximo usa un Ondemand retocado o un Conservative, pero nunca te quejes de la batería entonces. NOTA: no es fácil hacerse con el Lulzactive. Si no estás seguro de cómo configurarlo sigue leyendo los siguientes posts.


P. “Casi lo olvido, ¿cómo puedo cambiar los governors?"

R. La mejor manera es usando un script en init.d si tu kernel está preparado para ello. Otra opción, mucho más fácil, es usando aplicaciones como NSTools, Voltage Control, Pimp my CPU, etc.


P. “¿Cómo se qué governor es el mejor para mí?”

R. Depende de lo que necesites según el uso que le des al teléfono a diario: rendimiento o batería. La mejor elección es un governor que tenga un equilibro entre las dos opciones. O modificar un governor para obtener un mayor rendimiento en detrimento de la batería. Siempre podemos recargar la batería: en el coche cuando vamos al trabajo, en casa por la noche. Lo que no podemos es recargar el rendimiento. Si, como lo oyes. Prueba a disfrutar del teléfono, no le pongas barreras con tal de que gaste menos y te dura la batería 2 o 3 días. Si la batería te aguanta desde que te levantas hasta que te acuestas dale caña.


P. “Bien, he elegido me governor favorito para cuando se enciende la pantalla y otro para cuando se apaga. ¿Por qué el teléfono no se enciende al salir del reposo? Tengo que reiniciarlo pulsando el botón power durante unos 10 segundos…¿He tenido un SOD (sleep of death)?”

R. Si. No uses dos governos distintos para pantalla apagada/encendida si ambos tienen limitada la frecuencia máxima para la pantalla apagada. ¿No lo has entendido?
Ejemplo de mala combinación (pantalla encendida/apagada): OndemandX-SmartassV2.
Ejemplo de buena combinación: Ondemand-SmartassV2, Lulzaactive-SmartassV2.

P. "Noto cierto lag con un governor. Por ejemplo cuando hago scroll en el menú de aplicaciones o en el navegador web, etc. Me encanta este governor y no me digas que use otro…¿Puedo deshacerme del lag?"

R. Si…puedes. Básicamente lo que tenemos que hacer es que el governor muestree con menos frecuencia cuándo bajar la velocidad de la CPU. Incrementar el tiempo de muestro para bajar la frecuencia hace que la CPU esté durante más tiempo en una misma frecuencia antes de disminuirla. Esto podría eliminar el lag.


P. “Ok, quiero modificar el governor según mi uso habitual, porque no estoy a gusto con la configuración predetermianda.”

R. Se pueden modificar los governors usando un script en init.d, por ejemplo: /sys/devices/system/cpu/cpufreq/name-of-active-governor/name-of-the-paramater-to-tweak. La manera más fácil y cómoda, sin duda, es usando la aplicación NSTools, la cual permite ajustar los parámetros de todos los governors que lo permitan.


P. “Voy a elegir como frecuencia mínima 100 mhz porque mi kernel me da la opción. Espero que no haya nada malo en hacer esto.”

R. ¡Espera! Posiblemente desees no usar la frecuencia mínima de 100 mhz con la pantalla apagada/encendida por tres razones:
100 mhz consume más batería que 200 mhz. Según los test, 100 mhz consumen 1W/Ghz y 200 mhz consumen 0,7W/Ghz.
En 200 mhz se pueden hacer las mismas tareas más rápidamente que en 100 mhz y entrar antes en reposo.
Ojo: esta frecuencia mínima es la mejor para el SGS II. En el Motorola Milestone por ejemplo es 550 mhz. En el opo, lo normal es que sea de 300mhz, pero hay kernels que permiten bajarla hasta 256mhz, yo la he llevado asi, durante mucho tiempo , en 256mhz, y la verdad si nota un mejor consumo que en 300mhz. Si el kernel lo soporta, lo recomiendo.


P. “¿Cómo hacer mi teléfono más ágil? Me importa la duración de la batería…”

R. Selecciona un rango de 652 mhz a 2.5 ghz cuando la pantalla está encendida y uno de 256 mhz a 730mhz mhz cuando la pantalla está apagada. Usa un Performance o un Conservative/OndemanX modificados. La respuesta del teléfono será excelente y no te preocupes…un mínimo de 500 mhz con la pantalla encendida no gasta tanta batería como piensas.

[moludo]

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).

I/O SCHEDULERS

1. ROW
2. FIOPS
3. SIO
4. NOOP
5. ANTICIPATORY
6. ADAPTIVE ANTICIPATORY
7. CFQ
8. DEADLINE
9. V(R)
10. SIMPLE
11. BFQ
12. ZEN
13. SIOPLUS
14. FIFO
15. TRIPNDROID

(Click para mostrar/ocultar)

1)ROW

RoW significa “LECTURA sobre ESCRITURA” ya que la principal política en este algoritmo es la de despachar las peticiones. El Scheduler ROW está diseñado pensando en lo que un telefono movil necesita. En los dispositivos móviles, se aprecia por encima de todo una buena experiencia de usuario por encima de todo, ya que siempre queremos tener lo más rápido posible las peticiones que realizamos. En los móviles no tenemos muchas similitudes a las de los DeskTops. Por lo general, se trata de un solo hilo o como máximo 2 hilos de trabajo simultáneos para leer y escribir. Favoreciendo las peticiones de Lectura a las de escritura se consigue que apenas haya retardo en las peticiones de lectura.
La idea principal de la política del ROW es: Si hay peticiones de Lectura en proceso, las despacha, pero sin dejar de lado demasiado la escritura.
Encontrarás pequeñas similitudes a otros schedulers existentes.Los tests que se han hecho de lectura/escritura dicen que son muy parejos.

Ventajas
- Muy rápida Navegación UI y una mejor experiencia en general del telefono.
- Reinicios y aperturas de apk mas rapidos.mas rapidos
- Posiblemente mas duracion de bateria
- A veces se usa por defecto en Custom kernels y roms.

Inconvenientes
- Escritura mas lenta
- Algunas aplicaciones que pidan mucho rendimiento, como juegos, pueden hacer ralentizarse al telefono.

2)FIOPS

Este nuevo Scheduler se ha diseñado en torno a los siguientes supuestos sobre los dispositivos de almacenamiento Flash:
No hay tiempo de búsqueda I/O, el coste de la lectura y la escritura I/O sueler diferente a hacer correr archivos media, el tiempo para responder a una petición depende del tamaño de la petición, y el alto rendimiento de procesamiento y mayores IOPS con baja latencia.

Ventajas
- Alcanza velocidades altas de lectura y escritura en BenchMarks
- Carga mas rapida de APPs, y una experiencia global muy buena.
- Buena duracion de bateria

Inconvenientes
- No suele estar añadidos en todos los Kernel
- No es el scheduler mas sensible
- No es bueno Para multitarea muy pesada

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) 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.

5)ANTICIPATORY


Dos cosas importantes en este tema:


- Buscando en la unidad flash es muy lento en el arranque.
- Escribe operaciones mientras son procesadas en cualqueir momento, sin embargo, se prefieren leer, es decir, este planificador devuelve las operaciones de lectura en una prioridad más alta que las operaciones de escritura.

[i]Ventajas[/]
- Las solicitudes de los accesos de lectura no son tratados en segundo lugar, por eso tiene igualmente un buen rendimiento de lectura en unidades flash como noop.

Inconvenientes
- Las solicitudes de operaciones de procesos no siempre están disponibles
- Menor rendimiento de escritura en los discos duros de alto rendimiento
- No es muy común en la mayoría de los Kernel


6)ADAPTIVE ANTICIPATORY

Para el Anticipatory Scheduler, escalamos hasta el tiempo de espera de anticipación (caduca antic) utilizando la latencia factor de escala con el tiempo. Cuando las latencias de disco virtuales son bajos una pequeña escala del tiempo de espera es sucient para evitar el ocio engañosa, mientras que cuando las latencias son altos puede ser necesaria una escala mayor del valor de tiempo de espera para conseguir el mismo. Tenga en cuenta que tal ajuste dinámico del valor de tiempo de espera asegura que alcanzamos un buen comercio-o entre rendimiento (perdido debido a ralentí) y la mitigación de la ociosidad engañosa. El establecimiento de un valor alto para el factor de escala (el aumento del tiempo de ralentí) sólo ocurre cuando el servicio de disco latencias en sí son más altos. Esto no necesariamente puede causar una pérdida signicant en el rendimiento, ya que la presentación de una solicitud de otro proceso en lugar de ralentí no va a mejorar el rendimiento si el propio disco virtual no hay nada más rápido de lo que es en el período actual. Un tiempo de espera de anticipación superior también podría ser capaz de absorber eects programación de procesos dentro de la máquina virtual. Los resultados para el programador anticipatorio adaptativa se muestran en la Figura 2. El tiempo de lectura con nuestra aplicación modied (tercera barra en las combinaciones planificador dierent) muestra que es posible mitigar los eects de ociosidad engañosa mediante la adaptación del tiempo de espera. Una observación relacionada interesante es que el nivel al que la mejora es posible varía para dierent Domain-0 programadores; noop - 39%, anticipatoria - 67% y CFQ - 36%. Aquí se evidencia el hecho de que el planificador de E / S utilizado en Domain-0 es importante para la capacidad de la VM en la aplicación de garantías de programación de E / S. Dierent Domain-0 E / S programadores probablemente tiene una huella de latencia servicio dierent dentro de las máquinas virtuales, lo que contribuye a dierent niveles de mejora.

7) 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.



8) DEADLINE

El objetivo es minimizar la latencia de I/O o la necesidad de una petición. Esto se logra 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 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.


9) 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.


10) 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).

11.ZEN


Basado en el scheduler V(R). Esta basado en el algoritmo FCFS(First come, first serve).
Based on the VR Scheduler. It's an FCFS (First come, first serve) based algorithm. No es estrictamente FIFO. No hace ninguna clasificación.Utiliza plazos,“deadlines”, para ser equitativo, y trata las solicitudes sincrónicas con prioridad sobre complementos asíncronos.Aparte de eso , más o menos el mismo que el noop .

Ventajas
- Bien matizado y eficiente.
- Más suave que SIO
- Más estable que el V(R), principalmente porque no se comporta como tal

Inconvenientes
- No se encuentra en todos los kernel.

12.Sioplus:

Basado en el SIO original con alguna mejora. Funcionalidad para especificar las peticiones de lectura Asyncronas contra las syncronas. la necesidad de contar de peticiones de escritura solo funciona cuando en realidad solo hay peticiones de escritura en cola. Arregla un fix.

Ventajas
- Mejor Lectura y escritura que el SIO
- Muy buena duracion de bateria

Inconvenientes
- Los mismos que el SIO
- Que no es muy común en los kernel.

13.FIFO (First in First Out):
Un scheduler relativamente sencillo que hace lo que describe. Tambien es conocido como FCFS (First como First Serve) pero no es del todo cierto. Tieneclasificaciónn Básica. Clasifica los procesos acorde al orden apropiado y nada más. En otras palabras , se parece al NOOP.

Ventajas
- Es conveniente para las unidades flash porque no hay errores de búsqueda
- Buen rendimiento de datos en los sistemas de bases de datos.
- Sirve las solicitudes de I/O con menor número de ciclos de la CPU.

Inconvenientes
- La reducción del número de ciclos de CPU se corresponde con una disminución simultánea en el rendimiento
- No es muy buen multigestor

14.Tripndroid
Un nuevo Scheduler basado en Noop, deadline y VR y trata de tener una sobrecarga mínima. Hecho por TripNRaVeR

Ventajas
- Muy buen para buen rendimiento y multitask diario.
- Bien matizado y eficiente.
- Scheduler muy receptivo (Se le compara a FIOPS)
- relativamente amigo del buen uso de batería.

Inconvenientes
- No se encuentra en todos los Kernel
- El rendimiento varía entre diferentes equipos( Algunos rinden muy bien)

I/O schedulers Recomendados:

Para uso Diario

(Click para mostrar/ocultar)

- SIO (2ª Opción)
- NOOP
- CFQ (5ª Opción)
- Deadline (Mi eleccion personal)
- ROW
- ZEN(3ª Opción)
- TRIPNDROID(4ª Opción)

Para duracion de Bateria

(Click para mostrar/ocultar)

- SIO (3ª Opción)
- FIOPS (2ª Opción)
- NOOP (1ª Opción)
- ROW(4ª Opción)
- TRIPNDROID
- FIFO

Para jugar a juegos

(Click para mostrar/ocultar)

- Deadline
- CFQ
- ZEN(3ª Opción)
- SIO(1ª Opción)
- BFQ
- TRIPNDROID (2ª Opción)
- ROW
- FIOPS

Para alto rendimiento(Benchmarking):

(Click para mostrar/ocultar)

- VR
-NOOP
- TRIPNDROID (3ª Opción)
- SIO
- Deadline (2ª Opción)
- FIOPS (1ª Opción)

For multitasking:

(Click para mostrar/ocultar)

- BFQ(3ª Opción)
- Deadline (2ª Opción)
- CFQ (1ª Opción)

Comparacion I/O Scheduler

Rendimiento Global:
Mejor<------------------------------------------------------------------------->Peor
FIOPS> Noop > ZEN > Tripndroid > SIOplus > SIO > ROW > > VR > Deadline > BFQ > CFQ

Rendimiento Multitarea:
Menos Apps<------------------------------------------------------------>Muchas Apps
Noop < FIOPS < SIO < SIOplus < ROW < Tripndroid < ZEN < Deadline < VR < CFQ < BFQ

Duracion de Bateria:
Mejor<-------------------------------------------------------------------------> Peor
Noop > FIOPS > SIO > SIOplus > ROW > ZEN > Tripndroid > Deadline > VR > CFQ > BFQ


Comparacion grafica I/O Schedulers

Aqui hay un grafico del rendimiento de los Schedulers. Nota: La nota más alta no significa que sea el mejor Scheduler.
Sequential in MB/sec (MAs alto mejor)

(Click para mostrar/ocultar)

Aleatorio en IOPS (Mas alto mejor)

(Click para mostrar/ocultar)

Los siguientes graficos muestran la lectura/escritura por scheduler secuencialmente y aleatoriamente.

(Click para mostrar/ocultar)

==>Recuerda: Esto es un Delta% contra la media al 100%, esto hace que las pequeñas diferencias parezcan grandes. (sobre todo debido a la escala elegida)

(Click para mostrar/ocultar)

Como se lee el grafico?
Con valor de media 100%,
FIOPS es 109% en lectura secuencial, 116% en escritura secuencial, 102% en lectura aleatoria y 103% en escritura aleatoria.
BFQ es 94% en lectura secuencial, 90% en escritura secuencial, 97% en lectura aleatoria y 100% en escritura aleatoria.


Que nos muestra esto??
Fiops aqui parece que es el mejor
Zen, Noop, Sio y row parecen muy similares
Cfq y Vr estan detras en lectura secuencial pero es mejor en escitura secuencial
Deadline y Bfq son peores aqui
==> Estos resultados no son definitivos ni mucho menos, y pueden ser muy diferentes segun los telefonos y metodos de medicion.
Fuente:
http://andrux-and-me.blogspot.com.au...ormance-2.html and http://forum.xda-developers.com/show...3&postcount=85


PREGUNTAS

(Click para mostrar/ocultar)

P. “¿Cuál es el mejor I/O Scheduler?

R. No hay ninguno mejor que otro. Depende del uso que le des y las aplicaciones y tareas que tengas en ejecución, usa diferentes schedulers. Es lo mejor que te puedo decir. Sin embargo, considerando un rendimiento general, batería, fiabilidad y menos retardo, se piensa que SIO > Noop > Deadline > VR > BFQ > CFQ, considerando que todos los schedulers son modificables y el almacenamiento usado es una memoria flash.


P. “¿Cómo puedo cambiar los I/O Schedulers?”

R. Hay muchas aplicaciones para ello, la mas usada es Synapse

[moludo]

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á:

1. 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.
2. 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, gratis en la Play Store.

(Click para mostrar/ocultar)

1. ONDEMAND

Parámetros

1. 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.
2. 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.
3. 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.
4. 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

2.LULZACTIVE

Parámetros

1. 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.
2. 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.
3. pump_down_step: número de escalones que disminuye la frecuencia cuando la carga es menor que inc_cpu_load.
4. 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.
5. up_sample_time: tiempo de muestreo para subir la frecuencia de la CPU (valores entre 10.000 y 50.000).
6. down_sample_time: tiempo de muestreo para bajar 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

3.SMARTASSV2

Parámetros

1. 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.
2. 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.
3. 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).
4. 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).
5. max_cpu_load: lo mismo que la up_threshold en otros governors.
6. min_cpu_load: lo mismo que la down_threshold en otros governors.
7. 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.
8. ramp_up_step: es la frecuencia que se establece cuando estamos por encima de la frecuencia ideal. Un valor 0 deshabilita este parámetro.
9. 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

4.CONSERVATIVE

Parámetros

1. down_threshold: ya descrito en los otros governors.
2. up_threshold: ya descrito en los otros governors.
3. sampling_down_factor: ya descrito en los otros governors.
4. sampling_rate: ya descrito en los otros governors.
5. 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

5.INTERACTIVE

Parámetros

1. hispeed_freq: el valor por defecto es scaling_max_freq.
2. 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).
3. min_sample_time: la cantidad mínima de tiempo que pasamos en una frecuencia antes de bajarla.
4. 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

[moludo]

Hotplugging drivers:

- mpdecision (Driver por defecto de Qualcomm para el hotplug)
- msm_hotplug (Buena duracion de bateria, hotplug basado en el original de qualcomm hecho por myflux)
- intelliplug (Genial para rendimiento,muchas opciones de personalizacion hecho por Faux)
- Alucard HotPlug (Un genial driver de hotplug hecho por Alucard)
-AutoSMP, un simple y eficiente Driver para el Hotplug (Creado por Mrg666), se encuentra en kernels nexus 4.

Los Custom Kernels es posible que lleven sus propios driver Hotplug, pero normalmente se basan en estos.
Yo recomiendo jugar con ellos y ver como te responden. El hotplug Alucard parece ser el que mejor rendimiento de bateria da ,Los hotplug por defecto de qualcomm son mejores en rendimiento. Si tu experimentas problemas , manten los ajustes en AUTO. Si quieres experimentar, ten por seguro que experimentaras cambios en la vida de la bateria, tanto a peor como a mejor.



Gestor Termico

La manera que tienen de gestionar los cores el calor.Cuando activarlos o desactivarlos según la temperatura.

Thermald (Stock)
Intellithermal(Mejor control que el stock, opcion a cuando activar y que nucleos activar.)



GPU governors / Gpu Algorithm

GPU governors

(Click para mostrar/ocultar)

Simple: Es un nuevo governor para las frecuencias de la GPU. Permitira un control mucho mas fino sobre las frecuencias de la gpu, que lo que hacian sus governors predecesores. Esto significa un mayor rendimiento o un mayor control de la bateria.

Ondemand: Muy parecido al governor de la CPu, Ondemad subira la frecuencia cuando detecte que lo necesita la GPU. Tiene un buen balance entre rendimiento y bateria.

MSM-Adreno: El Governor de serie que usan Qualcom para sus GPus Adreno. Esta mas orientado al rendimiento que el Ondemand. Te dara mejores resultados de rendimiento ara juegos pero con mas gasto de bateria.

Performance: Como dice el nombre, este mantiene la frecuencia de la GPU a tope . Este es el governor a utilizar si quieres la mejor experiencia en juegos, eso si no te preocupes por la bateria porque se la bebe.

Powersave: Como el governor de CPu, esto mantendra la GPU en la frecuencia mas baja posible. El mejor en para la vida de la bateria, lags extremos en las juegos.

Gpu Algorithm

(Click para mostrar/ocultar)

Regulador Simple[Laziness] 0.....10
Esto ajusta el umbral para subir o bajar las frecuencias de la GPU. Cuanto mas bajo, mayor rendimiento(Mayor gasto de bateria claro)

Regulador Simple [ Ramp Threshold] 0....10
Esto ajusta el numero de veces que el regulador salta requisitos bajos. Cuanto mas alto, mayor rendimiento (mayor gasto de bateria)

Gestor de Memoria. Ajustes de memoria/cache

Intercambio de Zram
zRam es un módulo que ayuda a mejorar el desempeño del sistema evitando utilizar la memoria de intercambio en el disco duro (swap) utilizando en su lugar un dispositivo de bloque comprimido en la memoria RAM.

Siendo que utilizar memoria RAM es más eficiente y rápido que utilizar memoria de intercambio en el disco duro, zRam permite utilizar la memoria RAM al realizar intercambio/paginación cuando es requerido. Es sin duda una excelente alternativa para equipos antiguos con poco RAM.

Limpiador CAche VFS despues de arrancar

Esta opcion forzara que se reescriba la cache del sistema basado en la aplicacion usandose para procesos de arranque e inicio. Activalo para un mejor rendimiento de Lectura/Escritura del sistema!

Auto FS Writeback Delay Mode

esta opción retrasará la reescritura de los bits de sistema de archivos en caché en RAM , mientras que la pantalla está activada ( Activar para un mejor rendimiento @ ligero riesgo de posible pérdida de datos si falla o pérdida repentina de potencia)


Kernel Same-Page Merge

Intelli-KSM

KSM es una característica de-duplicación de memoria de ahorro . la makina KSM escanea periódicamente aquellas áreas de memoria de usuario que se han registrado en él , en busca de páginas de contenido idéntico que pueden ser sustituidos por una única página protegida contra escritura . Es útil en el runtime de android que genera muchas instancias de los mismos datos!

Battery Controls

Battery Temperature Throttling

Esta opción le permite reducir la frecuencia de la CPU para reducir la acumulación de calor durante la carga y cuando la CPU este a tope . Las baterías de iones de litio están optimizadas para funcionar a menos de 55 grados centígrados.
Con esto configuraremos a que temperatura exacta queremos que entre una frecuencia mas baja.


Protocolos TCP/IP y Algoritmos de control Congestion:


TCP / IP es un conjunto básico de protocolos de comunicación utilizados para transferir datos a través de Internet y redes similares. Los paquetes IP son el vehículo que los dispositivos utilizan para transferir datos entre un programa o aplicación y un servicio web. Ellos se componen de una cabecera, que contiene la dirección de origen / destinatario (entre otras cosas), y una carga útil, que contiene los datos reales. TCP, parte de la capa de transporte de Internet, proporciona la comunicación intermedia entre una aplicación y un servidor.

Cuando el envío de grandes cantidades de datos de un programa puede emitir una única solicitud a TCP en lugar de dividir los datos en una serie de paquetes IP y peticiones.

Debido a la congestión de la red y otros factores de los paquetes IP a menudo se pierden. TCP mantiene la entrega ordenada de paquetes mediante la detección de la pérdida de paquetes, solicitando retransmisión, la reordenación de los datos, y la minimización de congestión de la red. Cuando un host recibe un flujo de paquetes que vuelve a ensamblar los datos en la secuencia que fue enviado originalmente. Una vez que el receptor confrims la solidez de los datos que envía un paquete de reconocimiento para su recuperación, asi evitar la sobrecarga de la conexión entre un programa y uma camtidad de paquetes enviados, debe ocurrir antes de que más paquetes puedan ser enviados o recibidos.

Para cada conexión TCP mantiene una ventana de congestión. La ventana de congestión TCP se mantiene por el remitente y se usa para prevenir la red la congestión / sobrecarga debido a la pérdida de paquetes. Cuando lo paquetes se reciben el tamaño de la ventana de congestión TCP aumenta exponencialmente hasta que un tiempo de espera se produce o el receptor alcanza su límite de ancho de banda. Por lo tanto, a medida que más paquetes se reconocieron el tamaño máximo de segmento (especifica el más grande cantidad de datos en un único segmento TCP) de la ventana de congestión se hace más grande; cada vez de ida y vuelta el tamaño máximo de segmento duplica. Un mecanismo llamado "Slowstart" controla el tamaño máximo de segmento de la ventana de congestión TCP. Para evitar que la red algoritmos para evitar la congestión de TCP sobrecarga modifican ventana TCP tamaño ", de comienzo lento", y el umbral de comienzo lento. Por lo tanto, los algoritmos de evitación de la congestión de TCP tienen un impacto significativo en la velocidad de entrega de paquetes entre un programa de aplicación y un servicio de alojamiento web.


Descripciones:

(Click para mostrar/ocultar)

Tahoe:
Limita los paquetes desconocidos que se reciven.Limita la ventana de congestion , y se resetea a un estado de inicio lento.

Reno:
Basicamente es lo mismo que el tahoe, pero si 3 de los mismos paquetes son recividos , se reducira a la mitad la ventana, en lugar de reducirla a un MSS. Este cambia el umbral de inicio-lento, igualado al de la congestion de la ventana.

Vegas:
Uno de los mas suaves(junto con el cubic), este incrementa el retardo de tiempo de espera para los paquetes, el cual permite mas para recivir, pero a costa de un elevado ritmo. Tambien ha configurado tiempos de espera, lo que ayuda con la velocidad porque esta constantemente refrescandose.

Hybla:
Penaliza conexiones que utilizan la radio por satélite. No es muy usado en telefonos.

Cubic:
Uno de los mejores,Disponibles las opciones TCP mas recomendadas. Menos agresivo, modula las ventanas antes del evento. Se usa en Linux.

Westwood:
Una nueva version de RENO, y otro mas usado comunmente.Controla los parametros mejor,ayudando a la transmisión y la calidad general de la navegación por Internet . Uno de los Algoritmos más "justos" que hay, y es uno de los algoritmos más eficientes hasta la fecha.

Low Priority (LP):
Un algoritmo distribuido cuyo objetivo es utilizar sólo el ancho de banda en exceso en comparación con la "parte justa" de ancho de banda que es seleccionado por el TCP. Los mecanismos claves únicos para el control de congestión TCP-LP son el uso de los retrasos de paquetes de un solo sentido para las indicaciones de congestión temprana y una política de prevención de congestión en TCP transparente.
Binary Increase Congestion control (BIC):

BIC esta optimizado para redes de alta velocidad, con un alto estado de latencia: por eso se llama “long fat networks”, Tiene un algoritmo de ventana de congestion unico(cwnd) ,Este algoritmo intenta encontrar el máximo donde para mantener la ventana por un largo período de tiempo, mediante el uso de un algoritmo de búsqueda binario.

Scalable:

Se llama Scalable ya que reduce a la mitad el numero de paquetes perdidos. Efectivamente , este proceso reduce a la mitad el rendimiento hasta que se detiene la pérdida de paquetes. Una vez que la pérdida de paquetes se desploma, inicia lento para poder subir velocidades de los Backups. Cuando los tamaños de las ventanas son pequeños , por ejemplo 1 Mbit / s @ 200 ms de tiempo de ida y vuelta y la ventana es de unos 20 paquetes , este tiempo de recuperación es bastante rápido, en el orden de unos pocos segundos . Pero a medida que la velocidad de transferencia se acerca a 1 Gbit / s , el tiempo de recuperación se convierte en media hora y de 10 Gbit / s que es más de 4 horas .

Illinois:

Está diseñado para redes de alta velocidad , de larga distancia. Una modificación de parte del emisor para el algoritmo de control de congestión TCP estándar, se logra un rendimiento medio más alto que el estándar TCP, asigna los recursos de red más justamente que el estándar TCP, es compatible con el estándar TCP y proporciona incentivos para cambiar a los usuarios.

High speed (HSTCP):

HighSpeed TCP (HSTCP) es un nuevo algoritmo TCP. Los standares TCP andan peor en redes con un largo ancho de banda, Es incapaz de utilizar plenamente el ancho de banda disponible. HSTCP hace modificaciones menores en los mecanismos de control de congestión de TCP estándar para superar esa limitación .

Yeah-TCP:

Es un algoritmo TCP de alta velocidad, que utiliza un enfoque de pérdida / retraso mixto para calcular la congestión de las ventanas .Su objetivo es apuntar a una alta eficiencia, parecido RTT y Reno, y minimizando la pérdida de los enlaces ,mientras se mantienen el mínimo número de elementos de red cargados.

Teses de Velocidad

Resultados:
Latency - Download - Upload

(Click para mostrar/ocultar)

cubic:
1st run: 15ms - 10,75Mbps - 7,82Mbps
2nd run: 14ms - 10,84Mbps - 8,06Mbps

reno:
1st run: 13ms - 15,51Mbps - 6,73Mbps
2nd run: 13ms - 14,73Mbps - 8,51Mbps

bic:
1st run: 12ms - 10,38Mbps - 8,61Mbps
2nd run: 13ms - 10,78Mbps - 8,62Mbps

westwood:
1st run: 11ms - 17,65Mbps - 8,30Mbps
2nd run: 13ms - 13,28Mbps - 8,29Mbps

highspeed:
1st run: 13ms - 10,76Mbps - 7,94Mbps
2nd run: 16ms - 14,42Mbps - 8,52Mbps

hybla:
1st run: 14ms - 11,19Mbps - 7,44Mbps
2nd run: 14ms - 13,47Mbps - 7,56Mbps

htcp:
1st run: 14ms - 13,24Mbps - 7,03Mbps
2nd run: 15ms - 10,85Mbps - 8,00Mbps

vegas:
1st run: 14ms - 8,49Mbps - 6,62Mbps
2nd run: 14ms - 12,00Mbps - 7,07Mbps

veno:
1st run: 13ms - 9,58Mbps - 8,13Mbps
2nd run: 13ms - 8,50Mbps - 7,64Mbps

scalable:
1st run: 18ms - 12,01Mbps - 8,73Mbps
2nd run: 14ms - 13,96Mbps - 8,23Mbps

lp:
1st run: 14ms - 14,90Mbps - 8,68Mbps
2nd run: 14ms - 13,44Mbps - 8,72Mbps

yeah:
1st run: 14ms - 13,37Mbps - 8,28Mbps
2nd run: 17ms - 13,89Mbps - 8,14Mbps

illinois:
1st run: 13ms - 12,93Mbps - 8,24Mbps
2nd run: 16ms - 13,97Mbps - 6,46Mbps

Conclusión:

Se ha utilizado los algoritmos mas usados y que parecen que obtienen mejores resultados para hacer multiples teses , y PArece ser que "WestWood" es el algoritmo TCP mas prometedor. Los algoritmos recomendados son el "Cubic" y el "WestWood" ya que son los mas estables y eficientes. La navegacion real mostrara pocas diferencias entre algoritmos, por lo que la experiencia de cada uno variara. El cambio de algoritmos TCP no deberia alterar a la duracion de la bateria.


Que son las ToolChains?? Que es linaro, o sabermod? Descripciones de diferentes optimizaciones utilizadas en Android.

Linaro: Ver http://www.linaro.org/linux-on-arm

Hay varios cientos de desarrolladores que trabajan en Linaro. Linaro fusiona cambios de Google y también de GNU.org para optimizar herramientas de compilación que utilizan para optimizar kernels y ROMs.También hacen cambios en el código AOSP para permitir la compilación, ya sea con una versión superior GCC o para una mejor optimización. Linaro siempre está meses por delante de Google.Ejemplo: Google sigue utilizando 4.7.2 mientras Linaro utiliza 4.7.4. Las diferencias con respecto a 4.7.2 y 4.7.4 son, literalmente, miles y miles de líneas de código para hacer herramientas de compilación más optimizadas.Es por esto que muchos desarrolladores eligen la ruta Linaro. Los Benchmarks y la experiencia general del usuario ha demostrado que Linaro hace un mejor trabajo de optimización de Google.

Dato Curioso: Ubuntu 14.04 tiene Linaro 4,8 establecido como GCC por defecto actualmente. (Es evidente que hay muchos que le dan crédito a linaro. Deja claro que , No es tan solo una palabra de moda si hasta en Pcs se usa.)


SaberMod: Ver Fuente https://github.com/SaberMod

SaberMod es un proyecto de menor escala tripulado por sólo unos pocos desarrolladores con el objetivo de mejorar android en todas las formas posibles. Se hace hincapié en mantener las cosas más cercanas a AOSP, y no desviarse tan lejos del sentimiento stock como dice linaro.
Aqui los desarrolladores usan la ultima GCC fusionando bases semanales con multiples parchesados sobre AOSP como hace google. Los desarrolladores de SaberMod siempre construyen toolchains con las últimas toolchains internas de Ubuntu y utilizan de todos ellos optimizaciones del GCC posibles para hacer tu ROM mas rápida que nunca! SaberMod también hace uso del sistema completo y todos ellos -O3, Graphite y otros grandes indicadores del GCC para hacer tu ROM / Kernel lo más eficiente posible. Ellos parchean cualquier cosa para Android y su trabajo duro en efecto da sus frutos! Actualmente los benchmarks SaberMod son incluso superiores a los de Linaro. No me creais a mi, prueba cualquier cosa compilada con sabermod tu mismo! No te arrepentirás!


Regular Google AOSP Toolchains: ver https://android.googlesource.com/toolchain/gcc

Nota: Estas ToolChains no se utilizan normalmente, esto es más por comparar

Actualmente las ToolChains de Google, estan desfasadas tienen hasta mas de un año de antiguedad. Y no me creais a mi, descargaros los sources y comprobarlo. Google también parece haber construido su último lote de toolchains en una versión anterior de Ubuntu con GCC 4.6 ó GCC 4.7 como el conjunto de herramientas por defecto del sistema. Incluso una recompilación de su codigo actual Usando las últimas GCC Ubuntu 14.04 , GCC 4.8 o experimental GCC 4.9, aumenta la respuesta global de la UI. Los Benchmarks también se han mejorado ligeramente. Es por esto que es importante aprender a construir tus propias toolchains ya que Google va siempre muy por detrás y se obtiene un mejor rendimiento de tus propias toolchains. Esto no es una falacia !!! Dale una oportunidad y veras la diferencia.

Toolchain Optimization Flags: Ver https://gcc.gnu.org/onlinedocs/gcc/O...e-Options.html

-O2 vs. -O3 vs -Ofast: Normalmente los kernel de Stock vienen con -O2 como nivel de optimización por defecto.Muchas personas se encontraban a sí mismos haciéndose preguntas del tipo ¿Cómo difiere este nivel de los "O3" o "-Ofast" ¿Es un placebo?
Leer este link https://gcc.gnu.org/onlinedocs/gcc/O...e-Options.html sobre las opciones de optimización GCC y encontraras las diferencias entre “-O2”, “-O3” y “-Ofast”. te daras cuenta de que hay muchas optimizaciones nuevas en el -O3 en comparación con el -O2. Desafortunadamente las toolchias de Google 4.7,4.8 no soportan “-O3” ó “-Ofast” (Al menos las toolchain de ARM-EABI no, ni si quiera he perdido mi tiempo con Arm-Androideabi). A si que no es tan solo que sean viejos, si no que ni siquiera tienen la capacidad de optimizar muchas cosas.
Normally stock kernels come with -O2 as the default optimization level. Many folks find themselves asking questions like How does this differ from “-O3” or “-Ofast” Is this a placebo? Read this link https://gcc.gnu.org/onlinedocs/gcc/O...e-Options.html about GCC Optimization options and you’ll find out the differences between -O2, -O3, and -Ofast. You’ll notice several more optimizations are added from -O2 to -O3. Unfortunately, Google 4.7/4.8 toolchains don’t even support -O3 or -Ofast (At least the arm-eabi toolchains don’t, I haven’t even wasted my time with arm-androideabi). So they’re not only old but don’t even have the ability to optimize as much either.

Graphite: Mira esto https://gcc.gnu.org/wiki/Graphite-4.8. Graphite es un framework para la optimización de memoria de alto nivel utilizando el modelo poliédrico.

Los desarrolladores han dicho acerca de la optimización poliédrica: “ Para conseguir un verdadero optimizador poliédrico para Graphite , hemos elegido el Algoritmo “Pluto”. Pluto es un optimizador poliédrico que utiliza una función de costes única para optimizar simultáneamente los datos de localización, paralelismo y enclaustramiento. Ha mostrado buenos resultados en varios Kernel. el Autor principal se ha empleado a fondo para implantarlo de nuevo en IBM XL. Nosotros hemos añadido una implementación de este algoritmo al ISL. El nuevo conjunto de arreglos y parches permite a graphite usar este nuevo optimizador. A pesar de que el parche es un primer borrador y sin duda necesita una puesta a punto para que coincida con los resultados de la aplicación original, es un buen punto de comienzo para un optimizador poliédrico Real en Graphite” Esto fue hace como un año, ahora ya esta totalmente integrado.
Si queires saber mas: http://gcc.gnu.org/wiki/Graphite-4.8 Las 3 primeras cosas de las 4 que se querian ya se han conseguido.


Opticharging

Las ROMs personalizadas al principio tenían espacio limitado para trabajar por lo que Cyanogen introdujo opticharging a la herramienta personalizada de lanzamiento, con el fin de reducir el tamaño de las apk para adaptar más aplicaciones en particiones de sistema de los dispositivos Android originales. El script opticharger deja aparte aplicaciones cerca del final del build y optimiza todos PNGs que se encuentran en ellas. Originalmente este script utilizaba OptiPng el cual es muy bueno y no tiene ninguna perdida de calidad en las compresiones Png pero recientemente he empezado a utilizar PngQuant porque este comprime entre un 30% y un 70% mas, normalmente una media de un 50% mas comprimido. ( PngQuant seguro qeu tiene alguna perdida , pero aun no lo hemos visto.) ( Si queieres leer mas: http://pngquant.org) (Si estas preocupado acerca de la calidad siempre se puede utilizar OptiPNG que comprime sin pérdida de calidad, por lo general los themers utilizan esta opción en lugarde el PNGQuant)

Actualmente, CyanogenMod a abandonado el uso del OptiCharger, pero muchas roms aun siguen utilizándolo como SLIM, AOKP, Liquidsmooth, Dirty unicorns, Carbon, Validus, Y otras muchas.
Los themers y los desarrolladores de Apps del mismo modo usan estas técnicas para que sus apps o temas vayan más suaves. hacer un 70% más pequeñas laimágeneses hace que la aplicacion sea 3 veces mas rapida y ademas guarda mas RAM. Entiendo que las apks no lo son todo para la velocidad de una apk, pero te sorprenderias el número de Pngs inútiles va dejando google desde Froyo en ellas, y que tu systemUI debe cargar en ram de todas todas. Hay que agradecer a OptiCharging que reduzca del 50%- al 70% de esta carga en la ram , y así conseguir que nuestro SystemUI sea un poco más rápido, al ahorrarte tantos megas en tu ram.

ya que no podemos descargar de la ram el SystemUI bien vale la pena el esfuerzo! Mi lema siempre es : cada poquito cuenta
Muchos todavía argumentan que los dispositivos de gama alta no necesitan opticharging porque son lo suficientemente rápidos para manejar estos archivos PNG a tamaño completo. Bien esto es cierto, pero no cambia el hecho de que opticharing hace que sean aún un poco más rápidos y las aplicaiones “optichargeadas” van a hacer usar menos ram. Si no me creéis, probadlo vosotros mismos!

[Bardales]

Fenomeno
También cojo sitio por aquí
Entre tanto que publicais, me estais haciendo mas larga la espera

Originalmente Escrito por moludo

...

Huy, veo que has quitado la definición de inglés.

[dnfuentes]

Mola!!
Pilló sitio por aquí!!

[moludo]

Originalmente Escrito por Bardales

Fenomeno
También cojo sitio por aquí
Entre tanto que publicais, me estais haciendo mas larga la espera

Este gobernador, excepcionalmente raro para el mundo de los dispositivos móviles, permite que cualquier programa ejecutado por el usuario para establecer la frecuencia de funcionamiento de la CPU. Este gobernador es más común entre los servidores o PCs de escritorio en una aplicación (como una aplicación de perfil de energía) necesita privilegios para ajustar la velocidad de reloj de la CPU.

Huy, veo que has quitado la definición de inglés.

Si porque era un lio de entender, y es basicamente lo que he puesto en castellano. Pero gracias!

[Bardales]

Originalmente Escrito por moludo

Si porque era un lio de entender, y es basicamente lo que he puesto en castellano. Pero gracias!

Ahhh esque estaba pensado en traducir lo que puedo y ponerlo ahí en ese post reservado y que lo pongas. Si quieres claro!?
Más que nada es por el tiempo. Ya que a veces es mejor cortar, pegar que darle vueltas y tratar de escribirlo en castellano.

Saludos

[moludo]

ya , eso es cierto, pero prefiero entenderlo y tratar de dar yo una explicacion mas entendible. pero gracias!!

[Bardales]

Originalmente Escrito por moludo

ya , eso es cierto, pero prefiero entenderlo y tratar de dar yo una explicacion mas entendible. pero gracias!!

Vale. No problem

[Algo333]

Muy buen tutorial de como elegir la mejor opción. Muchas gracias por las aclaraciones de este post!!!

Este post se merece una chincheta.

[zxspectrun]

Uff!!! bravo, tremendo post, varias veces he estado divagando por la web, intentando empaparme sobre el tema y nunca me ha quedado tan claro

[Bundy]

Un aporte de la ostia....me lo leeré, no se cuando, con tiempo. De todos modos soy bastante escéptico en cuanto a la efectividad real de estos ajustes.

[dnfuentes]

Originalmente Escrito por Bundy

Un aporte de la ostia....me lo leeré, no se cuando, con tiempo. De todos modos soy bastante escéptico en cuanto a la efectividad real de estos ajustes.

Aunque milagros no hacen, se nota mejoria.

[Jota_zgz]

CRACK!

Gracias.

[N3xus22]

uno de los mejores hilos que se ha creado en este foro, chapó por el OP.

saludos

[jemjem73]

Me encanta el post. Expones claramente conceptos bastante dificiles de entender. Yo también apoyo que se ponga una chincheta a este post.

[jmas80]

Que buen trabajo, gracias por toda la información

[moludo]

Aun continuo traduciendo etc, iré completando con cosas nuevas etc. Me alegro que sea de ayuda.
Y bundy, como dice dnfuentes, milagros no hace pero se pueden conseguir muy buenos resultados con buenas combinaciónes.
Un saludo

[TRANG]

Bravo, muchas gracias.

Se le podia poner chincheta para que no este por ahi perdido.