[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Node throughput and packet delay



Tarik,

> > > Another solution that doesn't involve modifying ns is to create trace
> > > files for your simulation and perform filtering on the trace file using
> > > awk, for example to obtain the info you want. I've never done this, so I
> > > don't know exactly what it entails.
> 
> Ignorance maybe a bliss... but awk (or Perl) really isn't that hard to learn 
> (besides you can find a lot of example scripts in the test and ex directories0. 
> You can learn more about the tracefiles in ns: notes & documentation, chapter 16 
> in the Support section (as of april 1 99). And instprocs like trace-all and 
> trace-queue.

Yep, I'm familiar with both awk and perl and yes, these are certainly very
important and probably necessary tools for postprocessing data. However, I
still think that it would be useful to have more intelligent monitoring
components in ns than simply dumping *all* the simulation events to a file
and performing filtering.

This would have a number of advantages:

1. new users could be able to obtain the info they want more easily - I
think that ns is quite a comprehensive and possibly daunting piece of s/w
- I think many new users have to get their heads around (a) tcl, (b) otcl,
(c) otcl & c++ linkage, (d) the ns library and possibly more - having to
learn awk and perl on top of all that should not be necessary to obtain
quite common but useful (eg packet delays and variations) results.

2. Entire trace files often take up a very large amount of space, increase
simulation times, because large amounts of data are written to files, and
often require post processing to extract the information you want. I think
it would be better to have some of the filtering done throughout the
simulation, which decreases the amount of data output, hence the
simulation time, and hopefully requires less (or none) post-processing.
(Of course, if you always animate your sim, then this doesn't really
apply).

3. I think that it is more natural and possibly easier (depending on the 
interface) to configure a monitoring object and have it log the relevant
info, rather than logging everything, and fiddling around with the trace
files, which were not really written for this purpose (I guess). It's also
faster to have this logging done at the c++ level, rather than the tcl
level - hence it is useful to implement such functionality in c++.

I'm not saying that my approach is better, just that it has some
advantages, and no real disadvantages (that I can see) for certain cases.
Of course situations can arise in which, say, you run a reasonably long
simulation and you want to obtain many different results. In a situation
such as this, I think that it may be better to obtain a trace file, and
run filtering programs on the output to obtain the different sets of
results.

> some people work on saturdays!

some people work on sundays aswell - some people have no life :-).

Just my $0.02 (as always),
Sean.

-----
Sean Murphy,			Email: [email protected]
Teltec Ireland,			Phone: +353-1-7045080
DCU, Dublin 9,			Fax:   +353-1-7045092
Ireland.