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

Hace unos días le pedí al compañero @moludo que me dejará poner su trabajo por aquí y me ha dado permiso.
Consiste en una recopilación de todo (o casi todo lo relacionado con el kernel)
Dadle las gracias a él por el tremendo curro que se ha pegado con esta recopilación

Yo me voy a limitar a poner los más importante, si queréis leer mas, pasaos por su tema

FUENTE ORIGINAL
http://www.htcmania.com/showthread.php?t=960455

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

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)

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.

[Chelis59]

Muy buen trabajo alexret. Gracias y Saludos

[moludo]

Alex, yo pondría mas informacion. Sobre todo lo ideal. Me refiero a los ideales para cadabcosa. Además de redireccionar al hilo de perfiles. Normalmente la gente prefiere saber que es mejor o peor , que información pura y dura.

[sexter]

Saaaaaannnntttioooooo diossss, que hilo mas de puta madreeee. La de horas de Google que me habría ahorrado de haberlo tenido hace unos años, y la de horas que me voy a ahorrar aún así!!!! Muchisimas gracias por este curro. Con esto aquí, cualquier pregunta al respecto debería ser muy esporadica. Enorme, insisto, muchas gracias moludo y alex

Enviado desde mi MI 3W mediante Tapatalk

[hondapanan]

Este kernel funciona, por ejemplo, con Miko 30?
Gracias y fenomenal curro te has pegado. Se agradece.