Re: hierarchical, multicast routing etc

[Lloyd Wood <L.Wood@surrey.ac.uk>]

On Thu, 1 Oct 1998, Polly Huang wrote:

> > Oh right, ns/tcl/ex/simple-eqp1.tcl
> > is quite handy in understanding the command set here.
> > 
> > I was doing as per nsDoc 15.1:
> > 
> > $ns $linktype $n($node1) $n($node2) $bandwidth $propdelay $queuemethod
> > $ns cost $n($node1) $n($node2) $propdelaycost
> > $ns cost $n($node2) $n($node1) $propdelaycost
> 
> Is $propdelaycost differenct from $propdelay? 

Yes; it's a normalised value; I should have included the calculation. 
Propagation delay is say between 5 and 70 ms in most cases - 0.005 to
0.070. Quite large, relatively speaking. Since all the example cost
code I've seen sets an integer as cost value, I tried normalising the
fraction to a round integer to be on the safe side: 

set propdelaycost [expr int($propdelay * 100) ]

Anyway, it appeared to make no difference.


> Why not just assign the
> cost using $propdelay? That way, the routes will always be the shortest
> delay routes.

if cost can be a real number and I can dare deviate from examples,
I'll do that. 


> > where $linktype=="duplexlink"
> > 
> > which apparently did nothing, yet simple-eqp1.tcl
> > is using the different form: 
> > 
> > [$ns link $n2 $n4] cost 2
> > 
> > to set the costs instead, which must be what you are talking about.
> > 
> > So, I changed to:
> > [$ns link $n2 $n4] cost $propdelaycost
> > 
> > (where $propdelay is no larger than 31)
> > 
> > and now when I run my simulation with this cost code I get... no
> > traffic trace data to speak of, no scale in nam output, etc. Just
> > the topology. Suggestions?
> 
> This is odd. THe two lines
> 
> $ns cost <node1> <node2> <cost> 
> [$ns link <node1> <node2>] cost <cost>
> 
> work exactly the same.  Did you assign costs for both directions, like you
> did in the '$ns cost <node1> <node2> <cost>' version?

Yup.

The output of both now appears the same (which syntax is currently
preferred?) and they're both now working. It looks like was my own
fault for overlooking an early $ns rtproto command I hadn't removed,
which appears to mess ns up for me royally. 

Thanks for your help.

Cheers, 

L.

who can't use rtproto or any form of large address space with multicast.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/>PGP<L.Wood@surrey.ac.uk>