About Mobile Cluster Simulator

Generalidades sobre el comportamiento de cluster móvil soportado por el simulador
---------------------------------------------------------------------------------
 El simulador permite evaluar el desempeño de planificadores de trabajos (Job Scheduling) sobre agrupamientos de dispositivos móviles (Mobile Cluster Computing). El principal objectivo que se persigue al evaluar el desempeño de los planificadores es determinar la eficiencia en el uso de la energía disponible de los dispositivos móviles proveedores de recuros. Esto se resume contando la cantidad de trabajos completados. Se entiende que el planificador que más trabajos logre completar, es el que mejor aprovecha dicha energía. De ahí que la principales características modeladas de los dispositivos móviles es el consumo de batería causado por el uso de CPU, y de manera más simplificada, el consumo de batería causado por la transferencia de datos (envío y recepción) a través de una conexión WiFi con distintos niveles de calidad de señal. Esto permite evaluar planificadores trabajos cuyos requerimientos no se limitan al uso de CPU sino también a la transferencia de datos de entrada y/o salida. En todo caso, los trabajos se asumen pertenecientes a un único usuario e independientes, es decir, no existe un orden de precedencia que defina cuando deben ser ejecutados.
 Respecto al modelado de los canales de comunicación entre nodos, si bien está contemplada la posibilidad de configurar una topología ad-hoc, por defecto, se adopta una topología de Cluster tipo estrella, donde un nodo tipo hub, llamado proxy y con energía infinita, mantiene una conexión con cada uno de los nodos proveedores de recursos (dispositivos móviles), y estos a su vez, mantienen una conexión sólo con el nodo proxy. El ingreso de un nodo proveedor al cluster implica el establecimiento de una conexión con el proxy y la registración de sus atributos que incluyen: su nivel de batería actual medido en porcentaje, su capacidad energética total medida en Joules, su capacidad de procesamiento medida en MFLOPS, la calidad de señal de la conexión, entre otras que pueden aplicar a información requerida por algún planificador en particular. La permanencia de un nodo proveedor de recursos al cluster se rige por la energía disponible en su batería. Los nodos cuyo nivel de batería desciende por debajo del 1% se desconectan del proxy, causando la pérdida de los trabajos encolados en dicho nodo. Mientras se encuentran activos, los dispositivos móviles notifican al proxy cada vez que su nivel de batería disminuye en un 1%.
 Salvando el caso del planificador de lógica decentralizada (Job Stealing), la mayoría de los planificadores implementados son centralizados. Esto último implica que las decisiones de planificación de trabajos se toman en un único nodo (el nodo proxy). El proxy, no ejecuta trabajos sino que los asigna a un dispositivo móvil de acuerdo al criterio del planificador configurado. La asignación puede ser online o batch. La de tipo online asigna un trabajo tan pronto como este es recibido por el proxy. La de tipo batch espera a que un conjunto de trabajos se acumulen en el proxy para luego aplicar el criterio de asignación sobre el conjunto de trabajos.

Sobre la ejecución de trabajos en un nodo
--------------------------------------------------------------------------
 
Cada dispositivo cuenta con una cola de trabajos ilimitada donde se alojan los trabajos asignados por el proxy. La ejecución de trabajos de la cola de un dispositivo avanza de manera secuencial, de a uno por vez de manera ininterrumpida, sin concurrencia ni paralelismo. Recién cuando finaliza la ejecución de un trabajo, el dispositivo comienza a ejecutar el siguiente de la cola. Mientras el nodo atiende el siguiente trabajo de la cola, paralelamente puede estar transmitiendo hacia el proxy la salida producida por el último trabajo finalizado, y/o recibiendo otro trabajo asignado por el proxy.
La ejecución de un trabajo implica sólo uso de CPU, cualquier dependencia de datos del trabajo (job input) se transfiere en el momento que el proxy asigna el trabajo al dispositivo.
 La ejecución de un trabajo en un dispositivo utiliza tanta CPU como haya disponible. De lo anterior se deriva que si, producto de las acciones del usuario, el uso del CPU es del 30%, entonces la ejecución de un trabajo utilizará el 70% restante, lo que en suma supone un uso del CPU del 100%.

