martes, 30 de abril de 2013

Retroalimentación de las pruebas de usabilidad

La semana pasada todos los equipos hicimos una presentación mostrando las pruebas de usabilidad hechas a nuestro proyecto, para poder mejorar su diseño, la tarea para esta semana es dar algunas recomendaciones a los demás equipos de pruebas de usabilidad u otras cosas para mejorar su producto.

Alarma Inteligente para Autos
Presentación

En esta presentación a mi parecer faltaron algunas cosas ya que no me pareció adecuado que no hayan incluido fotos ni vídeos de por lo menos alguna prueba hubiera estado bien ver el vídeo de la reacción de usuarios o fotos además para validar que de verdad se hicieron y no solo una narración de ellas, les falto detallar como es que hicieron lo de hombre atrás de la cortina, ya que no se especifica si el proyecto esta terminado o no,  y por si es que aún no estaba funcionando el prototipo pero nunca se dieron detalles de como va el proyecto realmente.
También me parece que hubiera sido adecuado incluir pantallas de la app actual y un diseño general de lo que será ya integrado el hardware con el softaware.

Computadora Inteligente
Presentación

Las pruebas de usabilidad que se hicieron me parecieron adecuadas, pero no me agradó que al momento de decir las conclusiones dijeron  "algunos aspectos del sistema no les agrado" refiriendose al usuario pero no dijeron cual fue el aspecto en concreto que causa el problema. Pienso que también falto una muestra de lo que se lleva hasta ahora del sistema que se diga lo que fue simulado y lo que ya esta realmente funcionando.
Me hubiera gustado también ver un diseño de hardware y software aunque sea en dibujos para ver como va a quedar el producto final, sin embargo las encuestas me agradaron creo que fue una buena idea además de ellas pueden obtener datos relevantes para el sistema como por ejemplo saber si al usuario le agrada que se bloque la computadora o no.
Otra cosa que pudieron haber tomado en cuenta es el SO para el que se va a desarrollar hacerlo a usuarios linux y windows para saber si se acoplarían rápidamente al sistema.

Oficina personalizada
Presentación

La parte que parece importante aquí es que se debe de realizar un diseño que ayude a mostrar de manera más agradable el lector RFID y no que el usuario pueda ver la electrónica ya que eso podría no agradarle o parecerle un trabajo no terminado, sin embargo si se le aclaró al usuario que es solo un prototipo no me parece que haya problema.
Este proyecto creo que se prestaba a hacer pruebas de usabilidad de personas en el escenario mostrando diferentes situaciones en las que se usaría el sistema inteligente.
Pero en general me agradaron las pruebas realizadas, la evidencia, etc. 

Galería Inteligente
Presentación

En este proyecto me parece urgente que se consiga el sensor de proximidad para tener una idea más precisa de las capacidades del hardware que se va a utilizar, con eso se hubieran podido hacer mejor las pruebas de usabilidad me parece.
Creo que aquí falto la implementación de las pruebas de usabilidad como el hombre atrás de la cortina me parece que hubiera sido bastante fácil implementarlo de manera correcta haciendo pensar al usuario que de verdad funciona el sistema.
También aquí pienso que sería bueno haber puesto alguna foto o vídeo para evidenciar lo que sucedió. Y especificar el rango de edades al que va dirigido y al que se le hicieron las pruebas de usabilidad.

Casa Inteligente
Presentación

Me agradó bastante que hayan incluido evidencias de las pruebas realizadas así como las encuestas que contestaron lo usuarios, pero me hubiera gustado que agregaran más posibles escenarios a las pruebas además de especificar a los usuarios a los que va dirigida la prueba.
Los posibles escenarios que pudieron haber agregado son por ejemplo que se encendiera el microondas, el clima, la televisión o algo diferente para poder agregar más funcionalidades y que el usuario hubiera podido probarlas.

Auto con NFC
Presentación

Aquí la presentación esta muy completa e incluyen demasiadas pruebas de usabilidad eso es bueno, sin embargo pienso que deberían enfocarse en cumplir y cubrir las necesidades básicas y no en querer abarcar demasiado terreno ya que el semestre es corto y es mejor terminar con lo más básico, dejando en segundo termino las redes sociales y las demás cosas que mencionan en el proyecto.
Me hubiera agradado ver las evidencias como algunas encuestas online, vídeo o fotografías de los usuarios, y pienso que pudo haber sido fácil agregar lo de hombre atrás de la cortina ya que el prototipo final no se tiene terminado aun.
Lo demás nada que decir fueron pruebas de usabilidad muy completas, útiles y acorde a su proyecto.

