Hola, soy X:
Tengo varias dudas:
Estoy implementado el CsmaBus como un servidor sin cola de espera, bien
cuando el método connecto llama al método Csma::Recv() entonces, lo que
realizo es la creación de un evento Timer con los siguientes parametros,
y es aqui mi pregunta:
void CsmaBus::Recv (timeunits now, Packet *p)
{
packetTrace(now, '+', p);
¿ TimerHandler h=new TimerHandler( ?
Timer next = new Timer(tiempoProcesamiento()+t_now,NetElement::GetId(),
*this, TimerHandler th, p);
/*
...
...
*/
//delete[] name_;
}
Mi pregunta es: como creo el tipo TimerHandler, y si es necesario llamar
al método send, para enviar el paquete al destino, o el evento Timer()
se encarga de hacerlo.
Si el Timer solo llama a otro método del elemeto que tu le pases
entonces, no hace falta el método send del CsmaBus, pq le pasas como
parametro al CsmaBus el sumidero, y en Timer lo configuras para que
llame al método SrSink::Recv -> y en este caso cuando el tiempo expire
llama, directamente al método recv de SrcSink, esto lo recoge y ya ha
terminado de enviarse el paquete, si esto no es asin entonces, tendria
que llamar mediante Timer(), a la funcion miembro CsmaBus:send y
posteriormente enviar el paquete. pero es aqui donde esta mi duda.
Le ruego encarecidamente me conteste al e_mail ya sea para responderme a
la pregunta o simplemente darme una pista, por donde seguir., he leido
unas cuantas veces la libreria NetElement.h de trajano.us.es/clases/lsim
y sigo teniendo esta duda que le envio,. a ver si es tan amable de
responder a mi pregunta.
Gracias.
X wrote:
>> Hola, soy X:
>>
>> Tengo varias dudas:
>>
>> Estoy implementado el CsmaBus como un servidor sin cola de espera, bien
>> cuando el método connecto llama al método Csma::Recv() entonces, lo que
>> realizo es la creación de un evento Timer con los siguientes parametros,
>> y es aqui mi pregunta:
>>
>> void CsmaBus::Recv (timeunits now, Packet *p)
>> {
>> packetTrace(now, '+', p);
>> ¿ TimerHandler h=new TimerHandler( ?
>> Timer next = new Timer(tiempoProcesamiento()+t_now,NetElement::GetId(),
>> *this, TimerHandler th, p);
>>
A GetId no hace falta ponerle el NetElement:: delante, no se
sobreescribe (no es virtual), así que no existe CsmaBus::GetId con la
que confundirse. Y se te olvida el *.
>> /*
>> ...
>> ...
>> */
>> //delete[] name_;
>> }
>>
>> Mi pregunta es: como creo el tipo TimerHandler, y si es necesario llamar
El tipo ya está creado. Es un tipo que define un puntero a una funcion
que toma dos parametros: un timeunit (tiempo actual) y un puntero a paquete.
Si quieres que en el futuro se invoque a la funcion HazEsto, simplemente
defínela como
CsmaBus::HazEsto(timeunits now, Packet* p) {...};
y crea el Timer que la invoca con:
Timer* next = new Timer(futuro, 0,
this,
(Timer::TimerHandler)(&CsmaBus::HazEsto(),
p)
luego la encolas y en paz:
Simulation.Schedule (next);
(p es el puntero al paquete con que quieres que se encuentre HazEsto en
el futuro)
Fíjate que tanto Send como Recv pueden ir como parámetros de Timer,
puesto que son funciones que toman los dos parámetros que TimerHandler
requiere.
> *this, TimerHandler th, p);
>> al método send, para enviar el paquete al destino, o el evento Timer()
>> se encarga de hacerlo.
>>
El metodo Send envia el paquete en cuanto se invoca. No espera. No lo
hace en un futuro, sino YA!. Para Send, el instante YA es el que se le
pasa como primer parametro. No sabe si YA es de verdad el tiempo actual
o un tiempo futuro. No sabe esperar. Eres tu el que tiene que decirle
que se invoque en un tiempo futuro, pasándoselo como parámetro a un
ejemplar de Timer.
>> Si el Timer solo llama a otro método del elemeto que tu le pases
>> entonces, no hace falta el método send del CsmaBus, pq le pasas como
>> parametro al CsmaBus el sumidero, y en Timer lo configuras para que
>> llame al método SrSink::Recv -> y en este caso cuando el tiempo expire
>> llama, directamente al método recv de SrcSink, esto lo recoge y ya ha
>> terminado de enviarse el paquete, si esto no es asin entonces, tendria
>> que llamar mediante Timer(), a la funcion miembro CsmaBus:send y
>> posteriormente enviar el paquete. pero es aqui donde esta mi duda.
>>
Very very good point. En general, X.Send simplemente invoca a Y.Recv,
supuesto que hicimos X.ConnectTo(&Y). Tu dices que puedes saltarte el
paso. Pero invocar a X.Send es mejor, ya que estamos todavía dentro del
ejemplar origen, lo que nos permite:
- realizar recoleccion de estadisticas o ajuste de contadores a la
salida del ejemplar del que se sale, y eso no seria posiblee segun tu
esquema.
- realizar "multicast" en un punto centralizado (el Send), cuando
tenemos conectado un elemento a varios de salida: si hacemos
X.ConnectTo(&Y);
X.ConnectTo(&Z);
segun tu esquema tendriamos que encolar dos eventos en todos lados,
pero si lo hacemos en el Send, basta con que éste llame a los
Recv de todos los elementos que de él cuelguen.
Hola, Gracias por responder a los mensajes anteriores, con la
ayuda prestada creo que voy por buen camino, utilizo la fuente de
datos PacketSource y es en el Bus donde llamo a Send enlocando el
evento con la condicion de que el Bus este libre en ese momento,
utilizo la variable colFlag_ para determinar cuando se puede enviar
el paquete y cunado no?
Mi duda es:
void CsmaBus::Recv (timeunits now, Packet *p)
{
packetTrace(now, '+', p);
if (!colFlag_) {
T_occupancy.accum(1);
colFlag_= true;
Timer* next = new Timer(tiempoProcesamiento(now,p),GetId(), this,
(Timer::TimerHandler)&CsmaBus::Send,
p);
Simulation.Schedule(next);
} else {
NetElement::FragmentDrop (p);
}
}
No se muy bien como recolectar estadisticas, si bien es cierto que
he notado que es el servidor el que puede mostrar las estadisticas,
no?. Cuando el Bus está ocupado transmitiendo un paquete entoces
el paquete que llega es Drop, por ello he utilizado la funcion
NetElement::FragmentDrop(Packet *p); El caso es que cuando realizo
la simulación , para 5 fuentes obtengo lo siguiente:
./csmanet.exe 2004 60 10000000 0.005 5 4638.671875 2048
===============================
SourceSink: 2
Packets from Source 3 : 2298
Packets from Source 4 : 2313
Packets from Source 5 : 2283
Packets from Source 6 : 2288
Packets from Source 7 : 2250
Total Packets: 11432
Total Fragments: 11432
T. Occupancy: avg = 0.991771
: sdv = 0.0903379
: var = 0.00816094
: num = 22866
: max = 1
: min = 0
Service Time: avg = 0.0002048
: sdv = 0
: var = 0
: num = 11433
: max = 0.0002048
: min = 0.0002048
Simulation Data:
================
Start Sim. at tu.: 0
Last Event at tu.: 59.9999
Total Num. Events: 1403953
Event rate(ev/tu): 23399.3
La verdad es que el tiempo de servicio lo calculo tal que asin:
timeunits CsmaBus::tiempoProcesamiento(timeunits now, Packet *p) {
unsigned int tam = p->GetBits();
timeunits tserv = (double) (tam / rBin_);
S_serviceTime.accum((double) (tserv));
return now+tserv+delay_;
}
y la variable que representa la estadisticas del tiempo de servicio
la incremento con el valor del tiempo de servicio, pero no varia, y
siempre es el mismo, que por otra parte sería razonable pues el
tamaño de los paquetes es fijo e igual para todas las fuentes.
He supuesto que la carga del servidor es del 0.95, pues necesitaba
el valor de lambda para realizar la simulación, y por eso lo he
calculo en base a un valor del 0.95 en la carga del sistema.
la duración ha sido de unos 60seg, aunque se puede aumentar,
También decir que para 500 fuentes y activando la recolección del
Nam, la memoria Ram se consume entera y es practicamente con 512Mb
de ram realizar la simulación en un tiempo adecuado. Bueno, no se
si he formulado correctamente las preguntas, seguiré pensando en el
tema y ya le preguntaré con más tiempo en el laboratorio.
Salu2, :P
X wrote:
> Hola, Gracias por responder a los mensajes anteriores, con la
> ayuda prestada creo que voy por buen camino, utilizo la fuente de
> datos PacketSource y es en el
> Bus donde llamo a Send enlocando el evento con la condicion de
> que el Bus este libre en ese momento, utilizo la variable
> colFlag_ para determinar cuando se puede enviar el paquete y
> cunado no?
>
> Mi duda es:
>
> void CsmaBus::Recv (timeunits now, Packet *p)
> {
> packetTrace(now, '+', p);
> if (!colFlag_) {
> T_occupancy.accum(1);
> colFlag_= true;
> Timer* next = new Timer(tiempoProcesamiento(now,p),GetId(), this,
> (Timer::TimerHandler)&CsmaBus::Send,
> p);
> Simulation.Schedule(next); } else {
> NetElement::FragmentDrop (p);
> }
> }
>
¿Qué pasa si otra fuente intenta transmitir un paquete antes de que pase
el tiempo de propagacion?
> No se muy bien como recolectar estadisticas, si bien es cierto
> que he notado que es el servidor el que puede mostrar las
> estadisticas, no?.
Claro, ya que se guardan en variables miembro del mismo.
> Cuando el Bus está ocupado transmitiendo un paquete entoces el
> paquete que llega es Drop, por ello he utilizado la funcion
> NetElement::FragmentDrop(Packet *p);
> El caso es que cuando realizo la simulación , para 5 fuentes
> obtengo lo siguiente:
>
> ./csmanet.exe 2004 60 10000000 0.005 5 4638.671875 2048
> ===============================
> SourceSink: 2
> Packets from Source 3 : 2298
> Packets from Source 4 : 2313
> Packets from Source 5 : 2283
> Packets from Source 6 : 2288
> Packets from Source 7 : 2250
> Total Packets: 11432
> Total Fragments: 11432
> T. Occupancy: avg = 0.991771
> : sdv = 0.0903379
> : var = 0.00816094
> : num = 22866
> : max = 1
> : min = 0
> Service Time: avg = 0.0002048
> : sdv = 0
> : var = 0
> : num = 11433
> : max = 0.0002048
> : min = 0.0002048
>
> Simulation Data:
> ================
> Start Sim. at tu.: 0
> Last Event at tu.: 59.9999
> Total Num. Events: 1403953
> Event rate(ev/tu): 23399.3
>
> La verdad es que el tiempo de servicio lo calculo tal que asin:
>
> timeunits CsmaBus::tiempoProcesamiento(timeunits now, Packet *p) {
> unsigned int tam = p->GetBits();
> timeunits tserv = (double) (tam / rBin_);
> S_serviceTime.accum((double) (tserv));
> return now+tserv+delay_;
> }
>
El modelado no es correcto.
> y la variable que representa la estadisticas del tiempo de
>servicio la incremento con el valor del tiempo de servicio, pero
>no varia, y siempre es el mismo, que por otra parte sería
>razonable pues el tamaño de los paquetes es fijo e igual para
>todas las fuentes.
>
Eso como tu lo veas.
> He supuesto que la carga del servidor es del 0.95, pues
>necesitaba el valor de lambda para realizar la simulación, y por
>eso lo he calculo en base a un valor del 0.95 en la carga del
>sistema.
>
Pero te sale un 99%. Tienes algo mal. Compruebalo con la formula teorica.
> la duración ha sido de unos 60seg, aunque se puede aumentar,
>También decir que para 500 fuentes y activando la recolección del
>Nam, la memoria Ram se consume entera y es practicamente con 512Mb
>de ram realizar la simulación en un tiempo adecuado. Bueno, no se
>si he formulado correctamente las preguntas, seguiré pensando en
>el tema y ya le preguntaré con más tiempo en el laboratorio.
>
> Salu2, :P
>
Hola, tengo la siguiente duda sobre la práctica 13:
A la hora de calcular el intervalo de confianza necesitamos la
varianza. Tanto el filtro retardo.awk como el cola.awk nos
proporcionan un fichero con la varianza media.
Cuando realizamos la batería de 10 experimentos y hacemos la media
de esos 10 resultados mediante el filtro meanvar.awk, éste nos
devuelve otra varianza correspondiente a los valores introducidos.
¿Cuál de las dos varianzas tomo para el intervalo de confianza?
Mi respuesta es que debería usar el meanvar.awk para calcular la
varianza media extraida de los 10 ficheros .var devuelto por los
filtros y NO la varianza entre los valores medios que da
directamente el meanvar puesto que corresponde a esos valores
concretos sin tener en cuenta los 30000s que duró el
experimento. ¿Es correcto el razonamiento?
Gracias de antemano.
XXX
La varianza que tienes que usar es la de meanvar.awk. La otras varianzas
son la varianza muestral de la longitud media de la cola en cada
experimento. Es funcion del tiempo. A ti te interesa estimar el valor
esperado de la longitud media de la cola en régimen permanente. No hay
tiempo. Haces 10 experimentos, cada uno te da una muestra del
estadistico a estimar (la media) y usas la media y la varianza de esos
10 experimentos.
Hola Juan Manuel,
Soy X, alumno del laboratorio de simulación y teletráfico, y
tengo una duda con respecto a lo que se piede en la práctica 15.
Dice que hagamos 20 experiemntos por cada valor de la carga
(0.005-0.95) y que los resultados de estos 140 experimentos se
almacenen en un archivo.
A partir de este archivo se debe hallar una serie de intervalos
de confianza, uno para el tiempo entre llegadas, otro para el
tiempo de servicio y otro para el numero de tramas en el
sistema. Lo que no se es si tenemos que calcular solo tres
intervalos para todo el archivo de resultados (es decir mezclar los
resultados obtenidos para los distintos valores de la carga), o
tres intervalos por cada valor que toma dicho parámetro.
Espero que se haya entendido...
Gracias
No, no me he explicado bien. Tienes que repasar la teoria.
Preguntamelo en clase, creo que es una duda que tiene más de
uno. Si vienes este jueves al laboratorio, coméntamelo entonces.
En síntesis, el intervalo de confianza da un margen de error de la
medida de un parámetro estocástico, basándose en distintas
muestras. Esas muestras deben corresponderse con las mismas
condiciones, estando su variación motivada no por el cambio de
éstas sino por la propia aleatoriedad del fenómeno (en este caso la
semilla). Pero mejor lo hablamos.
¡Hola! Soy una alumna del laboratorio de simulación y
tengo algunas dudas con respecto a la prácticas 13 y
14.
En la práctica 13, en el apartado siete si
representamos el intervalo de confianza con respecto a
la carga, ¿ en qué ro representamos? ¿hay que usar las
fórmulas de Redes de Ordenadores (las de un sistema
M/M/1/21)? Usando estas fórmulas obtengo una
ro=0.8798, pero no estoy usando datos de la
simulación, sólo datos teóricos.
Por otra parte, en la práctica 14 cuando creamos los
agentes, ¿hay que crear un agente sumidero por cada
comunicación que se vaya a recibir o sólo es necesario
uno?
Muchas gracias.
> ¡Hola! Soy una alumna del laboratorio de simulación y
> tengo algunas dudas con respecto a la prácticas 13 y
> 14. En la práctica 13, en el apartado siete si
> representamos el intervalo de confianza con respecto a
> la carga, ¿ en qué ro representamos? ¿hay que usar las
> fórmulas de Redes de Ordenadores (las de un sistema
> M/M/1/21)? Usando estas fórmulas obtengo una
> ro=0.8798, pero no estoy usando datos de la
> simulación, sólo datos teóricos.
Hola. Esta no la entiendo. Si quieres me la preguntas en
clase o vienes en tutoria o me la reformulas.
> Por otra parte, en la práctica 14 cuando creamos los
> agentes, ¿hay que crear un agente sumidero por cada
> comunicación que se vaya a recibir o sólo es necesario
> uno?
En principio el esquema es
fuente-(attached to)->agente---(connect)--agente-(attached to)->sink
Los elementos se "attachean" (fuente al agente, sumidero al agente,
agente al nodo, nodo al enlace, etc). Los agentes se conectan entre
pares, y el efecto es que el agente de la fuente manda cosas al
agente del sumidero
O sea que van por parejas.
Pero si mal no recuerdo para el caso concreto de los
agentes Null da igual.
> Muchas gracias.
Creo que con la duda de otro ya lo he entendido.
Hay que representar el teorico del formulaco (que es un
punto) y el resultado de la simulacion (que es el
intervalo de confianza)
Hola, después de machacar la práctica 16 he llegado a la que creo
es la solución, el problema es que se contradice con el tamaño de
cola que me dijiste. Te comento:
He usado tu fichero net1.cc que es el caso sencillo de 1 fuente de
paquetes, 1 servidor y 1 sumidero. He hecho que la fuente siga una
tasa de llegadas determinista y que el tamaño de los paquetes fuese
también determinista, es decir, dos constantes. De esta forma sabía
exactamente lo que llegaba al servidor en cada momento. Pues bien,
da igual la capacidad que le pongas al servidor, que si la cola no
tiene un tamaño mínimo igual al tamaño de un paquete, se pierden
todos los paquetes. Por tanto, en nuestro caso de los 3
conmutadores no puedo poner lo que me dijiste de un tamaño de cola
igual a 64*53*8, ya que eso significaria que estoy considerando que
el tamaño de los paquetes se corresponde con el tamaño de una
célula ATM y estoy poniendo espacio para 64 células. Por lo tanto,
siempre que llegue un paquete, como este no cabe en la cola, ya que
el paquete suele ser de un tamaño de 3000*53*8 , el paquete se tira
-> Se tiran todos los paquetes.
Para el factor de escala tengo que es: 477000
Para el factor de forma (dato): 1.6
Tamaño de la cola en bits yo considero que tiene que ser:
64*3000*53*8=81408000
En fin, la clave está en que el tamaño de la cola depende del
tamaño de los paquetes. Si llega un paquete que no coge en la cola
se tira. Como el tamaño de nuestros paquetes siguen una
distribución Pareto de media 3000 células, lo mínimo que se le
puede poner a la cola es un tamaño de 3000*53*8. Como se nos dice
que la cola tiene 64 posiciones -> multiplicamos ese valor por 64.
En fin, nada más, gracias por tu atención y a ver si le puedes
echar un vistazo, te lo agradecería mucho. Ya se sabe que para
estás cosas la mente no descansa hasta que se da con la solución.
Un saludo.
> Hola, después de machacar la práctica 16 he llegado a la que creo
es la solución, el problema es que se contradice con el tamaño de
cola que me dijiste. Te comento:
>
> He usado tu fichero net1.cc que es el caso sencillo de 1 fuente
> de paquetes, 1 servidor y 1 sumidero. He hecho que la fuente siga
> una tasa de llegadas determinista y que el tamaño de los paquetes
> fuese también determinista, es decir, dos constantes. De esta forma
> sabía exactamente lo que llegaba al servidor en cada momento. Pues
> bien, da igual la capacidad que le pongas al servidor, que si la
> cola no tiene un tamaño mínimo igual al tamaño de un paquete, se
> pierden todos los paquetes. Por
Ya veo, es un problema de modelado.
> tanto, en nuestro caso de los 3 conmutadores no puedo poner lo
> que me dijiste de un tamaño de cola igual a 64*53*8, ya que eso
> significaria que estoy considerando que el tamaño de los paquetes
> se corresponde con el tamaño de una célula ATM y estoy poniendo
> espacio para 64 células.
No, lo que quiere decir es que tienes que fragmentar el paquete en
células _antes_ de entregarselo al conmutador. Estas suponiendo que las
células se entregan "en bloque" al conmutador, pero éstas tienen que
llegar de una en una al conmutador. Si no, no modelas el sistema real.
Los conmutadores los tienes bien. Las fuentes también. Pero no la
conexión de las segundas a los primeros.
> Por lo tanto, siempre que llegue un paquete, como este no cabe en
>la cola, ya que el paquete suele ser de un tamaño de 3000*53*8 ,
>el paquete se tira -> Se tiran todos los paquetes.
>
> Para el factor de escala tengo que es: 477000
> Para el factor de forma (dato): 1.6
> Tamaño de la cola en bits yo considero que tiene que ser: 64*3000*53*8=81408000
>
> En fin, la clave está en que el tamaño de la cola depende del
>tamaño de los paquetes. Si llega un paquete que no coge en la cola
>se tira. Como el tamaño de nuestros paquetes siguen una
>distribución Pareto de media 3000 células, lo mínimo que se le
>puede poner a la cola es un tamaño de 3000*53*8. Como se nos dice
>que la cola tiene 64 posiciones -> multiplicamos ese valor por
>64.
>
No, porque entonces no estimas probabilidades de pérdida de célula,
sino de paquetes, que no es lo que se pide.
Las soluciones son o bien poner un fragmenter o bien poner un
server especial que fragmente.
La primera no resuelve el problema, porque se fragmenta pero se
siguen entregando todas las celulas en bloque (el fragmenter no las
espacia).
La segunda sí que sirve, si pones servidores bobos con cola
infinita, que framenten y con una linea de salida con tasa igual al
regimen binario de salida del conmutador.
Hola Juan Manuel,
He terminado la practica 17 y me surge la siguiente duda:
Para una lambda muy pequeña y un tiempo de simulación pequeño (5
segundos) el cálculo de G (el eje coordenado) a partir de los datos
de simulación difiere del teórico mas que para lambdas mayores, por
eso al representar la curva, la experimental y la teórica coinciden
salvo para lambdas pequeñas que se desvía un poco. Sin embargo si
en lugar de obtener la G a partir de la simulación pongo
directamente la teórica para cada lambda (para 5 segundos también),
ambas curvas coinciden con una exactitud de lo mas deseada. Luego:
para cinco segundos se puede obtener la grafica perfecta si se usa
la G teórica. Para obtener una grafica con la misma precisión
usando G experimental debería subir el tiempo de simulación a unos
500 segundos. Ahí va: ¿Estamos obligados a tomar también el eje
coordenado de los datos de la simulación o podemos usar su valor
teórico?
Gracias.
> Hola Juan Manuel,
>
> He terminado la practica 17 y me surge la siguiente duda:
>
Parece que no os he enseñado nada. Has terminado de codificar.
La práctica empieza ahora.
> Para una lambda muy pequeña y un tiempo de simulación pequeño (5
> segundos) el cálculo de G (el eje coordenado) a partir de los datos
¿Cual de los ejes? ¿Qué es G?
> de simulación difiere del teórico mas que para lambdas mayores, por
> eso al representar la curva, la experimental y la teórica coinciden
> salvo para lambdas pequeñas que se desvía un poco. Sin embargo si
¿Es por eso? ¿No habrá otro motivo? La interpretacion de los resultados
es, junto con el modelado, la clave de la técnica de simulación. La
codificación del modelo la hace un siervo.
> en lugar de obtener la G a partir de la simulación pongo
> directamente la teórica para cada lambda (para 5 segundos también),
> ambas curvas coinciden con una exactitud de lo mas deseada. Luego:
> para cinco segundos se puede obtener la grafica perfecta si se usa
> la G teórica. Para obtener una grafica con la misma precisión
> usando G experimental debería subir el tiempo de simulación a unos
> 500 segundos.
¿No es sospechoso? (sí que lo es, si no lo fuera no me preguntarías)
Algo pasa en esos 5 segundos. Parece más razonable esperar los 500.
Pero eso no responde a por qué se se desvía un poco en lambda pequeña.
Y es esa respuesta la que me gustaría escucharte.... Lo vemos el jueves
(recuerdamelo)
> Ahí va: ¿Estamos obligados a tomar también el eje
> coordenado de los datos de la simulación o podemos usar su valor
> teórico?
>
Cuando sepamos la verdad sabremos responder a esto.
> Gracias.
¡Hola! Tengo una duda con la práctica 17. He leido en
la página del laboratorio que hay que reducir la
anchura del intervalo de confianza a 10e-02. He
realizado la simulación y ya se obtiene esa anchura
simulando 60s, pero no sé si está bien o no porque en
las prácticas anteriores considerábamos eso aún como
transitorio. Entonces, ¿tengo que simular más tiempo o
en esta práctica 60s ya no es transitorio?
Lo que tienes que hacer es determinar tu misma
si es o no transitorio. ¿Cómo? Muy fácil: aprendiste en
la práctica 13. "En las practicas anteriores" era en
las practicas anteriores, ahora la cosa puede haber
cambiado, o no. ¿Es en todas las simulaciones del mundo
el transitorio igual a 60 s? No parece razonable. ¿Si en una
simulacion el transitorio es 60 s, significa eso que en
ninguna otra puede ser el transitorio de esa
duracion? Tampoco parece razonable.
Lo primero, gracias por intentar contestarme por email las dudas. Te voy
poniendo algunas:
(Como veras el email es un poco "tocho" y alguna pregunta es un poco
"filosofica" sobre el modelo, asi que si lo ves mas efectivo te propongo
usar algun sistema de Voip como skype... se que no es muy frecuente de hacer
pero alomejor solucionamos las dudas antes)
1. Antes te comento el planteamiento genera,l que esta practia ya tiene algo
de "miga" (de todas formas te mando csma.cc y .h por si puede ayudar). Si
miras el codigo, y antes de que te lleves las manos a la cabeza :) algunas
cosas estan provisionales y otras hechas un poco rapidas (es una version
beta, digamos)
En principio, como lo unico que me interesa es el rendimiento del bus y no
el sistema completo, lo que he hecho es modelar (o intentarlo) el
comportamiento de las fuentes dentro de la clase del bus y asi poder usar
las fuentes estandar packetsource.
En principio defino dos estados: 1 las fuentes no saben si el bus esta
ocupado: t2*Tp+JT. si no es un
caos... poruque ni siquiera el sistema real funcionaria bien porque podria
no darse cuenta de algunas colisiones al llegar el refuerzo de colision
tarde (el paquete ya se habria enviado)
3. Calculo del tiempo de espera para retrx. No estoy muy seguro
t_aleat=(2^n)*R
R=RTD+JT (ventana colision) ; n=entero aleatorio entre 1 y k; k= numero de
reintentos de ese paquete
Esto lo hago en la funcion t_aleat(int k)
4. ¿Tenemos un numero maximo de reintentos??
¿ Tenemos un truncado para para calcular k, de forma que superado un
numero de reintentos no se incremente para calcular el tiempo de reintento?
5. Ahora no lo tengo modelado poruqe no me he dado cuenta, pero he visto en
algun sitio que se espera el tiemo de 96 bits para trasnmitir tramas
consecutivas ¿lo modelo?. Se supone a tramas consecutivas de la misma
fuente, ¿no?
6. Cuando una fuente esta retx no debo aceptar nuevos paquetes (que mi
fuente estandar me estara enviando porque es tonta). Tengo varias opciones
de modelar esto:
a) La mas facil y la que tengo implementada de momento. Como todas las
fuentes son iguales, no llevo control de que fuente exactamente esta retx.
Solo llevo un control del numero de fuentes (segun el identificadores de
paquete distintos) y admito un porcentaje de paquetes segun esto. Es lo que
hago en Recv():
if( unif_->GetVal()<(nsources_retx_/nsources_) ) {
delete p;
}else{ //sigo
b) Llevar un control de que fuentes exactamente estan retx. Esto me
obligaria a conectar un servidor entre la fuente y el bus, para identificar
el srvidor por el nombre (name_) (la fuente creo que no tieen nombre) (Aqui
se me planteo la duda del efecto de poner un servidor y si lo necesito o
no..... lo comento mas adelante mejor)
Si tengo un piuntero a Packet p, lo haria asi:
NetElement* source=p->GetSrc();
NetElement* server=source->GetNextHop(0);
//Lo sigioente esta bien?? name_ es privada!!!
servername=server->name_;
El problema es que name_ es private y no hay nngun metodo para acceder a
ella. Podria incluirlo en netelement.h, pero no se si puedo ¿?
c) Esa opcion esta bastante bien pero me obliga a modificar la fuente. Hacer
que mis fuentes no sean tan "tontas". Crear case derivada de Packetsource
donde redefina solo el metodo Send() de forma que pueda parar la siguiente
llegada con un flag: para la fuente cuando quiera. Crearia dos metodos para
parar y reactivar la fuente (solo cambiarian esta flag). Ej:
If(!stopped_){
//Enqueue next arrival
Start(now + t);
//Accumulate this interarrival time
S_interArrival.accum((double) t);
}
Pero esto solo lo haria el metodo si Send proporcionado en
EJEMPLOS_FUNCIONES.txt es el real de la clase y no esta simplificado. Y
obviamente si el metodo a) no es valido...
no tengo demasiado tiempo para ponerme a hacer florituras :)
7.Medida de la eficiencia. No tengo demasiado claro lo que tengo que medir
(y sin esto claro, de poco sirve tener el modelo del bus...)
La eficiencia que quiero mide el trafico cursado por el bus respecto al
trafico ofrecido al bus, no??. Pero siempre referido al bus, me da igual el
trafico total del sistema (las fuentes)...
Bien, en cuanto al trafico ofrecido: ¿seria el numero de reintentos*tam
paquete/tiempo total de simulacion?
en cuanto al trafico cursado: ¿seria el numero de paquetes enviados OK*tam
paquete/tiempo total de simulacion?
Si es asi, ¿para que quiero las instancas de Tstat y Lstat que aparecen en
el esqueleto propuesto?: S_serviceTime, T_occupancy
Supongo que los datos que me hacen falta puedo levarlos con contadores, sin
tener que usar estas clases, ¿no?
8- Sobre el modelado del istema con el bus.¿usar servidores o no?
A ver, se supone que a mi solo me interesan las estadisticas del bus, no de
lo demas. Por esto en principio parece que da igual conectarle algo entre la
fuente y el bus. Teniendo en cuenta que ademas el trafico ofrecido al bus
(con mis fuentes "tontas" y descartando los paquetes que no llegan en el
momento adecuado) no es el trafico generado por las fuentes en cualquier
caso.
- En principio pense que el servidor me ayudaria a tx al rbin del bus y
guardar mientras paquetes en la cola.... pero creo que lode la cola no me
aporta nada porque solo me interesa lo que llega al bus y lo que sale sin
colisionar. Y lo de tx a rbin creo que ya lo hago en el bus liberando con
BusFree() en t_tx (segun rbin), creo que es lo unico en lo que ifluye...
mientras esta ocupado simplemente desecho los paquetes que me llegan (esto
no se haria en un sistema real, se guardarian en un a cola, pero creo que da
igual)
Con lo que al final creo que optare por conectar las fuentes directamente al
bus. ¿Que opinas de esto?
9- El destructor de CsmaBus.
¿Con "Dump statistics" te refieres a guardar las estadisticas en un fichero
o algo asi? Si te refieres a las estadisticas de las instancias TStat y
LStat, no lo acabo de ver.... porque en la practica 15 tambien e usaban para
estadisticas pero no vi en ningun sitio que se tuviese que hacer nada para
volcarlas, suponia que lo hacia el objeto Simulator...
Pero, si no son necesarias estas instancias TStat y LStat, solo deberia
guardar los contadores que tengo para las retx y pauquetes ok, ¿no?
Intente usar la funcion padre NetElement::Reset(true) pero parece que no
esta definida.
10. Por lo demas, mi fichero compila bien pero no hace nada cuando lo
ejecuto.... supongo que es porque no guardo estadisticas en el destructor.
Pero he puesto un printf en Recv()
y no hace nada... un poco extraño. No se si podras (o querras) ayudarme con
esto porque ya es un poco concreto de mi programa... pero bueno, te lo
comento por si me puedes dar algunas pistilla
Un saludo y gracias de nuevo.
>
> Cuando estoy en 1, acepto los paquetes que me llegan pero no compruebo la
> colision hasta t0+Tp (con t0 el instante en que llega el primer paquete en
> 1), en el evento manejado por Check(). Si hay colision coy retirando los
> paquetes del sistema (inSystemPackets_--) y lanzo eventos para reintento
Si los retiras inmediatamente no es CSMA, sino CSMA/CD.
> (Retry()) en tiempos aleatorios segun el numero de reintentos de ese paquete
> (llevo la cuenta de esto en otra variable). Si no hay colision, llamo a Send
> para que empiece la tx del paquete.
>
Entonces has perdido un tiempo de trx igual a Tp. Y eso es falso, puesto
que la transmisión empieza en t0.
> En send, simplemente subo la bandera isBusy y lanzo el evento FreeBus para
> que baja esta bandera en Ttx (cuando acabe de tx). A continuacion paso el
> paquete al siguiente elmento (el Sink) con NetElement::Send(now, p);
>
> Y mas o menos ese es el funcionamiento general.
>
> DUDAS:
>
> 1. ¿Hago bien en retrasar la comprobacion hasta t0+Tp en el evento check? En
Sí.
> un sistema real algunas fuentes pueden detctarla antes (y yo en mi modelo
Es una de las simplificaciones aceptables del modelo. El analisis teorico tambien la supone.
> tambien, en cuanto intenten tx y ya haya una en el sistema), pero si no se
> complica un poco la cosa y ademas no estoy seguro hasta Tp . al fin y al
> cabo lo unico que cambio es el tiempo desde el cual empieza el contador
> aleatorio para retx.
>
> 2. ¿Es necesario modelar el envio del "refuerzo de bloqueo"?. Esto creo que
No sé que es eso del refuerzo... Si es la señal de jamming, eso es CSMA/CD, no CSMA.
> solo vale para que el primero que tx el paquete cuando hay colision se
> entere.Y tarda 2Tp+JT(=Ttx del refuerzo) desde que inicio la tx. Esto solo
> me influiria en que la primera fuente iniciaria el contador para el
> reintento un poco mas tarde, pero es que el tiempo 2*TP+JT es el caso peor y
Ah, ya veo (JT es jamming time): estas modelando csma/cd no csma.
> al final si es un tiempo aleatorio... no creo que influya mucho (es por
> simplificar)
>
> Por otro lado estoy suponiendo que se cumple la condicion de que la longitud
> del paquete es suficiente mente grande para que el Ttx>2*Tp+JT. si no es un
> caos... poruque ni siquiera el sistema real funcionaria bien porque podria
> no darse cuenta de algunas colisiones al llegar el refuerzo de colision
> tarde (el paquete ya se habria enviado)
>
Insisto, se pide csma, no csma/cd
> 3. Calculo del tiempo de espera para retrx. No estoy muy seguro
> t_aleat=(2^n)*R
> R=RTD+JT (ventana colision) ; n=entero aleatorio entre 1 y k; k= numero de
> reintentos de ese paquete
>
> Esto lo hago en la funcion t_aleat(int k)
>
que es t_aleat? Es igual, se pide csma, no csma/cd.
> 4. ¿Tenemos un numero maximo de reintentos??
> ¿ Tenemos un truncado para para calcular k, de forma que superado un
> numero de reintentos no se incremente para calcular el tiempo de reintento?
>
Depende de lo que estes modelando.
> 5. Ahora no lo tengo modelado poruqe no me he dado cuenta, pero he visto en
> algun sitio que se espera el tiemo de 96 bits para trasnmitir tramas
> consecutivas ¿lo modelo?. Se supone a tramas consecutivas de la misma
> fuente, ¿no?
>
Insisto, eso es csma/cd (y ademas para el caso particular de ethernet)
No es lo que se pide
> 6. Cuando una fuente esta retx no debo aceptar nuevos paquetes (que mi
> fuente estandar me estara enviando porque es tonta). Tengo varias opciones
> de modelar esto:
Si eso es así, entonces no puedes suponer poblacion infinita (al
retirar uno hay menos fuentes trxiendo), ni generacion poissoniana,
si comparar con el resultado teorico puesto que éste supone
pobl. infinita.
> a) La mas facil y la que tengo implementada de momento. Como todas las
> fuentes son iguales, no llevo control de que fuente exactamente esta retx.
> Solo llevo un control del numero de fuentes (segun el identificadores de
> paquete distintos) y admito un porcentaje de paquetes segun esto. Es lo que
> hago en Recv():
>
> if( unif_->GetVal()<(nsources_retx_/nsources_) ) {
>
> delete p;
>
> }else{ //sigo
>
> b) Llevar un control de que fuentes exactamente estan retx. Esto me
> obligaria a conectar un servidor entre la fuente y el bus, para identificar
> el srvidor por el nombre (name_) (la fuente creo que no tieen nombre) (Aqui
> se me planteo la duda del efecto de poner un servidor y si lo necesito o
> no..... lo comento mas adelante mejor)
>
> Si tengo un piuntero a Packet p, lo haria asi:
>
> NetElement* source=p->GetSrc();
> NetElement* server=source->GetNextHop(0);
>
> //Lo sigioente esta bien?? name_ es privada!!!
>
> servername=server->name_;
>
> El problema es que name_ es private y no hay nngun metodo para acceder a
> ella. Podria incluirlo en netelement.h, pero no se si puedo ¿?
>
>
No. name_ es accesible sólo en el constructor.
> c) Esa opcion esta bastante bien pero me obliga a modificar la fuente. Hacer
> que mis fuentes no sean tan "tontas". Crear case derivada de Packetsource
> donde redefina solo el metodo Send() de forma que pueda parar la siguiente
> llegada con un flag: para la fuente cuando quiera. Crearia dos metodos para
> parar y reactivar la fuente (solo cambiarian esta flag). Ej:
>
Insisto, si la fuente se para al detectar colisión, eso es csma/cd. No es lo que se pide.
> If(!stopped_){
> //Enqueue next arrival
> Start(now + t);
> //Accumulate this interarrival time
> S_interArrival.accum((double) t);
> }
>
> Pero esto solo lo haria el metodo si Send proporcionado en
> EJEMPLOS_FUNCIONES.txt es el real de la clase y no esta simplificado. Y
> obviamente si el metodo a) no es valido...
> no tengo demasiado tiempo para ponerme a hacer florituras :)
>
> 7.Medida de la eficiencia. No tengo demasiado claro lo que tengo que medir
> (y sin esto claro, de poco sirve tener el modelo del bus...)
>
> La eficiencia que quiero mide el trafico cursado por el bus respecto al
> trafico ofrecido al bus, no??. Pero siempre referido al bus, me da igual el
> trafico total del sistema (las fuentes)...
Correcto. Es una de las definiciones
> Bien, en cuanto al trafico ofrecido: ¿seria el numero de reintentos*tam
> paquete/tiempo total de simulacion?
> en cuanto al trafico cursado: ¿seria el numero de paquetes enviados OK*tam
> paquete/tiempo total de simulacion?
>
Esta es precisamente la pregunta base de la practica. Si te la digo
no tiene gracia.
> Si es asi, ¿para que quiero las instancas de Tstat y Lstat que aparecen en
> el esqueleto propuesto?: S_serviceTime, T_occupancy
> Supongo que los datos que me hacen falta puedo levarlos con contadores, sin
> tener que usar estas clases, ¿no?
>
Puedes usar o contadores que tú te definas, o esas clases, o ambas cosas.
> 8- Sobre el modelado del istema con el bus.¿usar servidores o no?
> A ver, se supone que a mi solo me interesan las estadisticas del bus, no de
> lo demas. Por esto en principio parece que da igual conectarle algo entre la
> fuente y el bus. Teniendo en cuenta que ademas el trafico ofrecido al bus
> (con mis fuentes "tontas" y descartando los paquetes que no llegan en el
> momento adecuado) no es el trafico generado por las fuentes en cualquier
> caso.
>
> - En principio pense que el servidor me ayudaria a tx al rbin del bus y
> guardar mientras paquetes en la cola.... pero creo que lode la cola no me
> aporta nada porque solo me interesa lo que llega al bus y lo que sale sin
> colisionar. Y lo de tx a rbin creo que ya lo hago en el bus liberando con
> BusFree() en t_tx (segun rbin), creo que es lo unico en lo que ifluye...
> mientras esta ocupado simplemente desecho los paquetes que me llegan (esto
> no se haria en un sistema real, se guardarian en un a cola, pero creo que da
> igual)
>
> Con lo que al final creo que optare por conectar las fuentes directamente al
> bus. ¿Que opinas de esto?
>
A mi me parece mas razonable no usar server. Pero el modelado no es unico.
> 9- El destructor de CsmaBus.
> ¿Con "Dump statistics" te refieres a guardar las estadisticas en un fichero
> o algo asi? Si te refieres a las estadisticas de las instancias TStat y
> LStat, no lo acabo de ver.... porque en la practica 15 tambien e usaban para
> estadisticas pero no vi en ningun sitio que se tuviese que hacer nada para
> volcarlas, suponia que lo hacia el objeto Simulator...
>
No, a ponerlas por pantalla. Los objetos TStat y LStat lo hacen al
destruirse. Igualmente lo hacen al morir fuentes y
sumideros. Espero que el Bus tambien lo haga.
> Pero, si no son necesarias estas instancias TStat y LStat, solo deberia
> guardar los contadores que tengo para las retx y pauquetes ok, ¿no?
>
Pero tendras que hacer alguna cuenta al final, y sacarla por
pantalla para poder representarla graficamente.
> Intente usar la funcion padre NetElement::Reset(true) pero parece que no
> esta definida.
>
Es virtual pura. Es decir, cada clase derivada debe implementarla.
Se invoca automágicamente por el simulador cuando acaba el
transitorio, para resetear contadores internos del objeto en
cuestion -por ej tus contadores antes citados que pertenecen a
CsmaBus- (esto permite eliminar el transitorio sin necesidad de
crear ficheros de trazas monstruosos)
> 10. Por lo demas, mi fichero compila bien pero no hace nada cuando lo
> ejecuto.... supongo que es porque no guardo estadisticas en el destructor.
> Pero he puesto un printf en Recv()
> y no hace nada... un poco extraño. No se si podras (o querras) ayudarme con
> esto porque ya es un poco concreto de mi programa... pero bueno, te lo
> comento por si me puedes dar algunas pistilla
>
>
La pista es: gdb.
Veo que te has dado cuenta que estaba modelando el bus csma/cd y no el csma
(vaya metedura de pata) ... di por hecho que era el csma/cd poruqe muchas veces
cuando hablamos de csma nos referimos al csma/cd... La verdad es que me habria
resultado mejor preguntar antes y ahorrarme algo de trabajo pero bueno...
Asi que voy a cambiar el "chip" a csma, retocar el modelo e ir digiriendo un
poco tus respuestas y supongo que pelearme con el gdb. Por cierto ¿tines alguna
idea de como instalar el xxgdb en el entorno Cygwin...? es que estoy un poco
perdido y con el gdb clasico no creo que me atreva
Un saludo y gracias.
xxgdb no esta soportado en cygwin.
Hola Juan Manuel
Esto te lo pregunto por si no puedes ir a la escuela el lunes, no espero que me
respondas en domingo :)
A ver, una vez que he empezado con el csma (no el csma/cd) la cosas
se ha simplificado bastante.. ya mayoria de las dudas que te
pregunte al principio eran para el csms/cd y en el csma no tienen
sentido. Ya tengo el modelo que compila y despues de repasarlo
muchas veces con el gdb diria que hace lo que yo quiero.
En el csma el planteamiento que he seguido es el mismo que te
comente la primera vez solo que cuando compruebo las colisiones en
Tp dejo el canal ocupado durante el tiempo de tx,
independientemente de que haya colision o no. Cuando el bus esta
ocupado las fuentes no inentan tx (en relidad si lo hacen porque
son tontas pero yo tiro los pquetes y no los cuento). Las
estadisticas las he recogido al final en contadores simples (sin
usar tstat), asi que tengo 3 contadores: num de tramas tx ok
(totalPaketsOK_), num de colisiones (numCollisions_) y num de
tramas enviadas por las fuentes (totalPakets_, realmente es la suma
de los dos anteriores); de esta forma calculo el rendimiento como:
totalPaketsOK_/totalPakets_ que corresponde al trafico cursado por
el bus sin colision/trafico ofrecido al bus por las fuentes.
La duda ahora esta en ¿tengo que considerar en el trafico ofrecido
al bus los paquetes que estoy "tirando" porque llegan cuando el bus
esta ocupado?, en principio no lo hago poruqe se supone que lo que
esta conectado al bus no intenta tx en esta fase... pero depende un
poco de como se defina el rendimiento y si quiero considerar el
hecho de que las fuentes quieran tx pero no puedan... (aunque esto
creo que seria mas el rendimiento del sistema y no del bus). Le he
dado muchas vueltas pero no me acabo de aclarar
Otra cosa que sigo sin entender bien es el uso de la funcion
Reset() del bus, de hecho la he dejado vacia y parece que todo
funciona bien... Otra cosa, no se si tengo que comparar la grafica
de rendimiento del modelo con la teorica (csma_np.gnuplot) en una
misma grafica. El problema lo encuentro al normalizar, para poder
comparar supongo que deberia normalizar ambas graficas respecto al
mismo valor de trafico ofrecido al bus ya que si no btengo
resultados distintos (realmente serian los mismos pero para valores
distintos del eje x..) , claro y esto influye porque cuanto mayor
sea lambda menor es el rendimiento y si no hago coincidir las
graficas en el mismo lambda (o trafico ofrecido) maximo pues creo
que asi no puedo compararlas...
De hecho he estado haciendo varias pruebas con lambdas cada vez
mayores y cada vez se aproximaba mas a la teorica.. hasta que me he
pasado (una cura de rendimiento menor). Para comparar los distintos
valores del modelo con Tp distinto no hay problema poque en ambo
usaria la misma lambda maxima y normalizaria respecto al mismo
valor. Otra cosa que no entiendo en la grafica teorica es el
parametro xprop (en el .gnuplot) aunque tampoco se si es importante
para algo o no Por lo demas, me parece que el resultado es valido
ya que evoluciona como se esperaba y con la misma forma que la
teorica: el rendimiento disminuye cuando aumenta el trafico y
tambien dismininuye cuando aumenta Tp Un saludo y gracias
> > La duda ahora esta en
¿tengo que considerar en el trafico ofrecido al bus los > paquetes
que estoy "tirando" porque llegan cuando el bus esta ocupado?, en >
principio no lo hago poruqe se supone que lo que esta conectado al
bus no > intenta tx en esta fase... pero depende un poco de como se
defina el
Bien.
> rendimiento y si quiero considerar el hecho de que las fuentes quieran tx pero
> no puedan... (aunque esto creo que seria mas el rendimiento del sistema y no
> del bus). Le he dado muchas vueltas pero no me acabo de aclarar
>
> Otra cosa que sigo sin entender bien es el uso de la funcion Reset() del bus, de
> hecho la he dejado vacia y parece que todo funciona bien...
>
Claro. Pero lo que debes hacer es que dentro de ellas se pongan a
cero todos tus contadores miembro.
> Otra cosa, no se si tengo que comparar la grafica de rendimiento del modelo con
> la teorica (csma_np.gnuplot) en una misma grafica. El problema lo
Pues claro. Lo contrario no es comparar. De hecho, si el modelo
está bien, salen superpuestas totalmente.
> encuentro al
> normalizar, para poder comparar supongo que deberia normalizar ambas graficas
> respecto al mismo valor de trafico ofrecido al bus ya que si no btengo
> resultados distintos (realmente serian los mismos pero para valores distintos
> del eje x..) , claro y esto influye porque cuanto mayor sea lambda menor es el
> rendimiento y si no hago coincidir las graficas en el mismo lambda (o trafico
> ofrecido) maximo pues creo que asi no puedo compararlas...
>
No entiendo eso. Tiene que estar todo normalizado.
> De hecho he estado haciendo varias pruebas con lambdas cada vez mayores y cada
> vez se aproximaba mas a la teorica.. hasta que me he pasado (una cura de
> rendimiento menor). Para comparar los distintos valores del modelo con Tp
> distinto no hay problema poque en ambo usaria la misma lambda maxima y
> normalizaria respecto al mismo valor.
>
> Otra cosa que no entiendo en la grafica teorica es el parametro xprop (en el
> .gnuplot) aunque tampoco se si es importante para algo o no
>
> Por lo demas, me parece que el resultado es valido ya que evoluciona como se
> esperaba y con la misma forma que la teorica: el rendimiento disminuye cuando
> aumenta el trafico y tambien dismininuye cuando aumenta Tp
>
> Un saludo y gracias
Por fin ya parece que sale todo bien...!! efectivamente el problema estaba
al procesar los datos y representar la eficiencia... y claro que no sabia
muy bien que significaba la eficiencia. Y que estaba empeñado en que la
lambda era la correspondiente al trafico que entraba en el bus y no el total
generado por las fuentes.
Aunque parece que despues de esta tarde lo tengo mas claro ya he encontrado
los apuntes esos que me decias, en el tema 7 de Redes, asi que me pondre
manos a la obra...
Vale