Re: node-field-size

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

On Fri, 23 Apr 1999, Dah Ming Chiu - Sun Microsystems wrote:

> I got the following error:
> "Number of nodes exceeds node-field-size of $nodebits_ bits"
> 
> Looks like nodebits_ is set in ns-address.tcl, as the value of idsize_.
> But idsize_ is determined by some rather convoluted procedure.  Can
> someone explain how I can reset nodebits_ to support a larger number of
> nodes?

I'll demonstrate below that you don't yet have explicit control
of $nodebits_ at the obvious OTcl command level. However,

Node expandaddr

in the OTcl script does the trick for me, and I've found it to work
better and more consistently across various versions of ns than
the alternatives - expanding address space is discussed a
lot in the archives. Since you don't say what version of ns you're
using, Node expandaddr is the simplest reliable option for you.

I've just tried $ns set-address-format expanded with a simple
multicast simulation in a topology of ~1600 nodes using the ns-2.1b6
snapshot of April 13, and after 2.5 hours I actually had a working
result sans any slot error. This looks like a significant untrumpeted
improvement... 

[checks cvs:
http://www-mash.cs.berkeley.edu/cgi-bin/cvsweb/ns-2/tcl/lib/ns-address.tcl
1.15 some bugs removed from set-adress-format expanded 
seems to have done something good; one robust result isn't
conclusive, but this is the best that I've ever seen
set-address-format expanded do with my simulations. Looks like:
Backward compatibility: Use "set-address-format expanded" instead of
"Node expandaddr"
is living up to its claims. Cool.]

Hmmm, since set-address-format-expanded is logically the same as: 
set-address-format hierarchical 1 22 (right?), then I ought to
be able to set any size address space via flat hierarchical
addressing, so I could enforce arbitrary bounds checking on the number
of nodes I allocate, and get _meaningful_ node-field-size errors
indicating my OTcl was doing something it shouldn't because I'd
created more nodes than I'd expected. This is useful for demonstrating
the ramifications of address space, and useful for anyone with complex
topology-generation code; can't think of a command for
how-many-nodes-exist-right-now offhand, come to think of it, and
keeping your own count is makework. 

Take for instance ~ns/tcl/ex/mcast.tcl; let's see if I can implement
arbitrary node/address-space limits in that.

Okay, I read through ns-address.tcl 1.15, scratching my head a little
over the outdated:
                                           (mcast should be enabled
                       before Simulator is inited (new Simulator is
                       called)

because the recommended
set ns [new Simulator -multicast on]
looks to be doing them at the same time to me, and I apply these hints
to that example script. 

There are four nodes in ~ns/tcl/ex/mcast.tcl. That's two bits, and one
extra bit is needed for multicast. Removing setting obsolete flags
because I have to and saying: 

set ns [new Simulator -multicast on]
$ns set-address-format hierarchical 1 3

instead, and using Node allocaddr to assign group numbers to variables
to replace the hard-coded group numbers (not necessary here, and
not a good example) as you'd expect, gets me:

ns: _o100 recv  2 0: no value given for parameter "m" to "_o100"
    (Agent/Mcast/Control recv line 1)
    invoked from within
"_o100 recv  2 0"

for everything up to 
$ns set-address-format hierarchical 1 6 - in fact, I even get this for
$ns set-address-format hierarchical 1 2, and only
$ns set-address-format hierarchical 1 1 gives 
 Number of nodes exceeds node-field-size of 1 bits

Not 0 bits, since the multicast bit is allocated first?
This suggests that the multicast bit doesn't always come out of the
available hierarchical address space, as suggested by the description
of the 8 8 8/8 8 7 behaviour when you don't specify numbers. Odd.

For 
$ns set-address-format hierarchical 1 7
and up it's my old friend:
_o101: no target for slot 1
(indicating problems with an address space of one byte and up, I think.)

Replace the hierarchical addressing with
$ns set-address-format expanded or Node expandaddr
and the script works fine; the former is preferable, since it's one
less warning and it works.

It looks like my ongoing grumbles about set-address-format are now
confined only to set-address-format hierarchical. Progress!

(I believe it's necessary that ns is capable of doing this robustly.
 If you can't trust the address space you create, what can you trust?)

thanks,

L.

well, I suppose you can trust $node1. 

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