Modelo en Simulink para el generador M/Pareto

Para analizar la arquitectura y el funcionamiento refiérase a la Fig. 5-4. El modelo consta de dos cadenas de entidades cada una con su generador Generator y su Sink (los Sinks no son obligatorios pero se han puesto por formalidad). En la cadena inferior se generan las ráfagas y en la superior los paquetes.

Fig. 5-3: Ventana de diálogo del bloque Event- Based Random Number

Si se cliquea dos veces sobre el bloque Event-Based Random Number se abre una ventana de diálogo con las propiedades, como se aprecia en la Fig. 5-3. Se seleccionó distribución exponencial con una media de tiempo interarribo de 1/lambda(kk). lambda(kk) es un elemento de un arreglo, ya que el modelo será manipulado desde Matlab mediante un script para automatizar la simulación. En el momento de ejecutarse el modelo, el arreglo lambda debe estar presente (cargado en memoria) en el workspace de Matlab, de otra forma se producirá un runtime error. Este generador provee los tiempos interarribo de las ráfagas conforme a una distribución exponencial.

La salida de este bloque toma sucesivos valores conforme a esta distribución, pero solo se hace presente un nuevo valor, después que una entidad haya partido del bloque subsiguiente, el Time-Based Entity Generator, cuya ventana de diálogo se muestra en la Fig. 5-5. Una nueva entidad partirá de este último bloque transcurrido el tiempo correspondiente al presente valor de t, y así sucesivamente. El puerto t del bloque Time-Based Entity Generator se lo denomina notifying port por esta propiedad.

54

55

Fig. 5-5: Ventana de diálogo del bloque Time-Based Entity Generator.

Fig. 5-6: Ventana de diálogo del bloque Set Attribute.

Entre el Time-Based Entity Generator y el Infinite Server se intercala el bloque Set-Attribute, Fig. 5-6. Este bloque crea una propiedad a cada entidad, si no fue creada previamente, asignándole un valor conforme a su notifying port de entrada A1. En este caso a cada ráfaga

56

se le asigna una duración dada por el bloque Event- Based Sequence, cuya secuencia con distribución Pareto es tomada del arreglo VectorPareto del workspace de Matlab, Fig. 5-7.

Fig. 5-7: Ventana de diálogo del bloque Event-Based Sequence.

Fig. 5-8: Ventana de diálogo del bloque Infinite Server.

El bloque que sigue es el ya mencionado Infinite Server, ver Fig. 5-8. Es un servidor compuesto de infinitos servidores idénticos en paralelo. Se configura para que el tiempo de servicio se corresponda con la duración establecida por la distribución Pareto, consignada en

57

el atributo Duracion de cada entidad que arribe. La salida estadística #n indica la cantidad de ráfagas que están siendo servidas simultáneamente en el bloque.

Fig. 5-9: Ventana de diálogo del bloque Entity Sink.

Las entidades, cumplida su función se descartan en el bloque sumidero Entity Sink, Fig. 5-9, cuya salida estadística #a alimenta a un bloque Display1 que informa la cantidad de entidades (ráfagas) arribadas del bloque anterior.

Fig. 5-10: Oscilograma de la cantidad de ráfagas superpuestas #n en el bloque Infinite Server.

A la salida #n del bloque Infinite Server se le ha conectado un Signal Scope para investigar si el proceso funciona correctamente. En la Fig. 5-10 se muestran los valores de #n de 0 a 10s. Por ejemplo en el tiempo de corrida del modelo igual a 5s, hay 7 ráfagas que están siendo servidas simultáneamente.

La información #n deberá estar disponible para fijar el tiempo de servicio del bloque Single Server de la cadena superior. Pero #n no representa el tiempo interarribo de paquetes,

58