Garage inteligente
Presentación

En este proyecto me parecería bien que se pudieran guardar fragmentos de vídeo relevantes para cuando el usuario regrese poder mostrárselo y que pudiera ver cualquier anomalía que haya sucedido mientras el no se encuentre en casa. 
En las pruebas de usabilidad me pareció excelente que hayan mostrado como se vería el sistema final porque así le dieron mejor idea al usuario del proyecto. además del uso de los escenarios.
Hubiera estado bien incluir el rango de edad al que se le hiso las pruebas, pero por lo demás esta bien.

Proyecto localizador
Presentación

En esta presentación faltó una lista de los aspectos a mejorar después de haber hecho las pruebas de usabilidad, una retroalimentación final para comenzar a corregir cosas, todos los equipos lo hicieron.
También hubiera sido  mejor agregar algunas imágenes o vídeos de las pruebas hechas además de incluir edades de las personas a las que se hicieron las entrevistas para poder ver si cumplen con el público objetivo.


Control de congestión

Para esta entrada se hizo uso de los módulos que se desarrollaron para generar topologías y generar patrones de tráfico en las tareas pasadas de laboratorio.

Topologías

Para esto se creo un script en python que genera código en python también que forman algúna topología común como estrella, anillo o árbol. Este es el código con algunas mejoras del que se realizo en laboratorio:



Tráfico

Esto se realizo con un archivo de texto que tenía algunos datos relevantes, los pasos a seguir son:

  • Se implementa una subclase de la clase Application.
  • Instanciar una o varios sockets dentro de esa aplicación.
  • Iniciar la programación de eventos cuando se llama StartApplication.
  • Parar la programación de eventos cuando StopApplication es llamada.
  • Se crean paquetes y se envían en cada evento.

El código y su archivo de entrada.
El archivo de entrada contiene varios renglones y cada uno contiene la información de un envío en el siguiente orden:
nodo_inicio, nodo_final, tiempo_inicio, tiempo_termino, ip, data_rate

Código:



Lo siguiente es comparar por lo menos dos diferentes esquemas de control de congestión (inventados por nosotros mismos, sin googlear ni por ideas ni código)

Las librerías que hay que importar para crear y modificar las tablas de ruteo son:



Este código base es lo más importante para los dos algoritmos de congestion que cree:


El primer algoritmo que hice de congestión es muy simple, solamente toma un nodo al azar y es al que se le da preferencia de transferir o enviar datos y así hasta que todos los nodos han completado alguna acción.

El segundo algoritmo lo que hace es tomar el primero que esta en la lista que quiere enviar o recibir algún paquete y darle prioridad a el y una vez que lo hiso se saca de la lista y se va por el siguiente y así hasta terminar.

Código



Vídeo Algoritmo 1:



Vídeo algoritmo 2:



Referencias

Ejemplos del paquete de ns3/src/routing
Injection

lunes, 29 de abril de 2013

Sleep Mode for Energy Saving PONs: Advantages and Drawbacks

Nombre del documento:
Sleep Mode for Energy Saving PONs: Advantages and Drawbacks

Autores:
Shing-Wa Wong, Luca Valcarenghi, She-Hwa Yen, Divanilson R. Campelo, Shinji Yamashita, y Leonid Kazovsky

Enlace:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5360736

Antes de comenzar a resumir el artículo aquí hay una lista de abreviaciones que es necesario tener en cuenta:

Introducción

Un enfoque común para reducir el consumo de energía en redes de comunicación es permitir a los elementos de la red para cambiar al modo de reposo. Si bien esta técnica ha sido ampliamente utilizada en redes inalámbricas, los estudios recientes han propuesto explotar el modo de reposo en redes cableadas para conservar la energía también. En este trabajo se se centra en algunas implementaciones posibles de modo de espera en redes ópticas (PON). En particular, el modo de suspensión ONU es
considerado. En el documento se describe por primera vez el proceso de despertar ONU utilizando protocolos de multiplexación por división de tiempo (TDM actuales) PON. 
Las ventajas en términos de ahorro de energía se calculan analíticamente bajo diferentes escenarios de tráfico. En el uso de las arquitecturas propuestas, los resultados analíticos muestran que más de 50% de energía se ahorro de tráfico TDM realista. Por último, los posibles inconvenientes en cuanto a los nuevos retos de programación también se discuten y se presentan soluciones potenciales.

Modo de reposo y sincronización en TDM-PON

