Actividad 9: Ahorro de Energía

Laboratorio de Redes de Telecomunicaciones
Actividad 9

Nombre del documento:
A Network Connection Proxy to Enable Hosts to Sleep and Save Energy

Autores:
Miguel Jimeno, Ken Christensen y Bruce Nordman

Enlace:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4745133

Introducción

Uno de los retos más urgentes es diseñar nuevas tecnologías que pueden permitir una transición hacia una sociedad más sostenible, con una huella de CO2 reducida. Los hosts de red consumen una gran y creciente cantidad de energía. Los centros de datos y servidores consumen aproximadamente el 1.5% del consumo total de electricidad de los Estados Unidos en 2006, con un costo total de alrededor de $4.5 mil millones de dolares. Sin embargo, aún mayor es la electricidad consumida por los equipos de la red que no están en los centros de datos. La EPA estima que las PC en los Estados Unidos consumen el 2% de toda la electricidad consumida. Se estima que el 9% de la electricidad consumida por los edificios comerciales es de equipo de oficina - mucho de este equipo siendo PCs conectados a la red. Más allá de las PC, son el creciente número de dispositivos comerciales y de consumo - tales como decodificadores y consolas de juego - que están conectados a Internet y se han convertido en máquinas de la red.

http://www.webseoanalytics.com/blog/wp-content/uploads/2011/12/transfer-web-hosting-checklist.jpg

Gran parte de la electricidad consumida por los equipos de la red se desperdicia. Estar conectado a Internet requiere un poco de participación activa. Cuando los hosts no lo hacen, se "caen fuera de la red" y las aplicaciones fallan. Miles de millones de dólares en electricidad cada año se utilizan para mantener los hosts de la red totalmente encendidos todo el tiempo sólo con el propósito de mantener la conectividad de la red. Si no fuera por la necesidad de conectividad de la red la mayor parte de estos hosts podrían estar "dormidos" la mayoría de las veces, con un ahorro significativo de energía resultante. Las encuestas han encontrado que alrededor del 60% de los PCs de escritorio de oficina son dejados de manera continua. Se trata de la necesidad de mantener la conectividad de red que contribuye a la desactivación de las funciones de gestión de energía existentes en muchos ordenadores.

Ahorro de este desperdicio de energía se puede hacer mediante 1) el rediseño de protocolos de red y aplicaciones, o 2) encapsulando la inteligencia para mantener la presencia de la red en una entidad distinta que el núcleo de los dispositivos conectados en red. La segunda opción que llamamos Conectividad de Red Proxy (NCP), donde un NCP es una entidad que mantiene presencia en la red completa para un host de red que esta dormido.

El problema de conectividad de red

¿Por qué aparatos de las oficinas y equipos domésticos se dejan encendidos incluso cuando no están en uso activo, inclusive en las noches o durante los fines de semana? Hay varias razones principales para ello con dos más importantes: 1) La molestia al usuario de tener que esperar a un PC para despertar fuera del estado de suspensión, y 2) la necesidad de mantener la conectividad de la red en todo momento para permitir acceso remoto o para aplicaciones centradas en red. La primera razón es cada vez menos importante como computadoras se vuelven capaces de encender más rápido, y la segunda razón es cada vez más importante a medida que más aplicaciones y protocolos se basan en una conexión a Internet permanente.

Para mantener la conectividad de la red, un host debe ser capaz de soportar un número de primitivas de aplicación y el protocolo incluyendo:

• Mantener la accesibilidad del host para responder a peticiones ARP periódicos.
• Mantenga su dirección IP mediante la generación de peticiones periódicas de arrendamiento de DHCP con el fin de no perder su dirección IP actual (si es que se utiliza DHCP para obtener una dirección IP).
• Mantener la capacidad de gestión, respondiendo a los paquetes ICMP, como ping.
• Apoyar la resolución de nombres NetBIOS, respondiendo a las consultas de nombres NetBIOS, según corresponda (si se ejecuta el protocolo NetBIOS y aplicaciones).
• Mantener la accesibilidad a nivel de aplicación, respondiendo a paquetes TCP SYN enviados para abrir (escuchar) los puertos.
• Mantener o conservar el estado de la aplicación (por ejemplo, el espacio de trabajo del usuario actual y datos) para cualquier aplicación con conexiones TCP abiertas a largo plazo.

Además, es deseable en muchos casos que los paquetes enviados a un host durante el tiempo que está durmiendo no se pierdan. Dado que la lista anterior no es completa, es un trabajo futuro para comprender mejor lo que pasa cuando los paquetes son recibidos por un host al dormir y cuál de los paquetes recibidos pueden ser ignorados, cuáles requieren una respuesta inmediata, y cuáles pueden ser guardados en un buffer para su posterior procesamiento. Es muy importante la capacidad de responder a los paquetes ARP incluso cuando duerme. Tarjetas de red Ethernet que admiten DMTFs para formato estándar de alertas (ASF) pueden responder a paquetes ARP para un host que duerme. Esto se hace manteniendo la NIC totalmente energizada cuando el host se encuentra en un estado de suspensión (con su CPU, pantalla, memoria y almacenamiento de desconexión). La NIC energizada también puede despertar el host cuando los paquetes específicos predeterminados para despertarlo son recibidos.

Figura 1.

Si un host puede seguir siendo accesible incluso al dormir y manteniendo su NIC encendido, este puede entonces ser despertado por la red por paquetes que la NIC reconoce. El Magic Packet se inventó para este fin en la década de 1990. La mayoría de las tarjetas de red soportan hoy tanto el Magic Packet y la capacidad de ajuste de patrones para los paquetes específicos para activar una llamada. Sin embargo, el despertar del host no resuelve el problema de conectividad de red.

Habilitar suspensión de hosts con NCP

Los hosts conectados a una red mantienen su presencia en otros hosts mediante la generación correcta y respondiendo a los mensajes para ambos protocolos de red y aplicación. Un proxy de conectividad de red (NCP) propuesto por los autores del documento, es una entidad que implementa las capacidades de presencia de red clave de un host con el fin de permitir que el host entre en suspensión, sin embargo, permite que el host aparezca en otros dispositivos como si estuviera en pleno funcionamiento y conectado a la red. Por lo tanto, un NCP puede habilitar un host para que entre en suspensión y ahorrar energía.

En la Figura 1 se muestra una red con dos máquinas de red etiquetados como cliente y servidor, y un NCP situado dentro de un interruptor para apoyar la máquina cliente. El NCP también podría estar situado en otro host de la red, dentro de un punto de acceso inalámbrico, o dentro de la NIC en el host en suspensión.

Los siguientes supuestos deben presentarse en el host de la red cubierta por un NCP:

• Tiene un modo de suspensión que se puede introducir mediante comandos dentro de la aplicación o del sistema operativo.
• Ser capaz de salir completamente del modo de suspensión en el lapso de tiempo de unos pocos segundos o preferiblemente menos.
• Tiene un modo de suspensión que preserva todos los protocolos locales y estados de la aplicación.
• Apoyar un método de reactivación remota basada en paquetes, tales como Magic Packet o coincidencia de patrones.
• Apoyar la capacidad de las aplicaciones en hosts para poder bloquear al host de entrar en un estado de suspensión, siempre y cuando la aplicación está utilizando activamente la CPU, red u otros recursos.

Los siguientes son los objetivos que se pretenden cubrir mediante un sistema usando NCP:

1. Un host debe poder entrar en suspensión y no perder su presencia en la red.
2. Un host debe mantener su dirección IP y estar accesible en routers y switches.
3. Conexiones TCP existentes a un host no deben ser olvidados y los datos no deben perderse.
4. Paquetes UDP enviados a un host no deben perderse.
5. Durante el tiempo que un equipo cliente está en suspensión, el estado remoto se debe mantener en todos los casos.
6. Los cambios en las aplicaciones y protocolos de red no deben ser necesarios en el cliente o el host del servidor.

Arquitectura del NCP

El NCP mantiene un host en suspensión. Esto requiere que el NCP pueda conocer el estado de la alimentación del host (por ejemplo, despierto o en suspensión) y ser capaz de transferir entre el host y el NCP. Los pasos funcionales clave para un NCP son:

1. El host decide que es hora de entrar en suspensión (por ejemplo, basado en un sistema operativo de inactividad tiempo, de espera o acción explícita por un usuario).
2. Los avisos y estados se pasan a la NCP, y el host entra en suspensión.
3. La NCP mantiene presencia completa en la red, dando respuesta, generando los paquetes de aplicaciones, según sea necesario.
4. El NCP determina cuándo ha llegado un paquete que requiere los recursos del host y señala el host a despertar. El host también puede despertar la actividad del usuario o de un temporizador interno.
5. Una vez que el host ha despertado plenamente, los estados se pasan del NCP al host y el host vuelve al funcionamiento totalmente energizado.

Figura 2.

Cuando el NCP está cubriendo un host en suspensión, recibe los paquetes destinados para el host. Cada uno recibió los resultados de paquetes en una de las siguientes acciones: responder directamente al paquete, despertar el host, descartar el paquete, o añadir a la cola de paquetes para su posterior procesamiento en el host cuando está despierto. La Figura 2 muestra el diagrama de flujo de acciones para cada paquete recibido.

Paquetes de bajo nivel, tales como ARP e ICMP pueden ser respondidos directamente. Otros paquetes, tales como un SNMP GET, pueden requerir que el host sea despertado si ese mismo host se encarga de ejecutar el servicio correspondiente al paquete recibido. Un GET de SNMP tiene una duración de vida limitada, que no puede ser puesto en cola para dar respuesta más tarde. Algunos paquetes de solicitud pueden ponerse en cola para su posterior procesamiento en el host cuando se despierte.

Consideramos especialmente dos aplicaciones de red usando cola de paquetes para su posterior procesamiento y donde el proxy puede permitir que un host entre en suspensión. Por ejemplo las aplicaciones de SSH y mensajería instantánea.

Estado de suspensión del host al NCP

El requisito del NCO es conocer en todo momento el estado actual del host que esta cubriendo en determinado momento. Esto depende en gran parte de donde se encuentra ubicado el NCP con respecto a la red. Si el NCP se encuentra localizado fuera del host en suspensión (por ejemplo, en un switch en la red), a continuación la señal del host en suspensión se puede lograr a través de un nuevo proceso que se ejecuta en el host que capta los estados de suspensión y despertar del sistema operativo, y comunica estas interrupciones a la NCP a través de un protocolo basado en paquetes. Un paquete de notificación se define en un campo que puede contener dos valores que pueden significar 1) el anfitrión está entrando en un estado de suspensión, o 2) el anfitrión está despierto después de haber estado en un estado de suspensión. La Figura 3 muestra la arquitectura para el estado de energía de señalización en el que se establece una conexión TCP entre el proceso de host y el punto de control de NCP. El NCP escucha para estas conexiones en un puerto predefinido.

Figura 3.

Otros trabajos que buscan el ahorro de energía

La comunidad de red inalámbrica durante mucho tiempo se han interesado en métodos para reducir el consumo de energía de los ordenadores inalámbricos móviles con el fin de aumentar la duración de la batería. Un enfoque que se ha explorado es tener una jerarquía de componentes de hardware que van desde alta potencia y de alta funcionalidad en la parte inferior, y de baja potencia y de bajo funcionalidad en la parte superior. Los componentes de bajo consumo funcionan para los niveles más bajos de alta potencia, y por lo tanto permiten que los componentes de alto poder entrar en suspensión. Un ejemplo de esto es el llamado "Wake on Wireless", donde se utiliza un componente inalámbrico fuera de la banda de un bajo consumo de energía para despertar un PDA de alta potencia. Otro ejemplo es un ordenador portátil con tres niveles de equipamiento, donde los componentes de baja potencia realizan tareas simples de red (tales como el mantenimiento de email actualizado) que permiten a los componentes de potencia superiores entrar en suspensión.

Conclusiones

Esta técnica al igual que muchas otras más existentes son empleadas con el fin de ahorrar energía ya que el incremento del uso de servidores y dispositivos que se mantienen conectados a la red en todo momento ha ido aumentando considerablemente en los últimos años, y lo que se busca son formas para que de alguna forma estos dispositivos de red logren entrar en suspensión mientras no se usen con el fin de ahorrar energía, sin dejar de brindar el servicio para el cuál fueron creados.

Referencia:
A Network Connection Proxy to Enable Hosts to Sleep and Save Energy, de Miguel Jimeno, Ken Christensen y Bruce Nordman

Experimento de Redes

Redes de Telecomunicaciones
Tarea 5

Para esta entrega se nos pidió desarrollar un modulo para NS-2 que permitiera crear topologías, generar patrones de tráfico y comparar por lo menos dos diferentes esquemas de control de congestión. De esta entrega las dos primeras partes ya se habían mencionado antes en las entregas de laboratorio y para la tercera solo me fue posible abordar con información acerca del tema.

Al final en la parte de referencias dejo los enlaces a documentos con muy buena información para el tema de congestión de redes y algunas pruebas hechas por otras personas acerca del mismo tema.

Generación de topologías y creación de tráfico

Para la parte de creación de topologías y creación de tráfico, me base en lo ya antes presentado en las tareas de laboratorio, pero ahora creando un solo archivo tcl que incluye funciones encargadas de la formación de una topología común conocida de unos cuantos nodos y de a selección manual de tráfico de red.

Con este mismo podemos obtener simulaciones como se muestra en las siguiente animación producida por nam.

Código

Control de congestión

Se llama congestión al exceso de tráfico en alguna parte de una red, que da lugar al exceso de demanda de algún recurso (ancho de banda, memoria, capacidad de procesamiento) y los síntomas notorios para este caso son el aumento en los retardos y la pérdida de paquetes.

Consecuencias de la congestión:

Retardos: Trabajar cerca de la capacidad de los enlaces es ideal desde el punto de vista de la productividad, pero no lo es respecto al retardo. Se experimentan grandes retardos en una cola según la tasa de llegadas de paquetes se acerca a la capacidad del enlace.

Pérdidas: Como los buffers no son de tamaño in finito, el emisor debe realizar retransmisiones para compensar los paquetes perdidos debido al desbordamiento de los buffers.

Desperdicio de recursos:

• Las retransmisiones innecesarias realizadas por el emisor en presencia de grandes retardos, que provocan que venzan los temporizadores de retransmisión antes de que lleguen los asentimientos, hacen que el ancho de banda de los enlaces se utilice para encaminar copias innecesarias de los paquetes.
• Cuando un paquete es desechado a lo largo de un camino, la capacidad de almacenamiento, procesamiento y transmisión que fue utilizada en cada uno de los nodos y enlaces anteriores, para encaminar ese paquete hasta el punto en el que es desechado, está siendo desperdiciada.

Algoritmos de control de congestión:

Mecanismo de Traffic Shaping

Es un mecanismo en bucle abierto. Conforma el tráfico que una fuente puede inyectar a la red. Se usa en redes ATM (Asynchronous Transfer Mode). En estas redes, la velocidad de línea es de 155 Mbps y el usuario puede ver una velocidad de unos 10 Mbps.

Si se tiene una ráfaga lista para transmitir, el sistema obliga a no transmitir todo seguido. Requiere un acuerdo entre proveedor y cliente: el proveedor garantiza que se cursa el tráfico si se transmite a una tasa determinada y tira el tráfico si se supera. Esto lo realiza mediante una función policía, que es un nodo que tira los paquetes que superan la tasa contratada a la entrada de la red (no se tiran una vez que ya ha entrado). Esto puede realizarse mediante un algoritmo de Leaky Bucket, cuyo nombre se debe a que es como si tuviéramos un bote que vamos llenando con un caudal determinado y por el que sale el líquido con otro caudal distinto; si llenamos muy deprisa el bote acabará llenándose y vertiéndose por arriba, lo que asemeja una pérdida de paquetes en una red.

Algoritmo de descarte de paquetes

Es un algoritmo de control de congestión en bucle cerrado. Se basa en que los nodos descartan (tiran) paquetes cuando su ocupación es alta. Para esto los nodos han de conocer sus recursos (CPU y memoria). Hace una asignación dinámica de los buffers en base a las necesidades de cada línea.

Sin embargo, cada línea necesita al menos una (o más) posiciones de memoria para gestionar información relevante, tal como asentimientos, que permite la liberación de posiciones de memoria ocupadas por paquetes que estaban esperando por si necesitaban retransmitirse. Si a la línea llegan datos (no asentiminentos u otra información relevante) y el buffer de salida de la línea correspondiente está lleno, se descarta el paquete. Hay varias formas de hacer la asignación de buffers:

• En base al uso. No es muy eficiente, porque cuando una línea se empieza a cargar acapara todos los recursos.
• Asignación fija. Tampoco es muy buena, ya que desaprovecha recursos.
• Asignación subóptima. Llamando k al número de posiciones del buffer y s al número de líneas de salida, se tiene que el número de posiciones de memoria asociadas a cada línea es:
  $$m=\dfrac {k}{\sqrt{s}}$$

Referencias:
Video Sources and Congestion Control Protocols
TCP Congestion Control Algorithms
TCP Performance Simulations
Control de Congestión
Algoritmos de Control de Congestión

Actividad 9: Retroalimentación de Proyectos

Laboratorio de Cómputo Ubicuo
Actividad 9

En el cuarto avance de la clase de Cómputo Ubicuo todos los equipos presentaron pruebas de usabilidad para conocer la opinión de personas que se podrían convertir en futuros usuarios de nuestros proyectos, y así en base a esta pruebas lograr hacer correcciones o modificaciones antes de la entrega del prototipo final. Después de escuchar a todos los equipos se nos pidió hacer nuevamente una retroalimentación, para dar sugerencias de mejora a las pruebas de usabilidad hechas por cada equipo.

A continuación están mis recomendaciones, sugerencias y críticas constructivas para las presentaciones de las pruebas de usabilidad.

Alarma Inteligente para Autos

Integrantes: Alex, Sergio, Roberto y Cristhian.

Como hicieron un grupo focal, creo que hubiera sido más adecuado tener la misma cantidad de jóvenes y de adultos, para que después de obtener las respectivas respuestas de los usuarios, se pudiera hacer una comparación entre estos dos grupos de personas, y conocer diferencias entre lo que piensan los jóvenes y los adultos, además de que falto determinar las edades de los que consideraron como jóvenes, así como las edades de los considerados como adultos.

Por otra parte me parece muy adecuado explicar a las personas del grupo focal, a manera de introducción, como es que funciona el sistema y las partes que lo integran, tal y como ustedes lo hicieron ya que esto ayuda mucho a que la retroalimentación de estas personas sea de ayuda.

Por último, en la parte de la interfaz me parece que falto hacer alguna prueba de usabilidad para conocer si el usuario encuentra problemas utilizando esta interfaz o si le gustaría tener más opciones en la misma aparte del monitoreo que ustedes proponen.

Enlace a presentación:
http://ubicomputo.blogspot.mx/2013/04/evaluaciones-de-usabilidad.html

Computadora Inteligente

Integrantes: Obed, Avendaño, Pedro y Jonathan.

Una de las pruebas de usabilidad que pudieron haber implementado fue la de "hombre detrás de la cortina" para poder dejar al usuario solo interactuando con la computadora y ver las reacciones y dificultades verdaderas que pudo haber enfrentado por si solo, ya que estando asesorando en todo momento a las personas con las que se hace la prueba de usabilidad podría dificultar la detección de posibles problemas en el uso de la interfaz.

En la encuesta que pusieron hubiera sido bueno agregar una pregunta relacionada a si lograban percibir que su computadora tardaba más tiempo en responder a las acciones habituales que ellos hacían, para conocer si les causa algún problema la carga del programa con el sistema operativo, o si simplemente no causaba ningún problema.

Y para la prueba de lugares con poca y mucha luz falto conocer el resultado que esto arrojó para determinar si esto afectará en el uso del sistema que proponen y poder considerarlo como alguna mejora a futuro o adecuación del mismo.

Enlace a presentación:
http://aveoctavo.blogspot.mx/2013/04/blog-post.html

Oficina Personalizada

Integrantes: Osvaldo, Triana, José y Esteban.

Como complemento a sus pruebas de usabilidad pudieron haber hecho un recorrido cognitivo u observar a las personas con las que se hizo la prueba la forma en como interactuaban con el prototipo para ver sus reacciones y conocer si realmente fue un proceso fácil el de pasar la tarjeta o brazalete para la apertura de la puerta, y detalles parecidos.

Lo que refiere a la parte del interior de la oficina creo que faltaron hacer pruebas con respecto a eso, ya que no mencionaron nada de lo que el usuario piensa al estar interactuando indirectamente con el sistema encargado de encender las luces y cosas por el estilo.

Enlace a presentación:
http://pepgonzalez.blogspot.mx/2013/04/avance-4.html

Proyecto Localizador

Integrantes: Omar, Saúl e Isaías.

Muy buenas pruebas de usabilidad las que utilizaron, me parecen adecuadas para el tipo de proyecto que están desarrollando. En la parte del recorrido cognitivo pudieron agregar algún ejemplo más de las acciones que el usuario puede hacer dentro de su aplicación, como la de "configurar por primera vez el dispositivo", tal y como lo hicieron después en sus pruebas de laboratorio, y después determinar si el usuario siguió los pasos que pensaban seguiría o hizo alguna otra cosa diferente.

En la parte de la prueba de laboratorio, el uso de "eyetrack" es de conocer hacia que punto exacto mira la persona en la interfaz y conocer cuales son las partes que ve primero o que ve con mayor frecuencia al estar usando la aplicación, y no se trata de ver el rostro de la persona como mencionan, pero que siendo una prueba de laboratorio, es de imaginarse que esto se puede hacer estando cerca de la persona mientras usa el dispositivo.

Enlace a presentación:
http://gtdsoftwa.blogspot.mx/2013/04/presentacion-usabilidad-computo-ubicuo.html

Galería Inteligente

Integrantes: Adriana, Blanca, Vanessa y Rodolfo.

