Re: [ns] Huge amount of traffic in simulation?

[Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>]

>> >I have some problems with the huge amount of random traffics simulation.
>> >
>> >For a 50 nodes backbone simulation, every node(with agents) needs to
>> >produce a huge amount of random (or possion distri.) traffics to random
>> >destinations.  Also, each traffic holding time is also random.  Two ways I
>> >can go:
>> >
>> >1. Each traffic corresponds to an agent pair (traffic sitting on), like
>> >   "agent-gen.tcl" script, but the problem is a huge amount of agent pairs
>> >   have to be created and attached to nodes.  It probably exceeds the
>> >   limit of node's port number soon.  Seems impossible?
>>
>> - if each pair has only a limited life time during the simulation you could
>> create them and destroy them as needed
>
>A problem is how to destroy them.  For node,  only "Node::detach .." seems
>to detach an agent, but it replaces it with a null-agent.  The port classifier
>space is still unreleased.

there should be a destructor for agents, see agent.cc.

>
>I am doing Optical WDM simulation on a backbone.  So, each node acts as
>an access node, where lots of traffics are aggregated with their various 
lifetime.
>Also, the traffic(not packet) arrival (start time) is a poison distribution.  
For
>ns,
>all traffics are created before the simulation starts.  Thus, they all have to 
be
>scheduled the start and stop time to the simulator.

you could use a random number generator to schedule random start and stop times

>
>> >2. Using one traffic to simulate multiple traffics.  Only create one agent
>> >   (like UDP) and one traffic (like CBR) for each node, and manage to 
control
>> >   the traffic to start and stop randomly.  I need modify the traffic...
>>
>> - this has the drawback (I think) of not permitting many flows to be 
simulated.
>> >
>> >Does anyone has the similar experience?  Which way is better? or some
>> >other better one? Any hints will be appreciated.
>>
>> generating lots of trafic is not nearly as hard as finding a way to trace and
>> (post) process the traces efficiently... I would prefer 1) but it really 
depends
>> on what you want to evaluate.
>
>At most time, tracing every packet is not necessary.  E.g. in my simulation, I
>just want to get the statistics results, such as wavelength assignment, and
>blocking
>prob.  Nam's trace graph is just a demo or education tool, not really useful 
for

yes, but to get a statistical result of any value you need events to extract the 
stats from... trace-all with a good number of flows for a good simulation time 
will produce files the order of Gb. I was not even thinking of Nam here...

>real simultation, since it really needs huge data.
>
>Thanks,
>Bo

Tarik