sino la cantidad de ráfagas activas simultáneamente, por ello con auxilio del bloque Divide y el bloque Constant (cuyo valor r se obtiene del workspace) se calcula el Tiempo interarribo de paquetes = 1 (r∗#n), cuyo oscilograma producido por el Signal Scope1 se muestra en la Fig. 5-11, nótese la inversión respecto al oscilograma de la Fig. 5-10.

Fig. 5-11: Oscilograma del Tiempo interarribo de paquetes.

Fig. 5-12: Vistas coordinadas en el tiempo del Signal Scope1 y el Instantaneous Entity Counting Scope.

En la Fig. 5-12 se muestra un detalle, de 0,6 a 1,4s, de la Fig. 5-11 y su correspondiente efecto en el bloque Instantaneous Entity Counting Scope.

Se analiza ahora la cadena superior. A la izquierda comienza con un bloque Time-Based Entity Generator1, el mismo es un generador de intervalos de tiempo de 0,1ms, Fig. 5-13. Se seleccionó 0,1ms como el mínimo tiempo interarribo posible entre paquetes para el tráfico

59

que se desea simular. Sea una conexión Ethernet de 100Mbits/s, supóngase paquetes

Fig. 5-13: Ventana de diálogo del bloque Time-Based Entity Generator1.

60

únicamente de 1000 bytes, el tiempo interarribo de paquetes no puede ser menor que 1000 byte

100 Mbit s ∗

8byte bit

= 1,25 s, en este caso 0,1ms es congruente con el tráfico que se quiere simular que es el almacenado en el archivo LBL-PKT4. Cuanto mayor es este tiempo más rápida es la simulación. Básicamente la función del bloque es disponer siempre paquetes frescos, para alimentar al bloque Single Server.

Le sigue un bloque Set Attribute1 que marca los paquetes con el tiempo interarribo provisto por la cadena inferior del modelo, en la Fig. 5-14 se muestra la ventana de diálogo correspondiente.

Fig. 5-15: Ventana de diálogo del bloque Output Switch.

El bloque que siguiente es un Output Switch, Fig. 5-15. Si el Single Server está bloqueado sirviendo un paquete el paquete es desviado al sumidero Entity Sinkl por el puerto OUT2 de esta forma el Time-Based Entity Generator1 nunca quedará bloqueado.

La cadena continúa con el bloque Single Server, cuyo tiempo de servicio queda definido por el atributo consignado en cada paquete cuyo nombre es Interarrival, Fig. 5-16.

Fue necesario modificar los datos de la solapa Preemption por una sutil cuestión que complicó el diseño. Cuando la cantidad de ráfagas superpuestas en el Infinite Server es nula, el tiempo interarribo de paquetes es infinitamente grande o un valor que por programa se pueda asignar arbitrariamente para representar el tiempo interarribo mas grande que pueda suceder. Si tras esta situación a los pocos milisegundos arriban muchas ráfagas al Infinite Server, #n se incrementa marcándose los paquetes que emergen del bloque Time-Based Entity

61

Generator1 con un tiempo interarribo de paquetes pequeño, pero estos son descartados por el OUT2 del bloque Output Switch debido a que el puerto IN del Single Server es del tipo notifying port, y este último bloque nombrado no aceptará paquetes hasta que haya servido el que tiene en curso cuyo tiempo de servicio es un valor elevado.

Fig. 5-16: Ventana de diálogo del bloque Single Server. Se modificó los datos de la pestaña Preemption.

La situación planteada es que un único paquete puede detener el tráfico de muchos otros. Esta situación no parece ajustarse a la realidad, pero puede ser discutible esta opinión, de hecho puede generar espaciamientos que reproduzcan mas fielmente el tráfico que el generador pretende simular, situación que no se ha investigado especialmente en lo que respecta el efecto sobre las colas.

Al permitirse Preemption por los paquetes con menor tiempo interarribo como atributo (Attribute name Interarrival), si el paquete presente posee como atributo un tiempo interarribo superior se descarta por el puerto P desbloqueando el Single Server para el que llega.

La salida estadística #d del Single Server es enviada al workspace por el bloque Discrete Event Signal to Workspace, Fig. 5-17, en forma de una estructura bautizada simout, en cuyo vector simout.time está el producto final de este modelo. Se agrega a la misma salida un bloque Display que monitorea la cantidad de paquetes generados mientras se ejecuta el modelo.

62

Fig. 5-17: Ventana de diálogo del bloque Discrete Event Signal to Workspace.

Fig. 5-18: Ventana de diálogo del bloque Path Combiner.

El Path Combiner, Fig. 5-18, combina los paquetes servidos con los no servidos para su deposición en el bloque Entity Sink1 que es idéntico al de la Fig. 5-9, excepto por el nombre.

63