Podrían primero antes de las pruebas con personas reales, haber creado situaciones con la creación de personas ficticias donde contemplarán las acciones que esperaban encontrar que los usuarios hicieran al momento de dirigirse a ver la obra dentro de la vitrina oscurecida, con el fin de comparar si lo que estaba escrito en papel coincidía de alguna forma con lo que pasó en la prueba que realizaron.

Pudieron haber hecho algunas cuantas preguntas más a las personas con las que hicieron la prueba como para conocer si les llevo tiempo entender el funcionamiento de la vitrina, o de si la obra dentro de esta se lograba apreciar bien, pero fuera de eso me pareció muy bien como manejaron la prueba con las personas de no mencionarles antes nada acerca del funcionamiento para observar las reacciones que tenían estando frente a la vitrina.

Enlace a presentación:
http://ultimo-sem.blogspot.mx/2013/04/entrega-4.html

Casa Inteligente

Integrantes: René, Raúl e Iván.

Me gusto la idea de la prueba de la aplicación con los dibujos en papel, ya que son buena práctica para evaluar un sistema antes de desarrollar la interfaz final que tendrá el usuario y poder hacer cambios antes de que ya se tenga una versión terminada, y se puede conocer si con los botones del dibujo en papel el usuario entiende lo que debe de hacer y si encuentran de forma fácil las opciones que necesitan.

Lo que pudieron haber agregado fue el uso de la técnica de "personas y escenarios" para mostrar situaciones que posiblemente se puedan dar en la implementación de un sistema así en la vida diaria.

Enlace a presentación:
http://3puntosteam.blogspot.mx/2013/04/pruebas-de-usabilidad.html

Auto con NFC

Integrantes: Abraham, Rafael, David y Juan.

Me gusto la parte de las pruebas de color, ya que es muy importante tomar en cuenta que algunos usuarios pueden tener algunas deficiencias visuales, y este tipo de pruebas ayudan mucho a la selección de colores adecuados para la interfaz. Como sugerencia personal creo que el color azul y sus diferentes tonalidades son más adecuadas para este tipo de interfaces, y como respaldo tenemos que plataformas de gran uso como las de algunas redes sociales, suelen usar este tipo de colores también.

Y un punto a mencionar en la prueba que hicieron para la evaluación de la interfaz, es que no solo se debe conocer si se les hizo fácil o no el uso de esta interfaz, sino conocer si en realidad se cumplió con la tarea que la persona quería hacer (como ver los mapas, ver la lista de música, etcétera), ya que hay que buscar que la aplicación cumpla con los objetivos y no solo que sea fácil de usar.

En cuanto a su presentación de resultados de estas pruebas de usabilidad, pudieron haber sintetizado todas las pruebas y conclusiones obtenidas, ya que me parece algo extensa su exposición e inclusive la cantidad de diapositivas presentadas esta algo excedida.

Enlace a presentación:
http://inteligentsystems.wordpress.com/2013/04/26/fase-4-pruebas-de-usabilidad/

Garage Inteligente

Integrantes: Emmanuel, Max, Carmen y Víctor.

Como han mencionado en su proyecto harán uso de un teléfono inteligente comos si fuese un control remoto, y no se si en las pruebas que hicieron tomaron en cuenta la habilidad del usuario para poder abrir la aplicación que se encargará de esto y si le resulta habitual o fácil poder conectar este sistema por medio de Internet o de Bluetooth, ya que me imagino que es parte elemental para hacer que el usuario se sienta cómodo con el uso del teléfono como control remoto.

En las presentaciones anteriores mencionan el uso de códigos QR como claves de acceso para la apertura del garage, lo que no se menciona mucho en esta presentación, así que una encuesta en cuanto al uso de códigos QR hubiera sido adecuada para conocer si los usuarios están familiarizados con estos, y si les gustaría hacer uso de los mismos para el uso de este garage inteligente.

Enlace a presentación:
http://obicomp.blogspot.mx/2013/04/presentacion-evaluaciones-de-usuario.html

En las presentaciones logramos observar varias pruebas existentes de usabilidad que en su momento no fueron creadas con el fin de hacer pruebas a proyectos de cómputo ubicuo, pero que han podido ser adaptadas a nuestras necesidades con el fin de recabar información útil para tomar decisiones en cuanto a las tareas que los usuarios lograrán realizar con nuestros proyectos.

Métodos de Diccionario: Byte Pair Encoding

Teoría de la Información y Métodos de Codificación
Puntos Extra

Veamos un ejemplo sencillo de compresión de información usando el método Byte Pair Encoding.

Codificación

La cadena de texto que voy a decodificar es la siguiente:

bbadefedbbafecedbbade

• La parte que más se repite en el texto es bba y la sustituimos por W.
  WdefedWfecedWde
• Luego tenemos cuatro posibles alternativas, sustituir ed, fe, Wde y edW ya que aparecen la misma cantidad de veces, pero como las últimas dos tienen más caracteres será mejor elegir uno de ellos. Cambiaré Wde por X.
  XfedWfecedX
• Y como ya no hay muchos elementos que se repiten cambiaremos fe por Y.
  XYdWYcedX

Nos resulta una tabla para decodificación como sigue.

W = bba
X = Wde
Y = fe

Y la cadena codificaca resulto así:
XYdWYcedX

Decodificación

Entonces si partimos de la tabla anterior, podemos recuperar la cadena original.

• De XYdWYcedX primero cambiamos las Y por fe.
  XfedWfecedX
• Ahora cambiamos las X por Wde.
  WdefedWfecedWde
• Y por último la W la cambiamos por bba.
  bbadefedbbafecedbbade

Y con esto logramos llegar a la cadena de texto original.

Referencias:
Byte Pair Encoding

Código Adaptativo

Teoría de la Información y Métodos de Codificación
Tarea 4

Para la entrega de esta tarea se nos pidió crear desde nuestras propias ideas el código adaptativo de la codificación Huffman, por lo tanto si estabas buscando una explicación del algoritmo de Huffman Adaptativo, este no es el mejor lugar ya que el método propuesto es de mi propia creación y no se asegura su funcionalidad.

Diseño del método adaptativo

Como idea para el método adaptativo pensé en algo muy simple, que seguramente en la evaluación de desempeño no logre mejorar al algoritmo simple de codificación Huffman. Lo que realicé fue crear un generador que recibe como entrada desde línea de comandos el parámetro del largo del texto que se irá generando carácter por carácter, y que se almacena en un buffer de un largo que también se define desde línea de comandos.

Lo que hace el programa es ir generando al momento el texto, que por el momento solo use los caracteres para letras minúsculas, y cuando el buffer llega al tamaño indicado, se crea un primer árbol de codificación, lo cual genera los códigos en binario necesarios para escribir los caracteres en menos de 8 bits. Después se libera este buffer y se espera a que se vuelva a llenar para volver a contar la frecuencia de cada carácter y poder generar un nuevo árbol que genere una codificación diferente.

Lo que sucede es que conforme se van generando los caracteres se genera un árbol completamente nuevo con los códigos actualizados, y después de un cierto tiempo el árbol llega a ser completo e incluir todos los caracteres incluidos, y el diccionario para codificar y decodificar empieza a cambiar menos drásticamente que al inicio.

Código

La siguiente imagen es una ejecución del programa donde como parámetros se le dio 500 para el largo del texto que ira creando y usando un buffer de 5 caracteres.

Se puede ver que no todos los caracteres cambiaron de codificación en las dos últimas creaciones del nuevo árbol.

Y en la siguiente imagen vemos que el archivo con 500 caracteres a comparación con el binario creado por el programa es 4 veces más pequeño, por lo que comprobamos que el código no es el indicado para comprimir archivos de texto.

Sugerencia para mejorar el método

El método propuesto no es el indicado para ahorrar espacio en memoria como su objetivo lo propone, porque en realidad ocupa más espacio el estar almacenando los nuevos diccionarios cada que se genera el nuevo árbol, además de que el proceso de decodificación resultaría algo más complicado.

La sugerencia de mejora es no crear un árbol nuevo cada vez que se llena el buffer sino actualizar el anterior, evitando modificar la codificación para un carácter cuando la frecuencia no incrementa mucho en comparación con la anterior tabla.

Actividad 7: Detección de Agujeros

Laboratorio de Visión Computacional
Actividad 7

Para la actividad de la semana se nos pidió probar la detección de agujeros con fotos de objetos tomadas por nosotros mismos. Para cada punto encontrado como pico del histograma se trazo una línea recta que lo cruzaba, para los casos del histograma vertical y el horizontal, para después de esto observar las intersecciones de las líneas donde debería de encontrarse un agujero.

A diferencia del código presentado en la publicación de este mismo tema pero para la entrega de la clase, tenemos ahora el código correspondiente para el trazo de los histogramas sobre la imagen y también el código que dibuja las líneas que intersectan los puntos de los picos encontrados.

Como primer ejemplo tengo una imagen de un enchufe de electricidad, donde podemos notar como en la primer imagen donde se muestra el histograma encontramos dos picos para el caso del histograma vertical y dos para el horizontal también, que posteriormente se muestra que de los 4 puntos donde se intersectaron las 4 rectas, dos de ellos son marcados con punto amarillo porque se comprobó que correspondían a puntos donde se encontraba un agujero.

Luego tome una fotografía más a una de las caras de un rallador de quesos el cual contenía un total de 32 agujeros y probé con el programa para ver si era posible detectarlos a todos. El resultado, como se ve en las siguientes imágenes, fue de una detección casi perfecta donde todos menos el agujero de la esquina inferior derecha fue detectado, y la razón es porque en el histograma vertical el pico se encontró un poco más a la izquierda y las líneas que cruzaron no entraron en el espacio de este agujero, por lo que fue descartado como agujero, pero en todos los demás pareció no haber ningún problema.


Aquí esta el resultado al colorear todos los agujeros de un color morado y etiquetados con un ID cada uno de ellos.

Código

Otra prueba más fue con un plato con un solo agujero, donde podemos observar que en el histograma se ven claramente donde están esos picos (valles, si se analizan desde la otra perspectiva), y el cruce de las líneas de los correspondientes picos indican el lugar donde debe encontrarse el agujero.

Y por último una prueba más con un colador para las ollas de vapor que contiene varios agujeros en diferentes tamaños, donde el histograma también logra indicar donde están los picos donde se encuentran estos agujeros.

Se marca con un punto amarillo donde la intersección de las líneas logra pasa por un agujero detectado.

Y en la siguiente imagen vemos los agujeros perfectamente detectados, con el único detalle de que en la foto un destello de luz corta uno de los agujeros y los detecta como dos agujeros independientes, pero como se observa el agujero completo es rellenado con algún color cercano a morado.

Y como se hizo para la entrega de la clase, en cada una de las pruebas el programa imprime en terminal el lugar donde se encontró el agujero y el tamaño del agujero en porcentaje del tamaño de la imagen completa. Enseguida una muestra.

Referencias:
Elisa Schaeffer - Detección de Agujeros

Actividad 8: Control de Congestión

Laboratorio de Redes de Telecomunicaciones
Actividad 8

Nombre del documento:
Rate Control For Streaming Video Over Wireless

Autores:
Minghua Chen y Avideh Zakhor

Enlace:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1497856

Introducción

El control de velocidad es importante para aplicaciones de streaming multimedia, tanto en redes cableadas e inalámbricas. En primer lugar, da lugar a la plena utilización de enlaces de cuello de botella, garantizando que las tasas de envío no sean demasiado bajas. En segundo lugar, evita el colapso de congestión, garantizando que las tasas de envío no son demasiado agresivos. Por ejemplo, hubo un colapso de la red de Internet en octubre de 1986 en la Universidad de California en Berkeley, dando lugar a la degradación del rendimiento. Por último, el control de velocidad adecuada asegura la equidad entre usuarios compartiendo vínculos comunes en una red dada.

Un sistema de control de velocidad muy popular para el streaming en redes cableadas está basado en ecuaciones de control de velocidad, también conocido como control de velocidad de TCP local (TFRC). En TFRC la tasa de TCP-friendly se determina en función de la tasa de pérdida de paquetes, el tiempo de ida y vuelta (RTT), y el tamaño del paquete, para imitar el funcionamiento constante a largo plazo de TCP. Hay básicamente tres ventajas para control de la frecuencia utilizando TFRC: en primer lugar, se puede utilizar plenamente las capacidades de cuello de botella al tiempo que evita la congestión del colapso. En segundo lugar, es justo a los flujos TCP, que son la fuente dominante de tráfico en Internet. En tercer lugar, los resultados TFRC de fluctuación del tipo de pequeño, por lo que es atractivo para aplicaciones de streaming que requieren calidad de vídeo constante.

La clave detrás de TCP y TFRC es que la pérdida de paquetes es una señal de congestión. En las redes inalámbricas, sin embargo, la pérdida de paquetes está dominado por los errores de canal físico y esta hipótesis es clave. Ni TFRC ni TCP pueden distinguir entre la pérdida de paquetes debido al desbordamiento del búfer o debido a errores de la capa física. Como se muestra más adelante, esto se traduce en la subutilización del canal inalámbrico.

El authTFRC asume que la pérdida de paquetes en redes cableadas es principalmente debido a la congestión y no es aplicable a redes inalámbricas en donde la principal causa de la pérdida de paquetes es la capa física.

El control de velocidad para aplicaciones de streaming de forma inalámbrica sigue siendo un problema abierto. Ha habido una serie de esfuerzos para mejorar el rendimiento de TCP o TFRC sobre wireless. Estos enfoques esconden hosts finales de la pérdida de paquetes debido a un error del canal inalámbrico, o proporcionan a los hosts finales la capacidad de distinguir entre la pérdida de paquetes causada por la congestión y la causada por el error del canal inalámbrico. Para obtener una mejor comprensión del espectro de enfoques para el control de velocidad de una conexión inalámbrica, se revisan brevemente las soluciones TCP y TFRC de forma inalámbrica.

Snoop, una solución conocida, es un enfoque de capa de enlace de retransmisión local de TCP-aware. Un módulo de Snoop reside en un router o estación base en el último salto (es decir, la conexión inalámbrica) y registra una copia de cada paquete enviado. Suponiendo que un módulo Snoop puede acceder a TCP mediante las respuestas (ACK) de paquetes desde el receptor TCP, que se ve en los paquetes ACK y lleva a cabo retransmisiones locales cuando un paquete es corrompido por los errores de canal inalámbricos. Mientras se hace la retransmisión local, el paquete ACK se suprime y no se reenvía al remitente TCP. Estos esquemas potencialmente pueden extenderse a TFRC con el fin de mejorar el rendimiento mediante el uso de un tratamiento más complicado de los paquetes ACK desde el receptor TFRC.

El escenario típico para la transmisión en la red inalámbrica, cuando un servidor de vídeo en la red por cable esta transmitiendo vídeo a un receptor en la red inalámbrica.

El enlace inalámbrico se supone que tienen ancho de banda disponible, y la tasa de pérdida de paquetes es causada por el error de canal inalámbrico. También podría haber pérdida de paquetes causada por la congestión en el nodo 2, mostrado por la PC. Nos referimos al canal inalámbrico como subutilizado, si la salida de transmisión es menor que el caudal máximo posible a través del enlace inalámbrico.

En base a este escenario, dos metas del esquema de control de velocidad se pueden indicar los siguientes, en primer lugar, la tasa de transmisión no debe causar ninguna inestabilidad de la red (es decir, el colapso de la congestión), en segundo lugar, debe conducir a un rendimiento óptimo (es decir, el throughput más alto posible y menor tasa de pérdida de paquetes posible). TFRC puede cumplir con la primera meta claramente, porque se ha demostrado que al ser TCP el usado, no causa inestabilidad de la red.

Una estrategia que conduce a un rendimiento óptimo puede ser descrito de la siguiente manera: seguir aumentando el número de conexiones hasta que una conexión adicional resulta en un viaje de extremo a extremo mejorando el tiempo de vuelta o la tasa de pérdida de paquetes. A continuación, utilizamos esta observación para desarrollar un esquema práctico llamado MULTFRC para determinar el número óptimo de conexiones.

La idea básica detrás de MULTFRC es medir el tiempo de ida y vuelta, y ajustar el número de conexiones de acuerdo con el fin de utilizar el ancho de banda inalámbrica de manera eficiente, y garantizar la equidad entre las aplicaciones. Hay dos componentes de nuestro sistema propuesto: un subsistema de medición de RTT y un subsistema del controlador de conexiones (CAC), ambos con domicilio en el remitente.

Para evaluar el desempeño de MULTFRC en aplicaciones de transmisión de vídeo, se simuló la transferencia de un clip de 60 segundos de vídeo a través de un canal, con el rastro del rendimiento correspondiente a una de las trazas obtenidas a partir de experimentos reales sobre RTT CDMA. El objetivo es comparar la calidad de la transmisión de vídeo alcanzable utilizando una conexión TFRC con la de MULTFRC.

Una comparación de estas dos se muestra en la siguiente imagen obtenida del mismo documento.

Conclusiones

En el documento se aborda una alternativa de solución para la transmisión de vídeos dentro de una red inalámbrica donde se hace uso de protocolos ya implementados para lograr conocer cuando un paquete logró ser transmitido correctamente hasta la computadora que lo esta requiriendo, y de no ser así se retransmite desde el buffer generado desde el router para evitar la solicitud del paquete hasta el servidor que provee el servicio. En teoría la solución propuesta parece ser buena ya que previene de alguna forma la congestión de la red.

Referencias:
"Rate Control For Streaming Video Over Wireless", Minghua Chen y Avideh Zakhor de La Universidad de California en Barkeley, Agosto 2005

Actividad 8: Evaluando Sistemas Ubicuos

Laboratorio de Cómputo Ubicuo
Actividad 8

Nombre del documento:
Evaluating Ubiquitous Systems with Users

Autores:
Christian Kray, Lars Bo Larsen, Patrick Olivier, Margit Biemans, Mirko Fetter, Tim Jay, Vassilis-Javed Khan, Gerhard Leitner, Ingrid, Thomas Plotz, and Irene Lopez de Vallejo

Enlace:
http://patrec.cs.tu-dortmund.de/pubs/papers/Kray2008-EUS

Introducción

Un número significativo de sistemas ubicuos se han construido para soportar las tareas de la vida diaria de los usuarios. Estas aplicaciones cubren una amplia gama de escenarios, incluidas las aplicaciones para la seguridad, el apoyo personalizado en el lugar de trabajo y las aplicaciones relacionadas con el ocio. Los usuarios interactúan con estos sistemas a través de los medios implícitas o explícitas, por ejemplo el uso de un dispositivo con pantalla táctil o el puro movimiento del cuerpo. Al mismo tiempo, muchas aplicaciones ambientales hacen uso de sensores para recopilar información sobre el contexto en el que estas interacciones tienen lugar, y el comportamiento del sistema puede cambiar dependiendo de factores contextuales. Todo esto se suma a una situación bastante compleja, que plantea nuevos retos para la evaluación, lo que podría empujar los límites de los métodos de evaluación tradicionales y la apertura de oportunidades para nuevos enfoques.

http://ciudadesinteligentes.smartmatic.com/wp-content/uploads/2012/06/sistemas-domoticos.jpg

El objetivo es discutir el estado actual de las técnicas de evaluación de los sistemas ubicuos con usuarios reales, para identificar deficiencias y beneficios de los métodos de evaluación tradicionales y explorar nuevos enfoques.

En este documento, en primer lugar se tiene un breve resumen de los enfoques existentes para la evaluación antes de discutir varios temas y preguntas de investigación que surgen de la evaluación de la computación ubicua y después se tratan pruebas actuales para aplicar los diferentes métodos en el contexto de computación ubicua.

Enfoques actuales para la evaluación

En principio, casi cualquier técnica de evaluación utilizado en la Interacción Humano-Computadora (IHC) también se puede aplicar para evaluar los sistemas ubicuos. Sin embargo, una parte significativa de la tecnología ubicua está destinado a tejerse invisible en la vida de los usuarios, por lo tanto las tareas de los usuarios y sus interacciones con un sistema son definidas menos claramente que en la configuración tradicional. Por esta razón, no siempre es sencillo de aplicar las técnicas que son ampliamente utilizados en IHC (por ejemplo, los métodos basados ​​en la ejecución de tareas). Lo mismo puede decirse de algunos parámetros utilizados en IHC, tales como el tiempo de finalización de la tarea y la tasa de error.

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjO8Mb_PNl0ew3kyypg71BDlzzk-S3_j4uSJPW7SHtWIXlXXsEmSWpvLEwyE6eBlniyyLJs4TGBf7Lnr5IgqQXbS7z62yRLKTmPStFjNOR4DFQbNMyagxmGAe3TDOkBJEYJHGCNYL4m_fI/s1600/Interacci%C3%B3n-persona-computador.png

Preece identifica cuatro paradigmas principales en los sistemas con los usuarios de la evaluación. Evaluaciones rápidas y sucias (Quick and Dirty) tienen el beneficio de entregar resultados rápidos y baratos, y son utilizados por muchos de los proyectos en la fase de análisis de requisitos. Las pruebas de usabilidad suelen tener lugar en un laboratorio, donde los puntajes de desempeño del usuario, tales como el tiempo de finalización de la tarea o las tasas de error se pueden medir fácilmente. Los estudios de campo tienen como objetivo la recopilación de datos en un entorno natural. Se ha producido un intenso debate sobre el valor de estudios en campo en comparación con los estudios de laboratorio. Técnicas predictivas utilizan expertos, heurística y modelos para evaluar los sistemas de usuario sin incorporar usuarios.

Algunos autores consideran que es necesario recabar información sobre cómo se utilizan los sistemas ubicuos en el mundo real. Otros creen que en muchos casos el esfuerzo asociado no está justificando las ideas adicionales adquiridas. Los estudios de campo pueden variar considerablemente en cuanto a su duración. Mientras que algunos estudios se llevan a cabo en un solo día o una semana, algunos proyectos van tan lejos como permitiendo a los usuarios viven con la tecnología durante meses o incluso años para obtener información sobre los efectos a largo plazo de la tecnología. Técnicas predictivas utilizan expertos y modelos para evaluar los sistemas de usuario sin incorporar usuarios.

Las evaluaciones formativas se emplean durante las iteraciones de diseño para conformar el diseño. Evaluaciones sumativas se utilizan después de la fase de diseño tiene y sirven para comparar el sistema con otros sistemas o un conjunto de objetivos predeterminados. Técnicas introspectivas piden al usuario pensar, mientras que las técnicas de observación se encargan de mirar el comportamiento real de los usuarios.

Las técnicas cualitativas recogen datos para describir el comportamiento, establecer escenarios de uso o construir categorías, mientras que las técnicas cuantitativas se reúnen datos para el análisis de datos estadísticos. En estudios a corto plazo se ven los efectos inmediatos que tiene un sistema sobre sus usuarios, mientras que los estudios a largo plazo apuntan a identificar los efectos que sólo se producen después de meses o incluso años de uso. En la aplicación de cualquiera de estas técnicas, el grado de sofisticación o fidelidad del sistema puede variar ampliamente. A veces, sólo se evalúa el comportamiento del usuario sin ningún prototipo. La mayoría de las veces, una creación de instancias de un sistema omnipresente es parte de la evaluación, y puede tomar la forma de un prototipo basado en papel, maquetas de interfaz, o parcialmente prototipos funcionales.

Otra forma de clasificar las técnicas de evaluación es de acuerdo a la manera en la que los usuarios participan, por ejemplo si están siendo observados, si los usuarios y expertos se están entrevistando directamente, si se ponen en un laboratorio de usabilidad, o son creados usando un modelo de usuario. La observación directa a menudo emplea técnicas de la etnografía. La información puede ser mantenida con un cuaderno y una cámara fotográfica, con la grabación de audio y una cámara de fotos, o el uso de vídeo. Observaciones indirectas pueden utilizar diarios, libros de visitas, los registros de interacción o en los registros de diversos sensores. Los sistemas que tienen la intención de cambiar el comportamiento del usuario se puede evaluar midiendo el comportamiento del usuario antes y después de usar el sistema. Del mismo modo, se puede observar el cambio del medio ambiente en todo el sistema.

Las formas más comunes para reunir directamente retroalimentación de los usuarios son los cuestionarios y entrevistas. Las entrevistas pueden ser estructuradas (es decir, que siguen un rígido procedimiento), o no estructuradas. Las entrevistas semiestructuradas a menudo comienzan con preguntas preplaneadas, para luego sondear el entrevistado para más información. Los grupos focales se usan ampliamente para permitir a los usuarios de diferentes grupos para ver la interacción de uno al otro. Los cuestionarios en línea tienen el potencial de llegar a un gran número de usuarios, pero es más difícil de controlar la muestra.

http://labolsadetrabajo.com.mx/wp-content/blogs.dir/5/files/2011/09/Tipos-de-entrevista.jpg

Problemas y preguntas de investigación

Ciertamente hay un gran número de opciones disponibles para evaluar un sistema ubicuo, no es necesariamente claro qué técnica es la más adecuada para un sistema o contexto de uso particular. Además, no es obvio si un técnica se puede aplicar de inmediato o si necesita ser adaptado para dar cabida a las propiedades específicas de computación ubicua.

Fuentes de datos para la evaluación

En términos generales, la evaluación de los sistemas ubicuos requiere a menudo el análisis de múltiples fuentes de datos. Los resultados individuales deben integrarse para incluir tanto los aspectos técnicos y los factores sociopsicológicos. El objetivo fundamental de este proceso de integración es evaluar plenamente el rendimiento de un sistema en todas partes con respecto a la satisfacción general del usuario y el rendimiento "técnico" del sistema.

Mientras que la gran cantidad de datos que se reunieron puede ser beneficioso en términos de obtener una imagen más clara del contexto y en relación con la evaluación detallada de un sistema, también hay algunas desventajas y otras repercusiones. Los datos obtenidos pueden incluir datos potencialmente sensibles con respecto a la seguridad y la privacidad de las personas o lugares. Es por lo tanto responsabilidad de los investigadores recoger la información para asegurarse de que los datos se manipulan de forma adecuada. Por otra parte, existe el peligro de que el volumen de datos es tan grande que la extracción de información significativa puede llegar a ser muy lento.

Comparabilidad

La comparabilidad de las evaluaciones es muy importante, sin embargo algo problemático. El propósito de la evaluación es informar el desarrollo de aplicaciones y sistemas en el futuro. Sistemas posteriores deben ser mejores que los que sustituyen. Ese término "mejor" causa problemas porque implica mensurabilidad. La evaluación de los dos sistemas debe permitirnos decir que un sistema sea mejor que otro, de acuerdo con un conjunto de objetivos.

El problema de comparar dos sistemas de computación ubicua puede ser significativamente más difícil que en otros dominios. Esto es en parte debido al carácter imprevisible de los factores contextuales y su impacto en la repetición, que es un requisito previo para la investigación rigurosa y la comparación de los sistemas entre sí. Por ejemplo, si bien puede ser bastante fácil de medir si la compra de un libro con un sitio web es más rápido que con cualquier otro sitio web, pero la comparación de dos sistemas ubicuos que prestan apoyo a la navegación adaptativa según el contexto puede ser más difícil.

La combinación de métodos cuantitativos y cualitativos

Para entender mejor el uso de sistemas ubicuos y evaluar rigurosamente su beneficios y costos propuestos, es necesaria una combinación de métodos cualitativos y cuantitativos. Dado que estos sistemas están todavía en el desarrollo de métodos cualitativos se deben implementar primero para evaluar la forma en que las personas interactúan y se adaptan a sus vidas tales sistemas. Entonces, cuando se establece una idea más clara del contexto y el beneficio propuesto, se requieren métodos cuantitativos para evaluar rigurosamente ese beneficio propuesto. De esta manera su potencial puede ser generalizada.

http://sphotos-b.ak.fbcdn.net/hphotos-ak-snc6/202482_395768260485412_1227728129_o.jpg

Conclusión

EL desarrollo de sistemas ubicuos es una tendencia muy reciente por lo que no existen muchas pruebas de usabilidad creadas específicamente para este tipo de ambientes donde el usuario no tiene una intervención directa con el sistema, pero se ha logrado adecuar pruebas de usabilidad que normalmente se usan en la evaluación de otro tipo de software.

Muchas de las pruebas suelen ser de alguna forma "genéricas" como en el caso de las encuestas y entrevistas, donde lo importante en realidad es en que forma se realizan las preguntas ya que deben estar orientadas para que el usuario que las conteste provea de información relevante a los desarrolladores para que ellos puedan tomar decisiones conforme a los resultados obtenidos.

Y como se mencionó entre las nuevas metodologías de evaluación existen aquellas donde la intervención directa de un usuario con el prototipo o producto final no es necesaria, como en la llamada "hombre detrás del telón" y aquella donde se requiere de algo de experiencia por parte del evaluador como en la evaluación heurística.

Detección de Agujeros

Visión Computacional
Tarea 6

Para la entrega de esta semana se nos pidió hacer lo siguiente.

• Agregar una rutina que detecta todos los agujeros en una imagen.
• Los agujeros detectadas se marcan con un borde morado oscuro y un relleno de morado claro.
• Un tono ligeramente diferente en cada agujero.
• Se marca el centro de cada agujero con un punto amarillo.
• Al centro de cada agujero se agrega una etiqueta del ID del agujero.
• El programa imprime un listado que indica para cada ID el tamaño del agujero (como porcentajes del tamaño de la imagen).

