From: Andrew McGregor <andrewmcgr@gmail.com>
To: igorm@etf.rs
Cc: codel@lists.bufferbloat.net, andrew.mcgregor@alliedtelesis.co.nz,
bloat@lists.bufferbloat.net
Subject: Re: [Codel] Python scripts from ns-3-dev GitHub repo
Date: Thu, 31 Jan 2013 10:38:47 +1100 [thread overview]
Message-ID: <CAA_e5Z7L8SZ_Q=5MmqbiY5R3GK6HmK5eHhLb0_pe7ygby=SJ8w@mail.gmail.com> (raw)
In-Reply-To: <CAFdo_mXwyingohF44TS-kak-XCv2DvPqvcridoEHamYai0zkJw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
Ok, so multirun.py runs a whole set of experiments. The various commented
bits of code around line 85 give ways to do ranges of options in several
different ways. The options are just passed as text to tcp_qfp.cc. It
runs experiment cases in parallel, one for each core in your machine.
That will produce a huge number of files, with names that tell you which
experiment they belong to and which nodes in the topology they were
collected from. Then you can analyse them.
burstmemoryestimators.py is a graphing routine that gives you a whole lot
of information about what happened in each run. It opens the ptrace files
left by the experiment (passed as an argument, you want a file called
something like tcp_qfp-1-11-Left.pcap if there were 10 nodes in your
experiment), and calculates a bunch of statistics: packet interarrival time
(blue dots), burstiness metric (red) and queue markov memory metric (green).
The burstiness metric runs from -1 (periodic) through 0 (Poisson process)
to +1 (1/f noise).
The memory metric is zero if the queue is perfectly memoryless, and
non-zero proportional to how much memory it has. Thus it shows the queue's
contribution to interarrival time statistics. Note that a queue is
memoryless both if it is empty OR if it is completely full, and this metric
is signed (negative if the queue is draining).
It only makes sense to run this script on a leaf link; if there is more
than one flow, the estimators will not track flows separately and thus will
not make sense.
On Wed, Jan 30, 2013 at 11:21 PM, Igor Maravić <igorm@etf.rs> wrote:
> Hi Andrew,
>
> I'm trying to use useful python scripts from ns-3-dev GitHub repo, but
> unsuccessfully.
>
> Could you provide some usage cases on how they should be used?
>
> BR
> Igor
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>
[-- Attachment #2: Type: text/html, Size: 2578 bytes --]
next prev parent reply other threads:[~2013-01-30 23:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-30 12:21 Igor Maravić
2013-01-30 23:38 ` Andrew McGregor [this message]
2013-01-31 10:57 ` Igor Maravić
2013-01-31 11:58 ` Andrew McGregor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA_e5Z7L8SZ_Q=5MmqbiY5R3GK6HmK5eHhLb0_pe7ygby=SJ8w@mail.gmail.com' \
--to=andrewmcgr@gmail.com \
--cc=andrew.mcgregor@alliedtelesis.co.nz \
--cc=bloat@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=igorm@etf.rs \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox