Reunion Domingo 26-11-2017

Nos juntamos Bárbara, Carolina y Yo  el Domingo a las 11am.

Desarrollamos los siguientes temas.

  1. Coordinar Reunión con Daniela. Acordamos avanzar en la reunion pendiente con Daniela, dado que su vuelta de Europa era para el 24-11. La idea es proponer la reunión entre el Jueves 7 y el Viernes 15 de Diciembre.
  2. Avanzamos con el documento que Claudia nos pidió completar para el proyecto de investigación. Consultamos con Claudia sobre la sección presupuesto dado que es necesario establecer algunos valores básicos (valor hora hombre nuestra?, valor hora hombre de los desarrolladores?, etc). Quedamos a la espera de la respuesta de ella para terminar de completar la planilla.
  3. Enviamos el documento para CAECE con las actividad y fechas estimadas
  4. Seleccionamos la herramienta para el prototipado de pantallas en el proyecto (Pencil). Se repasaron las posibles herramientas. Se llego a la conclusion que la mejora herramienta a usar en el proyecto es la herramienta Pencil (open source). Los motivos: Ofrece la funcionalidad necesaria de manera open source, su uso full no tiene vencimiento.
  5. Se coordinaron las actividades a realizar durante el mes de Diciembre.
  6. Durante Diciembre, avanzaremos con la documentación detallada de los requerimientos.

Quedamos en juntarnos nuevamente Sabado 2-12 a las 11am.

 

 

 

Reunión Interna de Equipo 11-11

En la reunión del día de hoy , se tocaron los siguientes puntos:

  1. Se agendaron las vacaciones para coordinar las tareas:
    • Bárbara todo diciembre
    • Andrés 7 de enero y 3 semanas
    • Carolina 1er semana de enero + fines de marzo y principio de abril
  2. Se definió Volere como estándar de documentación
  3. Se está analizando la herramienta para el prototipo de pantallas. La semana que viene se definirá cuál utilizar
  4. Se definió como metodología de trabajo un híbrido entre ágil y cascada, teniendo iteraciones de definición funcional y de prototipado con Marta y luego iteración de desarrollo y validación con el equipo de desarrollo

Entrevista con Marta 11-10

El día 11-10 nos reunimos con la referente de la fundación ATAR, Marta, para comentarle nuestra visión sobre la pagina web y validar con ella que la misma estuviera alineada con lo que esperan.

Los puntos que se tocaron fueron los siguientes:

  • Habrá perfiles de usuario, según su interacción con la página. Esto se encuentra relacionado al post anterior realizado por Carolina.
  • Los perfiles médicos podrán cargar información de los pacientes, sus tratamientos y evolución. Esta información será de vital importancia para los análisis posteriores. Cabe aclarar que la información cargada no contendrá datos indentificatorios del paciente.
  • Los médicos podrán ofrecer sus servicios, indicando especialidad. Sobre esto se generará un padrón de Especialistas.
  • Se creara una sección de preguntas frecuentes, en base a la cantidad de consultas que poseen actualmente en su Facebook.
  • Existirá una sección de Clínicas / Hospitales que disponen servicios para los pacientes.
  • Habrá una sección de alojamientos y locales preparados y adaptados para las distintas necesidades.
  • Contara también con una sección de reportes pre armados.
  • ABM de usuarios y permisos.
  • Sección para contacto directo con la fundación.

Se comento también la existencia de paginas en el exterior que podemos tomar como referencia.

Introducción a Openstack

Estructura

Compute (Nova)

Provee servicios para soportar la administración de instancias de máquinas virtuales.

Object Storage (Swift)

Provee soporte para almacenar y cargar datos arbitrariamente en la nube.

Block Storage (Cinder)

Provee de almacenamiento por bloques para instancias de computo.

Networking (Neutron)

Antiguamente llamado Quantum, provee varios servicios de networking a los usuarios de la nube, como dirección IP de administración, DNS, DHCP, balanceo de carga, y grupos de seguridad ( reglas de acceso a la red, como políticas de firewall).

Dashboard (Horizon)

Provee una interfaz web para usuarios y administradores de la nube. Usando esta interfaz, usuarios y administradores pueden aprovisionar, administrar, y monitorizar los recursos de la nube.

Identity service (Keystone)

Es un servicio compartido que provee servicios de autenticación y autorización hacia toda la infraestructura de la nube.

Image service (Glance)

Provee el servicio de administración imágenes de disco, incluyendo descubrimiento de imágenes, registración, y servicios de entrega al servicio de computo, como se necesite.

Actividad n° 6: Manejo de VLANs (Virtual LAN)

Objetivo: Desarrollar una aplicación que, mediante el uso de VLANs, permita crear sub-redes virtuales para distintos servicios que se definirán entre un host origen y un host destino. La topología de red sobre la cual se crearán las sub-redes virtuales, deberá considerar la existencia de al menos 2 switches en el recorrido desde el host origen al host destino (uso de VLAN en acceso + trunk de VLAN)

Etapas:
1) Entender el principio de funcionamiento y aplicación de las VLANs, escribir una breve descripción.
2) Consensuar, definir y publicar cuál sería la maqueta de pruebas.
3) Describir en un diagrama de flujo del funcionamiento que se desea obtener de las VLANs.
4) Investigar si existe código existente para dicha funcionalidad, entender y describir su funcionamiento.
5) Proponer un código para la aplicación solicitada.
6) Integrar la aplicación con lo desarrollado por los demás grupos.
7) Definir métricas para evaluar el desempeño de la aplicación desarrollada y realizar prueba de desempeño (performance).
8) Recopilar información y elaborar informes finales.

Actividad n° 5: Access Control Lists (ACL)

Objetivo: Desarrollar una aplicación que permita construír listas de control de acceso a recursos mediante filtrado.
>> Método de filtrado 1: Por dirección MAC

Etapas:
1) Entender el principio de funcionamiento y aplicación de las ACL, escribir una breve descripción.
2) Consensuar, definir y publicar cuál sería la maqueta de pruebas.
3) Describir en un diagrama de flujo el funcionamiento que se desea obtener de las ACL.
4) Investigar si existe código existente para dicha funcionalidad, entender y describir su funcionamiento.
5) Proponer un código para la aplicación solicitada.
6) Integrar la aplicación con lo desarrollado por los demás grupos.
7) Definir métricas para evaluar el desempeño de la aplicación desarrollada y realizar prueba de desempeño (performance).
8) Recopilar información y elaborar informes finales.

Informe N2

G.U.A.D.A. – Notas sobre Stellarium, Raspberry Pi 3 y OpenGL ES (en desarrollo)

desde 2017-10-26 al 2017-11-09

OpenGL y arquitectura ARM

Para poder llevar a cabo un pequeño estudio de los eventos sucedidos en éstas fechas, es importante considerar a los actores protagonistas: OpenGL (https://en.wikipedia.org/wiki/OpenGL) y el CPU de cuatro-núcleos ARM Cortex-A53 con una frecuencia de 1,2 GHz que monta la Raspberry Pi 3 junto al los 1024Mb de RAM y el modesto GPU VideoCore IV de 400 MHz.

Sobre OpenGL tenemos poco que decir: es un API de renderización gráfica, una de las más extendidas y la más usada en Linux para lograr aceleración de video vía hardware, mediante la interacción con la unidad de procesamiento gráfico (GPU).

Por otro lado, el ARM Cortex-A53 se presenta 10 veces más potente que el CPU del Raspberry Pi 2, y con el agregado de contar con un chip de procesamiento de video, aún manteniendo el ultra bajo costo del board, lo que nos llevó a considerar la misma como punto de partida para el proyecto.

Sin embargo, a pesar de la arquitectura notable del CPU que incluso cuenta con la posibilidad de trabajar en 64bits, no quita que es un procesador ARM, y por lo tanto, del tipo RISC, es decir, de instrucciones reducidas, que típicamente se dividen en instrucciones de entrada, instrucciones de salida e instrucciones de procesamiento de datos.

A diferencia de los procesadores x86 extendidos enormemente en el mundo y que cuentan con arquitectura CISC (de instrucciones complejas), las instrucciones reducidas requieren un manejo distinto de las mismas por parte del sistema operativo, problema que se hace más que notable al momento de ejecutar las miles de millones de variaciones que se realizan a fin de renderizar video con aceleración gráfica por hardware.

En nuestro proyecto, éste proceso debe ejecutarse si o si mediante el GPU, debido a que el CPU no cuenta con el poder suficiente ni la especificidad para llevar a cabo un proceso tan complejo como para procesar video al mismo tiempo que realiza los cómputos asignados por el SO.

OpenGL debería permitir delegar sobre el VideoCore IV los cálculos de punto flotante y otros cómputos específicos de video; pero OpenGL está optimizado para su uso en arquitecturas x86.

Fue ésta necesidad la que derivó en 2003 en la creación de OpenGL for Embedded Systems (OpenGL ES or GLES), un subset de instrucciones que busca extender la funcionalidad del API del que deriva a dispositivos celulares, tabletas y otros dispositivos con arquitecturas de instrucciones reducidas. Sin embargo, el dibujado en pantalla no se limita únicamente al renderizado, sino que suele articularse con APIs soporte como EGL, la cual funciona como una capa de cohesión entre el manejador de ventanas (en nuestro caso, Xorg) y OpenGL.

Rendimiento de Stellarium en nuestro setup ArchLinux @RPi3

El software Stellarium cuenta con un contador de Cuadros Por Segundo (Frames Per Second o FPS) para controlar el rendimiento de la aplicación. Considerando ésto, medir el rendimiento del mismo en nuestro Raspberry Pi nos es muy fácil, por lo que llamamos a la aplicación con el comando stellarium en la consola.

La primera ejecución del software en nuestro setup no resultó según lo esperado: el rendimiento resultante es deplorable. Menos de 1 FPS (entre 0.9 y 0.8 sostenidos) hacen completamente inutilizable el programa.

La razón de ésta baja performance se basa en que el procesamiento de video está siendo exclusivamente computado por el microprocesador central de la Raspberry Pi, cuya arquitectura no da a basto para cambiar de contexto de procesamiento, cómputo, manejo de memoria, y renderización a una velocidad que permita una experiencia de uso aceptable. Así mismo, el hecho de que el procesamiento de video no esté derivándose a nuestra unidad de procesamiento gráfico (GPU) se basa en que Arch debe estar siendo forzado a usar OpenGL y no la versión optimizada con instrucciones reducidas GLES.

Así fue que comenzamos la revisión del entorno Arch, volcando todas las configuraciones disponibles de EGL a stdout (una de las tres conexiones de entrada-salida -o I/O standard streams- con las que cuenta nuestro sistema operativo; stdout es la responsable de devolvernos la información solicitada) usando el comando:

eglinfo

La respuesta al comando fue:

libEGL warning: DRI2: failed to authenticate
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4 (DRI2)
EGL client APIs: OpenGL OpenGL_ES
EGL extensions string:
EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context
EGL_KHR_create_context_no_error EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
EGL_KHR_no_config_context EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context EGL_KHR_wait_sync
EGL_MESA_configless_context
EGL client extensions string:
EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_wayland
EGL_EXT_platform_x11 EGL_MESA_platform_gbm
Configurations:
bf lv colorbuffer dp st ms vis cav bi renderable supported
id sz l r g b a th cl ns b id eat nd gl es es2 vg surfaces
---------------------------------------------------------------------
0x01 32 0 8 8 8 8 0 0 0 0 0x21TC a y y y win,pb,pix
0x02 32 0 8 8 8 8 16 0 0 0 0x21TC a y y y win,pb,pix
0x03 32 0 8 8 8 8 24 0 0 0 0x21TC a y y y win,pb,pix
0x04 32 0 8 8 8 8 24 8 0 0 0x21TC a y y y win,pb,pix
0x05 32 0 8 8 8 8 32 0 0 0 0x21TC a y y y win,pb,pix
0x06 24 0 8 8 8 0 0 0 0 0 0x21TC y y y y win,pb,pix
0x07 24 0 8 8 8 0 16 0 0 0 0x21TC y y y y win,pb,pix
0x08 24 0 8 8 8 0 24 0 0 0 0x21TC y y y y win,pb,pix
0x09 24 0 8 8 8 0 24 8 0 0 0x21TC y y y y win,pb,pix
0x0a 24 0 8 8 8 0 32 0 0 0 0x21TC y y y y win,pb,pix
0x0b 32 0 8 8 8 8 0 0 0 0 0x1e4DC a y y y win,pb,pix
0x0c 32 0 8 8 8 8 16 0 0 0 0x1e4DC a y y y win,pb,pix
0x0d 32 0 8 8 8 8 24 0 0 0 0x1e4DC a y y y win,pb,pix
0x0e 32 0 8 8 8 8 24 8 0 0 0x1e4DC a y y y win,pb,pix
0x0f 32 0 8 8 8 8 32 0 0 0 0x1e4DC a y y y win,pb,pix
0x10 24 0 8 8 8 0 0 0 0 0 0x1e4DC y y y y win,pb,pix
0x11 24 0 8 8 8 0 16 0 0 0 0x1e4DC y y y y win,pb,pix
0x12 24 0 8 8 8 0 24 0 0 0 0x1e4DC y y y y win,pb,pix
0x13 24 0 8 8 8 0 24 8 0 0 0x1e4DC y y y y win,pb,pix
0x14 24 0 8 8 8 0 32 0 0 0 0x1e4DC y y y y win,pb,pix

Considerando los datos destacados en negrita podemos determinar que, efectivamente, nuestra versión de EGL debería poder soportar tanto OpenGL como OpenGL ES(GLES), siendo la segunda la API de aceleración gráfica que debería darnos la mejor performance en nuestro entorno.

Verificando en el directorio /opt/vc/lib/, dimos con las librerías dinámicas (con extensión .so) de GLES. Las mismas funcionan similar a los dll del entorno Windows. El listado completo de librerías disponibles es:

libEGL.so           libbrcmGLESv2.so       libkhrn_static.a       libvchostif.a
libEGL_static.a     libbrcmOpenVG.so       libmmal.so             libvcilcs.a
libGLESv1_CM.so     libbrcmWFC.so          libmmal_components.so  libvcos.so
libGLESv2.so        libcontainers.so       libmmal_core.so        libvcsm.so
libGLESv2_static.a  libdebug_sym.so        libmmal_util.so        pkgconfig
libOpenVG.so        libdebug_sym_static.a  libmmal_vc_client.so   plugins
libWFC.so           libdtovl.so            libopenmaxil.so
libbcm_host.so      libelftoolchain.so     libvcfiled_check.a
ibbrcmEGL.so       libkhrn_client.a       libvchiq_arm.so

Así, ya con la librería identificada, intentamos ejecutar Stellarium forzando su uso con el siguiente comando.

LD_PRELOAD="/opt/vc/lib/libGLESv2.so /opt/vc/lib/libEGL.so" stellarium -platform eglfs

Comando para el cual recibimos el mensaje siguiente mensaje por Terminal.

# LD_PRELOAD="/opt/vc/lib/libGLESv2.so /opt/vc/lib/libEGL.so" stellarium -platform eglfsQStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

Could not find DRM device!

Aborted (core dumped)

Procedimos entonces a instalar fbturbo-86 (como [email protected], es decir, como usuario administrador total del Sistema Operativo, modo al que accedimos usando el comando sudo -i), y aunque presenta colores más brillantes, el rendimiento se mantiene idéntico.

Finalmente, asesorado por un ayudante externo con amplios conocimientos en Linux (NOTA PARA DEOLINDO: puedo dar crédito a mi amigo, aunque no sea parte del CIDI ni alumno de UNSam? me parece que sería lo correcto, porque nos ayudó bocha),  forzamos la exportación de los pasos de ejecución a STDOUT con el comando

export QT_LOGGING_RULES=qt.qpa.*=true

A lo cual, recibimos en volcado en nuestro terminal la siguiente serie de mensajes.

LD_PRELOAD="/opt/vc/lib/libGLESv2.so /opt/vc/lib/libEGL.so" stellarium -platform eglfs

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_emu", "eglfs_kms_egldevice", "eglfs_kms", "eglfs_x11")

qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_kms", "eglfs_emu", "eglfs_kms_egldevice", "eglfs_x11")

qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_kms"

qt.qpa.eglfs.kms: New DRM/KMS via GBM integration created

qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_kms"

qt.qpa.eglfs.kms: platformInit: Opening DRM device

qt.qpa.input: udev device discovery for type QFlags<QDeviceDiscovery::QDeviceType>(Device_DRM|Device_VideoMask)

qt.qpa.input: Found matching devices ()

qt.qpa.eglfs.kms: Found the following video devices: ()

Could not find DRM device!

Aborted (core dumped)

En el stack devuelto no hay ni un registro de eglfs brcm, que es la porción de QT que precisamos para la ejecución con aceleración gráfica en la Raspberry Pi.

Ésta es la razón por la que la performance de Stellarium es inaceptable: todo el procesamiento de video está volcándose al microprocesador, en un esquema de cálculos no optimizados para un CPU sino para un GPU.

Solución transitoria y posibles caminos a seguir.

A fin de salvar la problemática, decantamos por una solución de paso basada en los últimos desarrollos comunicados por la comunidad de desarrollo de Raspberry Pi: la emulación directa de OpenGL x86, nativa como un módulo experimental en la versión Jesse de Raspbian.

Ésto implica reformatear la SD e instalar Raspbian, que es una distro basada en Ubuntu. Su peso es considerablemente más grande, y también la cantidad de módulos que vienen cargados por defecto, aumentando el overhead (cantidad de ciclos consumidos para cambios de contexto, es decir, ciclos de máquina que usa el Sistema Operativo para ordenar el procesamiento de tareas) y quitándonos velocidad de procesamiento. Sin embargo, al contar con la opción experimental de OpenGL, nuestro CPU debería funcionar con mucha menos carga de trabajo que cuando corría sobre Arch.

Siguiendo las instrucciones publicadas en https://www.raspberrypi.org/documentation/installation/installing-images/ , procedimos a llevar a cabo la instalación del nuevo SO.

Terminada la instalación, el siguiente paso consistió únicamente en habilitar el driver experimental.