Sobre la salida que el simulador es capaz de producir
-----------------------------------------------------
La ejecución de una simulación deja en pantalla un log de cada uno de los eventos transcurridos incluyendo scheduler y cantidad de trabajos configurados, tiempos en los que cada nodo ingresó y se retiró del cluster; tiempos y cambios de estado de cada trabajo y eventos de actualización del nivel de batería de los nodos.  Al final del log, se imprime una serie de mediciones discriminadas por tipo de nodos que incluyen la cantidad de trabajos finalizados, incompletos y cantidad de robos producidos (el último dato válido sólo en el caso de haber configurado el planificador Job Stealing). Sobre la la simulación se imprime su duración, cantidad de trabajos simulados, tiempo de ejecución de trabajos, tiempo de los trabajos en cola de espera, transferencias de trabajos, entre otros datos. En la sección del log que comienza en "Net stats summary" se presentan datos referidos al consumo de energía global en transferencia de datos por parte de los nodos proveedores y el volúmen de datos transferidos, discriminados en datos recibidos y datos enviados. Debajo de estos datos agregados se encuentra discriminado por nodo el porcentaje de energía total producido por transferencia de datos. Finalmente, en la sección de log "Jobs states summary" se presenta un resumen del estado de los trabajos, donde:
-Total arrived: se refiere a la cantidad de trabajos recibidos por el proxy.
-Rejected: aplica a trabajos que fueron recibidos por el proxy, tenidos en cuenta por la técnica de planificación pero no asignados a ningún dispositivo móvil. Esta situación aplica especialmente a los planificadores batch.
-Scheduled but transfered interrupted: aplica a trabajos que fueron asignados a nodos pero su transferencia fue interrumpida, es decir, el nodo destino nunca llegó a recibir el trabajo.
-Completed: aplica a trabajos que fueron ejecutados y su salida correspondiente fue recibida por el proxy.
-FinishedButNotCompleted: aplica a trabajos que fueron ejecutados pero la transferencia de su salida quedó incompleta.
-StartedButNotFinished: aplica a trabajos que comenzaron a ser ejecutados por un nodo pero dicha ejecución quedó trunca, es decir, el nodo nunca llegó a producir la salida correspondiente.
-Queued: aplica a trabajos que permanecieron en la cola de espera del dispositivo, es decir, que nunca llegaron a obtener la CPU.
-Not Scheduled: aplica a los trabajos que fueron recibidos por el proxy pero nunca llegaron a ser includidos en el proceso de planificación.

Además de ser logeada por salida estandar, mucha de esta información (a excepción de los datos indicados en las secciones del log "Net stats summary" y "Jobs states summary") es persistida en un modelo relacional. 


Sobre detalles de implementación del simulador
----------------------------------------------

Las caracteristicas del simulador descriptas anteriormente se implementan mediante un sistema basado en eventos. El arribo de un trabajo al cluster, la incorporación y baja de los nodos, la asignación y finalización de trabajos, las transferencias, etc., son representados mediante eventos. Este sistema basado en eventos se compone de varios proyectos, cada uno con un nivel de abstracción diferente. A continuación se brinda un panorama de los proyectos que componen el simulador.

Simulator: las clases contenidas en este proyecto modelan conceptos abstractos del sitema basado en eventos tales como las entidades, eventos, cola de eventos y simulación. Los eventos son generados por una entidad y consumidos o atendidos por otras. Al crearse, los eventos se insertan ordenados cronologicamente en la cola de eventos y la simulación avanza consumiendo eventos de dicha cola e invocando los métodos processEvenet implementados por las entidades interesadas en el evento en cuestión.

MobileGrid: las clases contenidas en este proyecto modelan conceptos más concretos que la clases del proyecto Simulator. En este proyecto se encuentan las clases mediante las cuales se representan los siguientes conceptos (entre parentesis se indical el nombre de la clase o interface java):
-Trabajo (edu.isistanMobileGrid.jobs.Job)
-Estadísticas de trabajo (edu.isistanMobileGrid.jobs.JobStats)
-Vinculos entre nodos (edu.isistanMobileGrid.network.SimpleNetworkModel, edu.isistanMobileGrid.network.Node, edu.isistanMobileGrid.network.Link)
-Dispositivo (edu.isistanMobileGrid.node.Device)
-Componentes de un dispositivo encargados de modelar aspectos tales como la ejecución propiamente dicha de trabajos, el desgaste de bateria y la transmisión de datos (edu.isistanMobileGrid.node.ExecutionManager, edu.isistanMobileGrid.node.BatteryManager y edu.isistanMobileGrid.node.NetworkEnergyManager respectivamente)
-Nodo proxy (edu.isistanMobileGrid.node.SchedulerProxy)
-Persistencia de información generada durante la simulación y comunicación con la base de datos (package edu.isistanMobileGrid.persistence).

