Print to PDF without this message by purchasing novaPDF

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

http://www.novapdf.com/


Android es un sistema operativo móvil basado en Linux, que junto con aplicaciones middleware está enfocado para ser utilizado en dispositivos móviles como teléfonos inteligentes, tabletas, Google TV y otros dispositivos. Es desarrollado por la Open Handset Alliance, la cual es liderada por Google. Este sistema por lo general maneja aplicaciones como Market (Mercado) o su actualización, Google Play.

Fue desarrollado inicialmente por Android Inc., una firma comprada por Google en 2005. Es el principal producto de la Open Handset Alliance, un conglomerado de fabricantes y desarrolladores de hardware, software y operadores de servicio.

Tiene una gran comunidad de desarrolladores escribiendo aplicaciones para extender la funcionalidad de los dispositivos. A la fecha, se han sobrepasado las 600.000 aplicaciones (de las cuales, dos tercios son gratuitas) disponibles para la tienda de aplicaciones oficial de Android: Google Play, sin tener en cuenta aplicaciones de otras tiendas no oficiales para Android, como pueden ser la App Store de Amazon o la tienda de aplicaciones Samsung Apps de Samsung. Google Play es la tienda de aplicaciones en línea administrada por Google, aunque existe la posibilidad de obtener software externamente. Los programas están escritos en el lenguaje de programación Java. No obstante, no es un sistema operativo libre de malware, aunque la mayoría de ello es descargado de sitios de terceros.

El anuncio del sistema Android se realizó el 5 de noviembre de 2007 junto con la creación de la Open Handset Alliance, un consorcio de 78 compañías de hardware, software y telecomunicaciones dedicadas al desarrollo de estándares abiertos para dispositivos móviles. Google liberó la mayoría del código de Android bajo la licencia Apache, una licencia libre y de código abierto.

La estructura del sistema operativo Android se compone de aplicaciones que se ejecutan en un framework Java de aplicaciones orientadas a objetos sobre el núcleo de las bibliotecas de Java en una máquina virtual Dalvik con compilación en tiempo de ejecución. Las bibliotecas escritas en lenguaje C incluyen un administrador de interfaz gráfica (surface manager), un framework OpenCore, una base de datos relacional SQLite, una Interfaz de programación de API gráfica OpenGL ES 2.0 3D, un motor de renderizado WebKit, un motor gráfico SGL, SSL y una biblioteca estándar de C Bionic. El sistema operativo está compuesto por 12 millones de líneas de código, incluyendo 3 millones de líneas de XML, 2,8 millones de líneas de lenguaje C, 2,1 millones de líneas de Java y 1,75 millones de líneas de C++.

Si ya llevas un tiempo familiarizado con Android, seguramente has escuchado el término Kernel. Mucho se habla de él y pocos saben realmente de que se trata.




El Kernel (Núcleo) es la parte fundamental del sistema operativo y es el que se encarga de dar acceso del hardware a los programas. Digamos que es el encargado de recoger y gestionar las ordenes que le llegan de las aplicaciones y mandárselas al hardware para después recoger las respuestas y devolverlas a las aplicaciones, por ejemplo, el desbloquear la pantalla al pulsar un botón. Es el corazón de cualquier sistema operativo.

En pocas palabras: "El Kernel es un conjunto de programas que logran conectar el hardware del equipo con el software, en este caso, el sistema operativo Android.". Android tiene como núcleo Linux, específicamente el Kernel 2.6.0. En este núcleo existe lo que han llamado como Dalvik, una máquina virtual de Java(JVM), que ha sido creada por Google para dispositivos con poca memoria y poca capacidad de proceso. En Android, cada aplicación corre en su propio proceso y tiene su propia instancia en la máquina virtual Dalvik. Una máquina virtual es como si tuviésemos un ordenador independiente en donde se ejecutan las aplicaciones, estas aplicaciones están desarrolladas en Java con las funcionalidades que les ofrece el SDK de Android. Las aplicaciones se ejecutan en la máquina virtual y esta a su vez se ejecuta sobre el kernel. Dalvik ejecuta archivos .dex en lugar de los clásicos .class de la máquina virtual de Java de escritorio. Éstos están más optimizados para los dispositivos móviles y son más compactos. En esta máquina virtual no disponemos de toda la API de JavaSE o JavaME, sino que podemos utilizar un subconjunto llamado Core Libraries, que han desarrollado los ingenieros de Google únicamente para Android.




GOVERNORS I) MANUAL: Acá hablaremos de 19 governors. 1) Ondemand 2) Ondemandx 3) Conservative 4) Interactive 5) Interactivex 6) Lulzactive 7) Smartass 8) SmartassV2 9) Intellidemand 10) Lazy 11) Lagfree 12) Lionheart 13) LionheartX 14) Brazilianwax 15) SavagedZen 16) Userspacce 17) Powersave 18) Performance

1) Ondemand:

Es el governor por defecto en casi todos los kernels stock. Una de las principales características de este governor es la de cambiar a la máxima frecuencia tan rápido como lo requiere el CPU asegurándose de la responsabilidad del system. Efectivamente, usa la ocupabilidad del CPU usando el parámetro “Cuan crítico es el rendimiento en este momento”. Así que el CPU salta a la máxima frecuencia mientras lo amerita el uso y baja de forma gradual cuando el CPU esta menos cargado o aprovechado en el fondo. Aunque muchos de nosotros consideramos este governor como uno de los mejores, suele quedarse corto en cuanto al ahorro de la batería y al rendimiento en los parámetros por defecto. Una de las razones potenciales para que el ondemand governor no tenga un grandioso “performance” es que ese governor decide la próxima frecuencia al mínimo de requerimiento durante un intervalo simple. Esta mínima frecuencia de requerimiento es la




responsable del cambio de requerimiento pero usualmente no se refleja en la carga real del CPU lo que probablemente causa el cambio frecuente entre las frecuencias altas y las bajas.

2) Ondemandx: Básicamente es un ondemand con perfiles supend/wake. Este governor está dirigido a ser amistoso con la duración de la batería. Cuando la pantalla está apagada, la máxima frecuencia se queda suspendida en la 500 MHz. Incluso aunque ondemand es el governor por defecto de muchos kernels stock y considerado como el más seguro y estable, el soporte de ondemand/ondemandX depende de la capacidad del CPU para hacer el cambio de frecuencia y las transiciones de las mismas.

3) Conservative: Es un poco más lento que el governor ondemand ya que sube de escala lentamente para salvar batería. El governor conservative está basado en el governor ondemand. Funciona básicamente igual ajustando dinámicamente las frecuencias basadas en la utilización del procesador. Como sea, el governor conservative incrementa y reduce la velocidad del CPU de manera más gradual. Simplemente, sube la frecuencia paso a paso sin saltar una y baja rápidamente la frecuencia de manera drástica ajustándola al uso que se le da de forma progresiva al CPU, dejando a un lado el salto a la máxima frecuencia. El factor “sampling down factor” actúa como un multiplicador negativo del “sampling rate” para reducir la frecuencia que el “scheduler” usa. Por ejemplo (para que sea entendido) si el ”sampling rate” es igual a 20.000 y el “sampling down factor” es 2, el governor utiliza el cambio de frecuencia del CPU cada 40.000 microsegundos. 4) Interactive: Puede ser considerado más rápido que el ondemand. Mas rápido = menos batería. Interactive está diseñado por para un estado latente interactuando con el trabajo de carga del CPU. En lugar de tomar una muestra en cada intervalo como lo hace ondemand, determina como la escala sube cuando el CPU corre fuera de profundidad. Este governor presenta unas ventajas, por ejemplo: a) Mayor consistencia, porque lo que hace básicamente es cargas los parámetros del CPU en un contexto “workqueue”, pero lo hace en un contexto temporal, que te da más consistencia en la carga de muestra del CPU. b) Mayor prioridad en el incremento de la frecuencia del CPU, así le da mayor mantenimiento a las tareas del CPU dándole el beneficio al rendimiento. Es mas “inteligente” que el ondemand por la estabilidad de las optimizaciones. Por qué?? Las muestras del CPU cargan cada “X” microsegundos (como el ondemand) pudiendo ahorrar batería con el encendido del CPU cada “X” microsegundos, Que conduce a pérdida de fotogramas, la interacción de interfaz de usuario, etc. en lugar de un muestreo del CPU a una velocidad determinada, el governor interactive comprobará si es preciso potenciar la frecuencia de la CPU hasta poco después de salir de la inactividad. Cuando la CPU sale de reposo, un temporizador está configurado para disparar dentro de 1-2 toques. Si la CPU está muy ocupada entre el reposo y la salida se activa el temporizador, entonces asumimos que el CPU es el poder suficiente y la rampa a la frecuencia máxima. 5) Interactivex: Es como el anterior pero con unos retoques en cuanto a los perfiles. Más amigable con el uso de la batería.




6) Lulzactive: Un Nuevo governor que viene de Tegrak y está basado en los governors interactive y smartass (es uno de los más populares). Nueva Versión: Cuando la carga es mayor que o igual a 60%, el governor escala al siguiente paso superior. Cuando la carga de trabajo es inferior al 60%, el governor escala al siguiente paso inferior. Cuando la pantalla está apagada, la frecuencia se bloquea a la frecuencia mínima. Nueva Versión: agrega 3 parametros configurables: inc_cpu_load, pump_up_step, pump_down_step. A diferencia de la versión anterior, ésta ofrece un mayor control para el usuario. Podemos establecer el umbral en el que el governor decide escalar hacia arriba / abajo. También se puede fijar el número de etapas de frecuencia que hay que saltar en el sondeo de arriba y abajo. 7) Smartass: Es el resultado de la “re escritura” del código del governor interactive por parte de Erasmux. El objetivo principal es el ahorro de la batería sin comprometer el rendimiento. No es tan amistoso con la batería como lo es el smartassV2 dado que con la pantalla encendida la frecuencia mínima es mayor que las frecuencias usadas durante la pantalla apagada. Este governor tiene la particularidad de saltar a la frecuencia alta con demasiada frecuencia. 8) SmartassV2: La segunda versión del governor smartass de Erasmux. Otro favorito de muchas personas. Este governor busca la “frecuencia ideal” y por encima de forma más agresiva hacia esta frecuencia y menos agresivas después. Utiliza diferentes frecuencias ideales para la pantalla de encendido y para la pantalla apagada, es decir, awake_ideal_freq y sleep_ideal_freq. Este governor escala la frecuencia del CPU hacia abajo muy rápido (para alcanzar sleep_ideal_freq de manera más efectiva), mientras que la pantalla está apagada y sube rápidamente a awake_ideal_freq (500 MHz para el GS2 por defecto) cuando la pantalla está encendida. No hay límite superior de frecuencia, mientras que la pantalla está apagada (a diferencia de Smartass). Así que el rango de frecuencias está disponible para el governor para su uso durante la pantalla-y el estado de la pantalla-off. El lema de este gobernador es un equilibrio entre el rendimiento y la batería. 9) Intellidemand: Conocido como El Ondemand Inteligente, otro governor basado en ondemand con algunas particularidades extra. A diferencia de lo que algunos usuarios creen, este gobernador no es el sustituto de Daemon OC (Tener diferentes gobernadores para los modos de encendido y apagado). El original de intellidemand se comporta de manera diferente según el uso de GPU. Cuando la GPU está muy ocupado (juegos, mapas, benchmarking, etc.) intellidemand se comporta como ondemand. Cuando la GPU esta “medio activo” (o con una actividad moderada), intellidemand limita la frecuencia máxima de un paso en función de las frecuencias disponibles en el kernel para ahorrar batería. Esto se denomina modo de navegación. Podemos ver algunos de los rastros del governor interactivo aquí. La Frecuencia de ampliación se basa en el tiempo de




inactividad del CPU. Bajo el tiempo de inactividad (<20%) hace que el CPU aumente la escala de la frecuencia actual. En resumen, se trata de un ondemand inteligente que entra en modo de navegación para limitar la frecuencia máxima en la GPU en el punto muerto, y (las salidas de modo de navegación) se comporta como ondemand, cuando la GPU está ocupado, para ofrecer un rendimiento ideal para juegos . Intellidemand no salta a la frecuencia más alta cuando la pantalla está apagada. 10) Lazy: Este governor hecho por Ezekeel es básicamente un ondemand con algunos parámetros adicionales (min_time_state) específicamente para controlar el mínimo tiempo en el cual el CPU debe estar en cada frecuencia antes de subir o descender a otra. La idea de este governor es eliminar cualquier inestabilidad causada por el cambio rápido de frecuencia. Lazy governor es mas como el ondemand pero cambia frecuencias solo cuando se completa el min_time_state en cada paso sobre leyendo el intervalo de la frecuencia. Tiene una frecuencia screenoff_maxfreq la cual se active cada vez que el governor selecciona la máxima frecuencia. 11) Lagfree: La diferencia más grande que caracteriza a este governor es su gran capacidad de ser más amigable con la bacteria (a costa de una gran pérdida en el rendimiento). Este governor no salta ninguna frecuencia por lo que para pasar de una a otra tiene que cumplir con todas las etapas. Otras de las desventajas de este governor es que suele presentar algo de retraso en la reproducción de contenido multimedia. 12) Lionheart: Está basado en el governor conservative el cual a su vez está basado en los recursos proporcionados por Samsung. Los valores ajustables (por ejemplo, los umbrales y la frecuencia de muestreo) fueron cambiados, por lo que el governor se comporta más como uno de rendimiento, a costa de la batería la cual consume muy rápido. 13) LionheartX Esla segunda versión del anterior con unos pocos cambios basados en el governor smartass, lo cual lo hace más amigable con la batería pero siguiendo el mismo patrón de consumo. 14) Brazilianwax: Similar al smartassV2, más agresivo subiendo las frecuencias lo cual se traduce en un mayor rendimiento pero a un alto coste de la bacteria. 15) SavagedZen: Otro governor basado en el SmartassV2. Tiene un gran balance entre rendimiento y batería comparado con el brazilianwax.




16) Userspace: En realidad este governor es algo confuso ya que no posee una clara determinación en cómo funciona, pero puede resumir su funcionamiento en que determina de manera automática las frecuencias que son usadas. 17) Powersave: En teoría su función es usar lo menos posible las máximas frecuencias y usar mas las frecuencias mínimas, una gran desventaja de este governor es que al hacer esto suele quedar el teléfono congelado lo cual ocasiona un lag impresionante y una baja en la calidad de rendimiento del teléfono. 18) Performance: Este governor hace que el CPU trabaje al máximo de su capacidad, no es recomendable para uso diario ya que recalienta el CPU y puede ocasionar que se queme, úsalo solo en ciertas ocasiones especiales o cuando hagas benchmarks de resto mantente alejado de este tipo de governor. II) PARAMETERS & TWEAKS: [Solo Ondemand, Conservative, SmartassV2, Lulzactive e Interactive; son los preferidos y los que tienen todos los kernels.] Cada governor tiene parametros diferentes pero para una comprension sencilla les explicamos lo siguiente: 1) Sampling Time/Rate la función de sondeo determina la frecuencia para “sondear” y decidir si la frecuencia debe ser reducida o incrementada. [Algunos governors tendrán tiempo de muestreo diferente para expandir la cobertura o la ampliación hacia abajo] 2) Thresholds Cuando la carga de la CPU llega a este punto, las escalas del governor hacia arriba o hacia abajo poseen ciertos parámetros de la CPU. [La mayoría de los governors tendrán que bajar del umbral, por lo que la CPU escala hacia arriba o abajo, respectivamente.

Hay otros parámetros o factores también, pero todos estan de alguna manera relacionados con estos dos parámetros.

1.ONDEMAND

[ SAMPLE TWEAKS ]




i) For battery:-

Code:

echo "95" /sys/devices/system/cpu/cpufreq/ondemand/up_threshold echo "120000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate echo "1" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor echo "5" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential

ii) For performance:-

Code:

echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold echo "50000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate echo "2" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor echo "15" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential

2.LULZACTIVE

i) For battery:-

Code:

echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step echo "2" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step


Code:





iii) For balanced-performance:-

Code:


3.SMARTASSV2

[ SAMPLE TWEAKS ]

i) For battery:-

Code:

echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq; echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq; echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq echo "85" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load; echo "70" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load; echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step; echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step; echo "48000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us echo "49000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us





Code:

echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq; echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq; echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq echo "75" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load; echo "45" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load; echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step; echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step; echo "24000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us echo "99000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us

4.CONSERVATIVE

[ SAMPLE TWEAKS ]

i) For battery:- [

Code:

echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step





Code:

echo "60" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold echo "40000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate echo "5" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor echo "20" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold echo "25" > /sys/devices/system/cpu/cpufreq/conservative/freq_step

5.INTERACTIVE

[ SAMPLE TWEAKS ] i) For battery:-

Code:

echo "95" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load echo "1000000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq echo "10000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate


Code:

echo "80" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load echo "1400000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate

I/O SCHEDULERS Que se supone que hace un i/o scheduler???

Reduce al mínimo la búsqueda del disco duro. Da prioridad a las peticiones de los procesos. Asigna ancho de banda de disco para los procesos en ejecución. Garantiza que las solicitudes antes de una fecha límite.

Que metas tiene cada scheduler???

Equidad (cada proceso tiene su cuota de acceso al disco) Rendimiento (tratar de atender las solicitudes cercanas a la posición actual del disco en

primer lugar). En tiempo real (garantía de que una solicitud es atendida en un tiempo determinado).




Descripción, ventaja y desventaja de cada I/O Scheduler 1) Noop Inserta todas las peticiones entrantes de I/O a un primer lugar, los implementos para esta solicitud se fusionan. Se recomienda utilizar este scheduler con dispositivos de almacenamiento que no dependen de movimiento mecánico para acceder a los datos (sí, como nuestras unidades flash). La ventaja aquí es que las unidades flash no requieren reordenamiento de las múltiples peticiones I/O a diferencia de los discos duros normales. Ventajas:

Sirve peticiones con menor número de ciclos de CPU. (Amistoso con la batería?) Lo mejor para las unidades flash ya que no hay pena de búsqueda. Buen rendimiento en los sistemas de adb.

Desventajas:

Reducción en el numero de ciclos del CPU usado, lo que se traduce como una perdida en el rendimiento.

2) Deadline El objetivo es minimizar las peticiones de una solicitud. La misma se logra mediante una política de todos contra todos para ser justos entre múltiples peticiones. Cinco colas se utilizan para cambiar el orden de manera agresiva de las solicitudes entrantes. Ventajas:

Cercano a un scheduler de tiempo real. Excels in reducing latency of any given single I/O. Sobresale en la reducción de cualquier propuesta única del I / O. Mejor acceso para la base de datos y consultas. El requisito de ancho de banda de un proceso (el porcentaje de CPU) que necesita,

se puede calcular fácilmente. Al igual que noop, un buen programador para unidades flash.

Desventajas:

Cuando el sistema está sobre cargado, realiza procesos que pueden pasar desapercibidos haciéndolo algo impredecible.

3) CFQ Este Scheduler mantiene una escala por proceso y los intentos de distribuir la disposición de ancho de banda en partes iguales entre todas las solicitudes del I/O. Cada proceso contiene




solicitudes sincronizada a un Intervalo de tiempo asignado para cada cola, dependiendo de la prioridad del "padre" del proceso. V2 de CFQ tiene algunas correcciones que buscan mejorar la capacidad de respuesta. Ventajas:

Considerado en un distribuidor entre balance y rendimiento. Fácil de modificar. Excelente en sistemas con multiprocesadores Mejor rendimiento con la base de datos del sistema después del punto muerto.

Desventajas:

Algunos usuarios reportan que el acceso a contenidos multimedia tomas más tiempo en completarse usando este scheduler. Esto puede ser porque las propiedades del ancho de banda se distribuye igual a todas las operaciones del I/O durante el reinicio, el escaneo multimedia no da ninguna prioridad especial.

Variación (en el peor de los casos lag) puede ser en algunas ocasiones muy graves, esto se debe al número alto por el cual las tareas compiten por espacio en el disco.

4) BFQ En lugar de la asignación del tiempo en los ciclos como lo hace CFQ, BFQ asigna “presupuestos”. El CPU se mantiene en un proceso activo hasta que el “presupuesto” (número de sectores) expira. BFQ asigna altos presupuestos a las tareas no leídas, asignado a un proceso una función de su comportamiento

Ventajas:

Se cree que es uno de los mejores en cuanto a la transferencia de data por medio de usb.

Se considera uno de los mejores scheduler en cuanto a la reproducción y grabación de video en HD comparado con otros.

Un scheduler con alto porcentaje de certeza Considered an accurate i/o scheduler. Puede alcanzar un rendimiento de 30% más alto que otros scheduler.

Desventajas:

No es el mejor scheduler para los benchmarking. El presupuesto superior asignado a un proceso puede afectar a la interactividad y el

aumento de la latencia.




5) SIO Simple scheduler que tiene como objetivo mantener los gastos al mínimos para lograr una baja latencia y así lograr atender las solicitudes del I/O. No hay prioridad de conceptos, pero su principal atractivo es la fusión única de base. Sio es una mezcla entre noop y deadline. Ventajas:

Simple y confiable. Minimiza el envío de solicitudes.

Desventajas:

Disminuye la velocidad de lectura en las unidades flash en comparación a otros scheduler.

La velocidad en la lectura secuencial tampoco es tan Buena.

6) V(R) A diferencia de otros programadores, las solicitudes sincrónicas y asincrónicas no se tratan por separado, en lugar de una frecuencia existe una frecuencia impuesta. La siguiente petición se basa en la distancia desde la última solicitud. Ventajas:

Puede que sea el mejor para los benchmark porque en el tope de su funcionamiento es mayor el rendimiento.

Desventajas:

En algunas ocasiones el rendimiento en cuanto a fluctuación puede ser por debajo del promedio.

Menos fiable / más inestable.




Todos los créditos para

Codeworkx Gokhanmoral Droidphile Chainfire Arighi Tegrak Vitalij Entropy512 Netarchy Koush Creams sk8erwitskil Hardcore Pikachu Myfluxi Kang Team Team Hacksumg Cyanogenmod




Print to PDF without this message by purchasing novaPDF

Documents

Transcript of Print to PDF without this message by purchasing novaPDF