[ns] Re: Fw: How can I calculate the packet loss of one flow(session) on the run timeRe: Re: [ns] packet loss!

[Huan Pham <huan@cs.jcu.edu.au>]

Thanks Brian for the reply, but here come the question again.

I am simulating this topology, where servers 2-5 are sending packets to
clients 6-20


            6        2  3
          \ |        | /
         -- 0 -------1 --4
          / |         \
           20         5

I want to measure the throughput on the link from Node 1 to Node 0. In
fact I simulate a much larger topology, and I require to run it for quite
long time in order to get a good results.

All your proposed solutions do not seem to work with my scenario (see
below)


Brian Lee Bowers wrote:

> On Thursday 21 June 2001 12:57, liu yong wrote:
> > Hi,
> >   How can I calculate the packet loss of one flow(session) on the
> > running time.I know I can get this information by proprocesstion
> > the trace file.My problem is how to know it in the running
> > time.Thank for your help.
>
> Several methods come to mind for determining number of packets lost
> for a flow:
>
> 1)  parse the trace file.  This is fairly simple with Perl.
> Depending on how much of the information you need, the regular
> expressions can get a little nasty looking, but they aren't difficult.
>

If I use TraceAll file, then the file size get as big as 1Gbyte. Currently
I read all the data to an array and process it, and RAM size is a problem,
not the Harddisk size.  I can not think of any other better algorithm that
does not read all the data to an array and process it. For example, if it
just reads a short chunk of data, processes them and read another.  The
algorithm must be very complicated .

> 2)  modify the sender to output the information you need.  This isn't
> quite precise, because you have to assume that any packet
> retransmitted was lost.  With two way traffic, a retransmission might
> mean that the packet was lost, the ACK was lost, or simply that the
> sender timed out the packet.
>

This is not precise in my case ether because some packets from Servers to
Clients (maybe a retransmitted one, ACK , or whatever)  may get dropped
before Node 1 received them. As a result, total packets sent from Servers
are different from those on the way from Node 1 --> Node0


>
> 3)  modify the sender to include a "persistent" variable.  The
> variable is used to count the number of retransmissions made by the
> sender.  You can then use a "record" function (see Greis's tutorial
> for an example) to get the number of retransmissions per your own
> time granularity.  After you get the number of packets dropped, you
> can reset the variable.
>

Again, same reason as for the second case.


I don't know if there is any Trace Support funtion that can help us to
record only information we need on the link 1-0 so that we can reduce the
trace size significantly.

Thanks