Re: [ns] ns scalability

[Aaron D Striegel <adstrieg@iastate.edu>]

No, I haven't had a chance to look at them yet.  I think the core problem arises from the fact that a packet goes up to the classifier/replicator and is re-copied at each node.  I'm not sure of a decent way to improve this aside from eliminating the unnecessary copy when the packets do not need to be replicated, i.e.:

----- Node ------

The packet comes into the node but leaves on only one link.  Hence, if the packet could simply be rescheduled, at least for sparse trees, the speed of the code could be dramatically improved.  Is there a way to make a packet reschedulable after it has been scheduled?  For cases like this, it could speed up the simulations quite a bit.  Even for something like this:

                 /
------- Node  
                 \

where it goes onto two branches where it is copied once and then the original packet is sent onwards and not copied, this could be significantly better.  I realize this is probably not an easy problem to solve but if I could figure out how to make a packet schedulable again on a link (after coming into the classifier), I think it would be possible.

Aaron

At 10:56 AM 8/22/2001 -0700, John Heidemann wrote:
>>Has there been any work on speeding up ns for multicast?  It seems to be exceptionally slow for multicast compared to unicasting which is probably due to how packets are copied at each node for multicasting.  If anyone has done any work on this, please let me know as I am extremely interested.  I've had exactly the opposite problem, I am running out of CPU speed far faster than I am running out of memory.
>
>I agree that this could be a problem, but I'm not sure we have a good
>example scenario that illustrates it.  If you have one in mind
>(ideally that works with the basic 2.1b8a release) can you send us a
>copy?
>
>Several of the abstractions (centralized multicast, etc.) that Polly
>Huang looked at dealt with multicast.  I don't know what your scenario
>is, but they should help both memory and CPU quite a bit.  Have you
>looked at them?
>
>   -John Heidemann