[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: asymetric link
I think that this is not ns but a nam-specific bug. I suppose that we
can try it by using the trace functions, the actual speed of the link
(which is simulated in ns) can be canculated from the trace file.
Cheers
NHT
Fernando Cela Diaz wrote:
>
> I have tried your example. I can see the same delay for both pkt and ack,
> too. It seems that NS is not doing properly the network description
> for NAM:
>
> If I set a new node in the middle
>
> 28k 28k
> ------- n2 --------
> / \
> n0 +---------------------+ n1
> 10M
>
> Now it works; I do see the difference between one path and the other.
>
> Taking a look to the nam output files for the first and second examples,
> we see that in the second case we have three lines like this in out.nam:
>
> l -t * -s 0 -d 1 -S UP -r 10000000 -D 0.59999999999999998 -c black -o
> l -t * -s 1 -d 2 -S UP -r 28800 -D 0.01 -c black -o
> l -t * -s 2 -d 0 -S UP -r 28800 -D 0.01 -c black -o
>
> I don't know many things about NAM but this seems to be the specification
> of the links, with their bandwidth and delay.
>
> In the first case (the example you posted), you can't find in nam.out a
> line like:
>
> l -t * -s 1 -d 0 -S UP -r 28800 -D 0.01 -c black -o
>
> (In fact you will not find the keyword "28800" in all the file).
>
> If you add it manually, you get a "duplicate edge" error message (I don't
> know if I'm doing it properly). I wonder if NAM can do such a kind of
> graphs...
>
> I append both the files. out.nam.orig and out2.nam. Maybe a NAM guru can
> tell us what happens.
>
> /FCD
--
------------------------------------------------
Nguyen Huu Thanh
Universitaet der Bundeswehr Muenchen
Institut fuer informationstechnische Systeme
Werner-Heisenberg-Weg 39
85577 Neubiberg
Tel.: +49 89 6004-2279
Email: [email protected]
-------------------------------------------------