Utilice la técnica de histograma lateral, que consiste en sumar las intensidades de todos los pixeles, primero por cada fila para obtener un histograma horizontal y luego por columna para obtener un histograma vertical.

Al tener las dos histogramas podemos ponerlos por encima de nuestra imagen para observar como se comporta el histograma cuando existe un agujero en la imagen.

Como podemos notar en la imagen anterior, donde se cruzan las líneas que cruzan los puntos mínimos de los dos histogramas podemos encontrar una zona oscura que será detectada como un agujero. Nota: El pixel de inicio en la imagen es el de la esquina superior izquierda, por lo que para la línea roja hay que entender que el mínimo es el que pareciera ser una elevación.

Ahora veamos otro ejemplo de la foto de una tabla de madera con dos perforaciones. En la segunda imagen podemos observar un paso intermedio al momento de estar buscando por las coincidencias en todos los mínimos detectados. Y por último como sale la imagen en el programa que escribí.

Para cada agujero encontrado se le marco con un número junto a su centro y se le relleno de un color de tonalidad morada.

Código

Más pruebas

Las fotos que use para hacer las pruebas fueron de capturas a una hoja de papel con perforaciones hechas con la punta de una pluma.

En este caso por la forma en que quedaba el histograma, el centro lo detecto algo desfasado.

Y en las siguientes dos pruebas incluyo la captura completa junto con la salida que se generaba en el terminal, con los tamaños de los agujeros en un porcentaje con respecto al tamaño de toda la imagen.

Actividad 6: Relleno de Elipses y Círculos

Laboratorio de Visión Computacional
Actividad 6

A diferencia del código mostrado en la publicación de la clase, este código diferencia entre elipses y círculos, ya que el método de cuerda-tangente puede ser usado para la detección de ambas figuras.

En este código una vez detectado el centro de la figura, a partir de este punto se usa BFS para ir coloreando todos los pixeles dentro del contorno del elipse. A cada elipse y círculo se le asigna un número y se imprimen sus semidiámetros o radios, según corresponda, y por último se imprime para cada uno un porcentaje del tamaño con respecto al tamaño total de la imagen.

Código

Pruebas

Imagen después de binarizar y obtener bordes de las figuras.

Imagen obtenida.

Salida en el terminal.

Imagen después de haber encontrado los bordes y haber binarizado, antes de mandarse al método que buscará posibles elipses y círculos.

Resultado obtenido.

Y por último una captura de la ventana desplegada junto a la terminal donde se muestran las figuras detectadas, en este caso elipses y círculos, y se muestra en donde se encontró su centro, si es un elipse los semidiámetros o si es un círculo su radio, así como el porcentaje que ocupa la figura en relación a la totalidad de pixeles de la imagen.

Actividad 7: Simular Tráfico en NS-2

Laboratorio de Redes de Telecomunicaciones
Actividad 7

En la siguiente tarea será necesario simular tráfico en ns-2/3. Averigüen cómo se genera tráfico con distintas propiedades y cómo pueden monitorear las medidas de desempeño (mencionadas en esta clase) en su simulador. Incluir un miniexperimento sobre esto.

Generación de tráfico en NS-2 con distintas propiedades

Los objetos que se incluyen en NS-2 para la generación de tráfico pueden ser de cuatro tipos:

1. Exponential
   Objetos de tráfico exponencial generan tráfico en periodos On/Off. Durante periodos "On", los paquetes son generados a una velocidad constante. Durante los periodos "Off", no se genera tráfico. Los tiempos de generación y de inactividad son tomados por la distribución exponencial. Los parámetros de configuración son:
   
   

   PacketSize_	tamaño constante de paquetes generados
   burst_time_	promedio de tiempo activo del generador
   idle_time_	promedio de tiempo inactivo del generador
   rate_	velocidad de envío durante tiempo activo

   
   
2. Pareto
   Los tiempos de generación y de inactividad son tomados por la distribución pareto. Los parámetros de configuración son:
   
   

   PacketSize_	tamaño constante de paquetes generados
   burst_time_	promedio de tiempo activo del generador
   idle_time_	promedio de tiempo inactivo del generador
   rate_	velocidad de envío durante tiempo activo
   shape_	el parámetro forma usado por la distribución pareto

   
   
3. CBR
   Objetos CBR generan paquetes a una velocidad de bits constante.
   $cbr start inicia el generador
   $cbr stop detiene el generador de paquetes
   Los parámetros de configuración son:
   
   

   PacketSize_	tamaño constante de paquetes generados
   rate_	velocidad de envío durante tiempo activo
   idle_time_	promedio de tiempo inactivo del generador
   interval_	(opcional) intervalo entre paquetes
   random_	introducir ruido aleatorio, de forma determinada se encuentra off
   maxpkts_	numero máximo de paquetes a enviar

   
   
4. Traffic Trace Estos objetos son usados para generar tráfico desde un archivo de rastreo. Un lugar de partida aleatorio en el archivo de rastreo se elige.
   No hay parámetros de configuración para este objeto.
   

Monitorear medidas de desempeño

Para monitorear el desempeño de la red creada se necesita analizar los archivos generados al ejecutar el script tcl, ya que este te da un historial de todo lo que paso durante la simulación, como de que nodo a que nodo se envió información, cuanto tiempo tardo, si llego el paquete o no, etcétera.

Como ya lo había hecho en entradas atrás, una de las medidas de desempeño que evalué fue el Jitter y ahora añado también el Delay, como parte de la prueba que más adelante se muestra.


Esta prueba de retraso no fue escrita por mi propia cuenta, pero es encontrada en numerosas fuentes web donde se presenta el caso de medidas de desempeño en el simulador NS-2.

Experimento

Como se mostró en el inicio de esta publicación, en NS-2 podemos activar diferentes simulaciones de tráfico, que ya vienen implementadas en el simulador, y que son solo algunas de las posibles que se pueden presentar también en la vida real, como conexiones para videoconferencias y el streaming para ver algún canal de televisión vía Internet, donde es necesario conocer como puede comportarse la red en determinado momento si una gran cantidad de usuarios, y en nuestro caso nodos, solicitan la recepción de los datos para poder acceder al servicio.

De la prueba creada, podemos ver el comportamiento de la variación del retraso que se origino al correr la simulación. Como sabemos y como es de esperarse en una simulación, al correr en diferentes ocasiones la simulación los datos obtenidos serán diferentes, pero te acercan a un estimado de la variación que puede haber.

Una de las pruebas fue con una topología en estrella, donde algunos nodos envían paquetes para ser recibidos por otros, y como es de esperarse, el nodo central suele tener una carga mayor ya que necesita dar servicio a aquellos nodos que necesiten transferir datos a otros nodos en la misma red, lo que ocasiona sobrecarga de paquetes y la pérdida de algunos de ellos.

Y después al ejecutar los scripts de AWK para las medidas de desempeño obtenemos los siguientes resultados.

Otra de las medidas de desempeño que se efectuó fue el retraso que se genera entre un flujo de datos y otro, ya que como se sabe, la información no fluye siempre en un estado constante, sino que se dejan interrupciones que pueden ser provocadas por el tiempo que tarda la fuente en generar un flujo de datos.

En esta última gráfica podemos observar que a partir del segundo 1 que se empieza el envío de paquetes, ocurren por lo menos 4 retrasos notables en la transmisión de los datos generados.

Referencias:
Simulation Of Networks
Introducción Al Simulador De Redes NS-2
How To Measure Packet Loss Rate, Jitter, And Delay