Re: Node throughput and packet delay

[George Riley <riley@cc.gatech.edu>]

Consider running the "postprocessing" on-the-fly, using TCL's output pipe
for the log file, as follows:

set logfile [open "|readtr2 3 4 1 2 >> test2.throughput.logs" w]
$ns trace-all $logfile

In my example above, I use a program I wrote "readtr2" to analyze raw
tracefiles, but it doesn't need to huge amount of disk space.  The reduced
data is written to test2.throughput.logs, and is just a summary of stuff I
was looking for in the tracefiles.

George


					
			-George F. Riley (riley@cc.gatech.edu)

On Mon, 11 Oct 1999, Tarik Alj wrote:

> Sean,
> 
> 	i agree with you: dumping everything to the tracefile is an easy 
> solution and it takes a lot of space. 
> 	However there are flow monitor objects that can be used to collect 
> statistics without much postprocessing.
> 	I also agree on the fact that if you want to collect specific data, well 
> you may as well derive your own monitor object. But still if you are a new user 
> it might just be easier to use trace-all and postprocess with awk than go  on 
> the darkside of ns: C++. I think that working on the C++ part of ns requires a 
> strong knowledge of ns internals.
> 
> > Date: Sun, 10 Oct 1999 12:21:58 +0100 (BST)
> > From: Sean Murphy <murphys@Teltec.DCU.IE>
> > X-Sender: murphys@lofn
> > To: Tarik Alj <aljtarik@ozias.inrs-telecom.uquebec.ca>
> > cc: L.Wood@surrey.ac.uk, ns-users@mash.cs.berkeley.edu
> > Subject: Re: Node throughput and packet delay
> > MIME-Version: 1.0
> > 
> > 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: sean.murphy@teltec.dcu.ie
> > Teltec Ireland,			Phone: +353-1-7045080
> > DCU, Dublin 9,			Fax:   +353-1-7045092
> > Ireland.
> > 
> 
> Tarik Alj
> INRS-Telecommunications
> 16 place du commerce
> Verdun (Ile des Soeurs), Qc, H3E 1H6
> Canada
> Tel: 514 761 8611
> Fax: 514 761 8619
> 
>