En el actual TDM-PON, OLT transmite físicamente tráfico de bajada a todas las ONU que permanecen activas aunque no son el destino de los datos. Esto se muestra en la siguiente figura los ahorros potenciales de energía deben mantenerse activos sólo en los intervalos de tiempo de recepción (es decir, cuando los datos están destinados a ellos) (sombreado) y cambiar al modo de dormir en los intervalos de tiempo vacíos (blanco). Mediante la explotación de la propiedad multiplexación estadística del tráfico, lo que provocaría una reducción significativa en el consumo de energía.


Para activar el modo de suspensión en la corriente TDM-PON, la ONU debe despertar del modo de suspensión y recuperar la sincronización con la red, la siguiente figura muestra las fases necesarias para una ONU cuando se quita el modo de dormir: la ONU debe recuperar el reloj OLT (Trecovery) y recuperar la sincronización con la red (Tsync). Esto causa en una sobrecarga,
Toverhead = Trecovery + Tsync  ,después de lo cual la ONU puede escuchar la asignación de ancho de banda y enviar o recibir datos de nuevo. El tiempo de sincronización, Tsync, depende de la formulación y el protocolo MAC utilizado. La subsección siguiente asume que el reloj se ha recuperado correctamente y detalla cómo una ONU podría recuperar la sincronización con la red del modo de suspensión, es decir, el proceso de sincronización.



Proceso de sincronización GPON

La transmisión GPON (GTC) especifica una marco GTC que dura 125μs , como se muestra en la figura siguiente al inicio de cada trama GTC, un bloque de control físico (PCB) se inserta, que incluye 4 bytes de sincronización física (Psync) y los bytes variables de asignación de ancho de banda ascendente. El ONU despierta el modo para ganar la sincronización de los primeros bytes del marco GTC. Cuando la ONU se despierta en medio de un GTC , que recibiría un encabezado Psync a más tardar 125μs más los 4 bytes para sincronizar con el marco GTC. Por lo tanto, el retardo máximo más largo que la sincronización no es 125μs.
Después de la sincronización de la trama GTC, la ONU podría reanudar el envío o recepción de datos en caso de que reciba un paquete o la asignación de ancho de banda. En GPON, esto podría ser
realizado utilizando el mapa de campo incrustado al final del PCB o el campo identificador de puerto de la encapsulación GPON.


Proceso de sincronización EPON

EPON tiene frames mucho más cortas que GPON. Cada EPON comprende solamente un paquete Ethernet, cuya unidad máxima de transmisión (MTU) de 1500 bytes, precedidos por un multi-punto de control (MPC) cabecea. Esta cabecera incluye un MPC que incluye una posición inicial fija delimitador (SPD) para permitir a la unidad ONU obtener la sincronización con el inicio del frame EPON. Por lo tanto, el tiempo de sincronización esperado en EPON es más corto que el tiempo de espera en GPON (125μs).



En EPON, multi-punto de protocolo de control (MPCP) se utiliza para reservas y asignar ancho de banda en la red. después sincronización con un marco de EPON, la ONU podría entonces aprender la asignación de aguas abajo de la capa de enlace subsiguiente campo de identificación (LLID). Para ancho de banda aguas arriba, la unidad ONU espera un mensaje de puerta que lleva sus donaciones de ancho de banda antes de enviar el tráfico.

Opciones de configuración del receptor ONU


Ahora se muestra el modo de dormir usando la arquitectura actual del receptor ONU. Enronces se proponen dos nuevas arquitecturas ONU de receptor que podría significativamente reducir el tiempo de recuperación de reloj en el proceso de despertador.

Actual arquitectura de receptor ONU y el modo dormir

En esta arquitectura, la señal óptica recibida es convertida primero en señal de energía eléctrica señal (es decir, la corriente) por un fotodiodo. Hay dos etapas de amplificadores eléctricos, incluyendo transimpedancia amplificador (TIA) y amplificador limitador (LA), amplifican la señal eléctrica antes de enviarla en el modo continuo Circuito CDR (CM-CDR). El CM-CDR envía la recuperación datos y de reloj para el deserializador (DMUX). El DMUX manda salidas paralelizadas de datos a la velocidad más baja, back-end digital de circuito para su posterior procesamiento. El circuito digital de fondo comprende principalmente la memoria y diversos datos digitales de procesamiento de bloques. Los detalles específicos del back-end digital de circuito se omiten debido a que sus implementaciones varían.



En esta arquitectura, cuando la ONU cambia al modo de dormir, todo el circuito analógico "front-end" y parte del "back-end" del circuito digital se apaga. Algunas partes del "back-end" digital de
circuito, tales como la memoria y reloj volátil, no se puede encender fuera y por lo tanto la ONU sigue consumiendo energía durante el modo de suspensión. Utilizando los datos de consumo de energía de una lista de PON bien conocida de proveedores de componentes, los consumos de energía previstos durante modo activo y el sueño por la opción 1 se resumen en la siguiente tabla:


Propuesta de Arquitectura del Receptor, opción 2

Para reducir el tiempo de recuperación de reloj experimentado por la primera opción, la unidad ONU receptor tendrá una arquitectura sobre la base de unidad ONU de un circuito de auto-actualización y un modo de ráfaga CDR (BM-CDR) es propuesto como opción 2. Se muestra el BM-CDR y el modo de dormir en el circuito de control que sustituye el circuito de CDR en la opción 1.



Propuesta de Arquitectura del Receptor, opción 3

Una desventaja de menor importancia de la opción 2 de la unidad ONU es que la arquitectura requiere la adición de un reloj preciso. Si bien no se espera que el coste de tales relojes sea alta, a menudo es deseable mantener el coste de la unidad ONU tan bajo como sea posible. Por lo tanto, se propone una arquitectura ONU alternativa que no añade ningún nuevo componente a la ONU de la opción pasada.


El análisis anterior no considera la pérdida de tráfico y retrasos de cola como resultado de la conmutación de una ONU de modo activo  a modo dormir. Cuando los nuevos paquetes llegan a una ONU durante el modo de suspensión, ONU podría poner en cola los paquetes antes de que se quiten del modo dormir y recuperar la sincronización con la OLT,  este proceso puede durar más de un tiempo de ciclo. Para resolver estos problemas, el OLT deben adoptar una programación más avanzada y un protocolo para asignar paquetes o subvenciones de ancho de banda ascendente cuando una ONU cambia al modo de suspensión. Un ejemplo de dicha programación avanzada y protocolo es el enfoque multi-poll eficiencia energética propuesto para las redes de área local inalámbricas.
Sin embargo, la amortiguación aumenta el retardo de paquetes. En TDM-PON, también ha demostrado notable reducción de almacenamiento en búfer de retardo cuando se utilizan modelos avanzados de predicción de tráfico.
Aunque minimiza el retardo es muy importante eliminar los efectos de la técnica de modo de suspensión sobre el tráfico.



El experimento sugiere que la opción 1, permite un ahorro de energía significativo cuando la ONU entra en modo de sueño para un largo período de tiempo. Esta característica podría ser útil cuando una ONU entra en un modo de stand-by en que la ONU sabe a ciencia cierta que va a estar fuera de línea para un cierto período de antemano. En muchos casos, sin embargo, una ONU no sabe acerca de su futura demanda de tráfico y la ONU tendría que despertar más a menudo para aprender acerca de la posibles asignaciones de tráfico. Las ONU son mucho más deseables. Por ejemplo, en la opción 2 y la opción 3  las unidades ONU proporcionan más de 10% de ahorro de energía que la opción 1 cuando el tiempo de sueño se encuentra entre 1 ms a 10 ms.

Conclusión

En este trabajo se presentan las posibles implementaciones de modo de dormir en las ONU para el ahorro de energía en redes PON. Se proponen arquitecturas que puede reducir significativamente los gastos de recuperación de reloj frente a arquitecturas ONU. Los resultados analíticos muestran que el ONU actual no logra un ahorro energético eficaz realista de tráfico TDM-PON. Por otra parte, se observan ahorros de energía, es decir, más del 50% de ahorro de energía, cuando se utilizan las dos arquitecturas propuestas.

Referencias

  1. Shing-Wa Wong, Luca Valcarenghi, She-Hwa Yen, Divanilson R. Campelo, Shinji Yamashita, Leonid Kazovsky, (2002). Sleep Mode for Energy Saving PONs: Advantages and Drawbacks. Photonics and Networking Research Laboratory. (), pp.6


jueves, 25 de abril de 2013

Métodos de diccionario-Byte pair encoding

Este método consiste en encontrar el par de bytes que más se repita en la cadena y sustituirlo por otro carácter que no se este usando.

Compresión
El string que usaré es "cdabcaabfeedefeede"

    • El que más se repite que podemos ver es el par "ee", entonces sustituimos este por X, lo qe nos da 
      • cdabcaabfXdefXde
        • X = ee
    • Ahora el que más se repite es "de" y lo podemos sustituir con Y, 
      • cdabcaabfXYfXY
        • Y = de
    • "XY" es ahora si el que más se repite y podemos sustituirlo con Z, de la siguiente manera:
      • cdabcaabfZfZ
        • Z = XY
    • "fZ" es ahora el que más se repite y cambiamos "fZ" por M, lo que nos da:
      • cdabcaabMM
        • M = fZ
    • El siguiente que hay que sustituir es "aa", lo podemos hacer con Q, y queda así:
      • cdabcQbMM
        • Q = aa
    • Y por último se sustituye "MM" por algun otro que puede ser R:
      • cdabcQbR
        • R = MM
Lo que nos da como resultado de "cdabcaabfeedefeede" a "cdabcQbR" se redujo de 18 a 8 bytes.

Descompresión
Para esto se usa el diccionario que ya tenemos que es el siguiente:
  • R = MM
  • Q = aa
  • M = fZ
  • Z = XY
  • Y = de
  • X = ee

    •  Comenzamos con "cdabcQbR" y se tiene que R = MM:
      • cdabcQbMM
    • Lo siguiente es sistituir la "Q" por "aa"
      • cdabcaabMM
    • Ahora la M por fZ:
      • cdabcaabfZfZ
    • Enseguida se sustituye la "Z" por "XY"
      • cdabcaabfXYfXY
    • Despues "Y" por "de"
      • cdabcaabfXdefXde
    • Y por ultimo "X" por "ee" y tenemos la cadena inicial:
      • cdabcaabfeedefeede

 Referencias

Byte pair encoding (). . [ONLINE] Available at: http://www.csse.monash.edu.au/cluster/RJK/Compress/problem.html. [Last Accessed 25 de abril de 2013].

Huffman adaptativo

Codificación adaptativa

La manera en que hice mi algoritmo adaptativo fue ir pasando carácter por carácter al codificador, entonces de manera que el primer carácter que entrara tuviera la frecuencia 1, pero que la raíz  siempre tuviera dos hijos, el derecho y el izquierdo en donde el izquierdo es un nodo auxiliar que es el que va a ayudar a ir colocando los nuevos símbolos en el árbol  cuando se encuentra que se colocó en un nodo algunas frecuencias al revés  por ejemplo "casualmente aparecen al principio 10 letras "e" y  5 letras "a" " con eso el árbol piensa que e merece un código más pequeño, pero después empiezan a aparecer las letras "a" y entonces se modifican los nodos para que siempre se cumpla con esa regla.  Cada vez que entra un nuevo carácter se va modificando la tabla de frecuencia y con esto podemos acomodar los nuevos nodos.

Decodificación

Para la decodificación se fueron guardando cada una de las tablas de frecuencia, y así al igual que en la entrada pasada simplemente, se leyó el archivo con la entrada y se empezó a decodificar cada uno de estos con los caracteres que ya se tenían previamente. Se fue leyendo el árbol para así poder decodificar y escribir en otro archivo el texto decodificado.

Experimento

Caso típico.- Para el experimento se tomo un texto de 100000 (el mismo de la tarea pasada)caracteres de un libro en inglés para poder representar el caso típico.
Peor caso.- Se escogió con random.choice de una lista que contiene ascci, del mismo largo que el texto que se tomo de ejemplo.
Y con estos dos textos de prueba se hicieron las pruebas con las siguientes variaciones:

  • Se cambió el largo que va agarrando, a lo que yo llamé "paso en el código", se fue cambiando de 10 en 10.
  • Se tomaron 10000 pruebas para gráficar.
Obviamente la impresión de esto es casi imposible así que solo para mostrar como corre el programa aquí dejo una captura con muy pocos caracteres:




Y el árbol de manera gráfica de otro ejemplo muy simple:


Aquí aun aparecía más veces la "b"
Después apareció más veces la "a" y cambiaron las posiciones
Este es el código:



Y las gráficas generadas se ven así:

Se puede apreciar ligeramente que el caso típico hace menos tiempo que el peor caso




Con lo que podemos concluir que el algoritmo funciona  mejor cuando se empieza a pasar de más de 100 caracteres, además podemos comprobar también que funciona mejor para el caso típico en cuestión de tiempo y ratio que para el peor caso.

Además se puede ver que el algoritmo funciona bien cuando el archivo es grande pero la tasa de compresión alcanzable es desfavorable al comienzo de la codificación o para archivos pequeños.

Para mejorarlo se podría tener ya una lista de probabilidades estándar en el idioma que se usa para así poder ir acomodando los nodos mientras van llegando sabiendo cual es su frecuencia también establecer siempre que el paso de caracteres sea siempre el mínimo por default 100 por ejemplo para poder evitar que entren pocos caracteres y se hagan probabilidades erróneas.

Referencias

Elisa Schaeffer-Métodos adaptativos

Preprocesamiento - Detección de agujeros

Prueban con algunas imágenes que contienen unos pocos objetos que no se empalman entre ellos y que tienen agujeros.
Usen fotografías tomadas por ustedes mismos.

Las fotografías que yo usaré son:







Dibujen encima de cada imagen una recta para cada pico del histograma lateral; independientemente para horizontal & vertical.
Imágenes mias:












en esta imagen vemos que se dibujan varias líneas debido a que los agujeros no están  alineados

Imagen de internet 1:





Imagen de internet 2:



Imagen de internet 3:






Código:



Refrencias

Visión computacional - Elisa Schaeffer

martes, 23 de abril de 2013

TCP-like Congestion Control for Layered Multicast Data Transfer

Artículo: TCP-like Congestion Control for Layered Multicast Data Transfer
Autores: Lorenzo Vicisano, Jon Crowcroft

En este documento se presenta un nuevo algoritmo de control de congestión adecuado para utilizar con flujos de datos en capas acumuladas en el MBone (IP Multicast Backbone). Este algoritmo se comporta de manera similar a los algoritmos de control de congestión de TCP, y comparte ancho de banda de forma justa con las demás instancias del protocolo y con flujos TCP, es enteramente receptor impulsado y no requiere el receptor el estado del remitente, en ordenar a escala a un gran número de receptores. Se basa en funcionalidades estándar de enrutadores de multidifusión, y es adecuado para la corriente continua y fiable la transferencia de datos.
En el documento se muestra el algoritmo, se caracteriza su respuesta a pérdidas tanto analítica como por las simulaciones, y se analiza su comportamiento mediante simulaciones y experimentos en redes reales. También se muestra que la recuperación puede ser tratada independientemente del control de la congestión mediante el uso Técnicas FEC, a fin de proporcionar la transferencia masiva de datos fiable.

Introducción

El diseño de uno a muchos protocolos de transferencia de datos que se ejecutan en la parte superior del servicio de multidifusión de Internet tienen que enfrentar el problema fundamental de control de congestión. La red es compartida por muchos usuarios que compiten y los flujos incontrolados y agresivos pueden llevar la red a un colapso de la congestión. Para evitar esto, las instancias del protocolo deben comportarse de tal manera para lograr una distribución equitativa de los recursos de red con las instancias de otros protocolos de buen comportamiento. Al mismo tiempo, en los protocolos de multidifusión, y de control eficaz de la congestión no debe ir en detrimento de la escalabilidad, ya que se desea abordar escenarios que comprenden miles de receptores.

El problema esta siendo cada vez más y más importante con la aumento de la difusión de las herramientas multimedia intensivas de banda ancha para vídeo y audioconferencia, que estimulan el uso de la red para llegar a grandes grupos heterogéneos, de los usuarios. para estas aplicaciones, las técnicas que se han propuesto para la transmisión de la misma corriente el uso de múltiples tipos de datos (que tiene diferentes niveles de calidad) sobre la base de una capa acumulada de organización de los datos. Mediante el uso de arreglos de datos apropiados, un enfoque puede ser usado para la transferencia fiable de datos.

El requisito de ser un competidor justo con otros protocolos de buen comportamiento, tales como TCP complica aún más el problema de la elaboración de un algoritmo adecuado que permita a los receptores elegir dinámicamente la velocidad de datos adecuada.

En este artículo se va a describir una congestión impulsada por el receptor algoritmo de control que es TCP y es adecuado para su uso en el Mbone. Se apoyan diferentes anchos de banda mediante una capa organización de los datos, y se deja que los receptores se adapten a la disposición de ancho de banda mediante la unión a uno o más grupos de multidifusión. Cada receptor toma decisiones de manera autónoma, pero las técnicas se utilizan para sincronizar receptores detrás del mismo cuello de botella (y que pertenecen a la misma instancia de protocolo), y para lograr un uso eficaz del ancho de banda. El algoritmo es completamente escalable y fácil de implementar, tanto en el emisor y en el lado del receptor.

Relación entre el rendimiento y la tasa de pérdida 

Las redes IP no tienen un mecanismo de notificaciones de congestión explícita. La respuesta a esta congestión hace que caigan paquetes, y ocasionan la pérdida de uno o más paquetes y el receptor informa al remitente donde se interpreta como una señal de congestión.

Un algoritmo de control de congestión debe reaccionar a señales de congestión mediante la reducción de la velocidad de transmisión.
La relación entre la tasa de pérdida de paquetes y el rendimiento, T, de una sesión de buen comportamiento es tal que incrementa los valores de p correspondientes a decrementar los valores de T. Para el algoritmo de control de congestión usado en TCP varios autores han llegado a la siguiente relación entre el rendimiento y la perdida de paquetes.


en donde la s es el tamaño del paquete, RTT es el tiempo de ida y vuelta para la sesión y la constante c esta en el rango 0.9...1.5. La relación es válida para pequeños valores de p, a altas tasas de pérdida, TCP tiende a perder su reloj auto ACK-basado, la sesión asume un caótico comportamiento y el rendimiento real tiene una disminución brusca y se convierte altamente dependiente de la longitud de la retransmisión tiempos de espera.

La pasada ecuación muestra que en presencia de tras el mismo cuello de botella (experimentando así una tasa de pérdida similar), la proporción real del ancho de banda depende de s y RTT.
Aparte de esta diferencia, compiten sesiones TCP para reducir su rendimiento de manera similar en la respuesta a las pérdidas. La equidad entre los diferentes protocolos requiere que todos ellos tengan un comportamiento similar en la respuesta a perdidas, y que sean comparables los valores absolutos de rendimiento y tiempos de respuesta.

La ecuación mostrada no captura completamente el comportamiento del sistema de control. Otro parámetro importante de cualquier algoritmo de control es la velocidad de respuesta a las variaciones en el sistema controlado en este caso condiciones de la red. Para el control de congestión del TCP, este tiempo de respuesta es del orden de RTT de la sesión que es el tiempo requerido para el remitente para recibir la retroalimentación y reaccionar.

Pertenencia a un grupo de multidifusión


La transmisión de datos de multidifusión en el Mbone es implementado por los routers de multidifusión, que se comunican con los hosts que utilizan un protocolo de pertenencia a un grupo dedicado, IGMP.
Los paquetes para un grupo multicast se presentan, en un segmento de red sólo si ese segmento conduce a receptores activos para ese grupo (ser nodos finales u otros routers multicast sirven para receptores activos).
En la fase de unión, un receptor que se une a un nuevo grupo envía una
Mensaje IGMP al router, que a su vez activa el reenvío para ese grupo, la propagación de la información a la enrutador de aguas arriba (mensaje del injerto). La fase de unión es rápida, teniendo aproximadamente un RTT (calculado entre el nodo de unión y el primer router hacia la fuente que está bloqueando el grupo).

En la fase de permiso, un receptor informa a su router local que no está interesado en el grupo. Esto desencadena una fase en la que comprueba el router multicast si otros receptores en la subred local todavía están interesados ​​en el grupo. Si no existen receptores activos, el router envía un mensaje para que el grupo y el enrutador de multidifusión bloque el reenvío para ese grupo. Dado que la ausencia de receptores activos sólo se puede determinar después de un tiempo de espera, la fase de licencia puede tardar mucho tiempo tiempo (unos segundos) lo que se llamamos demora de licencia.

Organización en capas de los datos


El protocolo de control de congestión se dirige a la distribución de los mismos datos (posiblemente, con diferente calidad) a un conjunto de receptores con diferentes anchos de banda, aumentando el ancho de banda. Suele ser factible para los flujos de datos multimedia, para los datos tales como un archivo y minimiza repeticiones.

Control de congestión para la capa de datos

El mecanismo de control de congestión está diseñado por un transmisor de envío de datos a muchos receptores en el Mbone. La comunicación puede implicar una corriente continua (por ejemplo, vídeo o audio datos), o una, de transferencia de datos mayor fiable (por ejemplo, un archivo). En esta sección se ignoran los paquetes que tenga que ser retransmitidos a fin de completar una transferencia de datos.

En las comunicaciones de unidifusión, el remitente toma parte de el control de congestión con señales de congestión de acuerdo a lo que recibe. En las comunicaciones multicast, este enfoque sería problemático, ya que los grupos de receptores pueden tener diferentes requisitos, y la adaptación a las necesidades de un conjunto de receptores penalizaría a los demás con los requisitos de contraste.

Adaptación a los requisitos heterogéneos se hace posible (y simple), ya que puede hacerse de forma independiente en cada uno subárbol servido por un router multicast. Como consecuencia de este enfoque, el transmisor no necesita ni siquiera tomar parte en el control de la congestión (excepto para el uso de una organización de los datos en capas).

En este algoritmo, los receptores conocen el estado de la red con señales de congestión (por lo general, las pérdidas de paquetes), y de control de flujo de datos de entrada utilizando la capacidad de enrutamiento multicast IP. Cada receptor se une o deja capas dependiendo de las señales de congestión recibidos. La estrategia para unirse o abandonar capas se elige de tal manera para emular el comportamiento de TCP y generar una relación similar entre el rendimiento y la tasa de pérdida.

Puntos de sincronización

Con más de un receptor detrás de un cuello de botella, la sincronización entre los receptores es fundamental con el fin de hacer que el mecanismo de trabajo funcione correctamente. De hecho:

  • la acción de un receptor de dejar caer una capa (dejando un grupo) no tiene ningún efecto a menos que todos los receptores compartan la caída de cuello de botella esa capa;
  • si un receptor provoca congestión  en la capa nueva, algún otro receptor puede interpretar los resultados como consecuencia de su nivel demasiado alto de suscripción y y soltar una capa;
  • si dos receptores detrás del mismo cuello de botella tienen diferentes niveles de suscripción, el cuello de botella del ancho de banda asignado a esa instancia del protocolo no se aprovecha plenamente;

Todos estos problemas pueden reducirse al mínimo si los intentos de unirse a diferentes receptores están coordinados.
Se ha evitado la introducción de un protocolo explícito para la coordinación receptor, ya que puede tener problemas de usabilidad, y podría ser lento.



Los problemas descritos en la sección anterior se agravan aún más por la duración de la demora, lo que hace un intento de unión y tiene consecuencias sobre la red durante mucho tiempo. Por otra parte, como una optimización del algoritmo, se debería ser capaz de aumentar el nivel de suscripción sólo cuando hay confianza de que el intento pueda tener éxito.

Diferencias con TCP

Aunque el algoritmo intenta imitar el comportamiento de control de la congestión TCP hay algunas diferencias entre los comportamientos de los dos algoritmos.

En primer lugar, con el algoritmo propuesto, los rendimientos relativos de las sesiones en competencia que experimentan el mismo tipo de pérdida no depende de la "distancia" (RTT) entre el emisor y el receptor. Entonces, el control de congestión de TCP tiene lo que puede aparecer como un grado de falta de equidad, en el que el rendimiento es inversamente proporcional al RTT. De hecho, ambos enfoques son apropiados y tienen diferentes objetivos:
En TCP, el control de congestión es controlado completamente por el remitente, y la única forma en que el receptor tiene que reducir el rendimiento es retrasar la generación de acuses de recibo, por lo que el RTT parece ser más grande de lo que realmente es. Además, las conexiones con mayor RTT son menos sensibles que aquellos con un RTT más corto, para ambos casos, es más que aceptable ese ancho de banda.


Conclusión

Se ha explicado un algoritmo de control de congestión para la transferencia de datos de multidifusión en la MBone, evaluado su desempeño y demostrado su aplicabilidad en corriente continua y la transferencia de mayor confianza. El algoritmo no requiere de apoyo del enrutador, o por el estado del emisor, sino que es completamente controlado por el  receptor, y no se basa en cualquier protocolo explícito para la sincronización del receptor o la gestión de pertenencia al grupo. Los resultados analíticos, simulaciones y experimentos en redes reales han demostrado que el algoritmo para lograr un reparto equitativo de la anchura de banda de cuello de botella con otras instancias del protocolo y con instancias TCP.

Este algoritmo es bastante óptimo ya que no toma en cuenta al enrutador y ni el emisor, si no todo es controlado por el receptor además no se basa solamente en protocolos para la sincronización del receptor si no toma en cuenta algunos otras medidas de calidad. Sería interesante programar en NS3 algo que simulara un comportamiento parecido para poder ver las estadísticas más a detalle y compararlo directamente con el TCP original.

Referencias

Detección de agujeros

Ahora se debe agregar a lo que se tiene (aún sin andar googleando y sin usar librerías para visión) una rutina que detecta todos los agujeros en la imagen, con las siguientes características:
  • 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).
Estas son las imágenes que yo conseguí tomando fotos en mi casa y los resultados de lo que obtuve:

Ejemplo 1:
Original

Histograma que ayuda a encontrar los cruces


Ayuda a saber los píxeles del contorno

Agujero detectado, centro: amarillo, id: 0, relleno: morado claro, contorno: morado obscuro





Ejemplo 2:








Ejemplo 3:







Y esta última es una imagen de internet
Ejemplo 4 :








Código:



Referencias

Elisa Schaeffer