Re: extenting topology (fwd)

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

On Wed, 19 May 1999, Polly Huang wrote:

> $ns set-address 26 5
>                 ^  ^
>                 |  |
>         node bits  port bits

(Ah, addressing. My favourite!)

Polly writes:
> The segmentation fault in the 1000 node simulation is probably due
> to limited memory space.

Hard to tell without installing tcl-debug and dmalloc to see what's
going on, comparing with any set limits as Polly points out, and
watching process size with something like top.

I've just had a play with Node expandaddr, $ns set-address-format
expanded, and $ns set-address with my simulations, using an unmodified
13 April snapshot which passed validate. Using $ns set-address-format
instead of the trusty Node expandaddr gives me:

_o25242: no target for slot 1024

(no segmentation fault here, but then I've got tcl-debug and dmalloc
 installed in an attempt to match developer setup and to get some idea
 of what's going on when ns falls over. You just can't live without
 them.)

and doing say:
doing either 
$ns set-address-format expanded
or 
Node expandaddr

with say:
$ns set-address 12 19

to alter the address/port space mix gets me the rather different:
ns: _o4 run-mcast: can't read "mrtObject_": no such variable
    while executing
"$mrtObject_ start"
    (procedure "_o586" line 3)
    (Node start-mcast line 3)
    invoked from within
"$node start-mcast"
    (procedure "_o4" line 5)
    (Simulator run-mcast line 5)
    invoked from within
"_o4 run-mcast"

a .nam file containing only link information, and a one-line
tracefile:

v 0 eval {set sim_annotation {1073741824 switch tree type}}

which is Definitely Odd.

This is using CtrMcast (subscript below); a trivial simulation to
demonstrate a simple multicast tree with a couple of joins and leaves
so the tree changes shape (across a rather complex ~500-node mesh
topology sort-of- approximating Teledesic, admittedly), using Node
allocaddr to allocate the group address as you'd expect. I'm not using
LANs (just duplex-link functionality I keep reminding myself to scrap
in favour of two simplex-links), so the bugfixes of 16 April shouldn't
affect this.

Node expandaddr succeeds and works just fine and dandy where
set-address-format/set-address variations fail. This is consistent
with previous reports of my various fiddles with setting addressing
space.

The reason I'm pointing this old saw (with new $ns set-address
variation) out now is New Hardware: I ran today's tests on an Ultra
Enterprise (5.5.1) with 2.25Gb of real memory and 3Gb of free swap.
top shows the ns running my simulation growing slowly from 87Mb to
140Mb or so before dying if not using only Node expandaddr. Of that,
20M was resident; we don't have process size limits. I don't believe
memory availability is always the issue; this looks like one or more
addressing problems.


Hmmm, surprising say $ns set-address-format 26 5 doesn't fall through
to set-address functionality rather than generating an obtuse error;
that's the obvious syntax from the Tcl-user viewpoint.

(Actually, the obvious syntax might have been set-address-space for
 -format and set-address-format for -address, but there you go.
 set-address looks like the parent of set-address-format, which it
 isn't; arguably a confusing name choice IMO.)


$ns set-address is in ~ns/tcl/lib/ns-address.tcl, but
isn't mentioned in the copious comments detailing
$ns set-address-format there, btw.


> Please search for 'abstract' in the mailing list
> archive for details.

Hmmm, a searchable archive (webglimpse?) would be very extremely
useful here; I'd flag it and those handy online HTML docs Nader is
maintaining (which would also benefit from a search facility, and
possibly from being mirrored) in REALLY BIG LETTERS on the ns
webpages. And probably put embedded search forms there too to
encourage their use.

cheers,

L.

and if someone can shove all the missing </B>s in 
http://www-mash.cs.berkeley.edu/ns/CHANGES.html
and set page colour to white I'd be most grateful. ta.

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

and now, the errant subscript. 

# Pick multicast type for all nodes e.g. 
# set mproto DM
# set mproto dynamicDM
# set mproto CtrMcast

set mproto CtrMcast

set group [Node allocaddr]

# set all nodes to be multicast nodes
set mrthandle [$ns mrtproto $mproto {} ]

# simple graphics test - set up a simple multicast group

$mrthandle switch-treetype $group
$mrthandle compute-mroutes

set m5 [new Agent/LossMonitor]
$ns attach-agent $g(5) $m5

set m12 [new Agent/LossMonitor]
$ns attach-agent $g(5) $m12

set udp0 [new Agent/UDP]
$ns attach-agent $g(1) $udp0
$udp0 set dst_ $group

set cbr0 [new Application/Traffic/CBR]
$cbr0 attach-agent $udp0
$udp0 set fid_ 1
$ns color 1 Red

# setting the central router doesn't work
# $mrthandle set-c-rp { n(20) }
# debug 1

$ns at 0.1 "$cbr0 start"
$ns at 1.0 "$g(5) join-group $m5 $group"
$mrthandle compute-mroutes
$ns at 2.0 "$g(12) join-group $m12 $group"
$mrthandle compute-mroutes
$ns at 3.0 "$g(32) join-group $m12 $group"
$mrthandle compute-mroutes
$ns at 4.0 "$g(44) join-group $m12 $group"
$mrthandle compute-mroutes
$ns at 5.5 "$g(32) leave-group $m12 $group"
$mrthandle compute-mroutes

$ns at 10.0 "finish"