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

[Bo Wen <bowen@mail.wsu.edu>]

Please see blow.

Tarik Alj wrote:

> >Date: Wed, 28 Jun 2000 11:28:47 -0700 (PDT)
> >From: Bo  Wen <bowen@mail.wsu.edu>
> >X-Sender: bowen@cheetah.it.wsu.edu
> >To: ns-users@mash.cs.berkeley.edu
> >Subject: [ns] Huge amount of traffic in simulation?
> >MIME-Version: 1.0
> >
> >
> >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.

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.

> >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
real simultation, since it really needs huge data.

Thanks,
Bo