MobileGridSimulation: las clases contenidas en este proyecto son instanciaciones de los conceptos representados por varias de las clases contenidas en el proyecto MobileGrid. Por ejemplo, contiene los distintos planificadores, la implementación de los componentes de los dispositivos y clases relacionadas con la configuración de los parametros de simulación. A continuación un resumen de lo que puede encontrarse en cada paquete del proyecto (A no confundir: los nombres de los paquetes pueden no representar fielmente lo que contienen, por ejemplo, gridgain no es utilizado en ninguna parte de los proyectos sin embargo figura en varios nombres de paquetes. Está planificada una actualización de nombres y posible reorganización de clases)
-edu.isistan.gridgain.information.comparator.seas y edu.isistan.gridgain.information.comparator.tradeoff: contienen clases que modelan distintos criterios de planificación de trabajos intensivos en CPU. 
-edu.isistan.gridgain.spi.loadbalancing.energyaware: contiene la clase que modela la lógica de scheduling tipo online.
-edu.isistan.persistence.mybatis: contiene clases que permiten la persistencia de información utilizando el mapeador objeto-entidad-relacion MyBatis
-edu.isistan.seas: Contiene la clase desde la cual se lanza una simulación.
-edu.isistan.seas.network: contiene una especialización de la clase BroadCastLink
-edu.isistan.seas.node: contiene las implementaciones de los componentes de un dispositivo.
-edu.isistan.seas.node.jobstealing: contiene clases que implementan el comportamiento activo de los dispositivos cuando se utiliza la técnica de planificacion descentralizada denominada job stealing.
-edu.isistan.seas.proxy.jobstealing: junto al subpaquete condition, contienen clases que definen el comportamiendo del nodo proxy cuando se utiliza la técnica de planificación descentralizada job stealing.
-edu.isistan.seas.proxy: contiene clases que implementan distintos mecanismos de asignación de trabajos centralizados. Por ejemplo, DataIntensiveScheduler define un comportamiento común de proxy que tiene en cuenta los datos de entrada y salida de los trabajos. LazyProxy, es un proxy que asigna trabajos intesivos en CPU asumiendo que los nodos son capaces de encolar sólo un trabajo. RandomProxy, implementa un proxy que asigna trabajos intensivos en CPU de forma random. El paquete también contiene criterios de asignación de trabajos intensivos en Datos o mixtos, ej. RemainingDataTransferingEvaluator, RSSIEnergyPercentageEvaluator, etc. 
-edu.isistan.seas.proxy.bufferedproxy: contiene clases que implementan diversas técnicas de scheduling batch. Todas estas técnicas son aplicables a trabajos intensivos en datos.
-edu.isistan.seas.proxy.bufferedproxy.genetic: contiene todas las clases relacionadas con la ejecución del algoritmo genético simple, pensado para planificar trabajos intensivos en datos. Operadores de mutación, cruce, seleción, clases de configuración, condición de terminación, etc., se encuentran contenidas en este paquete y los subpaquetes anidados.
-edu.isistan.seas.proxy.dataevaluator: contiene clases que sirven para evaluar la calidad de una planificación de trabajos intensivos en datos de acuerdo a diversos criterios. 
-edu.isistan.seas.reader: contiene clases relacionadas con la carga, lectura y parseo de parametros de simulación, nodos y trabajos.
-edu.isistan.seas.util: clases miscelaneas.

FileGenerator: este proyecto contiene clases que no hacen al funcionamiento del simulador sino que sirven para generar parte de la entrada que utiliza el simulador. Concretamente, el paquete "edu.isistan.jobs" contiene clases que sirven para generar trabajos intensivos en CPU, intensivos en datos o mixtos. El paquete "edu.isistan.baseprofile" y los paquetes anidados sirven para generar perfiles de uso base de un dispositivo.


Ejecutar una simulación desde el IDE eclipse
--------------------------------------------

1- Crear un workspace e incluir los proyectos arriba mencionados.
2- Click derecho sobre el proyecto "MobileGridSimulation-signal-strength-branch" -> Run as -> Run Configurations
3- Crear una "Java application Run configuracion" configurando como clase principal la clase "edu.isistan.seas.Simulation". Como argumentos, se debe indicar un único archivo, con un formato específico que contiene todos los parámetros de la simulación. El directorio "MobileGridSimulator/branches/signal-strength-branch/sim_input" contiene varios ejemplos de archivos de configuración de parámetros. Proveyendo la ruta relativa de cualquiera de ellos en el cuadro de texto donde se indican los argumentos de la aplicación java que estamos configurando, por ejemplo, "sim_input/sim-EnhSEAS-20A100-30GalaxyTab2-50L9-0-LSHD.cnf", y presionando el botón "run" debiera comenzar la simulación. La salida se muestra en la consola del IDE.