From mathieu.lacage at sophia.inria.fr  Wed Apr  1 00:34:19 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 01 Apr 2009 09:34:19 +0200
Subject: [Ns-developers] Wifi management frames
In-Reply-To: <49D27E0D.5040407@gmail.com>
References: <49D27E0D.5040407@gmail.com>
Message-ID: <1238571259.18589.242.camel@diese.inria.fr>

On Tue, 2009-03-31 at 22:33 +0200, Mirko Banchi wrote:
> Hi all,
> 
> i have some questions about 802.11 management frames i'd like to discuss
> with you.
> 
> For now all management frames are handled in NqstaWifiMac, NqapWifiMac,
> AdhocWifiMac, QapWifiMac, QstaWifiMac objects. This type of frames are
> stored in the same queues where are stored data frames.

Outgoing beacon frames are stored in a separate queue in NqapWifiMac.

> -First question:
> 
> Should be there a specific queue for management frames ?
> What will happen if a station becomes disassociated (so a probeReq or a
> associationReq are needed) and have other packets in queue?

There should not be a separate queue for nqos MACs.

> See:
> 
> src/devices/wifi/nqsta-wifi-mac.cc
>    NqstaWifiMac::Enqueue
>    NstaWifiMac::TryToEnsureAssociated
>    NqstaWifiMac::SendProbeRequest
> 
> -Second question:
> 
> Working with block ack there is need to send action frames (management
> frames) in order to setup block ack. I think that the exchange of this
> frames between two station must be accomplished with high priority. I
> used a method

What does 802.11e say about this ? 

> WifiMacQueue::PushFront (Ptr<Packet> packet, const WifiMacHeader &hdr)
> 
> that pushes packets in queue's head but it's very horrible: the
> expiration of MsduLifeTime doesn't work :(
> 
> I think that a dedicated queue (like m_beaconDca in NqapWifiMac) could
> resolve this problems.

It could, but I wonder what the specification requires.

Mathieu


From mathieu.lacage at sophia.inria.fr  Wed Apr  1 01:01:13 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 01 Apr 2009 10:01:13 +0200
Subject: [Ns-developers] GSoC 2009 - Minstrel rate control algorithm
In-Reply-To: <d5ff16190903310732r4a183b68p10708f0038f4ed97@mail.gmail.com>
References: <d5ff16190903292016v4316aee1y74cbb43fcf91222a@mail.gmail.com>
	<49D12D50.2030003@net.t-labs.tu-berlin.de>
	<d5ff16190903310732r4a183b68p10708f0038f4ed97@mail.gmail.com>
Message-ID: <1238572873.18589.250.camel@diese.inria.fr>

On Tue, 2009-03-31 at 11:32 -0300, Luciano Jerez Chaves wrote:

> The initial idea was to port CARA and AARF to ns-3 in order to fairly
> compare my solution with all available implementations, but I figured
> out that the AARF is already implemented on it. Although, we still
> have CARA, and there are other solutions in the literature that could
> be incorporated into the ns-3 as far as possible.

It would be nice to incorporate this:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=536

Mathieu


From mathieu.lacage at sophia.inria.fr  Wed Apr  1 01:08:50 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 01 Apr 2009 10:08:50 +0200
Subject: [Ns-developers] GSoC: WiMAX Projects
In-Reply-To: <ef7bdcb60903311926v5489d75en8624c534c7b7d4bc@mail.gmail.com>
References: <200903301756.55467.Amine.Ismail@sophia.inria.fr>
	<ef7bdcb60903311926v5489d75en8624c534c7b7d4bc@mail.gmail.com>
Message-ID: <1238573330.18589.252.camel@diese.inria.fr>

On Tue, 2009-03-31 at 23:26 -0300, Flavio Kubota wrote:

> looked wi-fi error model code in ns-3 but I don't know which model is.

>From yans-wifi-phy.h:

 * This PHY implements a model of 802.11a. The model
 * implemented here is based on the model described
 * in "Yet Another Network Simulator", 
 * (http://cutebugs.net/files/wns2-yans.pdf).
 *
 *
 * This PHY model depends on a channel loss and delay
 * model as provided by the ns3::PropagationLossModel
 * and ns3::PropagationDelayModel classes, both of which are
 * members of the ns3::YansWifiChannel class.

regards,
Mathieu


From Amine.Ismail at sophia.inria.fr  Wed Apr  1 01:25:49 2009
From: Amine.Ismail at sophia.inria.fr (Mohamed Amine Ismail)
Date: Wed, 1 Apr 2009 10:25:49 +0200
Subject: [Ns-developers] GSoC: WiMAX Projects
In-Reply-To: <ef7bdcb60903311926v5489d75en8624c534c7b7d4bc@mail.gmail.com>
References: <200903301756.55467.Amine.Ismail@sophia.inria.fr>
	<ef7bdcb60903311926v5489d75en8624c534c7b7d4bc@mail.gmail.com>
Message-ID: <200904011025.49342.Amine.Ismail@sophia.inria.fr>

Hi Flavio,

> I intend to
> investigate a channel-aware scheduler, and I'm very motiveted to implement
> this features in WiMAX module for ns-3.

Very interesting...nice idea

> For suburbans WiMAX environments, WiMAX Forum recommends SUI or COST231
> model for propagation.
> For error model, I read some people finding PER or BER throught AWGN curves
> with the SNR. Do you recommend some specific error model for 802.16? I
> looked wi-fi error model code in ns-3 but I don't know which model is.

I think it will be nice if you port the propagation and error model from the 
WiMAX module developed by NIST. We are also interested by the TU-6 
propagation  model wich is usefull to simulate broadcast communication

Regarding wi-fi error model, as Mathieu said before, the model implemented is 
based on the model described in http://cutebugs.net/files/wns2-yans.pdf.

Regards
Amine




On Wednesday 01 April 2009 04:26:57 Flavio Kubota wrote:
> Hi Amine and Thierry,
>
> Thanks for reply.
>
> > In my previous message, I forgot to emphasize the most essential part 
> > :-). We very welcome contributions in the current WiMAX module and are
> > open for any proposal to enhance it.
> > As it is important to coordinate the different works in the community,
> > please
> > keep us informed about any current/future work you are interested in or
> > planning to investigate, to avoid developing similar things.
>
> I am currently implementing Propagation and Error model in WiMAX module
> developed by NIST. I am also coding the scheduler developed by LRC [
> http://www.lrc.ic.unicamp.br/wimax_ns2] into this NIST module. I intend to
> investigate a channel-aware scheduler, and I'm very motiveted to implement
> this features in WiMAX module for ns-3.
>
> > Here are further details regarding the status of the WiMAX module.
> >
> > Concerning the implementation of the IPCS classifier, it is almost
> > finished and we are in the bug fixing phase. The code should be available
> > soon at http://code.nsnam.org/iamine/ns-3-wimax/  .
> >
> >
> > We intend to implement the tracing function in the next few weeks.
> > In May, a master student is expected to start an internship on the
> > development of scheduling algorithms (for both uplink and downlink).
> > For this task in particular, a coordination with other groups is crucial.
> >
> > Regarding the 2nd implementation of the PHY layer based on itpp, I would
> > like to mention that this module currently requires a huge computation
> > time since it encodes and modulates the bursts provided by the upper
> > layer. Basically, this implementation is far to be real-time... So if
> > anyone is interested in designing a more sophisticated PHY layer with
> > propagation/error
> > model, he/she would be very welcome.
>
> For suburbans WiMAX environments, WiMAX Forum recommends SUI or COST231
> model for propagation.
> For error model, I read some people finding PER or BER throught AWGN curves
> with the SNR. Do you recommend some specific error model for 802.16? I
> looked wi-fi error model code in ns-3 but I don't know which model is.
>
>
> Thank you a lot,
> Flavio



From Amine.Ismail at sophia.inria.fr  Wed Apr  1 01:26:23 2009
From: Amine.Ismail at sophia.inria.fr (Mohamed Amine Ismail)
Date: Wed, 1 Apr 2009 10:26:23 +0200
Subject: [Ns-developers] Fwd: Re:  GSoC: WiMAX Projects
Message-ID: <200904011026.23907.Amine.Ismail@sophia.inria.fr>


----------  Forwarded Message  ----------

Subject: Re: [Ns-developers] GSoC: WiMAX Projects
Date: Tuesday 31 March 2009
From: Mohamed Amine Ismail <Amine.Ismail at sophia.inria.fr>
To: n.dua at iitg.ernet.in

Dear Nitin,

The latest version of our code is available at:
http://code.nsnam.org/iamine/ns-3-wimax/
you can download it by using the following mercurial command:

hg clone http://code.nsnam.org/iamine/ns-3-wimax/

the code can be compiled  by using gcc-3.4 or gcc-4.2.

to compile the code use the following command:

CXX="gcc path" ./waf configure; ./waf

example:

CXX="/usr/bin/gcc-4.2" ./waf configure; ./waf

The following paper can help you to understand the implemented code
ftp://ftp-sop.inria.fr/rodeo/turletti/simutools09.pdf

If you have questions regarding the code or regarding the design of the 
scheduler please feel free to contact me . Here is my skype account: 
amine.ismail

Thanks,
Amine

On Tuesday 31 March 2009 18:24:18 Nitin Dua, IIT G wrote:
> Thanks Amine,
>
> > Hi Nitin,
> >
> >> In the best of my knowledge this scheduler is not implemented in ns-3
> >> WiMAX module. I would want to know if anyone is already taking up the
> >> implementation of the particular scheduler talked about in the paper. If
> >> not, then I would readily like to do so.
> >
> > Yes, this scheduler is not implemented in the current version of the
> > WiMAX module and nobody is working on its implementation. You can GO :).
> >
> > For further details on the existing code and API please do not hesitate
> > to
> > contact us.
>
> I would definitely like you to brief me about the existing code and the
> location where its available. I have ns-3 all-in-one but I think it does
> not have the WiMAX module or maybe I am not able to locate it. I through
> going through the documentation for ns-3. In the meanwhile I'll contact
> Juliana for the existing ns-2 code she developed for the scheduler.
>
> > Regards
> > Amine
> >
> > On Monday 30 March 2009 19:48:24 Nitin Dua, IIT G wrote:
> >> Dear ns-3 developers,
> >>
> >> Firstly I would like to inform all that I am an undergraduate student
> >> from
> >> Indian Institute of Technology Guwahati India and I am a new addition to
> >> the group. Its great to be among you!
> >>
> >> I am greatly interested in WiMAX networks and also well acquainted to
> >> its
> >> standards, protocol stack and performance. I was interested in the idea
> >> of
> >> implementing a uplink scheduling algorithm as a part of GSoC 2009. As
> >> suggested to me by Juliana Freitag Borin, I would like to port the
> >> scheduler presented here
> >> http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4411386
> >> in the WiMAX module.
> >>
> >> In the best of my knowledge this scheduler is not implemented in ns-3
> >> WiMAX module. I would want to know if anyone is already taking up the
> >> implementation of the particular scheduler talked about in the paper. If
> >> not, then I would readily like to do so.
> >>
> >> Any kind of guidance would be welcome.
> >>
> >> Thanks & Regards,
> >> Nitin Dua
> >>
> >> > Dear ns-3 developers,
> >> >
> >> >
> >> > In my previous message, I forgot to emphasize the most essential part
> >> >
> >> > :-).
> >> >
> >> > We very welcome contributions in the current WiMAX module and are open
> >> > for any proposal to enhance it.
> >> > As it is important to coordinate the different works in the community,
> >> > please
> >> > keep us informed about any current/future work you are interested in
> >>
> >> or
> >>
> >> > planning to investigate, to avoid developing similar things.
> >> >
> >> > Here are further details regarding the status of the WiMAX module.
> >> >
> >> > Concerning the implementation of the IPCS classifier, it is almost
> >> > finished
> >> > and we are in the bug fixing phase. The code should be available soon
> >>
> >> at
> >>
> >> > http://code.nsnam.org/iamine/ns-3-wimax/  .
> >> >
> >> >
> >> > We intend to implement the tracing function in the next few weeks.
> >> > In May, a master student is expected to start an internship on the
> >> > development of scheduling algorithms (for both uplink and downlink).
> >> > For this task in particular, a coordination with other groups is
> >>
> >> crucial.
> >>
> >> > Regarding the 2nd implementation of the PHY layer based on itpp, I
> >>
> >> would
> >>
> >> > like to mention that this module currently requires a huge computation
> >> > time
> >> > since it encodes and modulates the bursts provided by the upper layer.
> >> > Basically, this implementation is far to be real-time... So if anyone
> >>
> >> is
> >>
> >> > interested in designing a more sophisticated PHY layer with
> >> > propagation/error
> >> > model, he/she would be very welcome.
> >> >
> >> >
> >> > Thank you very much
> >> >
> >> > Amine & Thierry



-------------------------------------------------------

From Amine.Ismail at sophia.inria.fr  Wed Apr  1 01:39:31 2009
From: Amine.Ismail at sophia.inria.fr (Mohamed Amine Ismail)
Date: Wed, 1 Apr 2009 10:39:31 +0200
Subject: [Ns-developers] GSoC: WiMAX Projects
In-Reply-To: <52330.10.1.2.18.1238527865.squirrel@webmail.iitg.ernet.in>
References: <13786f330903251123v26376c0dk3f7b277be427b8bb@mail.gmail.com>
	<200903271015.39149.Amine.Ismail@sophia.inria.fr>
	<52330.10.1.2.18.1238527865.squirrel@webmail.iitg.ernet.in>
Message-ID: <200904011039.31259.Amine.Ismail@sophia.inria.fr>

Hi Nitin,

> estimated error. Do you think implementation of such a scheme in ns-3
> wimax module will be feasible?

I think such a mechanism is very interesting for the WiMAX module, however, in 
the current version of the code there is no error model implemented yet. You 
can maybe implement a basic error model (Gilbert model?)  and then design and 
implement  a mechanism which computes the optimal size of the PDU based on 
the estimated error.

Thanks
Amine

On Tuesday 31 March 2009 21:31:05 Nitin Dua, IIT G wrote:
> Dear Amine,
>
> I had some queries regarding the mail below which you sent a few days back.
>
> > Hi,
> >
> > I'am Mohamed Amine ISMAIL a Ph.D student at the INRIA. Actually I am
> > working
> > on the wimax module for ns-3.
> >
> > The current WiMAX module provides the main functionalities of the WiMAX
> > standard. The core part of the MAC layer includes the generation of the
> > MAC
> > frames (in TDD mode) and the construction and transmission of the key MAC
> > control messages (DL-MAP, UL-MAP, DCD, UCD, RNG-REQ and RNG-RSP).
> >
> > The Link Manager component at the SS and BS side handles the network
> > entry and initialisation procedure that a new SS follows upon entering
> > the WiMAX network. This procedure includes the scanning process  and the
> > initial ranging process.
> >
> > Once the network entry process is successful, the SS is assigned with a
> > set of
> > connections. This includes two connections for the management messages
> > and a
> > number of transport connections for the data traffic. Both SS and BS
> > maintain
> > their own connection managers. For the BS the connection manager handles
> > the
> > creation and management of all the connections associated to SSs
> > registered
> > with the BS. For SS the connection manager manages connection associated
> > to
> > the SS. The SS Manager component is maintained by the BS to access all
> > the SSs currently registered to BS.
> >
> > The service flows are set up during the installation of the application.
> > Once
> > registered with BS the SS then requests for creation of an already set up
> > service flow from BS, and BS then creates the service flow, registers the
> > QoS
> > parameters associated to it, and allocates service flow to SS. This whole
> > process is done through the exchange of DSA (DSA-REQ, DSA-RSP and
> > DSA-ACK) messages.
> >
> > The module supports all four scheduling services. Each service flow is
> > associated to exactly one transport connection and one scheduling
> > service. The QoS parameters associated to a service flow actually define
> > the scheduling service it belongs to. Standard QoS parameters for UGS,
> > rtPS, nrtPS and BE services, as specified in Tables 111a to 111d of the
> > 802.16e amendment, are supported.
> >
> >
> > The current WiMAX module provides two different versions of the PHY
> > layer. The first one is a basic PHY implementation which simply forwards
> > bursts received by the MAC layer ignoring any underlying PHY layer
> > details. The second one is a more complete OFDM PHY layer, it uses
> > external
> > mathematics and signal processing library IT++ together with the LAPACK,
> > BLAS
> > and FFTW libraries. no propagation/error model has been considered, hence
> > one
> > of the future works is also to add support for a propagation/error model.
>
> Is it that the optimal size for the PDU is not considered at all. I came
> across this paper
> http://ieeexplore.ieee.org/iel5/4483765/4488105/04488131.pdf?arnumber=44881
>31 which talks about finding an optimal size of the PDU based on the
> estimated error. Do you think implementation of such a scheme in ns-3
> wimax module will be feasible? I am sure there may exist other tested
> schemes. I would like to integrate such fragmenting/defragmenting PDU
> techniques in ns-3 over this summer. Please send me any resources you are
> aware of.
>
> > Actually we are working on an IPCS classifier. The classifier  is used to
> > map
> > the incoming packet to the appropriate service flow based on a set of
> > criteria. The service flows are created at the scenarios setup and a bind
> > function is developed to associate an IP traffic to a service flow based
> > on
> > the IP src,IP dst, protocol, port src, and port dst. The IPCS analyses
> > the headers of the incoming IP packets from the upper layer and map them
> > to the
> > appropriate connexion.
> >
> > An other ongoing work is the development of the pcap tracing function for
> > the
> > wimax packets.
> >
> >
> > The module currently lacks the implementations of :
> >
> > - fragmentation/defragmentation of PDU(s)
> > - dynamic burst profile management
> > - Propagation/error model
> > - more sophisticated algorithm for the scheduler
> > - more efficient algorithm for the bandwidth management mechanism
> >
> >
> >
> > Regards
> > Amine
>
> Thanks & Regards,
> Nitin



From ljerezchaves at gmail.com  Wed Apr  1 04:55:11 2009
From: ljerezchaves at gmail.com (Luciano Jerez Chaves)
Date: Wed, 1 Apr 2009 08:55:11 -0300
Subject: [Ns-developers] GSoC 2009 - Minstrel rate control algorithm
In-Reply-To: <70f6a1ed0904010136w50dd2e2fmb1aa54c4ba5063d8@mail.gmail.com>
References: <d5ff16190903292016v4316aee1y74cbb43fcf91222a@mail.gmail.com>
	<49D12D50.2030003@net.t-labs.tu-berlin.de>
	<d5ff16190903310732r4a183b68p10708f0038f4ed97@mail.gmail.com>
	<1238572873.18589.250.camel@diese.inria.fr>
	<70f6a1ed0904010136w50dd2e2fmb1aa54c4ba5063d8@mail.gmail.com>
Message-ID: <d5ff16190904010455t774d51d5h87b148d7256cf434@mail.gmail.com>

Hey guys

Yes, I'm considering the necessary efforts to implement and validate
minstrel in ns-3 in my proposal. Depending on how things evolve, I
think that by the end of the program it will be possible to implement
one more solution.

--
Luciano J. Chaves
MSc Computer Science Student
University of Campinas


On Wed, Apr 1, 2009 at 05:36, Duy Nguyen <dnlove at gmail.com> wrote:
> from what I've seen, porting and validating minstrel rate to ns3 will take
> some considerable? efforts also, do you expect applicants to consider this
> in their proposals too?
>
> Duy
>
> 2009/4/1 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
>>
>> On Tue, 2009-03-31 at 11:32 -0300, Luciano Jerez Chaves wrote:
>>
>> > The initial idea was to port CARA and AARF to ns-3 in order to fairly
>> > compare my solution with all available implementations, but I figured
>> > out that the AARF is already implemented on it. Although, we still
>> > have CARA, and there are other solutions in the literature that could
>> > be incorporated into the ns-3 as far as possible.
>>
>> It would be nice to incorporate this:
>> http://www.nsnam.org/bugzilla/show_bug.cgi?id=536
>>
>> Mathieu
>>
>
>


From n.dua at iitg.ernet.in  Wed Apr  1 07:59:00 2009
From: n.dua at iitg.ernet.in (Nitin Dua, IIT G)
Date: Wed, 1 Apr 2009 20:29:00 +0530 (IST)
Subject: [Ns-developers] GSoC: WiMAX Projects
In-Reply-To: <200904011039.31259.Amine.Ismail@sophia.inria.fr>
References: <13786f330903251123v26376c0dk3f7b277be427b8bb@mail.gmail.com>
	<200903271015.39149.Amine.Ismail@sophia.inria.fr>
	<52330.10.1.2.18.1238527865.squirrel@webmail.iitg.ernet.in>
	<200904011039.31259.Amine.Ismail@sophia.inria.fr>
Message-ID: <41463.10.1.2.18.1238597940.squirrel@webmail.iitg.ernet.in>

Hi Amine,

Thanks for the help. How is this for an abstract?

"I propose to implement in ns-3 WiMAX module a mechanism for
fragmenting/de-fragmenting of Protocol Data Units (PDUs) to the optimal
size when the error rate for the Forward Error Correction (FEC) block is
known. The FEC block error rate (BLER) shall be estimated by implementing
Gilbert-Elliot bit-error model. Using FEC BLER, the PDU error rate can be
computed which is further used to estimate the optimal PDU size."

Suggested modifications are most welcome.

Also I would like to read the paper[1] regarding error estimates but not
able to find it on the web. May be you could help me with this.
[1]- E. O. Elliot. Estimates of error rates for codes on burst-noise
channels. Bell Systems Technical Journal,
42:1977?1997, September 1963.

Please reply soon,
Thanks,
Nitin


> Hi Nitin,
>
>> estimated error. Do you think implementation of such a scheme in ns-3
>> wimax module will be feasible?
>
> I think such a mechanism is very interesting for the WiMAX module,
> however, in
> the current version of the code there is no error model implemented yet.
> You
> can maybe implement a basic error model (Gilbert model?)  and then design
> and
> implement  a mechanism which computes the optimal size of the PDU based on
> the estimated error.
>
> Thanks
> Amine
>
> On Tuesday 31 March 2009 21:31:05 Nitin Dua, IIT G wrote:
>> Dear Amine,
>>
>> I had some queries regarding the mail below which you sent a few days
>> back.
>>
>> > Hi,
>> >
>> > I'am Mohamed Amine ISMAIL a Ph.D student at the INRIA. Actually I am
>> > working
>> > on the wimax module for ns-3.
>> >
>> > The current WiMAX module provides the main functionalities of the
>> WiMAX
>> > standard. The core part of the MAC layer includes the generation of
>> the
>> > MAC
>> > frames (in TDD mode) and the construction and transmission of the key
>> MAC
>> > control messages (DL-MAP, UL-MAP, DCD, UCD, RNG-REQ and RNG-RSP).
>> >
>> > The Link Manager component at the SS and BS side handles the network
>> > entry and initialisation procedure that a new SS follows upon entering
>> > the WiMAX network. This procedure includes the scanning process  and
>> the
>> > initial ranging process.
>> >
>> > Once the network entry process is successful, the SS is assigned with
>> a
>> > set of
>> > connections. This includes two connections for the management messages
>> > and a
>> > number of transport connections for the data traffic. Both SS and BS
>> > maintain
>> > their own connection managers. For the BS the connection manager
>> handles
>> > the
>> > creation and management of all the connections associated to SSs
>> > registered
>> > with the BS. For SS the connection manager manages connection
>> associated
>> > to
>> > the SS. The SS Manager component is maintained by the BS to access all
>> > the SSs currently registered to BS.
>> >
>> > The service flows are set up during the installation of the
>> application.
>> > Once
>> > registered with BS the SS then requests for creation of an already set
>> up
>> > service flow from BS, and BS then creates the service flow, registers
>> the
>> > QoS
>> > parameters associated to it, and allocates service flow to SS. This
>> whole
>> > process is done through the exchange of DSA (DSA-REQ, DSA-RSP and
>> > DSA-ACK) messages.
>> >
>> > The module supports all four scheduling services. Each service flow is
>> > associated to exactly one transport connection and one scheduling
>> > service. The QoS parameters associated to a service flow actually
>> define
>> > the scheduling service it belongs to. Standard QoS parameters for UGS,
>> > rtPS, nrtPS and BE services, as specified in Tables 111a to 111d of
>> the
>> > 802.16e amendment, are supported.
>> >
>> >
>> > The current WiMAX module provides two different versions of the PHY
>> > layer. The first one is a basic PHY implementation which simply
>> forwards
>> > bursts received by the MAC layer ignoring any underlying PHY layer
>> > details. The second one is a more complete OFDM PHY layer, it uses
>> > external
>> > mathematics and signal processing library IT++ together with the
>> LAPACK,
>> > BLAS
>> > and FFTW libraries. no propagation/error model has been considered,
>> hence
>> > one
>> > of the future works is also to add support for a propagation/error
>> model.
>>
>> Is it that the optimal size for the PDU is not considered at all. I came
>> across this paper
>> http://ieeexplore.ieee.org/iel5/4483765/4488105/04488131.pdf?arnumber=44881
>>31 which talks about finding an optimal size of the PDU based on the
>> estimated error. Do you think implementation of such a scheme in ns-3
>> wimax module will be feasible? I am sure there may exist other tested
>> schemes. I would like to integrate such fragmenting/defragmenting PDU
>> techniques in ns-3 over this summer. Please send me any resources you
>> are
>> aware of.
>>
>> > Actually we are working on an IPCS classifier. The classifier  is used
>> to
>> > map
>> > the incoming packet to the appropriate service flow based on a set of
>> > criteria. The service flows are created at the scenarios setup and a
>> bind
>> > function is developed to associate an IP traffic to a service flow
>> based
>> > on
>> > the IP src,IP dst, protocol, port src, and port dst. The IPCS analyses
>> > the headers of the incoming IP packets from the upper layer and map
>> them
>> > to the
>> > appropriate connexion.
>> >
>> > An other ongoing work is the development of the pcap tracing function
>> for
>> > the
>> > wimax packets.
>> >
>> >
>> > The module currently lacks the implementations of :
>> >
>> > - fragmentation/defragmentation of PDU(s)
>> > - dynamic burst profile management
>> > - Propagation/error model
>> > - more sophisticated algorithm for the scheduler
>> > - more efficient algorithm for the bandwidth management mechanism
>> >
>> >
>> >
>> > Regards
>> > Amine
>>
>> Thanks & Regards,
>> Nitin
>
>
>


From kirillano at yandex.ru  Wed Apr  1 08:46:58 2009
From: kirillano at yandex.ru (kirillano)
Date: Wed, 01 Apr 2009 19:46:58 +0400
Subject: [Ns-developers] Metric calculation in 802.11s
Message-ID: <399031238600818@webmail25.yandex.ru>

Hi all,

my current work is aimed to calculate link metric in 802.11s.
For metric calculation I would like to know data rate of a transmitted packet and retry counter.
To get this parameters I want to use TxOk callback.
So I want to propose the following changes:
1. TxOk callback should be changed:
-  typedef Callback <void, WifiMacHeader const&> TxOk;
+  typedef Callback <void, WifiMacHeader const&, uint8_t, WifiMode> TxOk;
and it will be able to pass:
    - retry counter (uint8_t)
    - mode of transmitted packet (WifiMode)

This way allows MacHigh to collect statistics as it wish, rather than hardcoding statistics code inside RemoteStationManager.

On this way I see the following problems:
1. The problem of retry counter.
   Only RemoteStationManager knows about retry counter, but DcaTxop class has unused variable m_currentRetry.
   And I have no idea how to pass retry counter from station manager to dca txop.
2. Problem of transmission rate of ACK.
   When DcaTxop receives information about successfully transmitted packet through method DcaTxop::GotAck (double snr, WifiMode txMode), it gets txMode, which is transmission mode of ACK, rather than of a packet.
   How can I get a packet's data mode?

If this idea seems reasonable to you, probably it's worth adding some more parameters (like SNR) to TxOk callback.
I would like to know your comments on these proposed changes.


Regards,
Kirill

From gjcarneiro at gmail.com  Wed Apr  1 10:03:52 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Wed, 1 Apr 2009 18:03:52 +0100
Subject: [Ns-developers] olsr rework
In-Reply-To: <1237817555.23686.33.camel@diese.inria.fr>
References: <1237817555.23686.33.camel@diese.inria.fr>
Message-ID: <a467ca4f0904011003o205543cfifd1fc1131ff3e3bf@mail.gmail.com>

2009/3/23 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> hi,
>
> As a preparation for the ipv4 rework for next release, I did a first set
> of changes to olsr to move the call to Ipv4::AddRoutingProtocol from the
> olsr-agent-impl.cc file to olsr-helper.cc. What has changed:
>
> 1) removed olsr::Agent
> 2) renamed olsr::AgentImpl to olsr::RoutingProtocol
> 3) made olsr::RoutingProtocol derive from Ipv4RoutingProtocol instead of
> olsr::Agent
>
> There was an ipv4 memory management bug to fix to make the above simple
> file shuffling work which I pushed to ns-3-dev earlier today. This tree
> (http://code.nsnam.org/mathieu/ns-3-olsr) passes all regression tests
> and is API compatible. I am not really looking forward merging this now
> because I don't really want to handle any potential fallouts (although I
> am convinced there won't be any) but, I would like feedback to be ready
> to merge this as soon as our next release ships.
>
> Gustavo ?


I am not sure I agree with:

http://code.nsnam.org/mathieu/ns-3-olsr/rev/9e9c734b927e

It's true that Closing a socket is a good idea.  But it's also true that
calling Dispose () on all pointer-to-Object members is conceptually a good
idea.  I do not know whether the socket objects contain references to other
objects which could create a cycle back to me, nor do I know whether calling
Socket::Close would clear those references.  I can find that out by peeking
into the udp socket implementation, but clearly it is safer to just call
Dispose anyway, just in case.

Otherwise, no objections from me.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From tjkopena at cs.drexel.edu  Wed Apr  1 11:27:00 2009
From: tjkopena at cs.drexel.edu (Joseph Kopena)
Date: Wed, 1 Apr 2009 14:27:00 -0400
Subject: [Ns-developers] GSoC: Submit Your Proposals via the 2009 site
	*now*
In-Reply-To: <70f6a1ed0903311640u334eb912u4d6b57c9680b9dff@mail.gmail.com>
References: <f4eeff4e0903311555q4a483bafg1292e1deb2d23dda@mail.gmail.com>
	<70f6a1ed0903311640u334eb912u4d6b57c9680b9dff@mail.gmail.com>
Message-ID: <13786f330904011127s31bca566of8036362eb32427d@mail.gmail.com>

On Tue, Mar 31, 2009 at 7:40 PM, Duy Nguyen <dnlove at gmail.com> wrote:
> isn't the deadline this friday?

That is correct, though you should be able to revise your application
up to the deadline once you've submitted it.  Better to get it in
there and go from there than wait until the last minute and have
problems (technical problems, access problems, timezone issues, etc).

-- 
- joe kopena
right here and now

From tjkopena at cs.drexel.edu  Wed Apr  1 11:40:31 2009
From: tjkopena at cs.drexel.edu (Joseph Kopena)
Date: Wed, 1 Apr 2009 14:40:31 -0400
Subject: [Ns-developers] GSoC 09: Reactive Routing Protocols
In-Reply-To: <993601c10903291019i2c4d3100qaeb9cc8eed2b341c@mail.gmail.com>
References: <993601c10903241033h3436c58cxfb89003a2c9ec3a@mail.gmail.com>
	<13786f330903251535i49481e91of88cb55b27db2999@mail.gmail.com>
	<993601c10903291019i2c4d3100qaeb9cc8eed2b341c@mail.gmail.com>
Message-ID: <13786f330904011140i7fc0bae8v3fb5f1e17cbe0d00@mail.gmail.com>

On Sun, Mar 29, 2009 at 1:19 PM, karan verma <karan.verma86 at gmail.com> wrote:
> I also wanted to know that has any mentor been assigned to this particular
> project.

Hi Karan,

There is not a mentor specifically interested in reactive routing
protocols.  We do have some wiggle room, so an exceptional proposal
may still be selected and skewed closer to some of the other topic
areas, but certainly they're not as much of a priority.  If you have
time and you wish, you are also free to submit a proposal for another
topic (in addition to other GSoC programs).

Thx

-- 
- joe kopena
right here and now

From tjkopena at cs.drexel.edu  Wed Apr  1 11:42:14 2009
From: tjkopena at cs.drexel.edu (Joseph Kopena)
Date: Wed, 1 Apr 2009 14:42:14 -0400
Subject: [Ns-developers] can't find NS3 List when I am going to submit
	my proposal
In-Reply-To: <86d2e8120903291947j340f6219sb324fa20c34c96e3@mail.gmail.com>
References: <86d2e8120903291947j340f6219sb324fa20c34c96e3@mail.gmail.com>
Message-ID: <13786f330904011142od3b2a3cs7007de180a2c9753@mail.gmail.com>

On Sun, Mar 29, 2009 at 10:47 PM, Tomren <renhao2008 at gmail.com> wrote:
> ? ? ?I want to send proposal to NS3 project, but I can't find in GSoC List
> when I am going to write my idea. I don't know why, can anybody help me?

Tomren,

Did you resolve your issue here?  The system seems to be working fine
as we have received a number of other applications already.

Thx

-- 
- joe kopena
right here and now


From tjkopena at cs.drexel.edu  Wed Apr  1 11:53:25 2009
From: tjkopena at cs.drexel.edu (Joseph Kopena)
Date: Wed, 1 Apr 2009 14:53:25 -0400
Subject: [Ns-developers] Google SoC 2009 - Modeling routers
In-Reply-To: <f4eeff4e0903271104w52b50ea0q3354673d22cbcde6@mail.gmail.com>
References: <49CAB2ED.2030007@cs.wisc.edu>
	<f4eeff4e0903260850j2e7fbcb0v7cf741e0239ef554@mail.gmail.com>
	<49CD0974.7000104@cs.wisc.edu>
	<f4eeff4e0903271104w52b50ea0q3354673d22cbcde6@mail.gmail.com>
Message-ID: <13786f330904011153r1cd6c4e5wb586f7158da77479@mail.gmail.com>

On Fri, Mar 27, 2009 at 2:04 PM, Adrian Sai-Wah TAM <adrian at ieaa.org> wrote:
> What is more useful for NS-3? How much detail? I don't know. I have my
> own agenda and others have theirs. I am not sure about the preference.
> To the elegance, I think building a generic architecture first and
> base on the generic architecture to build something specific as an
> useful example looks more welcomed (e.g. to NS3 learners, because this
> looks more homogeneous and easier to understand).

Hi Lorenzo (and everyone),

I think the discussion between you and Adrian above is reasonably on
par with the level of detail expected of the proposals.  The key thing
is demonstrating that:

- You understand what the project is intending to do.

- You have a clear idea of the sub-goals of that project.

- You have a reasonable, albeit high level, idea of the components
necessary, their connections, and their relationship to the overall
ns-3 structure.

- You have a practical plan and schedule for implementing the required
components.

You seem on track to meet those goals in your proposal.  For example,
discussion about working with the NetDevice and Ipv4L3Protocol classes
and the interactions there as you have above, but without delving into
deeper details like specific function interfaces, is pretty much right
on target.


As far as interest, everything discussed here seems relevant, useful
to a wide range of users, and of interest to a mentor (Adrian).
Beyond that, I think working out general architecture/concepts to
support this topic and then iterating on more and more specific models
within that architecture is the way to go with this topic.

Thx

-- 
- joe kopena
right here and now

From fw at strlen.de  Wed Apr  1 12:25:42 2009
From: fw at strlen.de (Florian Westphal)
Date: Wed, 1 Apr 2009 21:25:42 +0200
Subject: [Ns-developers] setting available system memory on a node?
Message-ID: <20090401192542.GC10077@Chamillionaire.breakpoint.cc>

Hi everyone,

After doing a few tests with NSC: It really has to be extended
so the user can set the amount of RAM (memory pages) available,
i.e. the simulation results are different depeding on
the memory limits (the default tcp window size depends on this, for
instance).

How would you like to have this exposed on the ns3 side?
I am thinking node should have something like

.AddAttribute ("System Memory", "The amount of memory (in Ki Bytes) "
		"available to this stack", ...

OTOH, there are no users (yet), and ns-3 itself would not be using this.

Maybe it should be put on the back burner until the long-planned (well,
long planned by me, anyway) ns-3-nsc rework is completed (my plan
was to introduce an "nsc node" object, which could then pass such
an attribute on to NSC).

Thoughts?

From mk.banchi at gmail.com  Wed Apr  1 12:47:24 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Wed, 01 Apr 2009 21:47:24 +0200
Subject: [Ns-developers] Wifi management frames
In-Reply-To: <1238571259.18589.242.camel@diese.inria.fr>
References: <49D27E0D.5040407@gmail.com>
	<1238571259.18589.242.camel@diese.inria.fr>
Message-ID: <49D3C4CC.8090902@gmail.com>

Mathieu Lacage ha scritto:
> On Tue, 2009-03-31 at 22:33 +0200, Mirko Banchi wrote:
>> Hi all,
>>
>> i have some questions about 802.11 management frames i'd like to discuss
>> with you.
>>
>> For now all management frames are handled in NqstaWifiMac, NqapWifiMac,
>> AdhocWifiMac, QapWifiMac, QstaWifiMac objects. This type of frames are
>> stored in the same queues where are stored data frames.
> 
> Outgoing beacon frames are stored in a separate queue in NqapWifiMac.
> 
>> -First question:
>>
>> Should be there a specific queue for management frames ?
>> What will happen if a station becomes disassociated (so a probeReq or a
>> associationReq are needed) and have other packets in queue?
> 
> There should not be a separate queue for nqos MACs.
> 
>> See:
>>
>> src/devices/wifi/nqsta-wifi-mac.cc
>>    NqstaWifiMac::Enqueue
>>    NstaWifiMac::TryToEnsureAssociated
>>    NqstaWifiMac::SendProbeRequest
>>
>> -Second question:
>>
>> Working with block ack there is need to send action frames (management
>> frames) in order to setup block ack. I think that the exchange of this
>> frames between two station must be accomplished with high priority. I
>> used a method
> 
> What does 802.11e say about this ?

Standard doesn't specify how and with which priority these frames are
transmitted.
> 
>> WifiMacQueue::PushFront (Ptr<Packet> packet, const WifiMacHeader &hdr)
>>
>> that pushes packets in queue's head but it's very horrible: the
>> expiration of MsduLifeTime doesn't work :(
>>
>> I think that a dedicated queue (like m_beaconDca in NqapWifiMac) could
>> resolve this problems.
> 
> It could, but I wonder what the specification requires.

I didn't find in the standard nothing about this. But there's in section
C.2 a description in SDL/PR of the operators used in MAC state machine.
In Package Macsorts is defined a type "head" with the following description:

/* place MMPDU at head of transmit queue */

So seems WifiMacQueue::PushFront makes sense.

Regards,
Mirko

-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090401/e402fa0e/smime.bin

From ruben at net.t-labs.tu-berlin.de  Wed Apr  1 13:47:51 2009
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Wed, 01 Apr 2009 22:47:51 +0200
Subject: [Ns-developers] GSoC 2009 - Minstrel rate control algorithm
In-Reply-To: <d5ff16190903310732r4a183b68p10708f0038f4ed97@mail.gmail.com>
References: <d5ff16190903292016v4316aee1y74cbb43fcf91222a@mail.gmail.com>	
	<49D12D50.2030003@net.t-labs.tu-berlin.de>
	<d5ff16190903310732r4a183b68p10708f0038f4ed97@mail.gmail.com>
Message-ID: <49D3D2F7.2070909@net.t-labs.tu-berlin.de>

Hi Luciano,

Comments below,

On 3/31/09 4:32 PM, Luciano Jerez Chaves wrote:
> Hi Ruben,
>
> On Mon, Mar 30, 2009 at 17:36, Ruben Merz<ruben at net.t-labs.tu-berlin.de>  wrote:
>> Hi Luciano
>>
>> On 3/30/09 5:16 AM, Luciano Jerez Chaves wrote:
>>> Hi Ns-developers,
>>>
>>> My name is Luciano and I am a MSc Computer Science student at
>>> University of Campinas, Brazil.
>>>
>>> I'm working with Rate Adaptation solutions to wireless networks in
>>> my master's thesis and I'm interested in participating in Google
>>> Summer of Code this year.
>>>
>>> I've been looking for an idea in ns-3 wiki page and I found a interesting
>>> project to implement Minstrel rate control algorithm in ns-3.
>>>
>>> I believe it would be very motivating and helpful to me, since I'm
>>> evaluating my proposed algorithm based on simulations in ns-2.
>>> I've implemented two other different rate adaptations solutions in
>>> ns-2, using the dei802mr (develop by Nicola Baldo, and his team,
>>> at DEI) to compare my algorithm with.
>> Do you plan to also port these algorithms in ns-3?
>
> The algorithms that I implemented in ns-2 are the AARF (an extension
> of the original ARF), CARA, and my own solution, that I didn't finish
> yet.
>
> The initial idea was to port CARA and AARF to ns-3 in order to fairly
> compare my solution with all available implementations, but I figured
> out that the AARF is already implemented on it. Although, we still
> have CARA, and there are other solutions in the literature that could
> be incorporated into the ns-3 as far as possible.
>
>>> I think that a good implementation in ns-3 will contribute to my
>>> project and to many other people.
>>>
>>> I am still not familiar with the ns-3 code, but I figured out that
>>> there many others rate control algorithms implemented on it.
>>> I have good knowledge in C++ programming and about rate
>>> control in wireless networks. I'm currently studding the Minstrel
>>> algorithm, and I think that will be possible to successfully implement
>>> it in ns-3 during the GSoc program.
>> The rate control algorithms are all in src/devices/wifi. You can also go in
>> the example directory and grep for calls to SetRemoteStationManager.
>
> Looking in the suggested directory and in some rate control solutions
> there, it doesn't seem very difficult to implement a new rate control
> algorithm, since the code structure is well defined.

Good to hear. But what I'd like to hear from you is a more detailed plan 
than what you describe below. Minstrel has several components. There are 
(1) gathering the statistics for all the links (2) the moving average 
algorithm (3) the retry chain algorithm and (4) the rate lookaround 
algorithm.

How would you tackle those issues? For instance, gathering the 
statistics for all the links is something that might be of interest for 
the other rate control algorithms? So, it might be interesting to get a 
more general solution. The retry chain concept is something that is more 
related to the underlying hardware than the rate control algorithm in 
itself.

> I believe that it's possible to implement the Minstrel algorithms in
> something like five weeks or so.

As I said above, try to come up with a more detailed plan.

> Since the Minstrel solution is based solely in statistical measured
> performance with minimum of assumptions, the coding difficulty is
> linked to create a data structure that will be used by the algorithm
> (a table to store values for each destiny) and to obtain, from the

Typically, I'm not sure that a simple table would be the most efficient 
way. I'd rather advise a hash table or some tree structure.

I think you should also look into the linux kernel code that implements 
Minstrel: http://lxr.linux.no/linux+v2.6.29/net/mac80211/rc80211_minstrel.c

> simulated code, the performance metrics evaluated.
>
> After that, with the experience obtained with ns-3 programming, the
> code style, simulator structure and many other things, it will be
> possible to introduce other solutions.

Let's see. Before moving to other solutions, I'd like to see some 
validation and testing done. I don't know yet how, but this should be 
planned.

Once it's sure that the code performs reasonably well, I'll be happy to 
see some other rate control algorithm implemented.

>>> I would like a feedback about these project, and any suggestion
>>> that may arise. I would be happy with a mentor' contact.
>> Let me know if you have questions.
>
> I'm looking forward to hearing from you in order to improve my GSoC application.

Well, don't forget to submit you proposal on the gsoc website.

Best
Ruben

>> Best
>> Ruben
>>
>>> Best regards,
>>>
>>> --
>>> Luciano J. Chaves
>>> MSc Computer Science Student
>>> University of Campinas
>> --
>> Ruben Merz                   Deutsche Telekom Laboratories
>> http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml
>>
>
> Regards
>
> --
> Luciano J. Chaves
> MSc Computer Science Student
> University of Campinas

From ruben at net.t-labs.tu-berlin.de  Wed Apr  1 13:49:41 2009
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Wed, 01 Apr 2009 22:49:41 +0200
Subject: [Ns-developers] GSoC 2009 - Minstrel rate control algorithm
In-Reply-To: <1238572873.18589.250.camel@diese.inria.fr>
References: <d5ff16190903292016v4316aee1y74cbb43fcf91222a@mail.gmail.com>	
	<49D12D50.2030003@net.t-labs.tu-berlin.de>	
	<d5ff16190903310732r4a183b68p10708f0038f4ed97@mail.gmail.com>
	<1238572873.18589.250.camel@diese.inria.fr>
Message-ID: <49D3D365.70806@net.t-labs.tu-berlin.de>



On 4/1/09 10:01 AM, Mathieu Lacage wrote:
> On Tue, 2009-03-31 at 11:32 -0300, Luciano Jerez Chaves wrote:
>
>> The initial idea was to port CARA and AARF to ns-3 in order to fairly
>> compare my solution with all available implementations, but I figured
>> out that the AARF is already implemented on it. Although, we still
>> have CARA, and there are other solutions in the literature that could
>> be incorporated into the ns-3 as far as possible.
>
> It would be nice to incorporate this:
> http://www.nsnam.org/bugzilla/show_bug.cgi?id=536

That would be a good follow-up to Minstrel.

R

> Mathieu
>

From ruben at net.t-labs.tu-berlin.de  Wed Apr  1 14:14:56 2009
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Wed, 01 Apr 2009 23:14:56 +0200
Subject: [Ns-developers] GSoC 2009 - Minstrel rate control algorithm
In-Reply-To: <70f6a1ed0904010136w50dd2e2fmb1aa54c4ba5063d8@mail.gmail.com>
References: <d5ff16190903292016v4316aee1y74cbb43fcf91222a@mail.gmail.com>	
	<49D12D50.2030003@net.t-labs.tu-berlin.de>	
	<d5ff16190903310732r4a183b68p10708f0038f4ed97@mail.gmail.com>	
	<1238572873.18589.250.camel@diese.inria.fr>
	<70f6a1ed0904010136w50dd2e2fmb1aa54c4ba5063d8@mail.gmail.com>
Message-ID: <49D3D950.8040503@net.t-labs.tu-berlin.de>

Duy,

The GSOC project idea for rate control is actually to port and validate 
Minstrel. So yes, I expect applicants to consider this in their 
proposal. Minstrel is also planned to become the default rate control 
algorithm for 802.11 in Linux. So from a validation and comparison point 
of view, I think it would be very worthwhile to have Minstrel in ns-3.

Best
Ruben

On 4/1/09 10:36 AM, Duy Nguyen wrote:
> from what I've seen, porting and validating minstrel rate to ns3 will
> take some considerable  efforts also, do you expect applicants to
> consider this in their proposals too?
>
> Duy
>
> 2009/4/1 Mathieu Lacage <mathieu.lacage at sophia.inria.fr
> <mailto:mathieu.lacage at sophia.inria.fr>>
>
>     On Tue, 2009-03-31 at 11:32 -0300, Luciano Jerez Chaves wrote:
>
>      > The initial idea was to port CARA and AARF to ns-3 in order to fairly
>      > compare my solution with all available implementations, but I figured
>      > out that the AARF is already implemented on it. Although, we still
>      > have CARA, and there are other solutions in the literature that could
>      > be incorporated into the ns-3 as far as possible.
>
>     It would be nice to incorporate this:
>     http://www.nsnam.org/bugzilla/show_bug.cgi?id=536
>
>     Mathieu
>
>

-- 
Ruben Merz                   Deutsche Telekom Laboratories
http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml

From ruben at net.t-labs.tu-berlin.de  Wed Apr  1 14:27:39 2009
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Wed, 01 Apr 2009 23:27:39 +0200
Subject: [Ns-developers] GSoC + WiPreSS
In-Reply-To: <20090331135004.m744tc8fnoggwog4@webmail.telecompress.net>
References: <20090331135004.m744tc8fnoggwog4@webmail.telecompress.net>
Message-ID: <49D3DC4B.3030607@net.t-labs.tu-berlin.de>

Dear Paolo

Comments below

On 3/31/09 1:50 PM, paolo.pilia at telecompress.net wrote:
> Quoting Ruben Merz <ruben at net.t-labs.tu-berlin.de>:
>
>> Dear Paolo
>>
>> On 3/29/09 6:18 PM, paolo.pilia at telecompress.net wrote:
>>> Dear NS3 developers,
>>>
>>> I want inform ns-3 developers about the new project WiPreSS ( Wireless
>>> Prediction and Simulation Software - info on telecompress dot net).
>>> I'm working to integrate ns-3 for simulation.
>>
>> Would you give us a bit more details than what is on
>> http://telecompress.net/ ? How does really ns-3 relate to it? Which
>> parts of ns-3 do you want to use?
>>
>
> WiPreSS is a free solution for wireless network design and testing.
> Basically it will be a really-free alternative to Radio Mobile, with
> some additional features.
> It calculate the radio propagation in a real scenario. Importing data
> of terrain (altitude) from DEM repositories and combine it with
> builds-data from shapefile.
> Ns3 is the best candidate for testing a wireless application after the
> design.
> I'm working also to develop another kind of simulation based on it++
> for custom trasmission channel ( p2p radio link) with definition of
> modulation, coding, filter.
>
>>> At this moment the radio propagation tool of ns3 is so poor. I'm going
>>> to register in socghop and present my candidature as student for GSoC on
>>> antennas module.
>>
>> Could you please elaborate on how you would work on this project. What
>> kind of antenna radiation pattern model would you implement? How would
>> you implement it? Maybe even validate it?
>>
>
> The innovation (confronting with actual ns3) in an antenna class that
> compute the 3d pattern of antenna reading the specifications file (MSI

Ok, an antenna class might be a good start. But then, where would 
integrate such a class in the current ns-3 codebase? Typically, such a 
class should interface with the propagation models. So, how would you do 
that?

> or ANT). These files are used by the antennas vendor. It make possible
> to test a radio connection with a chosen antennas (for example select
> a Kathrein specific model).
> 3D pattern is result of horizontal and vertical diagram combination.

Well, before a full 3D radiation pattern, I would start with a simpler 
2D pattern. Also, the implementation of a radiation pattern implies that 
nodes must have an orientation. This is not yet supported in ns-3.

> I've an implementation of this class for WiPreSS.
>
> I'm going to add the function for elements combination in array.
> It's simple implementable with defined elements, positions and phases.
>
> About propagation model I'm going to write the code.

There are already propagation models in ns-3. Assuming the work on the 
antenna is done, what would you propose?

> Validation is planned (Wipress is a thesis project).

Could you please elaborate on this?

>
> On side of propagation model I'm working to combine multi-path
> propagation model (it++) with ray tracing.
> Actually the realization it's related to the critical aspect of
> processing environment.

That would be very interesting but I fear this is way too much. 
Actually, this is likely another project in itself.

Ruben

> The goals are simple defined in the equation:
> Antennas::3dpattern + environment::raytracing + channel::multipath =
> diversity simulation
>
>
>
>
>> Best
>> Ruben
>>
>>> Regards,
>>> Paolo Pilia

From raj.b at gatech.edu  Wed Apr  1 14:35:41 2009
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Wed, 1 Apr 2009 17:35:41 -0400
Subject: [Ns-developers] ns-3 animation / visualization HOWTO request
Message-ID: <12d69e490904011435t6daae966n6f77a9a361adf6e7@mail.gmail.com>

I have noticed that several people have talked about animation and
visualization for ns-3 on this list; of these people, several have
also posted some code and made it available for use.

I'd like to invite these people who are interested in getting their
tool more exposure to create a page on the ns-3 wiki describing how to
use their tool with ns-3.  In the "Current Development" page, I have
updated the description of the current GUI based projects that I know
of:

http://www.nsnam.org/wiki/index.php/Current_Development#Visualization_for_ns-3

If anyone would like to post additional information here about an
animator they have been working on, OR if you would like to flesh out
a brief tutorial on how to use an animator/GUI you have created, it
would be greatly appreciated.

Ideally, each of these contributions will have a page on the wiki,
which takes the perspective of a HOWTO, walking new users through the
prerequisites for compilation, compilation steps, and use of the tool
with ns-3.

-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955

From raj.b at gatech.edu  Wed Apr  1 17:46:03 2009
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Wed, 1 Apr 2009 20:46:03 -0400
Subject: [Ns-developers] Announcing release of ns-3.4
Message-ID: <12d69e490904011746q6cb32228w12840891a619b077@mail.gmail.com>

The latest release of the ns-3 software is available immediately at
the following locations:

Tarball:
http://www.nsnam.org/releases/ns-allinone-3.4.tar.bz2

Mercurial:
http://code.nsnam.org/ns-3.4

Supported platforms
-------------------
ns-3.4 has been tested on the following platforms:
  - linux x86 gcc 4.2, 4.1, and, 3.4.6.
  - linux x86_64 gcc 4.3.2, 4.2.3, 4.2.1, 4.1.3, 3.4.6
  - MacOS X ppc and x86
  - cygwin gcc 3.4.4 (debug only)

Not all ns-3 options are available on all platforms; consult the
wiki for more information:
http://www.nsnam.org/wiki/index.php/Installation

New user-visible features
-------------------------
  a) Wifi models: Timo Bingman contributed a ThreeLogDistance and a Nakagami
     propagation loss model based on the ns-2 models. Fabian Mauchle contributed
     multicast support.

  b) Object Name Service:  A facility allowing ns-3 Objects to be assigned
     names has been added.

  c) Tap Bridge:  A second option for integrating ns-3 with real-world hosts
     has been added.  This allows for real hosts to talk over ns-3 net devices
     and simulated networks.

  d) A new build option (ns-3-allinone) has been provided to make it easier for
     users to download and bulid commonly used ns-3 configurations.

  e) The ns-3 calendar queue scheduler has been ported to ns-3.

  f) XML support has been added to the ConfigStore.

API changes from ns-3.3
-----------------------
API changes for this release are documented in the file CHANGES.html

Known issues
------------
ns-3 build is known to fail on the following platforms:
  - gcc 3.3 and earlier
  - optimized builds on gcc 3.4.4 and 3.4.5
  - optimized builds on linux x86 gcc 4.0.x
  - optimized builds on Ubuntu 8.10 alpha 5 x86 gcc4.3.2
  - MinGW

The IPv4 API defined in src/node/ipv4.h is expected to undergo major changes
in preparation of the merge of the IPv6 API and implementation.

Future releases
---------------
Our next release, which is expected to happen in 2 to 4 months from now, will
feature the merging of some of our projects currently in development including
fuller IPv6 support, and IPv4 and routing protocol refactoring, and some smaller
features such as a new Global ARP package and possibly a new Testing
and Validation
suite,

Special thanks to Craig for preparing these release notes.  ns-3-dev
is now open for business;  if you've had changes you wanted to push,
the tree is open once again!  Enjoy ns-3.4

-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955

From ljerezchaves at gmail.com  Wed Apr  1 21:03:17 2009
From: ljerezchaves at gmail.com (Luciano Jerez Chaves)
Date: Thu, 2 Apr 2009 01:03:17 -0300
Subject: [Ns-developers] GSoC 2009 - Minstrel rate control algorithm
In-Reply-To: <49D3D2F7.2070909@net.t-labs.tu-berlin.de>
References: <d5ff16190903292016v4316aee1y74cbb43fcf91222a@mail.gmail.com>
	<49D12D50.2030003@net.t-labs.tu-berlin.de>
	<d5ff16190903310732r4a183b68p10708f0038f4ed97@mail.gmail.com>
	<49D3D2F7.2070909@net.t-labs.tu-berlin.de>
Message-ID: <d5ff16190904012103k37826132yb908ac097bcfc073@mail.gmail.com>

Hi,

I have detailed several issues in my proposal, but I didn't submit it
yet (I?ll do it as soon as possible). Answering some questions, the
following paragraphs describe what I?m planning to do.

Talking about the first problem of gathering the statistic for all the
links, the Minstrel algorithm uses the throughput as a performance
metric. It?s necessary to know the probability of a packet success
transmission in each rate, the number of bytes transmitted, and the
necessary time to transmit this single packet in the air.

The number of bytes transmitted is straightforward to obtain just
counting the number of packets transmitted, and the necessary time to
transmit a packet in the air can be obtained by the function
YansWifiPhy::CalculateTxDuration. There are also some functions in the
interference-helper class got probability of transmission packets, but
I?m not sure if it gives the right probability we are looking for.

Many rate control algorithms try to optimize the throughput. Even if
not all of them use this metric in the decision of a rate change, I
could be a good idea to provide simple functions capable of retrieving
this information and make it available for any other optimization
solution.

About the moving average, I think that will be simple. I don?t know
yet which values the Minstrel uses as alpha in the EWMA, but the
implementation is quite simple.

In my opinion, the retry chain mechanism is the major challenge in
this project. My initial solution is to look for the function
responsible for packet retransmissions and keep track of the attempt
number of each retransmission. As this number increases, the algorithm
needs to change the rate accordingly, but I don?t know how to perform
these adjustments in the Minstrel class yet. I think it can be done in
a similar way ARF updates or decreases its rate, using functions like
ArfWifiRemoteStation::DoReportRtsFailed.

Talking about the table to store the performance values, I had already
identified the need of some efficient structure and I agree with you
that a hash table could provide a very good performance. At ach cycle,
it?s necessary to read one positions for rate in each link, and update
as many positions as the rates tested. Since links can be included and
exclude accordingly the routing algorithms, it?s necessary to avoid
reading useless positions in the table, and a hash function can help
in this situation leading to the right position with minimum effort.

About the evaluation process, the tests need to be planed and well
discussed during the project.
About implementing other rate control solutions, I didn?t include it
in my proposal with intent to avoid over-working in the short duration
of this project. Despite the fact, I?m planning to implement it anyway
(even after the program ends), because I?ll need it for my personal
research.

Regards,

--
Luciano J. Chaves
MSc Computer Science Student
University of Campinas




On Wed, Apr 1, 2009 at 17:47, Ruben Merz <ruben at net.t-labs.tu-berlin.de> wrote:
> Hi Luciano,
>
> Comments below,
>
> On 3/31/09 4:32 PM, Luciano Jerez Chaves wrote:
>>
>> Hi Ruben,
>>
>> On Mon, Mar 30, 2009 at 17:36, Ruben Merz<ruben at net.t-labs.tu-berlin.de>
>> ?wrote:
>>>
>>> Hi Luciano
>>>
>>> On 3/30/09 5:16 AM, Luciano Jerez Chaves wrote:
>>>>
>>>> Hi Ns-developers,
>>>>
>>>> My name is Luciano and I am a MSc Computer Science student at
>>>> University of Campinas, Brazil.
>>>>
>>>> I'm working with Rate Adaptation solutions to wireless networks in
>>>> my master's thesis and I'm interested in participating in Google
>>>> Summer of Code this year.
>>>>
>>>> I've been looking for an idea in ns-3 wiki page and I found a
>>>> interesting
>>>> project to implement Minstrel rate control algorithm in ns-3.
>>>>
>>>> I believe it would be very motivating and helpful to me, since I'm
>>>> evaluating my proposed algorithm based on simulations in ns-2.
>>>> I've implemented two other different rate adaptations solutions in
>>>> ns-2, using the dei802mr (develop by Nicola Baldo, and his team,
>>>> at DEI) to compare my algorithm with.
>>>
>>> Do you plan to also port these algorithms in ns-3?
>>
>> The algorithms that I implemented in ns-2 are the AARF (an extension
>> of the original ARF), CARA, and my own solution, that I didn't finish
>> yet.
>>
>> The initial idea was to port CARA and AARF to ns-3 in order to fairly
>> compare my solution with all available implementations, but I figured
>> out that the AARF is already implemented on it. Although, we still
>> have CARA, and there are other solutions in the literature that could
>> be incorporated into the ns-3 as far as possible.
>>
>>>> I think that a good implementation in ns-3 will contribute to my
>>>> project and to many other people.
>>>>
>>>> I am still not familiar with the ns-3 code, but I figured out that
>>>> there many others rate control algorithms implemented on it.
>>>> I have good knowledge in C++ programming and about rate
>>>> control in wireless networks. I'm currently studding the Minstrel
>>>> algorithm, and I think that will be possible to successfully implement
>>>> it in ns-3 during the GSoc program.
>>>
>>> The rate control algorithms are all in src/devices/wifi. You can also go
>>> in
>>> the example directory and grep for calls to SetRemoteStationManager.
>>
>> Looking in the suggested directory and in some rate control solutions
>> there, it doesn't seem very difficult to implement a new rate control
>> algorithm, since the code structure is well defined.
>
> Good to hear. But what I'd like to hear from you is a more detailed plan
> than what you describe below. Minstrel has several components. There are (1)
> gathering the statistics for all the links (2) the moving average algorithm
> (3) the retry chain algorithm and (4) the rate lookaround algorithm.
>
> How would you tackle those issues? For instance, gathering the statistics
> for all the links is something that might be of interest for the other rate
> control algorithms? So, it might be interesting to get a more general
> solution. The retry chain concept is something that is more related to the
> underlying hardware than the rate control algorithm in itself.
>
>> I believe that it's possible to implement the Minstrel algorithms in
>> something like five weeks or so.
>
> As I said above, try to come up with a more detailed plan.
>
>> Since the Minstrel solution is based solely in statistical measured
>> performance with minimum of assumptions, the coding difficulty is
>> linked to create a data structure that will be used by the algorithm
>> (a table to store values for each destiny) and to obtain, from the
>
> Typically, I'm not sure that a simple table would be the most efficient way.
> I'd rather advise a hash table or some tree structure.
>
> I think you should also look into the linux kernel code that implements
> Minstrel: http://lxr.linux.no/linux+v2.6.29/net/mac80211/rc80211_minstrel.c
>
>> simulated code, the performance metrics evaluated.
>>
>> After that, with the experience obtained with ns-3 programming, the
>> code style, simulator structure and many other things, it will be
>> possible to introduce other solutions.
>
> Let's see. Before moving to other solutions, I'd like to see some validation
> and testing done. I don't know yet how, but this should be planned.
>
> Once it's sure that the code performs reasonably well, I'll be happy to see
> some other rate control algorithm implemented.
>
>>>> I would like a feedback about these project, and any suggestion
>>>> that may arise. I would be happy with a mentor' contact.
>>>
>>> Let me know if you have questions.
>>
>> I'm looking forward to hearing from you in order to improve my GSoC
>> application.
>
> Well, don't forget to submit you proposal on the gsoc website.
>
> Best
> Ruben
>
>>> Best
>>> Ruben
>>>
>>>> Best regards,
>>>>
>>>> --
>>>> Luciano J. Chaves
>>>> MSc Computer Science Student
>>>> University of Campinas
>>>
>>> --
>>> Ruben Merz ? ? ? ? ? ? ? ? ? Deutsche Telekom Laboratories
>>> http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml
>>>
>>
>> Regards
>>
>> --
>> Luciano J. Chaves
>> MSc Computer Science Student
>> University of Campinas
>


From mathieu.lacage at sophia.inria.fr  Wed Apr  1 23:59:05 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 02 Apr 2009 08:59:05 +0200
Subject: [Ns-developers] setting available system memory on a node?
In-Reply-To: <20090401192542.GC10077@Chamillionaire.breakpoint.cc>
References: <20090401192542.GC10077@Chamillionaire.breakpoint.cc>
Message-ID: <1238655545.23784.9.camel@diese.inria.fr>

On Wed, 2009-04-01 at 21:25 +0200, Florian Westphal wrote:

> How would you like to have this exposed on the ns3 side?
> I am thinking node should have something like
> 
> .AddAttribute ("System Memory", "The amount of memory (in Ki Bytes) "
> 		"available to this stack", ...

sounds ok for me (although I have no idea what you would use this for :)

> 
> OTOH, there are no users (yet), and ns-3 itself would not be using this.
> 
> Maybe it should be put on the back burner until the long-planned (well,
> long planned by me, anyway) ns-3-nsc rework is completed (my plan
> was to introduce an "nsc node" object, which could then pass such
> an attribute on to NSC).

Why can't you add this attribute to NscTcpL4Protocol ?

Mathieu



From fw at strlen.de  Thu Apr  2 00:51:03 2009
From: fw at strlen.de (Florian Westphal)
Date: Thu, 2 Apr 2009 09:51:03 +0200
Subject: [Ns-developers] setting available system memory on a node?
In-Reply-To: <1238655545.23784.9.camel@diese.inria.fr>
References: <20090401192542.GC10077@Chamillionaire.breakpoint.cc>
	<1238655545.23784.9.camel@diese.inria.fr>
Message-ID: <20090402075103.GD10077@Chamillionaire.breakpoint.cc>

Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> > How would you like to have this exposed on the ns3 side?
> > I am thinking node should have something like
> > 
> > .AddAttribute ("System Memory", "The amount of memory (in Ki Bytes) "
> > 		"available to this stack", ...
> 
> sounds ok for me (although I have no idea what you would use this for :)

Linux runs on pretty much anything from mobile phones to 64k-Processor
clusters, and the stack behaviour is very different depending on the
system memory available. The NSC Linux stacks now available have about
390 MB memory available. I will probably raise this to one GB in the
2.6.29 stack port. One can already change it (sort of, for TCP anyway) via
NSCs buffer_size() method (which tweaks tcp memory sysctls), but I
believe it makes more sense to
1) have an NSC API to change the memory (so all stacks adjust
   automatically at stack init time).
2) have a way (in ns-3) to specify memory settings (e.g., if your
   simulation is about smart phones running linux, you should
   probably lower memory settings accordingly).

> > Maybe it should be put on the back burner until the long-planned (well,
> > long planned by me, anyway) ns-3-nsc rework is completed (my plan
> > was to introduce an "nsc node" object, which could then pass such
> > an attribute on to NSC).
> 
> Why can't you add this attribute to NscTcpL4Protocol ?

I could, but NSC can also run SCTP or DCCP, so i would like to
avoid making it a TCP property.

Thanks, Florian

From mathieu.lacage at sophia.inria.fr  Thu Apr  2 01:10:25 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 02 Apr 2009 10:10:25 +0200
Subject: [Ns-developers] setting available system memory on a node?
In-Reply-To: <20090402075103.GD10077@Chamillionaire.breakpoint.cc>
References: <20090401192542.GC10077@Chamillionaire.breakpoint.cc>
	<1238655545.23784.9.camel@diese.inria.fr>
	<20090402075103.GD10077@Chamillionaire.breakpoint.cc>
Message-ID: <1238659825.23784.26.camel@diese.inria.fr>

On Thu, 2009-04-02 at 09:51 +0200, Florian Westphal wrote:

> > > Maybe it should be put on the back burner until the long-planned (well,
> > > long planned by me, anyway) ns-3-nsc rework is completed (my plan
> > > was to introduce an "nsc node" object, which could then pass such
> > > an attribute on to NSC).
> > 
> > Why can't you add this attribute to NscTcpL4Protocol ?
> 
> I could, but NSC can also run SCTP or DCCP, so i would like to
> avoid making it a TCP property.

Ok, so aggregating an ns3::Nsc object to ns3::Node and an
ns3::Nsc::SystemMemory attribute should do it, right ?

Mathieu


From fw at strlen.de  Thu Apr  2 01:15:12 2009
From: fw at strlen.de (Florian Westphal)
Date: Thu, 2 Apr 2009 10:15:12 +0200
Subject: [Ns-developers] setting available system memory on a node?
In-Reply-To: <1238659825.23784.26.camel@diese.inria.fr>
References: <20090401192542.GC10077@Chamillionaire.breakpoint.cc>
	<1238655545.23784.9.camel@diese.inria.fr>
	<20090402075103.GD10077@Chamillionaire.breakpoint.cc>
	<1238659825.23784.26.camel@diese.inria.fr>
Message-ID: <20090402081512.GE10077@Chamillionaire.breakpoint.cc>

Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> > I could, but NSC can also run SCTP or DCCP, so i would like to
> > avoid making it a TCP property.
> 
> Ok, so aggregating an ns3::Nsc object to ns3::Node and an
> ns3::Nsc::SystemMemory attribute should do it, right ?

Thanks, that sounds perfect.

From paolo.pilia at telecompress.net  Thu Apr  2 03:37:35 2009
From: paolo.pilia at telecompress.net (paolo.pilia@telecompress.net)
Date: Thu, 02 Apr 2009 12:37:35 +0200
Subject: [Ns-developers] GSoC + WiPreSS
Message-ID: <20090402123735.pzrlu7qwask0gco4@webmail.telecompress.net>

Dear Ruben ,

below some details about the ideas for the class ns3::antenna.
I'm writing a Proposal on sochop database, it will be a summary of  
this discussion integrated with some addition.


Quoting Ruben Merz <ruben at net.t-labs.tu-berlin.de>:

> Dear Paolo
>
> Comments below
>
> On 3/31/09 1:50 PM, paolo.pilia at telecompress.net wrote:
>> Quoting Ruben Merz <ruben at net.t-labs.tu-berlin.de>:
>>
>>> Dear Paolo
>>>
>>> On 3/29/09 6:18 PM, paolo.pilia at telecompress.net wrote:
>>>> Dear NS3 developers,
>>>>
>>>> I want inform ns-3 developers about the new project WiPreSS ( Wireless
>>>> Prediction and Simulation Software - info on telecompress dot net).
>>>> I'm working to integrate ns-3 for simulation.
>>>
>>> Would you give us a bit more details than what is on
>>> http://telecompress.net/ ? How does really ns-3 relate to it? Which
>>> parts of ns-3 do you want to use?
>>>
>>
>> WiPreSS is a free solution for wireless network design and testing.
>> Basically it will be a really-free alternative to Radio Mobile, with
>> some additional features.
>> It calculate the radio propagation in a real scenario. Importing data
>> of terrain (altitude) from DEM repositories and combine it with
>> builds-data from shapefile.
>> Ns3 is the best candidate for testing a wireless application after the
>> design.
>> I'm working also to develop another kind of simulation based on it++
>> for custom trasmission channel ( p2p radio link) with definition of
>> modulation, coding, filter.
>>
>>>> At this moment the radio propagation tool of ns3 is so poor. I'm going
>>>> to register in socghop and present my candidature as student for GSoC on
>>>> antennas module.
>>>
>>> Could you please elaborate on how you would work on this project. What
>>> kind of antenna radiation pattern model would you implement? How would
>>> you implement it? Maybe even validate it?
>>>
>>
>> The innovation (confronting with actual ns3) in an antenna class that
>> compute the 3d pattern of antenna reading the specifications file (MSI
>
> Ok, an antenna class might be a good start. But then, where would
> integrate such a class in the current ns-3 codebase? Typically, such a
> class should interface with the propagation models. So, how would you
> do that?

The classical formula used add diversity terms of tx and rx antennas in
Friis .
It's possible to maintain that formula and use
the additional loss.

>
>> or ANT). These files are used by the antennas vendor. It make possible
>> to test a radio connection with a chosen antennas (for example select
>> a Kathrein specific model).
>> 3D pattern is result of horizontal and vertical diagram combination.
>
> Well, before a full 3D radiation pattern, I would start with a simpler
> 2D pattern. Also, the implementation of a radiation pattern implies
> that nodes must have an orientation. This is not yet supported in ns-3.
>


I assume the North on Y direction, Est on X direction.

* in 2D

+ fixed nodes:
the orientation is related to antennas , it have to be set in the
configuration of antenna with phi (orizontal angle between North and
direction of max radiation).
After configuration the radiation pattern is allocated in a vector of
360 element.
This permit to consider all nodes directed to north.

+ mobile nodes:
If the choose is to make a good simulation of real world, it is
need a correction of orientation each times the direction of moving
change. In term of mobility model is an addition of int
mobility::getdirection

For antennas class as to be implemented a setdirection method
that set the index  for the vector. antennas::getdirectivity return
the element of vector correspondent to the index.

* In 3d

+ a deltatetha (tilt - angle between horizont and
direction of max radiation) have to be setted in addition to deltaphi   
. the vector of directivity became a matrix

+ getdirection() set &deltaphi &deltatetha , in addition a get  
deltaphi() method for 2d moving.


>> I've an implementation of this class for WiPreSS.
>>
>> I'm going to add the function for elements combination in array.
>> It's simple implementable with defined elements, positions and phases.
>>
>> About propagation model I'm going to write the code.
>
> There are already propagation models in ns-3. Assuming the work on the
> antenna is done, what would you propose?
>
>> Validation is planned (Wipress is a thesis project).
>
> Could you please elaborate on this?


About antennas the validation is done using classical validated formulas.

The critical point is in the combination of vertical and horizontal radiation
pattern. That's a question of precision,  will be never perfect
considering that each antenna element has not the exact radiation pattern
declared.

However I'll confront result with scientific literature and know case.
I have to product documentation about it for thesis too.

>
>>
>> On side of propagation model I'm working to combine multi-path
>> propagation model (it++) with ray tracing.
>> Actually the realization it's related to the critical aspect of
>> processing environment.
>
> That would be very interesting but I fear this is way too much.
> Actually, this is likely another project in itself.

    ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^


Paolo

>
> Ruben
>
>> The goals are simple defined in the equation:
>> Antennas::3dpattern + environment::raytracing + channel::multipath =
>> diversity simulation
>>
>>
>>
>>
>>> Best
>>> Ruben
>>>
>>>> Regards,
>>>> Paolo Pilia






From paolo.pilia at telecompress.net  Thu Apr  2 03:49:16 2009
From: paolo.pilia at telecompress.net (paolo.pilia@telecompress.net)
Date: Thu, 02 Apr 2009 12:49:16 +0200
Subject: [Ns-developers] GSoC + WiPreSS
In-Reply-To: <20090402123735.pzrlu7qwask0gco4@webmail.telecompress.net>
References: <20090402123735.pzrlu7qwask0gco4@webmail.telecompress.net>
Message-ID: <20090402124916.o5g22wh39c488ss8@webmail.telecompress.net>

There is an error in the phrase

> The classical formula used add diversity terms of tx and rx antennas in
> Friis .
> It's possible to maintain that formula and use
> the additional loss.

change diversity with directivity

P

From securityfusion at gmail.com  Thu Apr  2 06:50:15 2009
From: securityfusion at gmail.com (Richardson Lima)
Date: Thu, 2 Apr 2009 10:50:15 -0300
Subject: [Ns-developers] AntNet Devel NsNam.org Support
Message-ID: <3a835c350904020650n709f3e9ana05ddc8e31bd7c87@mail.gmail.com>

Dear,

I'm tweaking the algorithm AntNet for Ns-2, how can I get a wiki, FTP server
and space to make the tarball and a Web site?
The www.nsnam.org could provide me?
I am thinking about porting the AntNet for the Ns-3.

[]' s
-- 
-- 
-----------------------------------------------
Richardson Lima
http://antnet.wordpress.com
http://securityfusion.sourceforge.net
(Security Fusion intrusion detection system)

Position:  Security System Administrator
Location:  Networking and Telecommuncations Research Group
Federal University of Pernambuco
Informatics Center, Brazil

P.O. Box: 7851, ZIP: 50732-970
Phone: +55-81-2126-8954 Fax:+55-81-2126-8955
Gsm Mobile: +55 81 88725173


Este e-mail ? confidencial e de uso exclusivo do destinat?rio. Seu conte?do
n?o deve ser revelado a terceiros. Caso voc? n?o seja o destinat?rio, por
favor notifique o remetente e elimine esta mensagem imediatamente. Alerto
que esta mensagem transitou por rede p?blica de comunica??o, estando,
portanto, sujeita aos riscos inerentes a essa forma de comunica??o.

This e-mail is private and confidential, and of exclusive use of the
addressee only. Its contents should not be revealed to third parties. If you
are not the intended addressee, please notify the sender and promptly delete
this message. It should be advised that this correspondence has been
transmitted through a public communication channel, being, therefore,
subject to the inherent risks of such kind of communication.

From alextud at gmail.com  Wed Apr  1 08:51:32 2009
From: alextud at gmail.com (Alexandru Tudose)
Date: Wed, 1 Apr 2009 18:51:32 +0300
Subject: [Ns-developers] GSoC: Advanced Queues
Message-ID: <878a2ed60904010851o71e2b680n22e71f2d2eb3a4a@mail.gmail.com>

Hi,

  I want to implement/port advanced queues such as fair queuing, RED
and RIO. From what I've seen in ns-3 source there are defined only two
queues:
 - first is a generic one
 - second is DroptTail queue (FIFO) which extends first queue and
implements virtual methods like DoEnqueue, DoDequeue and DoPeek.

So all queues (RED, RIO, ... ) should implements above functions plus
adding some configuration parameters specific to them.
This shouldn't be so difficult as long some of them were implemented in ns-2.

My questions are related to QoS. As far as I have seen there is
defined only one queue per link (net-device), so called transmission
queue. So my question is:
It is possible in ns-3 to give priority for some applications at
network layer based on TOS field (Type of service), port number,
source/destination address, ... ?

If answer is no, then I think that ns-3 should contain following blocks:
 - Classifier
 - Queuing
 - Scheduler

If you find that I'm wrong  or it's too early for this to be added in
ns-3 then I could resume only on advanced queues.
In the other case with your help and guidance this could be achieved
trough GSoC program. At first, there could be added a generic
framework, then we will start to add more features like in case of
Scheduler: strict priority, round-robin, .... and so on.


I'm a student in telecommunications field, final year, Romania. I have
good experience in development on Unix platform. I have taken Cisco
courses CCNA1, CCNA2 and now CCNA3.  For my diploma paper I have
designed and implemented a new protocol which can find the best/suited
path for an application. In this case application requirements are
mapped to a network profile (packet size, delay, jitter, bandwidth,
packet loss) with intention to make decisions  easier. After the path
is found packets routing is done by MPLS. This protocol is implemented
and tested in Qualnet.

Best regards,
Alexandru Tudose

From easchimidt at gmail.com  Wed Apr  1 18:04:09 2009
From: easchimidt at gmail.com (Emanuel Amaral Schimidt)
Date: Wed, 1 Apr 2009 22:04:09 -0300
Subject: [Ns-developers] GSoC '09 - Any ideas?
Message-ID: <7f4b8d4a0904011804y3502b2e4v5b486ba5b8509a29@mail.gmail.com>

Good evening,

First, I would like to introduce myselft. I'm Emanuel, from Brazil. I've
just began my master studies on computer networks (actually I'm only
watching some classes).

I'm still learning (and remembering what I learned on graduation) many of
the fundamentals of networks. So, I have no concrete ideas. I would like to
participate to help developing ns-3, but mainly to force myself on learn the
things faster and implement something you need. It could be something on
fault tolerance or routing.

I work with developing (and will be working during GSoC), but can invest
some hours/day during the 10 weeks.

Well, I know it looks quite stupid come here, with the poor english and no
ideas, but I would like to watch your ideas and learn how to do it,
implementing and giving some contribution.

Thanks :)

Emanuel

From tomh at tomh.org  Thu Apr  2 07:23:40 2009
From: tomh at tomh.org (Tom Henderson)
Date: Thu, 02 Apr 2009 07:23:40 -0700
Subject: [Ns-developers] ns-3.5 planning
Message-ID: <49D4CA6C.5060405@tomh.org>

With the release of ns-3.4 yesterday, I would like to look forward to
the next few months and solicit some discussion on how we are doing and
where we are headed.

I am excited by the enthusiastic response to our Google Summer of Code
project, both from a mentor and student perspective.  Thanks to Joe
Kopena for managing the many inquiries about GSOC applications.

Where are things headed for ns-3.5?  First, Mathieu volunteered to be
release manager for the next release, so I'd like to accept Mathieu's
offer and thank Raj for doing this work for ns-3.4. From my perspective,
I would like to focus on a few development/maintenance priorities for
ns-3.5. Craig and I are going to prioritize these issues in the next
release cycle.

1) IP refactoring. We have discussed this for a while now, and I've been
prototyping some ideas in the tomh/ns-3-ip repository. From my point of
view, we need to try to address some of these issues to allow people the
flexibility to do interesting network- and routing-level research in the
future. What has become clear is that the present prototype is becoming
too large for a single merge event, so Mathieu and I have discussed a
staged merge process. I will send out more email on this later, but this
(along with IPv6 merge) is really my main development priority for April.

2) Code contributions. Our intent all along has been to encourage and
support model development and contributions from researchers, and we can
see from the code repository that we have a lot of work in the pipeline.
I would like to improve our processes for ensuring timely reviews and
clear merge guidelines to contributors. To that end, we are going to
look at a reviewboard application for managing code reviews, and we will
try to establish a regular process among ns-3 maintainers to distribute
reviews and provide feedback. I will also try to improve guidelines for
code contributors and address the coding style questions that have come
up recently. It would be great to start to merge more of the work we are
seeing in the many repositories on our code server.

3) Validation. A primary goal of the project is to support not just new
models but validated models. Presently, we have drifted into the state
of equating regression tests with validation, and relying too heavily on
trace-based regression tests. We haven't yet exploited the new ns-3
tracing framework to write better validation tests and link them into
our regression testing framework. Again, I will have more to say on this
in a separate email, but I would like to harness the recent activity on
802.11 validation and define some best current practices and good
examples of how to contribute validation results and programs to the
ns-3 project.

The above are my priorities for the next release cycle. But, I would
also like to hear back from users and developers as to what features,
bugs, or other project issues need attention, from your perspective, to
help us set priorities and roadmaps for the rest of the year. If you
have concrete merge proposals also for ns-3.5, now is the time to
socialize them so we can build the big picture plan.

- Tom

From adrian at ieaa.org  Thu Apr  2 07:56:00 2009
From: adrian at ieaa.org (Adrian Sai-Wah TAM)
Date: Thu, 2 Apr 2009 10:56:00 -0400
Subject: [Ns-developers] GSoC: Advanced Queues
In-Reply-To: <878a2ed60904010851o71e2b680n22e71f2d2eb3a4a@mail.gmail.com>
References: <878a2ed60904010851o71e2b680n22e71f2d2eb3a4a@mail.gmail.com>
Message-ID: <f4eeff4e0904020756i140167bdt2808ddf49364769f@mail.gmail.com>

Hi Alexandru,

> My questions are related to QoS. As far as I have seen there is
> defined only one queue per link (net-device), so called transmission
> queue. So my question is:
> It is possible in ns-3 to give priority for some applications at
> network layer based on TOS field (Type of service), port number,
> source/destination address, ... ?
That depends on how you define a priority. If there is a strict
priority regardless of the time the packets arrived, you can implement
this in a priority queue (heap) instead of a FIFO queue. I did that.

> If answer is no, then I think that ns-3 should contain following blocks:
>  - Classifier
>  - Queuing
>  - Scheduler
If I understand correctly, that means you want to have multiple queues
instead of a single queue for transmission. I can tell you this is not
going to be a big piece of work. You can actually do this in a week.
(I tried)

> If you find that I'm wrong  or it's too early for this to be added in
> ns-3 then I could resume only on advanced queues.
> In the other case with your help and guidance this could be achieved
> trough GSoC program. At first, there could be added a generic
> framework, then we will start to add more features like in case of
> Scheduler: strict priority, round-robin, .... and so on.
No. I think that's useful. However, to make your code more useful, you
have to think about how to make it generic and easily configured for
fit other applications. That's the hardest part. I can give you my
code as a starting point if you want but mine is tailored specific for
a particular application.

If you want to submit to GSoC (deadline is Friday), please think about
the design and explain it in good detail in the proposal. I love your
idea.

- Adrian.

From adrian at ieaa.org  Thu Apr  2 07:58:44 2009
From: adrian at ieaa.org (Adrian Sai-Wah TAM)
Date: Thu, 2 Apr 2009 10:58:44 -0400
Subject: [Ns-developers] GSoC '09 - Any ideas?
In-Reply-To: <7f4b8d4a0904011804y3502b2e4v5b486ba5b8509a29@mail.gmail.com>
References: <7f4b8d4a0904011804y3502b2e4v5b486ba5b8509a29@mail.gmail.com>
Message-ID: <f4eeff4e0904020758p2caaaed1k99a65f643bb11503@mail.gmail.com>

I don't mind poor english given that you can express your idea well.
But the way GSoC works is to have you to submit a proposal about what
you want to do first. So if you want to rush for GSoC this year, you
better think about that.

- Adrian.

On Wed, Apr 1, 2009 at 9:04 PM, Emanuel Amaral Schimidt
<easchimidt at gmail.com> wrote:
> Good evening,
>
> First, I would like to introduce myselft. I'm Emanuel, from Brazil. I've
> just began my master studies on computer networks (actually I'm only
> watching some classes).
>
> I'm still learning (and remembering what I learned on graduation) many of
> the fundamentals of networks. So, I have no concrete ideas. I would like to
> participate to help developing ns-3, but mainly to force myself on learn the
> things faster and implement something you need. It could be something on
> fault tolerance or routing.
>
> I work with developing (and will be working during GSoC), but can invest
> some hours/day during the 10 weeks.
>
> Well, I know it looks quite stupid come here, with the poor english and no
> ideas, but I would like to watch your ideas and learn how to do it,
> implementing and giving some contribution.
>
> Thanks :)
>
> Emanuel
>

From tazaki at sfc.wide.ad.jp  Thu Apr  2 09:10:27 2009
From: tazaki at sfc.wide.ad.jp (Hajime Tazaki)
Date: Fri, 03 Apr 2009 01:10:27 +0900
Subject: [Ns-developers] About real-world application integration
In-Reply-To: <1237198269.31135.121.camel@diese.inria.fr>
References: <m2tz67w3f6.wl@sfc.wide.ad.jp>
	<1236790499.658.31.camel@mathieu-laptop>
	<1237193331.31135.36.camel@diese.inria.fr>
	<m27i2pwzxf.wl@sfc.wide.ad.jp>
	<1237198269.31135.121.camel@diese.inria.fr>
Message-ID: <m2tz57qbnw.wl@sfc.wide.ad.jp>


Hi Mathieu,

Now I try to make repo as you suggested,

>  - create a mercurial repo with only the patches you want to send me
>and I will pull from this repo, review, and push in mathieu/ns-3-simu


I added the modification in src/process-manager from my repo
(http://www.sfc.wide.ad.jp/~tazaki/hg/ns-3-simu_zebra_ipv6/),
but I include something from other directories,

 M src/node/node.cc
 M src/node/socket.cc
 M src/node/socket.h

and some blocks is covered with 
 #ifdef SIMU_NETLINK_IPV6
because it's heavily depend on ipv6 codes and netlink code.


For example,

src/process-manager/unix-socket-fd.cc

includes the following modification.

Address
UnixSocketFd::PosixAddressToNs3Address (const struct sockaddr *my_addr, socklen_t addrlen) const

 :
  else if (my_addr->sa_family == AF_NETLINK )
    {
      const struct sockaddr_nl *addr = (const struct sockaddr_nl *)my_addr;
      //user space netlink socket has a nozero process id
      uint32_t pid = addr->nl_pid ? addr->nl_pid : getpid();
      NetlinkSocketAddress nladdress = NetlinkSocketAddress(pid, addr->nl_groups);
      return nladdress;
    }
  else if (my_addr->sa_family == AF_INET6)
    {
      const struct sockaddr_in6 *addr = (const struct sockaddr_in6 *)my_addr;
      Ipv6Address ipv6;
      ipv6.Set ((uint8_t *)addr->sin6_addr.s6_addr);
      uint16_t port = ntohs (addr->sin6_port);
      Inet6SocketAddress inet = Inet6SocketAddress (ipv6, port);
      return inet;
    }


NetlinkSocketAddress is in netlink-socket.cc, but this time,
I didn't include this netlink stuff into this repo. 

Do you think it's better to include src/node/netlink-* into
ns-3-simu?


You can find all of my modification with a little comments at

http://www.sfc.wide.ad.jp/~tazaki/hg/ns-3-simu-mod/


#This is the first step, see you soon.

regards,
hajime


From tjkopena at cs.drexel.edu  Thu Apr  2 09:25:53 2009
From: tjkopena at cs.drexel.edu (Joseph Kopena)
Date: Thu, 2 Apr 2009 12:25:53 -0400
Subject: [Ns-developers] GSoC Reminders
Message-ID: <13786f330904020925r7b267f21t6e8a7fdc62ee987f@mail.gmail.com>

Hi everyone,

Just a reminder that GSoC proposals are due tomorrow (Friday), April
3, 12 noon PDT/19:00 UTC.  We encourage everyone to file their
proposal as soon as possible.  You may continue to modify it up until
the deadline, and it is definitely safer to get it in there and revise
rather than potentially face a problem at the last minute.  As a
bonus, proposals submitted before the deadline get early feedback from
mentors and are able to address any issues before the final cutoff.


Also, three key points again on what we're looking for:

- Reasonably detailed technical approach.  Key here is demonstrating
  some familiarity with ns-3, having looked into it enough to figure
  out what components and connections you will have to work with to
  implement your project.  For some topics you should also point to
  literature and/or existing implementations that you may draw from.
  Note that the exact approach may not be exactly what you wind up
  implementing.  The first part of every project will be discussing in
  much further detail with the mentors exactly how to accomplish the
  project's goals.  It's also worth noting that some of the mentors
  have posted reasonably tough technical questions to some of the
  proposals.  In most cases this is actually a good sign, it means
  there was enough content in the proposal to have a solid discussion.
  We also expect those discussions to continue and form the bulk of
  the early phases of each project.

- Feasible, reasonably detailed workplan.  A plan along the lines of
  "2 weeks reading, 2 months coding" is not actually a plan.  Good
  proposals will include a workplan that breaks down the overall
  project into a series of smaller subgoals associated with components
  or features.  That makes it much easier to estimate time required,
  assess realistic feasibility, track progress, and hit the summer
  with a ready plan.  Note that this schedule is not necessarily
  exactly what you'll be held to---accepted students will discuss this
  further with their mentor once the project begins---but we're
  looking for proposals where some time has been spent on planning,
  and for students capable and organized enough to do this sort of
  self-directed project management.

- Full time commitment.  GSoC is intended for students available full
  time (40 hours/week) throughout the duration of the program.  With
  so many good applicants there is no reason in any case to take on
  students not able to commit as much time to the project.  We would
  love for all interested parties to become involved in using and
  contributing to ns-3, but the GSoC program is only for those
  committing to it just like any other full time position.


The applications received so far have been generally pretty solid, so
keep them coming.  I'd also like to really thank our mentors for
already putting so much time and energy in reviewing the proposals and
providing feedback to the applicants!

Thx

-- 
- joe kopena
right here and now

From gjcarneiro at gmail.com  Thu Apr  2 10:31:18 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Thu, 2 Apr 2009 18:31:18 +0100
Subject: [Ns-developers] precompiled headers for python bindings
Message-ID: <a467ca4f0904021031p5fdc4589wddc1e19dd7c79225@mail.gmail.com>

Here's a patch to add an option ./waf configure --enable-python-pch.  This
activates gcc precompiled headers when compiling the ns-3 python bindings.

The compilation speedup (for the python bindings part alone) seems to be
only around 30%.  I was a bit disappointed, and am not sure whether it is
worth committing this patch.  Anyway, for future web archeologists, here it
is.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ns3-python-pch.diff
Type: text/x-patch
Size: 4213 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090402/7fb83f34/ns3-python-pch.bin

From palucci at smar.com.br  Thu Apr  2 07:19:47 2009
From: palucci at smar.com.br (Rodrigo Palucci Pantoni)
Date: Thu, 2 Apr 2009 11:19:47 -0300
Subject: [Ns-developers] IEEE 802.15.4 GTS on NS2 model
Message-ID: <CCC2AD909099443B8F82930F882F461A@rodrigopalucci>

Hello all,
    I plan to evaluate IEEE 802.15.4 GTS on current 802.15.4 model but it seems 
that this part of the standard is not currently supported. Is there 
someone who has developed a GTS support in NS ? There is a plan to include this part on the next release of the simulator?

Thanks in advance.

From tomh at tomh.org  Fri Apr  3 11:04:46 2009
From: tomh at tomh.org (Tom Henderson)
Date: Fri, 03 Apr 2009 11:04:46 -0700
Subject: [Ns-developers] tag rework for next release
In-Reply-To: <1237840347.5907.60.camel@mathieu-laptop>
References: <1237840347.5907.60.camel@mathieu-laptop>
Message-ID: <49D64FBE.9010105@tomh.org>

Mathieu Lacage wrote:
> hi,
> 
> code: http://code.nsnam.org/mathieu/ns-3-tags
> 
> As a preparation for the ipv4 rework for next release, I finally spent
> some time to try to deal with some of the issues around the tag API:
> there are now two types of tags for each packet: 'packet' tags vs 'byte'
> tags. Their semantics are slightly different to try to solve two
> different use-cases:
> 
> 1) byte tags could be typically used for flow ids: they will be
> preserved across packet fragmentation and aggregation. byte tags can be
> added to a packet but they can't be removed piecemeal: you have to
> remove them all all at once or not at all.
> 
> 2) packet tags will typically be used for cross-layer interactions (they
> are presently used, for example, to convey the ipv4 ttl from the udp
> layer to the ipv4 layer). They could be used to convey qos tids from
> applications to a wifi layer. They can be removed one by one. The
> implementation is optimized to be really efficient when the tag removed
> is the last tag added (just like a stack).

Mathieu,

One thing that I noticed is that packet tags are left out of the 
Packet::Serialize() process (while byte tags are included).  This is a 
bit subtle, but it basically means that packets that are sent to another 
node via an ns-3 channel will retain packet tags but if that ns-3 
channel happens to utilize a real IP tunnel (in a distributed simulation 
use case) the packet tags will be stripped.

It seems like we ought to support packet tags in Serialize, but is there 
a reason why not?

We ought to document somewhere the interaction between application-level 
tags and NSC, while this is not yet fixed for NSC.

samples/main-packet-tag.cc could be enhanced with a byte example and 
more commenting.  I would volunteer to contribute this patch if you want.

Also, in udp-echo-server.cc:

            NS_LOG_INFO ("Received " << packet->GetSize() << " bytes 
from " <<
              address.GetIpv4());

-          packet->RemoveAllTags ();
+          packet->RemoveAllPacketTags ();

            NS_LOG_LOGIC ("Echoing packet");
            socket->SendTo (packet, 0, from);


Why not remove all byte tags also?  Conceptually, this is a new packet 
that is being echoed; i.e., it should behave the same as if the packet 
were freed and a new one generated.

CHANGES.html needs some words upon merge.

Other than that, I support the overall concept/approach and would like 
to support merging this once the above discussion plays out.

Tom


From mathieu.lacage at sophia.inria.fr  Fri Apr  3 11:14:58 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 03 Apr 2009 20:14:58 +0200
Subject: [Ns-developers] tag rework for next release
In-Reply-To: <49D64FBE.9010105@tomh.org>
References: <1237840347.5907.60.camel@mathieu-laptop>
	<49D64FBE.9010105@tomh.org>
Message-ID: <1238782498.31308.8.camel@mathieu-laptop>

On Fri, 2009-04-03 at 11:04 -0700, Tom Henderson wrote:

> One thing that I noticed is that packet tags are left out of the 
> Packet::Serialize() process (while byte tags are included).  This is a 
> bit subtle, but it basically means that packets that are sent to another 
> node via an ns-3 channel will retain packet tags but if that ns-3 
> channel happens to utilize a real IP tunnel (in a distributed simulation 
> use case) the packet tags will be stripped.
> 
> It seems like we ought to support packet tags in Serialize, but is there 
> a reason why not?

Lazyness: I can fix this late next week but feel free to beat me to it.

> We ought to document somewhere the interaction between application-level 
> tags and NSC, while this is not yet fixed for NSC.

I doubt it will ever be really fixed in nsc.

> samples/main-packet-tag.cc could be enhanced with a byte example and 
> more commenting.  I would volunteer to contribute this patch if you want.

please, do.

> 
> Also, in udp-echo-server.cc:
> 
>             NS_LOG_INFO ("Received " << packet->GetSize() << " bytes 
> from " <<
>               address.GetIpv4());
> 
> -          packet->RemoveAllTags ();
> +          packet->RemoveAllPacketTags ();
> 
>             NS_LOG_LOGIC ("Echoing packet");
>             socket->SendTo (packet, 0, from);
> 
> 
> Why not remove all byte tags also?  Conceptually, this is a new packet 
> that is being echoed; i.e., it should behave the same as if the packet 
> were freed and a new one generated.

Yes, this makes sense.

> CHANGES.html needs some words upon merge.

yes.


From tomh at tomh.org  Fri Apr  3 12:41:06 2009
From: tomh at tomh.org (Tom Henderson)
Date: Fri, 03 Apr 2009 12:41:06 -0700
Subject: [Ns-developers] olsr rework
In-Reply-To: <1237817555.23686.33.camel@diese.inria.fr>
References: <1237817555.23686.33.camel@diese.inria.fr>
Message-ID: <49D66652.1020500@tomh.org>

Mathieu Lacage wrote:
> hi,
> 
> As a preparation for the ipv4 rework for next release, I did a first set
> of changes to olsr to move the call to Ipv4::AddRoutingProtocol from the
> olsr-agent-impl.cc file to olsr-helper.cc. What has changed:
> 
> 1) removed olsr::Agent
> 2) renamed olsr::AgentImpl to olsr::RoutingProtocol
> 3) made olsr::RoutingProtocol derive from Ipv4RoutingProtocol instead of
> olsr::Agent
> 

Mathieu,
I reviewed this and support merging it.

One minor nit that we may want to pick up at some point is the magic 
number in the helper (Olsr is hardcoded priority 10):

+  ipv4->AddRoutingProtocol (agent, 10);

which is consistent with the current behavior (which is also a magic 
number deeper in the code), but I think we can consider this small point 
again once we look at the final reviews for the IP routing rework.

Tom


From lentracy at u.washington.edu  Fri Apr  3 14:37:12 2009
From: lentracy at u.washington.edu (Leonard Tracy)
Date: Fri, 3 Apr 2009 14:37:12 -0700
Subject: [Ns-developers] Underwater acoustic module for NS-3
In-Reply-To: <6c14d5550903221355t755ea845ncdbdb9e9c26ab299@mail.gmail.com>
References: <6c14d5550810131948x6272d17ap11af76cc9074733@mail.gmail.com>
	<1225180259.715.126.camel@localhost.localdomain>
	<6c14d5550903220117v54a259c0u2a83578bfad1ffcc@mail.gmail.com>
	<1237739881.6923.7.camel@mathieu-laptop>
	<6c14d5550903221355t755ea845ncdbdb9e9c26ab299@mail.gmail.com>
Message-ID: <6c14d5550904031437v33914b15j1f12f426cb6dee72@mail.gmail.com>

Hi Everybody (again),

I've done some more work on the NS3 Underwater Acoustic Networking model I'd
like to submit for design review.  My basic goal has been to develop a model
suitable for the simulation of Layer 2 and Layer 3 protocols in underwater
networks.  As modeling of the underwater acoustic channel is complex, I've
attempted to provide support for variety of propagation models as well as a
PHY model that can be tailored to represent a variety of modulations.  I'd
appreciate input on the design and implementation.  The repository has been
moved to:  http://code.nsnam.org/ltracy/ns-3-dev-uan

A couple of known open issues:  1. I plan on reworking UanPropModelBh
(possibly to store information in a SQL DB).  2.  I'm guessing that
UanTxMode can likely be combined with WifiMode.

Leonard Tracy



On Sun, Mar 22, 2009 at 1:55 PM, Leonard Tracy <lentracy at u.washington.edu>wrote:

>
> Hi Everybody,
>
> I've been working on an NS3 model for simulation of wireless underwater
> acoustic network simulation.  My ultimate goal is to develop a general
> framework that can be used to model a variety of different underwaterscenarios (e.g. research new MAC layers with various underlying PHY/channel
> models).  To this end, I've followed the design model of the wifi module
> included in current NS3 releases (with some pointers from Mathieu) with some
> modifications to account for the difference in intended purpose.
>
> Although this work is still ongoing, I'd like to submit my progress thus
> far for design review.  I still have several tasks on my todo list including
> a doxygen writeup of the model, and improving the commenting of several
> recently added classes.  I also plan on simplifying the implementation of
> the Bellhop propagation model (UanPropModelBh) as I more or less copied this
> from some previous ns2 work I did, and I plan to implement a PER model which
> makes use of the detailed propagation information for the WHOI micromodem.
>
> Comments on the code and/or the model design would be greatly appreciated.
>
> The code repository is available at http://freehg.org/u/ltracy/ns3-uan
>
> Thanks,
> Leonard Tracy
>
>
>

From tomh at tomh.org  Fri Apr  3 16:28:10 2009
From: tomh at tomh.org (Tom Henderson)
Date: Fri, 03 Apr 2009 16:28:10 -0700
Subject: [Ns-developers] Underwater acoustic module for NS-3
In-Reply-To: <6c14d5550904031437v33914b15j1f12f426cb6dee72@mail.gmail.com>
References: <6c14d5550810131948x6272d17ap11af76cc9074733@mail.gmail.com>	<1225180259.715.126.camel@localhost.localdomain>	<6c14d5550903220117v54a259c0u2a83578bfad1ffcc@mail.gmail.com>	<1237739881.6923.7.camel@mathieu-laptop>	<6c14d5550903221355t755ea845ncdbdb9e9c26ab299@mail.gmail.com>
	<6c14d5550904031437v33914b15j1f12f426cb6dee72@mail.gmail.com>
Message-ID: <49D69B8A.7070503@tomh.org>

Leonard Tracy wrote:
> Hi Everybody (again),
> 
> I've done some more work on the NS3 Underwater Acoustic Networking model I'd
> like to submit for design review.  My basic goal has been to develop a model
> suitable for the simulation of Layer 2 and Layer 3 protocols in underwater
> networks.  As modeling of the underwater acoustic channel is complex, I've
> attempted to provide support for variety of propagation models as well as a
> PHY model that can be tailored to represent a variety of modulations.  I'd
> appreciate input on the design and implementation.  The repository has been
> moved to:  http://code.nsnam.org/ltracy/ns-3-dev-uan
> 
> A couple of known open issues:  1. I plan on reworking UanPropModelBh
> (possibly to store information in a SQL DB).  2.  I'm guessing that
> UanTxMode can likely be combined with WifiMode.
> 
> Leonard Tracy
> 

Hi Leonard,
Craig agreed to give you a review of this shortly.

- Tom

From ichrak.amdouni at gmail.com  Mon Apr  6 10:34:58 2009
From: ichrak.amdouni at gmail.com (ichrak amdouni)
Date: Mon, 6 Apr 2009 19:34:58 +0200
Subject: [Ns-developers] transmission range in wifi network
Message-ID: <1c96436a0904061034q2fafd716u7fff25c7c9cb3472@mail.gmail.com>

Hi all,

I need to fix the transmission range for access points and mobile stations
in an infrastructure wifi network.
I mean, how to manage to let communication restricted to a given distance?
I know that in the ns3.3 version, this parameter is not explicitly set, but
affected by others like the TxPower and the channel loss model, but
actually, I experimented multiple matching between those parameters but I
have always stange results (a sta can affiliate with an APdistant of
thousands of meters!!).

Having distinct results from those of the wifi-phy-test.cc example, I wonder
if this issue has a relation with other layers other than the Physical one?
I find the hypothesis very stange but I really reproduced the same scenario
as in wifi-phy-test.cc.
May I missing something?

  - Did someone experiment this issue especially in high mobiliy network? or
have an idea to deal with it differently?
  - Is the transmission range explicitly set in ns 3.4? If  yes, which files
were modified?

Any answer would be very appreciated.

Best regard.
Ichrak.

From timo.bingmann at student.kit.edu  Wed Apr  8 02:18:53 2009
From: timo.bingmann at student.kit.edu (Timo Bingmann)
Date: Wed, 8 Apr 2009 11:18:53 +0200
Subject: [Ns-developers] Merge of NakagamiPropagationLossModel
Message-ID: <200904081118.53662.timo.bingmann@student.kit.edu>

Hello guys,
with ns-3.4 out of the door, I believe it is the right time for some new patches. Thus I'm requesting permission to apply following changes:

Two new RandomVariables: GammaVariable and ErlangVariable
http://www.nsnam.org/bugzilla/show_bug.cgi?id=475

NakagamiPropagationLossModel to wifi (not in bugzilla), but in my wifiex repository.
http://code.nsnam.org/timob/ns-3-wifiex/

NonUnicast bug as mentioned on ns-3-users
http://www.nsnam.org/bugzilla/show_bug.cgi?id=531

I just rechecked the first two issues and am positive the code is ok. The third is trivial.

Greetings
Timo

From saba717671 at hotmail.com  Tue Apr  7 15:53:08 2009
From: saba717671 at hotmail.com (anas)
Date: Wed, 8 Apr 2009 01:53:08 +0300
Subject: [Ns-developers] big delay in MAC-802_11 in NS2.33
Message-ID: <BLU104-DS3A527CA7BA712294CAF4DDF850@phx.gbl>

Dear all,

I have encountered a large delay end to end delay
and when I checked the out put file I see some of the packets have a very 
large delay at MAC layer as shown below:

f 202.663960039 _25_ RTR  --- 585 cbr 576 [13a 2b 19 800] ------- [9:1 10:1 25 30] [17] 7 2
s 358.840523771 _25_ MAC  --- 585 cbr 634 [13a 1e 19 800] ------- [9:1 10:1 25 30] [17] 7 2

as it appears there is about 150 second at MAC layer!!!!

what is the bug here
I used NS2.33 under both Linux and sygwin all of them have the same bug

please help me
best regards
Anas 

From tomh at tomh.org  Wed Apr  8 12:27:12 2009
From: tomh at tomh.org (Tom Henderson)
Date: Wed, 08 Apr 2009 19:27:12 +0000
Subject: [Ns-developers] Merge of NakagamiPropagationLossModel
Message-ID: <W1869518715191181239218832@mail.mailsnare.net>

Hi Timo,
I'd support merging these when you get a +1 from the relevant maintainers (Michele on the first one, Mathieu on the second one), and would suggest to go ahead with the third one.

Thanks,
Tom

>-----Original Message-----
>From: Timo Bingmann [mailto:timo.bingmann at student.kit.edu]
>Sent: Wednesday, April 8, 2009 01:18 AM
>To: ns-developers at ISI.EDU
>Subject: [Ns-developers] Merge of NakagamiPropagationLossModel
>
>Hello guys,
>with ns-3.4 out of the door, I believe it is the right time for some new patches. Thus I'm requesting permission to apply following changes:
>
>Two new RandomVariables: GammaVariable and ErlangVariable
>http://www.nsnam.org/bugzilla/show_bug.cgi?id=475
>
>NakagamiPropagationLossModel to wifi (not in bugzilla), but in my wifiex repository.
>http://code.nsnam.org/timob/ns-3-wifiex/
>
>NonUnicast bug as mentioned on ns-3-users
>http://www.nsnam.org/bugzilla/show_bug.cgi?id=531
>
>I just rechecked the first two issues and am positive the code is ok. The third is trivial.
>
>Greetings
>Timo
>



From tomh at tomh.org  Wed Apr  8 21:40:29 2009
From: tomh at tomh.org (Tom Henderson)
Date: Wed, 08 Apr 2009 21:40:29 -0700
Subject: [Ns-developers] big delay in MAC-802_11 in NS2.33
In-Reply-To: <BLU104-DS3A527CA7BA712294CAF4DDF850@phx.gbl>
References: <BLU104-DS3A527CA7BA712294CAF4DDF850@phx.gbl>
Message-ID: <49DD7C3D.7030001@tomh.org>

anas wrote:
> Dear all,
> 
> I have encountered a large delay end to end delay
> and when I checked the out put file I see some of the packets have a very 
> large delay at MAC layer as shown below:
> 
> f 202.663960039 _25_ RTR  --- 585 cbr 576 [13a 2b 19 800] ------- [9:1 10:1 25 30] [17] 7 2
> s 358.840523771 _25_ MAC  --- 585 cbr 634 [13a 1e 19 800] ------- [9:1 10:1 25 30] [17] 7 2
> 
> as it appears there is about 150 second at MAC layer!!!!
> 
> what is the bug here
> I used NS2.33 under both Linux and sygwin all of them have the same bug
> 
> please help me
> best regards
> Anas 

Can you please send a test script to reproduce it, or post one in the 
ns-2 tracker [*], so someone can take a look?

- Tom

[*] http://sourceforge.net/tracker/?group_id=149743&atid=775392

From tomh at tomh.org  Wed Apr  8 22:40:35 2009
From: tomh at tomh.org (Tom Henderson)
Date: Wed, 08 Apr 2009 22:40:35 -0700
Subject: [Ns-developers] validation plans
In-Reply-To: <49D4CA6C.5060405@tomh.org>
References: <49D4CA6C.5060405@tomh.org>
Message-ID: <49DD8A53.60904@tomh.org>


> 
> 3) Validation. A primary goal of the project is to support not just new
> models but validated models. Presently, we have drifted into the state
> of equating regression tests with validation, and relying too heavily on
> trace-based regression tests. We haven't yet exploited the new ns-3
> tracing framework to write better validation tests and link them into
> our regression testing framework. Again, I will have more to say on this
> in a separate email, but I would like to harness the recent activity on
> 802.11 validation and define some best current practices and good
> examples of how to contribute validation results and programs to the
> ns-3 project.
> 

Craig has started to put together a framework for improved validation 
and model verification.  People interested in this topic can review and 
comment on what he has written so far at:
http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting

What I have in mind is that we try to separate better the example or 
sample scripts, regression tests, and validation or verification 
scripts.  Validation or verification tests should be designed to 
explicitly test for specific behavior.  A few possible examples to start 
with are our TCP model, 802.11 PHY models, and random variables.  But 
rather than just dump and archive trace files, it would be better to 
instrument the tests to explicitly test whether an expected event (e.g. 
a TCP timeout) occurred due to some stimulus.  Selected validation tests 
and all unit tests could be run through a regression testing framework 
(what we have now), where the objective would be to cover as much of our 
code as possible.  Example programs would be programs that show how 
users might want to build simulation scenarios.  It may be that some of 
our examples are also used in regression testing if other scripts to 
achieve the desired code coverage are not available, but we would try to 
be more rigorous in the future about separating these types of scripts.

- Tom


From mathieu.lacage at sophia.inria.fr  Thu Apr  9 02:49:56 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 09 Apr 2009 11:49:56 +0200
Subject: [Ns-developers] Merge of NakagamiPropagationLossModel
In-Reply-To: <W1869518715191181239218832@mail.mailsnare.net>
References: <W1869518715191181239218832@mail.mailsnare.net>
Message-ID: <1239270596.27929.1.camel@diese.inria.fr>

On Wed, 2009-04-08 at 19:27 +0000, Tom Henderson wrote:
> Hi Timo,
> I'd support merging these when you get a +1 from the relevant
> maintainers (Michele on the first one, Mathieu on the second one), and
> would suggest to go ahead with the third one.

+1 from me: I was waiting for the rng changes to go in first.

Mathieu



From mathieu.lacage at sophia.inria.fr  Thu Apr  9 02:55:14 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 09 Apr 2009 11:55:14 +0200
Subject: [Ns-developers] transmission range in wifi network
In-Reply-To: <1c96436a0904061034q2fafd716u7fff25c7c9cb3472@mail.gmail.com>
References: <1c96436a0904061034q2fafd716u7fff25c7c9cb3472@mail.gmail.com>
Message-ID: <1239270914.27929.4.camel@diese.inria.fr>

On Mon, 2009-04-06 at 19:34 +0200, ichrak amdouni wrote:
> Hi all,
> 
> I need to fix the transmission range for access points and mobile stations
> in an infrastructure wifi network.
> I mean, how to manage to let communication restricted to a given distance?
> I know that in the ns3.3 version, this parameter is not explicitly set, but
> affected by others like the TxPower and the channel loss model, but
> actually, I experimented multiple matching between those parameters but I
> have always stange results (a sta can affiliate with an APdistant of
> thousands of meters!!).

I doubt that is the case with the default values of all parameters.
Maybe you changed some parameters ?

> Having distinct results from those of the wifi-phy-test.cc example, I wonder
> if this issue has a relation with other layers other than the Physical one?

No, it's all a PHY layer thing.

> I find the hypothesis very stange but I really reproduced the same scenario
> as in wifi-phy-test.cc.

What kind of scenario ? Could you be more explicit about what you, what
you get, and what you expect from wifi-phy-test ?

> May I missing something?
> 
>   - Did someone experiment this issue especially in high mobiliy network? or
> have an idea to deal with it differently?
>   - Is the transmission range explicitly set in ns 3.4? If  yes, which files
> were modified?

No, ns-3.4 has no support for this. A patch to add a range-based PHY
model would be welcome.

Mathieu



From kirillano at yandex.ru  Thu Apr  9 03:13:03 2009
From: kirillano at yandex.ru (kirillano)
Date: Thu, 09 Apr 2009 14:13:03 +0400
Subject: [Ns-developers] 802.11s code review
Message-ID: <171201239271983@webmail34.yandex.ru>

Hi, All!
5 weeks ago I have published our code of 802.11s draft standart:
(http://forge.wenos.ru/hgprojects/ns3dev/).
The information about architectural structure you can see here:
(http://www.nsnam.org/wiki/index.php/Mesh)
Now the implementation of 802.11s seems reached the next milestone.

In comparsion with the first version of 802.11s in NS-3 we have changed the following:

1. We have moved all our project to src/devices/mesh and put all files related with 'pure dot11s' to dot11s namespace
2. We have renamed some classes (like "L2RoutingNetDevice" now is "MeshPointDevice")
3. We have standartized interface between MAC-layer and parts of protocols (like peer management, HWMP routing) - MeshWifiInterfaceMac class and MeshWifiInterfaceMacPlugin
4. We have standarized WifiInformationElement (but did not change existing information elements of wifi), and all dot11s information elements are inherited from this base class
5. We have tested multi-interface mesh-points (extension of dot11s) and checked, that in case of single-interface it works exactly like 'pure dot11s'.
6. To test multi-interface scenario, we have added channel switching to wifi-channel (implementation of channel switching is litte bit raw, but in static frequency pattern of network it works properly)
7. In our implementation we use PacketTags, which is not included in the main ns-3-dev repository.
Changes were taken from http://code.nsnam.org/mathieu/ns-3-tags

Could you please make a review of our code and make your opinion about it?

At this moment I have NOT IMPLEMENTED the following:
1. Airtime link metric does not take into account packet error rate, because I have no idea how to access retry counters (TracedValue<uint16_t> m_slrc) in WifiRemoteStation class. This retry counter is needed to estimate the average value of packet error rate. So, could you please give some examples of using TracedValue, because, as I think, tutorial and doxygen has unsufficient information.

Regards, Kirill.

From mk.banchi at gmail.com  Thu Apr  9 05:45:10 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Thu, 09 Apr 2009 14:45:10 +0200
Subject: [Ns-developers] Initial 802.11n support for ns-3.5
Message-ID: <49DDEDD6.3070802@gmail.com>

Hi all,

I'd like to receive some feedbacks about my code

http://code.nsnam.org/mirko/ns-3-80211n

and i'd like to merge for ns-3.5.
In particular repository contains new WifiHelpers also for Qos stas,
Edca support and frame aggregation at MSDU level (next step MPDU
aggregation).

Currently i'm working on block ack but i don't think that code will be
ready and reviewed for next release. However in a short time i'll
publish it.

Thank you all,

Mirko

-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090409/56f83259/smime.bin

From ichrak.amdouni at gmail.com  Thu Apr  9 06:59:45 2009
From: ichrak.amdouni at gmail.com (ichrak amdouni)
Date: Thu, 9 Apr 2009 15:59:45 +0200
Subject: [Ns-developers] transmission range in wifi network
In-Reply-To: <1239270914.27929.4.camel@diese.inria.fr>
References: <1c96436a0904061034q2fafd716u7fff25c7c9cb3472@mail.gmail.com>
	<1239270914.27929.4.camel@diese.inria.fr>
Message-ID: <1c96436a0904090659u24992f51u2b0b26b3a82e4f2d@mail.gmail.com>

Hi all,
Thank you Mathieu.

* *
2009/4/9 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> On Mon, 2009-04-06 at 19:34 +0200, ichrak amdouni wrote:
> > Hi all,
> >
> > I need to fix the transmission range for access points and mobile
> stations
> > in an infrastructure wifi network.
> > I mean, how to manage to let communication restricted to a given
> distance?
> > I know that in the ns3.3 version, this parameter is not explicitly set,
> but
> > affected by others like the TxPower and the channel loss model, but
> > actually, I experimented multiple matching between those parameters but I
> > have always stange results (a sta can affiliate with an APdistant of
> > thousands of meters!!).
>
> I doubt that is the case with the default values of all parameters.
> Maybe you changed some parameters ?
>

 Yes, it is the case,  the mac association succeed between an access point
and one mobile station  distant of 3000m,  connectivity is however not
maintained. Note that my nodes simulates vehicles running at 50km/h.

>
> > Having distinct results from those of the wifi-phy-test.cc example, I
> wonder
> > if this issue has a relation with other layers other than the Physical
> one?
>
> No, it's all a PHY layer thing.
>
> > I find the hypothesis very stange but I really reproduced the same
> scenario
> > as in wifi-phy-test.cc.
>
> What kind of scenario ? Could you be more explicit about what you, what
> you get, and what you expect from wifi-phy-test ?


I am expecting to  have nodes that can't "see" each other beyond the
theoretical coverage area.
For example I used the following setting:

  *channel.AddPropagationLoss("ns3::LogDistancePropagationLossModel","Exponent",
DoubleValue(1.70));

  channel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel");
  Ptr<YansWifiChannel> chan = channel.Create ();
 **  wifiPhy.SetChannel (chan);*
*  wifiPhy.SetErrorRateModel ("ns3::ErrorRateModel");

  wifiPhy.Set ("TxPowerStart",DoubleValue(5));
  wifiPhy.Set ("TxPowerEnd",DoubleValue(5));
  wifiPhy.Set ("TxPowerLevels",UintegerValue (1));
  wifiPhy.Set ("TxGain",DoubleValue (2));
  wifiPhy.Set ("RxGain",DoubleValue (2));

*This make connection impossible beyond 250m, but the problem now is that
packet transfert failure is important due to  the condition:*
(m_random.GetValue () < snrPer.per** ) *at the physical layer when sending
probe responses.*

*

>
>
> > May I missing something?
> >
> >   - Did someone experiment this issue especially in high mobiliy network?
> or
> > have an idea to deal with it differently?
> >   - Is the transmission range explicitly set in ns 3.4? If  yes, which
> files
> > were modified?
>
> No, ns-3.4 has no support for this. A patch to add a range-based PHY
> model would be welcome.
>
> Mathieu
>
>
> Best Regards.
Ichrak.

From dave at antacs.com  Wed Apr  8 15:56:00 2009
From: dave at antacs.com (David Ross)
Date: Thu, 09 Apr 2009 08:56:00 +1000
Subject: [Ns-developers] big delay in MAC-802_11 in NS2.33
In-Reply-To: <BLU104-DS3A527CA7BA712294CAF4DDF850@phx.gbl>
References: <BLU104-DS3A527CA7BA712294CAF4DDF850@phx.gbl>
Message-ID: <49DD2B80.40201@antacs.com>

Anas, see my post to ns-users (sorry, I see you got no response in 3 
days before posting here - I only look at the lists occasionally)  The 
delay is between RTR forwarding and the MAC completing the send, which 
is unlikely to be a bug in the MAC, but more likely a large queue of 
packets waiting at this node in a network with lots of nodes in heavy 
contention.

Do you know if this is likely?

I suspect this is not a bug, so should move back to ns-users.

I'm writing-up, but will check ns-users again in a few days (sorry, very 
busy)

- David Ross.


anas wrote:
> Dear all,
>
> I have encountered a large delay end to end delay
> and when I checked the out put file I see some of the packets have a very 
> large delay at MAC layer as shown below:
>
> f 202.663960039 _25_ RTR  --- 585 cbr 576 [13a 2b 19 800] ------- [9:1 10:1 25 30] [17] 7 2
> s 358.840523771 _25_ MAC  --- 585 cbr 634 [13a 1e 19 800] ------- [9:1 10:1 25 30] [17] 7 2
>
> as it appears there is about 150 second at MAC layer!!!!
>
> what is the bug here
> I used NS2.33 under both Linux and sygwin all of them have the same bug
>
> please help me
> best regards
> Anas 
>   


From saba717671 at hotmail.com  Thu Apr  9 07:54:43 2009
From: saba717671 at hotmail.com (anas)
Date: Thu, 9 Apr 2009 17:54:43 +0300
Subject: [Ns-developers] [ns] big delay by MAC-802_11 bug
In-Reply-To: <BLU104-DS657F3FC03E789E296979FDF840@phx.gbl>
	<49DD269F.7000605@isrc.qut.edu.au>
	<BLU104-DS743A62BFB75615A0A44E6DF820@phx.gbl>
	<49DD2D7C.1010700@isrc.qut.edu.au>
References: <BLU104-DS657F3FC03E789E296979FDF840@phx.gbl>
	<49DD269F.7000605@isrc.qut.edu.au>
	<BLU104-DS743A62BFB75615A0A44E6DF820@phx.gbl>
	<49DD2D7C.1010700@isrc.qut.edu.au>
Message-ID: <BLU104-DS10F707EFD3A5B09BB003DDF830@phx.gbl>

dear David,

I have done what you have said, but I figured out that there is no packets 
in the queue
may be there is another reason
as you will see in the trace file of node 25, it works regularly and it 
received many data and control packets and forward it normally within the 
period which packet 585 is still waiting ( 202-358) I send you the trace 
file of 585 packet .

Regards

--------------------------------------------------
From: "David Ross" <David.Ross at isrc.qut.edu.au>
Sent: Thursday, April 09, 2009 2:04 AM
To: "anas" <saba717671 at hotmail.com>
Subject: Re: [ns] big delay by MAC-802_11 bug

> Anas, if you grep out all the "_25_" entries, you should be able to work 
> out how many packets it has queued at 202 seconds (all the ones the RTR 
> has sent less the ones the MAC has sent on) to see if this really is the 
> problem.
>
> Like if the MAC just sent packet 100, but the RTR just queued 585, look 
> back to see what other packet IDs are in this node and count them until 
> you get to the one the MAC just sent at 202 seconds.
>
> Hope that helps - David Ross.
>
> anas wrote:
>> thank you sooooo much David
>> so what I will try to minimize the queue length  to improve my end to end 
>> delay
>> is it right
>>
>>
>> --------------------------------------------------
>> From: "David Ross" <David.Ross at isrc.qut.edu.au>
>> Sent: Thursday, April 09, 2009 1:35 AM
>> To: "anas" <saba717671 at hotmail.com>
>> Cc: "ns" <ns-users at ISI.EDU>
>> Subject: Re: [ns] big delay by MAC-802_11 bug
>>
>>> Anas, the delay is not the MAC, it is the RTR to the MAC, which is the 
>>> IFQ.  The only time I see these delays is with lots of nodes and lots of 
>>> queued packets, say 50 queued and each takes 3 seconds to win contention 
>>> = 150 seconds for the packet to get out.
>>>
>>> - David Ross
>>> QUT, Australia. (UTC+10hours)
>>>
>>> anas wrote:
>>>> Dear all,
>>>>
>>>> I have encountered a large delay end to end delay
>>>> and when I checked the out put file I see some of the packets have a 
>>>> very large delay at MAC layer as shown below:
>>>>
>>>> f 202.663960039 _25_ RTR  --- 585 cbr 576 [13a 2b 19 800] ------- 
>>>> [9:1 10:1 25 30] [17] 7 2
>>>> s 358.840523771 _25_ MAC  --- 585 cbr 634 [13a 1e 19 800] ------- 
>>>> [9:1 10:1 25 30] [17] 7 2
>>>> as it appears there is about 150 second at MAC layer
>>>>
>>>> what is the bug here
>>>> I used NS2.33 under both Linux and sygwin all of them have the same bug
>>>>
>>>> please help me
>>>> best regards
>>>> Anas
>>>
>>>
>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out25b.tr
Type: application/octet-stream
Size: 100411 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090409/c27abc78/out25b-0001.obj

From mathieu.lacage at sophia.inria.fr  Thu Apr  9 09:00:59 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 09 Apr 2009 18:00:59 +0200
Subject: [Ns-developers] transmission range in wifi network
In-Reply-To: <1c96436a0904090659u24992f51u2b0b26b3a82e4f2d@mail.gmail.com>
References: <1c96436a0904061034q2fafd716u7fff25c7c9cb3472@mail.gmail.com>
	<1239270914.27929.4.camel@diese.inria.fr>
	<1c96436a0904090659u24992f51u2b0b26b3a82e4f2d@mail.gmail.com>
Message-ID: <1239292859.27929.30.camel@diese.inria.fr>

On Thu, 2009-04-09 at 15:59 +0200, ichrak amdouni wrote:

>         
>         I doubt that is the case with the default values of all
>         parameters.
>         Maybe you changed some parameters ?
>         
> 
>  Yes, it is the case,  the mac association succeed between an access
> point and one mobile station  distant of 3000m,  connectivity is
> however not maintained. Note that my nodes simulates vehicles running
> at 50km/h.

As I said, I don't believe that the default parameter values allow any
kind of packet reception at 3000m.

Here is what I get with ns-3-dev from today:
[mlacage at diese ns-3-dev]$ ./build/debug/src/devices/wifi/wifi-phy-test
Psr --PacketSize=40 --TxMode=wifia-6mbs --Distance=3000
0

or:

[mlacage at diese ns-3-dev]$ ./build/debug/src/devices/wifi/wifi-phy-test
SizeVsRange --TargetPsr=0.0001 --TxMode=wifia-6mbs 
10 199.125
50 189.214
90 182.218
130 177.554
170 174.639
210 171.918
250 172.307
290 170.947
330 169.586
370 168.226
...

To summmarize, the default parameter setup and values ensure that the
probability of successful reception of packets 10bytes-long by the PHY
with mode 6mbs is close to zero after 200m. If you don't get this, then,
either you have a very broken version of ns-3 or you have changed some
default parameter, but I have no idea which. Or, I could be wrong, but I
don't have enough information to reproduce the behavior you are
describing.

>         
>         > Having distinct results from those of the wifi-phy-test.cc
>         example, I wonder
>         > if this issue has a relation with other layers other than
>         the Physical one?
>         
>         
>         No, it's all a PHY layer thing.
>         
>         > I find the hypothesis very stange but I really reproduced
>         the same scenario
>         > as in wifi-phy-test.cc.
>         
>         
>         What kind of scenario ? Could you be more explicit about what
>         you, what
>         you get, and what you expect from wifi-phy-test ?
> 
> I am expecting to  have nodes that can't "see" each other beyond the
> theoretical coverage area.
> For example I used the following setting:

what is the 'theoretical' coverage area ?

> 
> 
> channel.AddPropagationLoss("ns3::LogDistancePropagationLossModel","Exponent", DoubleValue(1.70));
>  
>   channel.SetPropagationDelay
> ("ns3::ConstantSpeedPropagationDelayModel");
>   Ptr<YansWifiChannel> chan = channel.Create (); 
>    wifiPhy.SetChannel (chan);
>   wifiPhy.SetErrorRateModel ("ns3::ErrorRateModel");
> 
>   wifiPhy.Set ("TxPowerStart",DoubleValue(5));
>   wifiPhy.Set ("TxPowerEnd",DoubleValue(5));
>   wifiPhy.Set ("TxPowerLevels",UintegerValue (1));
>   wifiPhy.Set ("TxGain",DoubleValue (2));
>   wifiPhy.Set ("RxGain",DoubleValue (2));
> 
> This make connection impossible beyond 250m, but the problem now is
> that packet transfert failure is important due to  the condition:
> (m_random.GetValue () < snrPer.per ) at the physical layer when
> sending probe responses.


I am not sure what you are trying to achieve. Theoretically, all you
need to do to adjust the transmission range is to change the tx power.

Mathieu


From mathieu.lacage at sophia.inria.fr  Thu Apr  9 14:31:57 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 09 Apr 2009 23:31:57 +0200
Subject: [Ns-developers] code review tool
Message-ID: <1239312717.16137.27.camel@mathieu-laptop>

hi,

Because the number of pending code reviews is growing quickly, and email
is a pain to deal with them, tom and I would like to get a code review
tool up and running. A new collegue of mine, Faker looked at
review-board.org which looks cool in a demo but is a real pain to setup
correctly and seems to be problematic to use for our mercurial-based
workflow. 

So, I would like to suggest that we use rietveld instead. I uploaded a
sample patch: http://codereview.appspot.com/37042
and anyone can review it if they have a google account. If you have a
google account, you can also post new patches for review:
http://codereview.appspot.com/new

I used the upload.py script mentioned in the webpage above to create
this test review patch:
hg clone http://code.nsnam.org/mathieu/ns-3-simu
cd ns-3-simu
# edit README
hg ci -m "test" README
upload.py --rev=4583

The above is pretty straightforward which is why I feel it would be nice
to pick this tool and just go ahead with actually doing code reviews :)

So, I would like to propose that:
1) we create a google group ns-3-reviews: if you want to follow through
email code reviews, this is where you should subscribe
2) we ask those who submit code for review/inclusion to submit it
through rietveld with upload.py  (I believe that the web interface will
not work with anything but svn repositories but I would be happy to be
proven wrong) and make sure they CC ns-3-reviews

One thing some might feel concerned about is adding a dependency on an
externally-maintained server: I personally don't feel bad about this: we
can always install a copy of rietveld on a server of our own if we are
unhappy about google's handling of the corereview.appspot.com server.

It would be nice to hear positive or negative comments about this
proposal.

Mathieu


From saba717671 at hotmail.com  Thu Apr  9 07:57:33 2009
From: saba717671 at hotmail.com (anas)
Date: Thu, 9 Apr 2009 17:57:33 +0300
Subject: [Ns-developers] big delay in MAC-802_11 in NS2.33
In-Reply-To: <BLU104-DS3A527CA7BA712294CAF4DDF850@phx.gbl>
	<49DD7C3D.7030001@tomh.org>
References: <BLU104-DS3A527CA7BA712294CAF4DDF850@phx.gbl>
	<49DD7C3D.7030001@tomh.org>
Message-ID: <BLU104-DS675A7C1366819B222721BDF830@phx.gbl>

dear Tom,
I just use the wireless.tcl example and change the traffic
I attach also the output file

thank you for your reply
Anas

--------------------------------------------------
From: "Tom Henderson" <tomh at tomh.org>
Sent: Thursday, April 09, 2009 7:40 AM
To: "anas" <saba717671 at hotmail.com>
Cc: <ns-developers at ISI.EDU>
Subject: Re: [Ns-developers] big delay in MAC-802_11 in NS2.33

> anas wrote:
>> Dear all,
>>
>> I have encountered a large delay end to end delay
>> and when I checked the out put file I see some of the packets have a very 
>> large delay at MAC layer as shown below:
>>
>> f 202.663960039 _25_ RTR  --- 585 cbr 576 [13a 2b 19 800] ------- [9:1 
>> 10:1 25 30] [17] 7 2
>> s 358.840523771 _25_ MAC  --- 585 cbr 634 [13a 1e 19 800] ------- [9:1 
>> 10:1 25 30] [17] 7 2
>>
>> as it appears there is about 150 second at MAC layer!!!!
>>
>> what is the bug here
>> I used NS2.33 under both Linux and sygwin all of them have the same bug
>>
>> please help me
>> best regards
>> Anas
>
> Can you please send a test script to reproduce it, or post one in the ns-2 
> tracker [*], so someone can take a look?
>
> - Tom
>
> [*] http://sourceforge.net/tracker/?group_id=149743&atid=775392
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wireless2.tcl
Type: application/octet-stream
Size: 8122 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090409/fe84acba/wireless2-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out2.tr
Type: application/octet-stream
Size: 4575619 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090409/fe84acba/out2-0001.obj

From adrian at ieaa.org  Thu Apr  9 15:15:50 2009
From: adrian at ieaa.org (Adrian Sai-Wah TAM)
Date: Thu, 9 Apr 2009 18:15:50 -0400
Subject: [Ns-developers] code review tool
In-Reply-To: <1239312717.16137.27.camel@mathieu-laptop>
References: <1239312717.16137.27.camel@mathieu-laptop>
Message-ID: <f4eeff4e0904091515s7538efc2u15bf99f960033890@mail.gmail.com>

I vote for this one. This makes a better presentation of pending patches.

On Thu, Apr 9, 2009 at 5:31 PM, Mathieu Lacage
<mathieu.lacage at sophia.inria.fr> wrote:
> hi,
>
> Because the number of pending code reviews is growing quickly, and email
> is a pain to deal with them, tom and I would like to get a code review
> tool up and running. A new collegue of mine, Faker looked at
> review-board.org which looks cool in a demo but is a real pain to setup
> correctly and seems to be problematic to use for our mercurial-based
> workflow.
>
> So, I would like to suggest that we use rietveld instead. I uploaded a
> sample patch: http://codereview.appspot.com/37042
> and anyone can review it if they have a google account. If you have a
> google account, you can also post new patches for review:
> http://codereview.appspot.com/new
>
> I used the upload.py script mentioned in the webpage above to create
> this test review patch:
> hg clone http://code.nsnam.org/mathieu/ns-3-simu
> cd ns-3-simu
> # edit README
> hg ci -m "test" README
> upload.py --rev=4583
>
> The above is pretty straightforward which is why I feel it would be nice
> to pick this tool and just go ahead with actually doing code reviews :)
>
> So, I would like to propose that:
> 1) we create a google group ns-3-reviews: if you want to follow through
> email code reviews, this is where you should subscribe
> 2) we ask those who submit code for review/inclusion to submit it
> through rietveld with upload.py ?(I believe that the web interface will
> not work with anything but svn repositories but I would be happy to be
> proven wrong) and make sure they CC ns-3-reviews
>
> One thing some might feel concerned about is adding a dependency on an
> externally-maintained server: I personally don't feel bad about this: we
> can always install a copy of rietveld on a server of our own if we are
> unhappy about google's handling of the corereview.appspot.com server.
>
> It would be nice to hear positive or negative comments about this
> proposal.
>
> Mathieu
>
>


From tomh at tomh.org  Thu Apr  9 21:37:12 2009
From: tomh at tomh.org (Tom Henderson)
Date: Thu, 09 Apr 2009 21:37:12 -0700
Subject: [Ns-developers] code review
Message-ID: <49DECCF8.4030803@tomh.org>

(changing subject header slightly to avoid being caught in mailman's filter)

Mathieu Lacage wrote:

> 
> I used the upload.py script mentioned in the webpage above to create
> this test review patch:
> hg clone http://code.nsnam.org/mathieu/ns-3-simu
> cd ns-3-simu
> # edit README
> hg ci -m "test" README
> upload.py --rev=4583
> 
> The above is pretty straightforward which is why I feel it would be nice
> to pick this tool and just go ahead with actually doing code reviews :)

While the above is easy for that simple case, I think it will be helpful
to our contributors if they could also just upload a diff against the
tip of ns-3-dev, or upload a standalone diff.  It's not clear to me that
upload.py has a straightforward way to do that for repositories where
there have been many merges with ns-3-dev in the past.  Maybe we could
wrap upload.py with some other code to automate that, and distribute the
modified file ourselves.

> 
> So, I would like to propose that:
> 1) we create a google group ns-3-reviews: if you want to follow through
> email code reviews, this is where you should subscribe
> 2) we ask those who submit code for review/inclusion to submit it
> through rietveld with upload.py  (I believe that the web interface will
> not work with anything but svn repositories but I would be happy to be
> proven wrong) and make sure they CC ns-3-reviews
> 
> One thing some might feel concerned about is adding a dependency on an
> externally-maintained server: I personally don't feel bad about this: we
> can always install a copy of rietveld on a server of our own if we are
> unhappy about google's handling of the corereview.appspot.com server.

I am not concerned about this aspect.

I think we could really use a tool for this, and I would support trying
this unless other people would like to suggest another tool.

Tom


From tomh at tomh.org  Thu Apr  9 21:55:42 2009
From: tomh at tomh.org (Tom Henderson)
Date: Thu, 09 Apr 2009 21:55:42 -0700
Subject: [Ns-developers] 802.11s code review
In-Reply-To: <171201239271983@webmail34.yandex.ru>
References: <171201239271983@webmail34.yandex.ru>
Message-ID: <49DED14E.4060808@tomh.org>


> Could you please make a review of our code and make your opinion about it?

Hi Kirill,
I will try to give you a review in the coming few days.  I've logged it 
here for now:
http://www.nsnam.org/wiki/index.php/Contributed_Code

Thanks,
Tom

From tomh at tomh.org  Thu Apr  9 21:57:08 2009
From: tomh at tomh.org (Tom Henderson)
Date: Thu, 09 Apr 2009 21:57:08 -0700
Subject: [Ns-developers] Initial 802.11n support for ns-3.5
In-Reply-To: <49DDEDD6.3070802@gmail.com>
References: <49DDEDD6.3070802@gmail.com>
Message-ID: <49DED1A4.7020703@tomh.org>

Mirko Banchi wrote:
> Hi all,
> 
> I'd like to receive some feedbacks about my code
> 
> http://code.nsnam.org/mirko/ns-3-80211n
> 
> and i'd like to merge for ns-3.5.
> In particular repository contains new WifiHelpers also for Qos stas,
> Edca support and frame aggregation at MSDU level (next step MPDU
> aggregation).
> 
> Currently i'm working on block ack but i don't think that code will be
> ready and reviewed for next release. However in a short time i'll
> publish it.
> 
> Thank you all,
> 
> Mirko
> 

Mirko,
Similarly to 802.11s, I've logged this at:
http://www.nsnam.org/wiki/index.php/Contributed_Code
and we will try to coordinate some reviews in the next week or so.

Thanks,
Tom

From faker.moatamri at sophia.inria.fr  Fri Apr 10 01:16:04 2009
From: faker.moatamri at sophia.inria.fr (Faker Moatamri)
Date: Fri, 10 Apr 2009 10:16:04 +0200
Subject: [Ns-developers] code review tool
In-Reply-To: <1239312717.16137.27.camel@mathieu-laptop>
References: <1239312717.16137.27.camel@mathieu-laptop>
Message-ID: <49DF0044.4000407@sophia.inria.fr>

Mathieu Lacage wrote:
> hi,
>
> Because the number of pending code reviews is growing quickly, and email
> is a pain to deal with them, tom and I would like to get a code review
> tool up and running. A new collegue of mine, Faker looked at
> review-board.org which looks cool in a demo but is a real pain to setup
> correctly and seems to be problematic to use for our mercurial-based
> workflow. 
>
> So, I would like to suggest that we use rietveld instead. I uploaded a
> sample patch: http://codereview.appspot.com/37042
> and anyone can review it if they have a google account. If you have a
> google account, you can also post new patches for review:
> http://codereview.appspot.com/new
>
> I used the upload.py script mentioned in the webpage above to create
> this test review patch:
> hg clone http://code.nsnam.org/mathieu/ns-3-simu
> cd ns-3-simu
> # edit README
> hg ci -m "test" README
> upload.py --rev=4583
>
> The above is pretty straightforward which is why I feel it would be nice
> to pick this tool and just go ahead with actually doing code reviews :)
>
> So, I would like to propose that:
> 1) we create a google group ns-3-reviews: if you want to follow through
> email code reviews, this is where you should subscribe
> 2) we ask those who submit code for review/inclusion to submit it
> through rietveld with upload.py  (I believe that the web interface will
> not work with anything but svn repositories but I would be happy to be
> proven wrong) and make sure they CC ns-3-reviews
>
> One thing some might feel concerned about is adding a dependency on an
> externally-maintained server: I personally don't feel bad about this: we
> can always install a copy of rietveld on a server of our own if we are
> unhappy about google's handling of the corereview.appspot.com server.
>
> It would be nice to hear positive or negative comments about this
> proposal.
>
> Mathieu
>
>   
Hi all,
I completely agree with the solution proposed by Mathieu, the code 
review looks very cool and I think this will work very well for users. 
The interface is well done and the addition of a review is relatively 
straightforward.

I've been through the details of how to add a review to rietveld(this 
can be used for a small how to):
-Download the upload.py code from 
http://codereview.appspot.com/static/upload.py
-put it in you repository and change the access right: /chmod +x upload.py/
-after committing your code to your local version control using your 
preferred tool, you can use the command: /hg log -v | less/ to find the 
revision number needed (you can also use eclipse to get it)
-use the command given by Mathieu:/upload.py --rev=rev_num /where the 
revision number is the revision number from which you want to compare 
your code, in my case it was 4308
-you will get the message:
/Upload server: codereview.appspot.com (change with -s/--server)
New issue subject:
/-You enter the issue subject
-you will be asked : /Email (login for uploading to 
codereview.appspot.com):/
-you enter your google email: faker.moatamri at gmail.com
-you will be asked your password: /Password for faker.moatamri at gmail.com:
-/enter your password:/ password /(sorry can't give you my password :-) )
-you get the url of the review and the files added:
/Issue created. URL: http://codereview.appspot.com/39045
Uploading base file for utils/testfile.cc
Uploading base file for utils/mobility-visualizer-view.cc
/(Note:The above files are the files I changed)/
/-You are done, you can wait for comments now

I tried to add a new repository but actually they don't even ask for the 
type of repository which confirms that they work exclusively with svn. 
So obviously the web interface to add a review will work, as Mathieu 
said, only with svn.

Best regards
Faker


From gjcarneiro at gmail.com  Fri Apr 10 10:30:37 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Fri, 10 Apr 2009 18:30:37 +0100
Subject: [Ns-developers] code review tool
In-Reply-To: <1239312717.16137.27.camel@mathieu-laptop>
References: <1239312717.16137.27.camel@mathieu-laptop>
Message-ID: <a467ca4f0904101030h99a3203g3b5553ebfebfbfb2@mail.gmail.com>

Well, this tool does not make the job any easier for submitters of patches,
just for the reviewer.  And it does not take full advantage of DVCS, for
instance create a temporary branch to fix a bug, maintainer responds,
submitter makes a new commit in the branch to fix the problems, and so on.

That being said, it may not make submitter's job easier, but it does not
seem to make it noticeably harder either, so no objections from me.

But do we need to do this for _all_ patches, or just the medium/large
patches?

2009/4/9 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> hi,
>
> Because the number of pending code reviews is growing quickly, and email
> is a pain to deal with them, tom and I would like to get a code review
> tool up and running. A new collegue of mine, Faker looked at
> review-board.org which looks cool in a demo but is a real pain to setup
> correctly and seems to be problematic to use for our mercurial-based
> workflow.
>
> So, I would like to suggest that we use rietveld instead. I uploaded a
> sample patch: http://codereview.appspot.com/37042
> and anyone can review it if they have a google account. If you have a
> google account, you can also post new patches for review:
> http://codereview.appspot.com/new
>
> I used the upload.py script mentioned in the webpage above to create
> this test review patch:
> hg clone http://code.nsnam.org/mathieu/ns-3-simu
> cd ns-3-simu
> # edit README
> hg ci -m "test" README
> upload.py --rev=4583
>
> The above is pretty straightforward which is why I feel it would be nice
> to pick this tool and just go ahead with actually doing code reviews :)
>
> So, I would like to propose that:
> 1) we create a google group ns-3-reviews: if you want to follow through
> email code reviews, this is where you should subscribe
> 2) we ask those who submit code for review/inclusion to submit it
> through rietveld with upload.py  (I believe that the web interface will
> not work with anything but svn repositories but I would be happy to be
> proven wrong) and make sure they CC ns-3-reviews
>
> One thing some might feel concerned about is adding a dependency on an
> externally-maintained server: I personally don't feel bad about this: we
> can always install a copy of rietveld on a server of our own if we are
> unhappy about google's handling of the corereview.appspot.com server.
>
> It would be nice to hear positive or negative comments about this
> proposal.
>
> Mathieu
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From mathieu.lacage at sophia.inria.fr  Sat Apr 11 11:31:59 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Sat, 11 Apr 2009 20:31:59 +0200
Subject: [Ns-developers] code review tool
In-Reply-To: <a467ca4f0904101030h99a3203g3b5553ebfebfbfb2@mail.gmail.com>
References: <1239312717.16137.27.camel@mathieu-laptop>
	<a467ca4f0904101030h99a3203g3b5553ebfebfbfb2@mail.gmail.com>
Message-ID: <1239474719.19565.4.camel@mathieu-laptop>

On Fri, 2009-04-10 at 18:30 +0100, Gustavo Carneiro wrote:
> Well, this tool does not make the job any easier for submitters of
> patches, just for the reviewer.  And it does not take full advantage
>  of DVCS, for instance create a temporary branch to fix a bug,
> maintainer responds, submitter makes a new commit in the branch to fix
> the problems, and so on.
> 
> That being said, it may not make submitter's job easier, but it does
> not seem to make it noticeably harder either, so no objections from
> me.
> 
> But do we need to do this for _all_ patches, or just the medium/large
> patches?

If I _personally_ have to review some code, I would rather use this tool
than do the review by email so, I would find it really helpful if patch
submitters were willing to do this. If submitters don't do it, I will
probably end up doing it myself to write reviews for them. Writing
reviews by mail is just way too painful.

Mathieu


From tazaki at sfc.wide.ad.jp  Fri Apr 10 16:44:13 2009
From: tazaki at sfc.wide.ad.jp (Hajime Tazaki)
Date: Sat, 11 Apr 2009 08:44:13 +0900
Subject: [Ns-developers] code review tool
In-Reply-To: <1239312717.16137.27.camel@mathieu-laptop>
References: <1239312717.16137.27.camel@mathieu-laptop>
Message-ID: <0012CB1B-AEB6-4947-ACF5-6A30CC5E3321@sfc.wide.ad.jp>

Hi,

+1

i'm ready to go.

regards,
hajime

On 2009/04/10, at 6:31, Mathieu Lacage  
<mathieu.lacage at sophia.inria.fr> wrote:

> hi,
>
> Because the number of pending code reviews is growing quickly, and  
> email
> is a pain to deal with them, tom and I would like to get a code review
> tool up and running. A new collegue of mine, Faker looked at
> review-board.org which looks cool in a demo but is a real pain to  
> setup
> correctly and seems to be problematic to use for our mercurial-based
> workflow.
>
> So, I would like to suggest that we use rietveld instead. I uploaded a
> sample patch: http://codereview.appspot.com/37042
> and anyone can review it if they have a google account. If you have a
> google account, you can also post new patches for review:
> http://codereview.appspot.com/new
>
> I used the upload.py script mentioned in the webpage above to create
> this test review patch:
> hg clone http://code.nsnam.org/mathieu/ns-3-simu
> cd ns-3-simu
> # edit README
> hg ci -m "test" README
> upload.py --rev=4583
>
> The above is pretty straightforward which is why I feel it would be  
> nice
> to pick this tool and just go ahead with actually doing code  
> reviews :)
>
> So, I would like to propose that:
> 1) we create a google group ns-3-reviews: if you want to follow  
> through
> email code reviews, this is where you should subscribe
> 2) we ask those who submit code for review/inclusion to submit it
> through rietveld with upload.py  (I believe that the web interface  
> will
> not work with anything but svn repositories but I would be happy to be
> proven wrong) and make sure they CC ns-3-reviews
>
> One thing some might feel concerned about is adding a dependency on an
> externally-maintained server: I personally don't feel bad about  
> this: we
> can always install a copy of rietveld on a server of our own if we are
> unhappy about google's handling of the corereview.appspot.com server.
>
> It would be nice to hear positive or negative comments about this
> proposal.
>
> Mathieu
>

From adrian at ieaa.org  Mon Apr 13 11:42:56 2009
From: adrian at ieaa.org (Adrian Sai-Wah TAM)
Date: Mon, 13 Apr 2009 14:42:56 -0400
Subject: [Ns-developers] OnOffApplication in ns3
Message-ID: <f4eeff4e0904131142i146da296lc94bff4f0e1a5c83@mail.gmail.com>

Hi all,

I found something strange: OnOffApplication::Construct is a function
declared in the onoff-application.h but defined nowhere. Shall we
remove it?

PS: I checked ns-3.3 and ns-3.4.

- Adrian.

From craigdo at ee.washington.edu  Mon Apr 13 19:04:51 2009
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Mon, 13 Apr 2009 19:04:51 -0700
Subject: [Ns-developers] Underwater acoustic module for NS-3
In-Reply-To: <6c14d5550903221355t755ea845ncdbdb9e9c26ab299@mail.gmail.com>
References: <6c14d5550810131948x6272d17ap11af76cc9074733@mail.gmail.com><1225180259.715.126.camel@localhost.localdomain><6c14d5550903220117v54a259c0u2a83578bfad1ffcc@mail.gmail.com><1237739881.6923.7.camel@mathieu-laptop>
	<6c14d5550903221355t755ea845ncdbdb9e9c26ab299@mail.gmail.com>
Message-ID: <91E3FFCC89704D89996C6B6C29EF89D4@CRAIGVAIO>

 
> I've been working on an NS3 model for simulation of wireless 
> underwater
> acoustic network simulation.  

[ ... ]

> Although this work is still ongoing, I'd like to submit my 
> progress thus far
> for design review.

[ ... ]

>From a follow-up email:

> The repository has been moved to:
http://code.nsnam.org/ltracy/ns-3-dev-uan
> 
> A couple of known open issues:  1. I plan on reworking UanPropModelBh
> (possibly to store information in a SQL DB).  2.  I'm guessing that
> UanTxMode can likely be combined with WifiMode.
> 

Hi Leonard,

The first "minor detail" :-) is that ns-3-dev-uan doesn't build on
ns-regression:

---------- Begin Included File ----------
cc1plus: warnings being treated as errors
../src/devices/uan/uan-prop-model-bh.cc: In member function ??~virtual bool
ns3::BhConfig::Config(std::string)??T:
../src/devices/uan/uan-prop-model-bh.cc:80: warning: comparison is always
false due to limited range of data type
../src/devices/uan/uan-prop-model-bh.cc:92: warning: comparison is always
false due to limited range of data type
Build failed
---------- End Included File ----------

This is because npos is defined as -1 and you are comparing with a uint32_t.
I changed the two instances to std::sting::size_type to get it to compile.
The same error is present in create-dat.cc in uan-apps.  You should run this
code through the nightly build environment (at least to see that it compiles
everywhere) using:

sudo bash
su nsnam
cd /tmp
nohup /usr/local/bin/ns-3-run-tests.sh -n ltracy/ns-3-dev-uan -m
lentracy at u.washington.edu &

before you make an "official" submission.  I would use this as an initial
"acceptance test."  

Have you tried to generate and build Python bindings?  Have you tried to
build and run on Cygwin?  We have a list of supported platforms and a common
pitfall is to not try your code "everywhere."

I expected to see an example in the directory examples with something
descriptive in it.  There is a top-level directory called uan-apps that
contains what seems to be example programs.  These should probably go into
the examples directory.  If you think it is time to make a uan subdirectory
under examples, that would be fine.  You don't build uanapps/firstuan.cc --
is this intentional?

It's evident that there is a configuration file of some sort that needs to
be created.  I assumed that this was optional and that I could do something
semi-useful with defaults without running this.  When I run the remaining
example, bhtest, it asserts looking for StaticMobilityModel.  I changed this
to StaticPositionMobilityModel and ran bhtest again.  When I ran bhtest,
then it complained about not finding the config file.

So I gave up on trying to get the code to execute and produce some results.
I really think you should have an example I can just run and get results, or
some more obvious documentation (I didn't see it, but I didn't look very
hard either -- it should be easy to find, perhaps in a devices/uan/uan.h
file as described below).  An approach I took on some of the tap bridge code
that has external dependencies was to just write out what to do in the
example as a comment.  See examples/tap-wifi-dumbbell.cc for what I did.
Some people don't like this much commentary in an example, but it is easy to
find and if you type what I tell you, it just works.  YMMV.

That said, we really do need some kind of test that can be used in our
current regression environment to let us know that everything continues to
work as expected.  You could write a regression test that does the
configuration, but IMO it would be helpful to be able to have a default
configuration that doesn't require a configuration file.  Tom mentioned
something about storing configuration information in a database.  I didn't
see anything like that either.  

Ideally there should be example programs and regression tests, but we aren't
very good at this and so usually what has been done is to overload an
example program that produces trace files into doing double duty.  Take a
look at the regression/tests directory to see what needs to go in.  For
example, the file test-udp-echo.py causes udp-echo (source in
examples/udp-echo.cc) to be run and the trace output compared with
known-good bits checked into ns-3-dev-ref-traces.

IMO your examples should have a few comments at least.  Most examples have
at least an illustration of what is going on.  For example, this is from
examples/csma-one-subnet.cc:

// Network topology
//
//       n0    n1   n2   n3
//       |     |    |    |
//       =================
//              LAN
//
// - CBR/UDP flows from n0 to n1 and from n3 to n0
// - DropTail queues
// - Tracing of queues and packet receptions to file "csma-one-subnet.tr"

The Doxygen throughout is very sparse.  For example, there is no doxygen for
class UanMacAloha.  Now I can guess what this means, but we really need to
document this stuff.

It is convenient to check in a copy of waf in your directory so one can
build out of that directory, so I would check in a src/devices/uan/waf (copy
from wifi).

There are many instance of code that looks like:

namespace ns3
{
class UanMac : public ns3::Object

The ns3:: is redundant.  It looks like you may have added the ns3 namespace
later.

I personally like to see more NS_LOG statements, but that is really a matter
of style that is up to you.  I think they are helpful, especially to people
not intimately familiar with the code, when they're trying to get their
bearings.

I personally like to see the use of _MSG variants of the assertion and error
macros.  It is quite helpful to get some initial information when something
crashes.  But this is really a matter of style that is up to you.

I personally like to see more inline comments in the code.  This can be a
sensitive subject; but for example, 

---------- Begin Included File ----------
double
UanNoiseModelDefault::GetNoiseDbHz(double fKhz) const
{
  double turb, win, ship, thermal, noise;
  turb = 17.0 - 30.0 * log10(fKhz);
  turb = pow(10.0, turb*0.1);

  ship = 40.0 + 20.0 *(this->m_shipping-0.5) + 26.0*log10(fKhz) -
60.0*log10(fKhz+0.03);
  ship = pow(10.0,(ship*0.01));

  win = 50.0+7.5*pow(m_wind, 0.5) + 20.0*log10(fKhz) - 40.0*log10(fKhz+0.4);
  win = pow(10.0, m_wind*0.1);

  thermal = -15 + 20*log10(fKhz);
  thermal = pow(10, thermal*0.1);

  noise = 10*log10(turb + ship + win + thermal);

  return noise;
}
---------- End Included File ----------

The Doxygen says that this a standard ambient acoustic noise model.  Is this
something that would be obvious to anyone using this device in the real
world?  Are all of these various numbers from some authoritative source?
Should there be a better description or a pointer to some further
description.  e.g., this is taken from the YaddaYaddaNoiseModel (see
http://YaddaYaddaNoiseModel.htm for details).

Other devices have a file (cf src/devices/csma/csma.h) that describes what
the purpose of the model is, what it is attempting to model and a basic
description of the device and channel.  This would be very helpful.  For
example, I can imagine how all of the pieces of your device fit together,
but it is always better to have some documentation.  Eventually, someone is
going to suggest that you write a chapter for the manual and have pictures
with circles and arrows ...

I get nervous when I see things like,

  // TODO Auto-generated constructor stub

in the code.  Have you run valgrind?

It's really par for the source, but I have the usual coding standard nits
that seem to be part of every review.  This is going to be painful to fix,
and probably sounds pedantic, but every project has its own version and we
really do want to have a similar coding style across the project.  Everyone
seems to get caught by this to some extent or another.  

1) You should make sure that every source file starts with an emacs mode
line, has an appropriate GPL comment at the top with copyright holder, etc.
You have some of this, but for example, uan-address.cc doesn't have an emacs
mode line and uan-prop-model-bh.cc doesn't have any.

2) You have lots of cases of CamelCase member variables (e.g., uint32_t
m_FreqStepHz) that should be camelBack (e.g., uint32_t m_freqStepHz).  See
the file codingstd.txt under the doc directory.

3) You have lots of cases where your types and parens don't follow the GNU
practice.  For example, you should use 

  string& 
  BhConfig::trim (string& s)

and not

  string& BhConfig::trim( string& s )

I found a couple of malformed while and do constructs, but I lost them ...
sorry.

I realize this has been a litany of negative comments.  The majority of this
should be easily addressed.

The one thing that stood out to me was that I couldn't just "open the box,"
run an example program and get something to work, start looking at traces,
turn on logs, etc.  I submit that this is an important feature for people
who are starting to use your model.  You don't want to turn them off before
they see how great your stuff really is (:-).  You'll have to remedy the
config issue somehow for a regression test, so hopefully it's no big deal to
check in some kind of default configuration and stick in some log messages.

I really can't comment on the model itself since I'm not a domain expert;
and I really have no reasonable way of knowing what your model is supposed
to do other than reading 25 KLOC.  

Regards,

-- Craig




From mathieu.lacage at sophia.inria.fr  Mon Apr 13 23:53:01 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 14 Apr 2009 08:53:01 +0200
Subject: [Ns-developers] OnOffApplication in ns3
In-Reply-To: <f4eeff4e0904131142i146da296lc94bff4f0e1a5c83@mail.gmail.com>
References: <f4eeff4e0904131142i146da296lc94bff4f0e1a5c83@mail.gmail.com>
Message-ID: <1239691981.6390.27.camel@diese.inria.fr>

On Mon, 2009-04-13 at 14:42 -0400, Adrian Sai-Wah TAM wrote:
> Hi all,
> 
> I found something strange: OnOffApplication::Construct is a function
> declared in the onoff-application.h but defined nowhere. Shall we
> remove it?

I think so. 

> 
> PS: I checked ns-3.3 and ns-3.4.
> 
> - Adrian.


From mathieu.lacage at sophia.inria.fr  Tue Apr 14 00:03:50 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 14 Apr 2009 09:03:50 +0200
Subject: [Ns-developers] c0de review submission HOWTO
Message-ID: <1239692630.6390.38.camel@diese.inria.fr>

(strange title to go through the ns-dev filters)

hi,

Since I did not receive screaming emails saying that it was a horribly
bad idea, I created http://groups.google.com/group/ns-3-reviews/, and I
would like to suggest everyone who wants to submit a review to:

0) download http://codereview.appspot.com/static/upload.py
1) record the changes you want to request a review for in a mercurial
repository: "hg commit ..."
2) within the mercurial repository, run upload.py to submit a review
with http://codereview.appspot.com/. Make sure you specify
ns-3-reviews at googlegroups.com as a CC.
3) Paste your review request on
http://www.nsnam.org/wiki/index.php/Reviews or send me an email and I
will add it there
4) announce your review request on ns-developers

thank you,
Mathieu


From paolo.pilia at telecompress.net  Tue Apr 14 02:29:58 2009
From: paolo.pilia at telecompress.net (paolo.pilia@telecompress.net)
Date: Tue, 14 Apr 2009 11:29:58 +0200
Subject: [Ns-developers] Contribute to ns-3 - antennas Wireless PHY
Message-ID: <20090414112958.78jihame4gg84c40@webmail.telecompress.net>

Dear Mentors,
Dear Developers,

I want to contribute to ns-3.5 development in the part of antenna's class
(part of Google Summer of Code program) and Wireless PHY too.

About PHY Wireless, what I understand in wiki page is  about  
definition of rules for states switching (busy, sync,...). Is it right?

I think that condition depends on signals rx by antennas (related to  
Angle of Arrival, pattern, band of rx, freq) . Condition that change  
for each antennas and each node.


Case of my proposal for SoC will be accepted, I'll work for  
implementation of antennas module and wireless phy for ns 3.5.


Best Regards,
Paolo P.







From gjcarneiro at gmail.com  Tue Apr 14 02:38:23 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Tue, 14 Apr 2009 10:38:23 +0100
Subject: [Ns-developers] c0de review submission HOWTO
In-Reply-To: <1239692630.6390.38.camel@diese.inria.fr>
References: <1239692630.6390.38.camel@diese.inria.fr>
Message-ID: <a467ca4f0904140238y41981dadw85b09dc2a82edced@mail.gmail.com>

This sounds OK, but in the end please make sure someone adds these steps to
the Wiki (Developer FAQ).

I remember how lost I was regarding the regression testing stuff until the
instructions were added to the wiki; having to search my email archives
repeatedly was getting tedious..

Thanks.

2009/4/14 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> (strange title to go through the ns-dev filters)
>
> hi,
>
> Since I did not receive screaming emails saying that it was a horribly
> bad idea, I created http://groups.google.com/group/ns-3-reviews/, and I
> would like to suggest everyone who wants to submit a review to:
>
> 0) download http://codereview.appspot.com/static/upload.py
> 1) record the changes you want to request a review for in a mercurial
> repository: "hg commit ..."
> 2) within the mercurial repository, run upload.py to submit a review
> with http://codereview.appspot.com/. Make sure you specify
> ns-3-reviews at googlegroups.com as a CC.
> 3) Paste your review request on
> http://www.nsnam.org/wiki/index.php/Reviews or send me an email and I
> will add it there
> 4) announce your review request on ns-developers
>
> thank you,
> Mathieu
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From mk.banchi at gmail.com  Tue Apr 14 02:38:09 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Tue, 14 Apr 2009 11:38:09 +0200
Subject: [Ns-developers] New 802.11e/n review
Message-ID: <49E45981.6090905@gmail.com>

Hi all,

i've created a new issue for 802.11e/n review.

URL: http://codereview.appspot.com/41059

Thank you all,

Mirko

-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090414/66f1cd3f/smime-0001.bin

From gjcarneiro at gmail.com  Tue Apr 14 02:52:30 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Tue, 14 Apr 2009 10:52:30 +0100
Subject: [Ns-developers] WAF 1.5.4
Message-ID: <a467ca4f0904140252r17f74cecm5d49bdb527ead421@mail.gmail.com>

WAF 1.5.4 was released.  I merged my bazaar branch with 1.5.4, and made a
gjc/ns-3-waf154 branch to use it.  Today I checked that the regression
testing build farm passed the gjc/ns-3-waf154 tests.  I would like to merge
it in ns-3-dev in the next few days, if there are no objections.

I made just one small change.  Now it's "./waf shell" instead of "./waf
--shell".  The new WAF version supports custom commands (unlike before).
"waf --shell" just tells you about this change now.

Regards,
-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From mathieu.lacage at sophia.inria.fr  Tue Apr 14 03:17:18 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 14 Apr 2009 12:17:18 +0200
Subject: [Ns-developers] c0de review submission HOWTO
In-Reply-To: <a467ca4f0904140238y41981dadw85b09dc2a82edced@mail.gmail.com>
References: <1239692630.6390.38.camel@diese.inria.fr>
	<a467ca4f0904140238y41981dadw85b09dc2a82edced@mail.gmail.com>
Message-ID: <1239704238.6390.72.camel@diese.inria.fr>

On Tue, 2009-04-14 at 10:38 +0100, Gustavo Carneiro wrote:
> This sounds OK, but in the end please make sure someone adds these
> steps to the Wiki (Developer FAQ).

I did, but you know that you could do it yourself :)

Mathieu


From gjcarneiro at gmail.com  Tue Apr 14 03:38:22 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Tue, 14 Apr 2009 11:38:22 +0100
Subject: [Ns-developers] c0de review submission HOWTO
In-Reply-To: <1239704238.6390.72.camel@diese.inria.fr>
References: <1239692630.6390.38.camel@diese.inria.fr>
	<a467ca4f0904140238y41981dadw85b09dc2a82edced@mail.gmail.com>
	<1239704238.6390.72.camel@diese.inria.fr>
Message-ID: <a467ca4f0904140338i3bc4b6cev672e8f82d06d0c4e@mail.gmail.com>

2009/4/14 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> On Tue, 2009-04-14 at 10:38 +0100, Gustavo Carneiro wrote:
> > This sounds OK, but in the end please make sure someone adds these
> > steps to the Wiki (Developer FAQ).
>
> I did, but you know that you could do it yourself :)
>

Sorry, I thought this was just a proposal for now, and I did not want to
commit a proposal to a wiki, only the final result.

Thanks,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From mathieu.lacage at sophia.inria.fr  Tue Apr 14 05:00:02 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 14 Apr 2009 14:00:02 +0200
Subject: [Ns-developers] New 802.11e/n review
In-Reply-To: <49E45981.6090905@gmail.com>
References: <49E45981.6090905@gmail.com>
Message-ID: <1239710402.6390.78.camel@diese.inria.fr>

thank you:

http://groups.google.com/group/ns-3-reviews/browse_thread/thread/85947122d33af719



On Tue, 2009-04-14 at 11:38 +0200, Mirko Banchi wrote:
> Hi all,
> 
> i've created a new issue for 802.11e/n review.
> 
> URL: http://codereview.appspot.com/41059
> 
> Thank you all,
> 
> Mirko
> 


From mathieu.lacage at sophia.inria.fr  Tue Apr 14 06:32:51 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 14 Apr 2009 15:32:51 +0200
Subject: [Ns-developers] ns-3.5 planning
In-Reply-To: <49D4CA6C.5060405@tomh.org>
References: <49D4CA6C.5060405@tomh.org>
Message-ID: <1239715971.6390.176.camel@diese.inria.fr>

hi all,

[lengthy email]

On Thu, 2009-04-02 at 07:23 -0700, Tom Henderson wrote:

> Where are things headed for ns-3.5?  First, Mathieu volunteered to be
> release manager for the next release, so I'd like to accept Mathieu's

I have been very quiet recently because I was busy with a few other
things, but, I spent some time thinking about our next release, and what
we could realistically put in it. I have also spent some time to
convince a co-worker, faker to help me with all the release management
aspects of this release: he agreed to help manage the bug tracker, fix
bugs, do some code reviews, install buildbot, and, more generally, take
a share of the boring painful stuff which needs to get done (and,
hopefully, the less boring stuff too). Hopefully, this will help us all
to make this release another great release.

Tom mentionned a couple of important items he would like to see done for
this release: 
1) ipv4 rework
2) code contributions
3) validation improvements

2) is a kind of meta item because it covers lots of other projects so, I
have tried to detail it below. 

1) ipv4 rework
2) 802.11n work
3) 802.11s work
4) virtual devices
5) wifi PHY work
6) validation improvements
7) various small patches present in the bug tracker
8) ipv6
9) underwater models
10) tag rework

If there is something I forgot, please, let me know.

Here is my understanding of the status of each separate item:

1) ipv4 rework: tom and I agreed to try to split it, and specifically,
try to split the API changes from the implementation changes. Right now,
the proposal is to merge the following trees:
  - mathieu/ns-3-olsr
  - tomh/ns-3-ip-interfaces: my main comment for this tree is that I am
still unsure I understand what the peer field is supposed to represent
and how it is expected to be used.
  - tomh/ns-3-ip-routing: missing a README.api. Ipv4Route should derive
from src/node/ref-count-based.h instead of implementing Ref+Unref.

Needed followup patches:
  - new src/helper/ipv4-routing-helper.h 
  - move src/internet-stack/static-routing-protocol.h to src/node,
modify it to implement a linux-like routing table API
  - introduce a loopback device, remove Ipv4LoopbackInterface
  - remove virtual methods from Ipv4Interface
  - add src/node/arp.h, implement it in ArpL3Protocol
  - remove ::SetNode in src/internet-stack/*.h|cc: all these objects are
aggregated to a node, so, they can call GetObject.
  - remove src/internet-stack/internet-stack.cc:
      a) make UdpL4Protocol aggregate UdpSocketFactory to self from
constructor. Same for TcpL4Protocol/TcpSocketFactory.
      b) add src/core/object.h: call NotifyNewAggregate from
AggregateObject
      c) Hook in NotifyNewAggregate from UdpL4Protocol, check for
Ipv4L3Protocol, register new l4 protocol when Ipv4L3Protocol is
aggregated or when they are created

If you are scared, you are right: it's a scary big work item.

2) The 802.11n work is progressing nicely: I expect it can be merged in
a couple of weeks after one or two more review iterations

3) The 802.11s work has progressed too: I will do a review of the wifi
part once the non-wifi part has been reviewed by others. I expect tom
and gustavo to provide reviews on the non-wifi part because I can see
some aspects of the non-wifi part being somewhat related to bridging.

4) virtual devices was sent here for review a long time ago:
http://code.nsnam.org/gjc/ns-3-virtual-netdevice/ I think that it could
be useful to more users so, I would support merging it and would be
happy to help gustavo port this to ns-3-dev.

5) various wifi PHY patches are left in bugzilla. These need to be
merged. 

6) validation improvements: the plan layed out in
http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting#What_Does_it_Look_Like looks great. I am worried that this is new development and that it might be hard to make sure it matures sufficiently for this release cycle.

7) small patches: I expect faker to help me get a better grasp of what
we can help merge soon, and what we should just drop.

8) so far, ipv6 is blocked on item 1) and item 1. is far from being
finished. If I put my realistic hat on, I predict that there is zero
chance to complete 1) sufficiently early to allow ipv6 to go in this
release cycle.

9) An initial review: we need to see how long it will take to get all
the already-identified items to get fixed before considering this
feature for this release cycle

10) This was posted a while ago: tom agreed on the basic idea with minor
comments, and there were no other comments. I think that it could go in
in a couple of days once we have fixed the identified issues.

pfew ! That was long, but it's quite likely that I forgot something so,
if there is an item you are working on and you believe should be
considered for this new release cycle which will end in mid-june with a
new release, please, let me/us know _now_.

Mathieu


From tazaki at sfc.wide.ad.jp  Tue Apr 14 09:24:39 2009
From: tazaki at sfc.wide.ad.jp (Hajime Tazaki)
Date: Wed, 15 Apr 2009 01:24:39 +0900
Subject: [Ns-developers] Review request (ns-3-simu extension) (Re: About
	real-world application integration)
In-Reply-To: <m2tz57qbnw.wl@sfc.wide.ad.jp>
References: <m2tz67w3f6.wl@sfc.wide.ad.jp>
	<1236790499.658.31.camel@mathieu-laptop>
	<1237193331.31135.36.camel@diese.inria.fr>
	<m27i2pwzxf.wl@sfc.wide.ad.jp>
	<1237198269.31135.121.camel@diese.inria.fr>
	<m2tz57qbnw.wl@sfc.wide.ad.jp>
Message-ID: <m2d4bf9pa0.wl@sfc.wide.ad.jp>


Hi All,

>http://www.sfc.wide.ad.jp/~tazaki/hg/ns-3-simu-mod/

I post several review requests.

http://codereview.appspot.com/40071
http://codereview.appspot.com/41049
http://codereview.appspot.com/41048
http://codereview.appspot.com/40070
http://codereview.appspot.com/40069
http://codereview.appspot.com/40068
http://codereview.appspot.com/41047
http://codereview.appspot.com/40067
http://codereview.appspot.com/41046
http://codereview.appspot.com/41045
http://codereview.appspot.com/40065
http://codereview.appspot.com/40064
http://codereview.appspot.com/40063
http://codereview.appspot.com/41044
http://codereview.appspot.com/41043
http://codereview.appspot.com/40062
http://codereview.appspot.com/40061
http://codereview.appspot.com/40060
http://codereview.appspot.com/40059

regards,
hajime


From mk.banchi at gmail.com  Tue Apr 14 12:46:48 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Tue, 14 Apr 2009 21:46:48 +0200
Subject: [Ns-developers] New 802.11e/n review
In-Reply-To: <adbe58370904140958w57e7efedh34ced547d380a8c8@mail.gmail.com>
References: <49E45981.6090905@gmail.com>
	<adbe58370904140958w57e7efedh34ced547d380a8c8@mail.gmail.com>
Message-ID: <49E4E828.8040709@gmail.com>

Basim Javed ha scritto:
> hello Mirko
> 
> Would you say a few words about which specific issues you handled/corrected
> for 802.11e? I would appreciate your reply.
> 
> Thanks in advance.
> 
> best
> B
> 

Hi Basim,

i've added objects in order to use 802.11e Qos facility. It's possible
to define wifi Stas that use 4 queues to manage Qos traffic. If you want
to work with a particular kind of traffic you have to mark every packet
adding a QosTag to it. An application that marks traffic would be
welcome:) For 802.11n support i've added frame aggregation to a MSDU
level (A-MSDU), A-MPDU in the future. In a short time i should be able
to publish code about block ack: Basic variant (802.11e) and Compressed
variant (802.11n).

Regards,

Mirko


-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090414/4c40e171/smime-0001.bin

From mk.banchi at gmail.com  Tue Apr 14 15:42:06 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Wed, 15 Apr 2009 00:42:06 +0200
Subject: [Ns-developers] New review for 802.11e/n extensions
Message-ID: <49E5113E.5070000@gmail.com>

Hi all,

i can't understand the reason, but previous issue 41059 for 802.11e/n
extensions stopped to work. Only reason i can figure out is that my
laptop turned off during upload of a new patch. Unfortunately i can't
remove old issue.

New patch is at URL: http://codereview.appspot.com/40088

Sorry for trouble,

Mirko

-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090415/3b341805/smime.bin

From lentracy at u.washington.edu  Tue Apr 14 23:29:56 2009
From: lentracy at u.washington.edu (Leonard Tracy)
Date: Tue, 14 Apr 2009 23:29:56 -0700
Subject: [Ns-developers] Underwater acoustic module for NS-3
In-Reply-To: <91E3FFCC89704D89996C6B6C29EF89D4@CRAIGVAIO>
References: <6c14d5550810131948x6272d17ap11af76cc9074733@mail.gmail.com>
	<1225180259.715.126.camel@localhost.localdomain>
	<6c14d5550903220117v54a259c0u2a83578bfad1ffcc@mail.gmail.com>
	<1237739881.6923.7.camel@mathieu-laptop>
	<6c14d5550903221355t755ea845ncdbdb9e9c26ab299@mail.gmail.com>
	<91E3FFCC89704D89996C6B6C29EF89D4@CRAIGVAIO>
Message-ID: <6c14d5550904142329x30886c3dj44f6fd866537676b@mail.gmail.com>

Hi Craig,

Thank you very much for the comments.  I will address all of these issues.
The specific piece of the model that it sounds like is most objectionable
(uan-prop-bh/ and the programs that use/support it bhtest/create-dat) I knew
were poor and I've been considering how best to rework that code.  I should
have this fixed up this weekend.  I've also begun writing more
documentation.  In short, I think I will have these issues addressed in
short order.  Thanks for the tip on the nightly build also.

Leonard


On Mon, Apr 13, 2009 at 7:04 PM, <craigdo at ee.washington.edu> wrote:

>
> > I've been working on an NS3 model for simulation of wireless
> > underwater
> > acoustic network simulation.
>
> [ ... ]
>
> > Although this work is still ongoing, I'd like to submit my
> > progress thus far
> > for design review.
>
> [ ... ]
>
> From a follow-up email:
>
> > The repository has been moved to:
> http://code.nsnam.org/ltracy/ns-3-dev-uan
> >
> > A couple of known open issues:  1. I plan on reworking UanPropModelBh
> > (possibly to store information in a SQL DB).  2.  I'm guessing that
> > UanTxMode can likely be combined with WifiMode.
> >
>
> Hi Leonard,
>
> The first "minor detail" :-) is that ns-3-dev-uan doesn't build on
> ns-regression:
>
> ---------- Begin Included File ----------
> cc1plus: warnings being treated as errors
> ../src/devices/uan/uan-prop-model-bh.cc: In member function ??~virtual bool
> ns3::BhConfig::Config(std::string)??T:
> ../src/devices/uan/uan-prop-model-bh.cc:80: warning: comparison is always
> false due to limited range of data type
> ../src/devices/uan/uan-prop-model-bh.cc:92: warning: comparison is always
> false due to limited range of data type
> Build failed
> ---------- End Included File ----------
>
> This is because npos is defined as -1 and you are comparing with a
> uint32_t.
> I changed the two instances to std::sting::size_type to get it to compile.
> The same error is present in create-dat.cc in uan-apps.  You should run
> this
> code through the nightly build environment (at least to see that it
> compiles
> everywhere) using:
>
> sudo bash
> su nsnam
> cd /tmp
> nohup /usr/local/bin/ns-3-run-tests.sh -n ltracy/ns-3-dev-uan -m
> lentracy at u.washington.edu &
>
> before you make an "official" submission.  I would use this as an initial
> "acceptance test."
>
> Have you tried to generate and build Python bindings?  Have you tried to
> build and run on Cygwin?  We have a list of supported platforms and a
> common
> pitfall is to not try your code "everywhere."
>
> I expected to see an example in the directory examples with something
> descriptive in it.  There is a top-level directory called uan-apps that
> contains what seems to be example programs.  These should probably go into
> the examples directory.  If you think it is time to make a uan subdirectory
> under examples, that would be fine.  You don't build uanapps/firstuan.cc --
> is this intentional?
>
> It's evident that there is a configuration file of some sort that needs to
> be created.  I assumed that this was optional and that I could do something
> semi-useful with defaults without running this.  When I run the remaining
> example, bhtest, it asserts looking for StaticMobilityModel.  I changed
> this
> to StaticPositionMobilityModel and ran bhtest again.  When I ran bhtest,
> then it complained about not finding the config file.
>
> So I gave up on trying to get the code to execute and produce some results.
> I really think you should have an example I can just run and get results,
> or
> some more obvious documentation (I didn't see it, but I didn't look very
> hard either -- it should be easy to find, perhaps in a devices/uan/uan.h
> file as described below).  An approach I took on some of the tap bridge
> code
> that has external dependencies was to just write out what to do in the
> example as a comment.  See examples/tap-wifi-dumbbell.cc for what I did.
> Some people don't like this much commentary in an example, but it is easy
> to
> find and if you type what I tell you, it just works.  YMMV.
>
> That said, we really do need some kind of test that can be used in our
> current regression environment to let us know that everything continues to
> work as expected.  You could write a regression test that does the
> configuration, but IMO it would be helpful to be able to have a default
> configuration that doesn't require a configuration file.  Tom mentioned
> something about storing configuration information in a database.  I didn't
> see anything like that either.
>
> Ideally there should be example programs and regression tests, but we
> aren't
> very good at this and so usually what has been done is to overload an
> example program that produces trace files into doing double duty.  Take a
> look at the regression/tests directory to see what needs to go in.  For
> example, the file test-udp-echo.py causes udp-echo (source in
> examples/udp-echo.cc) to be run and the trace output compared with
> known-good bits checked into ns-3-dev-ref-traces.
>
> IMO your examples should have a few comments at least.  Most examples have
> at least an illustration of what is going on.  For example, this is from
> examples/csma-one-subnet.cc:
>
> // Network topology
> //
> //       n0    n1   n2   n3
> //       |     |    |    |
> //       =================
> //              LAN
> //
> // - CBR/UDP flows from n0 to n1 and from n3 to n0
> // - DropTail queues
> // - Tracing of queues and packet receptions to file "csma-one-subnet.tr"
>
> The Doxygen throughout is very sparse.  For example, there is no doxygen
> for
> class UanMacAloha.  Now I can guess what this means, but we really need to
> document this stuff.
>
> It is convenient to check in a copy of waf in your directory so one can
> build out of that directory, so I would check in a src/devices/uan/waf
> (copy
> from wifi).
>
> There are many instance of code that looks like:
>
> namespace ns3
> {
> class UanMac : public ns3::Object
>
> The ns3:: is redundant.  It looks like you may have added the ns3 namespace
> later.
>
> I personally like to see more NS_LOG statements, but that is really a
> matter
> of style that is up to you.  I think they are helpful, especially to people
> not intimately familiar with the code, when they're trying to get their
> bearings.
>
> I personally like to see the use of _MSG variants of the assertion and
> error
> macros.  It is quite helpful to get some initial information when something
> crashes.  But this is really a matter of style that is up to you.
>
> I personally like to see more inline comments in the code.  This can be a
> sensitive subject; but for example,
>
> ---------- Begin Included File ----------
> double
> UanNoiseModelDefault::GetNoiseDbHz(double fKhz) const
> {
>  double turb, win, ship, thermal, noise;
>  turb = 17.0 - 30.0 * log10(fKhz);
>  turb = pow(10.0, turb*0.1);
>
>  ship = 40.0 + 20.0 *(this->m_shipping-0.5) + 26.0*log10(fKhz) -
> 60.0*log10(fKhz+0.03);
>  ship = pow(10.0,(ship*0.01));
>
>  win = 50.0+7.5*pow(m_wind, 0.5) + 20.0*log10(fKhz) - 40.0*log10(fKhz+0.4);
>  win = pow(10.0, m_wind*0.1);
>
>  thermal = -15 + 20*log10(fKhz);
>  thermal = pow(10, thermal*0.1);
>
>  noise = 10*log10(turb + ship + win + thermal);
>
>  return noise;
> }
> ---------- End Included File ----------
>
> The Doxygen says that this a standard ambient acoustic noise model.  Is
> this
> something that would be obvious to anyone using this device in the real
> world?  Are all of these various numbers from some authoritative source?
> Should there be a better description or a pointer to some further
> description.  e.g., this is taken from the YaddaYaddaNoiseModel (see
> http://YaddaYaddaNoiseModel.htm for details).
>
> Other devices have a file (cf src/devices/csma/csma.h) that describes what
> the purpose of the model is, what it is attempting to model and a basic
> description of the device and channel.  This would be very helpful.  For
> example, I can imagine how all of the pieces of your device fit together,
> but it is always better to have some documentation.  Eventually, someone is
> going to suggest that you write a chapter for the manual and have pictures
> with circles and arrows ...
>
> I get nervous when I see things like,
>
>  // TODO Auto-generated constructor stub
>
> in the code.  Have you run valgrind?
>
> It's really par for the source, but I have the usual coding standard nits
> that seem to be part of every review.  This is going to be painful to fix,
> and probably sounds pedantic, but every project has its own version and we
> really do want to have a similar coding style across the project.  Everyone
> seems to get caught by this to some extent or another.
>
> 1) You should make sure that every source file starts with an emacs mode
> line, has an appropriate GPL comment at the top with copyright holder, etc.
> You have some of this, but for example, uan-address.cc doesn't have an
> emacs
> mode line and uan-prop-model-bh.cc doesn't have any.
>
> 2) You have lots of cases of CamelCase member variables (e.g., uint32_t
> m_FreqStepHz) that should be camelBack (e.g., uint32_t m_freqStepHz).  See
> the file codingstd.txt under the doc directory.
>
> 3) You have lots of cases where your types and parens don't follow the GNU
> practice.  For example, you should use
>
>  string&
>  BhConfig::trim (string& s)
>
> and not
>
>  string& BhConfig::trim( string& s )
>
> I found a couple of malformed while and do constructs, but I lost them ...
> sorry.
>
> I realize this has been a litany of negative comments.  The majority of
> this
> should be easily addressed.
>
> The one thing that stood out to me was that I couldn't just "open the box,"
> run an example program and get something to work, start looking at traces,
> turn on logs, etc.  I submit that this is an important feature for people
> who are starting to use your model.  You don't want to turn them off before
> they see how great your stuff really is (:-).  You'll have to remedy the
> config issue somehow for a regression test, so hopefully it's no big deal
> to
> check in some kind of default configuration and stick in some log messages.
>
> I really can't comment on the model itself since I'm not a domain expert;
> and I really have no reasonable way of knowing what your model is supposed
> to do other than reading 25 KLOC.
>
> Regards,
>
> -- Craig
>
>
>

From mathieu.lacage at sophia.inria.fr  Wed Apr 15 00:07:03 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 15 Apr 2009 09:07:03 +0200
Subject: [Ns-developers] c0de review submission HOWTO
In-Reply-To: <1239692630.6390.38.camel@diese.inria.fr>
References: <1239692630.6390.38.camel@diese.inria.fr>
Message-ID: <1239779223.17543.12.camel@diese.inria.fr>

hi all,

After 2 iterations with mirko, I would like to point out a couple of
important issues:

1) When there are multiple iterations over a review (patch submited,
review done, new patch submitted, new review done), it might be easier
to submit a patch _relative_ to the previous patch to help the reviewer
assess what changes you really did. But, it might also be easier to
generate a complete patch: it really depends on the context. Generally,
if you produce a complete patch which is not relative to the previous
review, you _need_ to produce also some explanation text to explain what
you changed such that the reviewer can review these parts without having
to look again at everything in the patch. If you produce a relative
patch, it's ok to not include that explanation because the patch already
contains that information.

2) It helps a lot to _split_ the changes in independent small simple
patches: simple method renames can be done either as a separate
preparation patch or as a followup patch. These decrease the size of
each patch to review, and thus make it easier to merge these patches
quickly in ns-3-dev.

I know that this is a lot of pain for submitters but it's also a lot of
pain for reviewers so, we really need to figure out a decent way to
handle this process.

Mathieu

On Tue, 2009-04-14 at 09:03 +0200, Mathieu Lacage wrote:
> (strange title to go through the ns-dev filters)
> 
> hi,
> 
> Since I did not receive screaming emails saying that it was a horribly
> bad idea, I created http://groups.google.com/group/ns-3-reviews/, and I
> would like to suggest everyone who wants to submit a review to:
> 
> 0) download http://codereview.appspot.com/static/upload.py
> 1) record the changes you want to request a review for in a mercurial
> repository: "hg commit ..."
> 2) within the mercurial repository, run upload.py to submit a review
> with http://codereview.appspot.com/. Make sure you specify
> ns-3-reviews at googlegroups.com as a CC.
> 3) Paste your review request on
> http://www.nsnam.org/wiki/index.php/Reviews or send me an email and I
> will add it there
> 4) announce your review request on ns-developers
> 
> thank you,
> Mathieu
> 


From mathieu.lacage at sophia.inria.fr  Wed Apr 15 00:26:42 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 15 Apr 2009 09:26:42 +0200
Subject: [Ns-developers] Review request (ns-3-simu extension) (Re: About
 real-world application integration)
In-Reply-To: <m2d4bf9pa0.wl@sfc.wide.ad.jp>
References: <m2tz67w3f6.wl@sfc.wide.ad.jp>
	<1236790499.658.31.camel@mathieu-laptop>
	<1237193331.31135.36.camel@diese.inria.fr>
	<m27i2pwzxf.wl@sfc.wide.ad.jp>
	<1237198269.31135.121.camel@diese.inria.fr>
	<m2tz57qbnw.wl@sfc.wide.ad.jp> <m2d4bf9pa0.wl@sfc.wide.ad.jp>
Message-ID: <1239780402.17543.19.camel@diese.inria.fr>

hi hajime,

I looked at these patches and posted some reviews for some of them. A
couple of high-level comments:

1) Most of these are too small to be a single review request: you need
to group them logically for me to be able to make sense of them. For
example all these should be a single review request:
http://codereview.appspot.com/40069
http://codereview.appspot.com/40068
http://codereview.appspot.com/41047
http://codereview.appspot.com/40067

2) There are obviously pieces missing from the patchset: where is the
implementation of simu_getopt_long_r ?

Generally, I think that when you (or anyone else) submits a patch, you
have to ask yourself: what would I do if I had to review this patch ? Is
this patch sufficiently self-contained to allow the reviewer to review
it ? Do I need to provide explanation text ? Can I split this patch in
separate self-contained smaller pieces ? i.e., the question is: what can
I do to make it as easy as possible for the reviewer to say 'ACK,
please, apply' ? If you have good answers to these questions, the
chances are good that your patches will go in ns-3-dev really quickly
with few reviews. If you don't, changes are good that it will take a lot
of work and iterations with a reviewer which is really not good for
anyone.

Mathieu

On Wed, 2009-04-15 at 01:24 +0900, Hajime Tazaki wrote:
> Hi All,
> 
> >http://www.sfc.wide.ad.jp/~tazaki/hg/ns-3-simu-mod/
> 
> I post several review requests.
> 
> http://codereview.appspot.com/40071
> http://codereview.appspot.com/41049
> http://codereview.appspot.com/41048
> http://codereview.appspot.com/40070
> http://codereview.appspot.com/40069
> http://codereview.appspot.com/40068
> http://codereview.appspot.com/41047
> http://codereview.appspot.com/40067
> http://codereview.appspot.com/41046
> http://codereview.appspot.com/41045
> http://codereview.appspot.com/40065
> http://codereview.appspot.com/40064
> http://codereview.appspot.com/40063
> http://codereview.appspot.com/41044
> http://codereview.appspot.com/41043
> http://codereview.appspot.com/40062
> http://codereview.appspot.com/40061
> http://codereview.appspot.com/40060
> http://codereview.appspot.com/40059
> 
> regards,
> hajime
> 


From gjcarneiro at gmail.com  Wed Apr 15 02:28:08 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Wed, 15 Apr 2009 10:28:08 +0100
Subject: [Ns-developers] c0de review submission HOWTO
In-Reply-To: <1239779223.17543.12.camel@diese.inria.fr>
References: <1239692630.6390.38.camel@diese.inria.fr>
	<1239779223.17543.12.camel@diese.inria.fr>
Message-ID: <a467ca4f0904150228v48ea6a4ew4c66bfc77ba562fb@mail.gmail.com>

2009/4/15 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> hi all,
>
> After 2 iterations with mirko, I would like to point out a couple of
> important issues:
>
> 1) When there are multiple iterations over a review (patch submited,
> review done, new patch submitted, new review done), it might be easier
> to submit a patch _relative_ to the previous patch to help the reviewer
> assess what changes you really did. But, it might also be easier to
> generate a complete patch: it really depends on the context. Generally,
> if you produce a complete patch which is not relative to the previous
> review, you _need_ to produce also some explanation text to explain what
> you changed such that the reviewer can review these parts without having
> to look again at everything in the patch. If you produce a relative
> patch, it's ok to not include that explanation because the patch already
> contains that information.
>
> 2) It helps a lot to _split_ the changes in independent small simple
> patches: simple method renames can be done either as a separate
> preparation patch or as a followup patch. These decrease the size of
> each patch to review, and thus make it easier to merge these patches
> quickly in ns-3-dev.
>
> I know that this is a lot of pain for submitters but it's also a lot of
> pain for reviewers so, we really need to figure out a decent way to
> handle this process.


This is why I think this review tool is not enough.  For trivial patches, I
think it's not worth the trouble to use a review tool.  For extensive
changes, puiblishing a mercurial branch is probably a better solution,
because with a branch the reviewer already has access to both absolute and
incremental changes, taking care of your first point, and small separate
commits can take care of your second point.

This is not your fault, and I do not have any better solution.  Just
pointing out some conclusions I reached.  Probably the ideal tool would
allow online annotations, like rietveld, but would work on top of a
mercurial branch instead of a plain patch.  Unfortunately, probably such a
tool does not exist.  And so this email is probably not helping, I know...
:-)


>
>
> Mathieu
>
> On Tue, 2009-04-14 at 09:03 +0200, Mathieu Lacage wrote:
> > (strange title to go through the ns-dev filters)
> >
> > hi,
> >
> > Since I did not receive screaming emails saying that it was a horribly
> > bad idea, I created http://groups.google.com/group/ns-3-reviews/, and I
> > would like to suggest everyone who wants to submit a review to:
> >
> > 0) download http://codereview.appspot.com/static/upload.py
> > 1) record the changes you want to request a review for in a mercurial
> > repository: "hg commit ..."
> > 2) within the mercurial repository, run upload.py to submit a review
> > with http://codereview.appspot.com/. Make sure you specify
> > ns-3-reviews at googlegroups.com as a CC.
> > 3) Paste your review request on
> > http://www.nsnam.org/wiki/index.php/Reviews or send me an email and I
> > will add it there
> > 4) announce your review request on ns-developers
> >
> > thank you,
> > Mathieu
> >
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From tomh at tomh.org  Wed Apr 15 07:39:56 2009
From: tomh at tomh.org (Tom Henderson)
Date: Wed, 15 Apr 2009 07:39:56 -0700
Subject: [Ns-developers] ns-3.5 planning
In-Reply-To: <1239715971.6390.176.camel@diese.inria.fr>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>
Message-ID: <49E5F1BC.1070501@tomh.org>


> Here is my understanding of the status of each separate item:
> 
> 1) ipv4 rework: tom and I agreed to try to split it, and specifically,
> try to split the API changes from the implementation changes. Right now,
> the proposal is to merge the following trees:
>   - mathieu/ns-3-olsr
>   - tomh/ns-3-ip-interfaces
 >   - tomh/ns-3-ip-routing

I didn't yet socialize these trees to the list yet for review but they 
are ready for review.  I will introduce these in a separate mail.

>    -tomh/ns-3-ip-interfaces: my main comment for this tree is that I am
> still unsure I understand what the peer field is supposed to represent
> and how it is expected to be used.

This is a field in struct in_addr used for point-to-point links in 
Linux; documentation from iproute2:

  peer ADDRESS--- address of remote endpoint for pointopoint interfaces.

We do not use this in our code right now, so it could be commented out 
until it is used.

>   - tomh/ns-3-ip-routing: missing a README.api. Ipv4Route should derive
> from src/node/ref-count-based.h instead of implementing Ref+Unref.

OK.  This tree is not as far along as the other tree in incorporating 
the proposed routing changes that are in ns-3-ip tree.

> 
> Needed followup patches:
>   - new src/helper/ipv4-routing-helper.h 
>   - move src/internet-stack/static-routing-protocol.h to src/node,
> modify it to implement a linux-like routing table API
>   - introduce a loopback device, remove Ipv4LoopbackInterface
>   - remove virtual methods from Ipv4Interface
>   - add src/node/arp.h, implement it in ArpL3Protocol

agree with all of the above

>   - remove ::SetNode in src/internet-stack/*.h|cc: all these objects are
> aggregated to a node, so, they can call GetObject.
>   - remove src/internet-stack/internet-stack.cc:
>       a) make UdpL4Protocol aggregate UdpSocketFactory to self from
> constructor. Same for TcpL4Protocol/TcpSocketFactory.
>       b) add src/core/object.h: call NotifyNewAggregate from
> AggregateObject
>       c) Hook in NotifyNewAggregate from UdpL4Protocol, check for
> Ipv4L3Protocol, register new l4 protocol when Ipv4L3Protocol is
> aggregated or when they are created

I hadn't planned to do the above replumbing, but one improvement that 
the current ns-3-ip-interfaces has is the removal of class Ipv4Impl. 
I'll leave the above alone for now since they are somewhat orthogonal to 
the routing stuff (which is where I want to focus).

> 
> 4) virtual devices was sent here for review a long time ago:
> http://code.nsnam.org/gjc/ns-3-virtual-netdevice/ I think that it could
> be useful to more users so, I would support merging it and would be
> happy to help gustavo port this to ns-3-dev.

+1 but we could probably call this one a TapDevice.

> 8) so far, ipv6 is blocked on item 1) and item 1. is far from being
> finished. If I put my realistic hat on, I predict that there is zero
> chance to complete 1) sufficiently early to allow ipv6 to go in this
> release cycle.

I would like to move forward on a few IPv6 things at least in this 
release cycle, but I agree that the item 1 work is substantial.


> 
> 10) This was posted a while ago: tom agreed on the basic idea with minor
> comments, and there were no other comments. I think that it could go in
> in a couple of days once we have fixed the identified issues.
> 

Agree.

- Tom

From tomh at tomh.org  Wed Apr 15 08:03:05 2009
From: tomh at tomh.org (Tom Henderson)
Date: Wed, 15 Apr 2009 08:03:05 -0700
Subject: [Ns-developers] IP trees for review
Message-ID: <49E5F729.5040301@tomh.org>

This is a follow-up on threads that started last January:
http://mailman.isi.edu/pipermail/ns-developers/2009-January/005206.html

Since then, we decided not to push for ns-3.4 merge, but wait for ns-3.5 
cycle and do merges earlier in the review cycle.

The tree that has been holding this code previously is
http://code.nsnam.org/tomh/ns-3-ip

In an effort to try to capture where all of this work is headed, I 
created some figures and documentation and posted them here:

http://www.nsnam.org/~tomh/manual/manual.html#SEC1

Comments are still welcome on the overall design plan, but there haven't 
been any major ones so far.

To start review and merge, I created two repos that take portions of the 
previous tree and isolate some changes into a few changesets:

1) ns-3-ip-interfaces:  http://code.nsnam.org/tomh/ns-3-ip-interfaces
   - deconflict NetDevice::ifIndex and Ipv4::ifIndex (bug 85)
   - allow multiple IPv4 addresses to be assigned to an interface (bug 188)
   - remove class Ipv4Impl (this is just a general cleanup item)

See the README.api file in that repo for more details about the API 
changes proposed.

2) ns-3-ip-routing:  http://code.nsnam.org/tomh/ns-3-ip-routing
   - split Ipv4RoutingProtocol declaration out of ipv4.h
   - make Ipv4Route and Ipv4MulticastRoute use smart pointers

The above two things are the tip of the iceberg for this work but are 
initial mergeable chunks.

I can add an item into the code review tool later today or tomorrow to 
allow detailed comments to be logged there.

- Tom

From f1mauchl at hsr.ch  Wed Apr 15 01:03:49 2009
From: f1mauchl at hsr.ch (Fabian Mauchle)
Date: Wed, 15 Apr 2009 10:03:49 +0200
Subject: [Ns-developers] ns-3.5 planning / mac multicast
In-Reply-To: <1239715971.6390.176.camel@diese.inria.fr>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>
Message-ID: <001201c9bda0$b754e120$25fea360$@ch>

Hi all,
hi Mathieu

I recently worked on multicasting in Wifi networks. The current
implementation of MAC multicast in Wifi and Csma networks do basically their
thing, but they do not correctly represent reality.

1. The NetDevice is currently responsible for creating the multicast MAC
address [NetDevice::GetMulticast(Ipv4Address)]. I don't know of any real API
which would do this.

2. Most NetDevices accept all (or most) multicast frames without any
selection or configuration. After I have seen some hints in several RFC's
that a L3 protocol MUST register the multicast addresses (MAC) it wants to
listen to, I searched for an API for this and found one in Linux [see
manpage netdevice (7)]

3. The netdevice API in Linux also allows to enable or disable promiscuous
mode. The NetDevice API in ns-3 only allows the registration of a
promiscuous or non-promiscuous receive callback.

My current plans are as follows:
- I will try to adapt the NetDevice API to the linux API
- Any implementation of the NetDeivce is still free how they treat multicast
frames
- Revert the creation and control over multicast addresses to the
Ipv4L3Protocol*
- I will try to figure out which other components are affected
- I will try to come up with a patch within 2-3 weeks from now.

*The use of multicast in IPv4 is relatively rare. This prepares basically
for IPv6 since it often makes use of multicast.

What are your feelings about this?

Regards

Fabian Mauchle
Institute for Internet Technologies and Applications,
University of Applied Sciences Rapperswil, Switzerland




From tazaki at sfc.wide.ad.jp  Wed Apr 15 08:11:26 2009
From: tazaki at sfc.wide.ad.jp (Hajime Tazaki)
Date: Thu, 16 Apr 2009 00:11:26 +0900
Subject: [Ns-developers] Review request (ns-3-simu extension) (Re: About
	real-world application integration)
In-Reply-To: <1239780402.17543.19.camel@diese.inria.fr>
References: <m2tz67w3f6.wl@sfc.wide.ad.jp>
	<1236790499.658.31.camel@mathieu-laptop>
	<1237193331.31135.36.camel@diese.inria.fr>
	<m27i2pwzxf.wl@sfc.wide.ad.jp>
	<1237198269.31135.121.camel@diese.inria.fr>
	<m2tz57qbnw.wl@sfc.wide.ad.jp> <m2d4bf9pa0.wl@sfc.wide.ad.jp>
	<1239780402.17543.19.camel@diese.inria.fr>
Message-ID: <m27i1m9ckh.wl@sfc.wide.ad.jp>


Hi Mathieu,

At Wed, 15 Apr 2009 09:26:42 +0200,
Mathieu Lacage wrote:
>
>hi hajime,
>
>I looked at these patches and posted some reviews for some of them. A
>couple of high-level comments:
>
>1) Most of these are too small to be a single review request: you need
>to group them logically for me to be able to make sense of them. For
>example all these should be a single review request:
>http://codereview.appspot.com/40069
>http://codereview.appspot.com/40068
>http://codereview.appspot.com/41047
>http://codereview.appspot.com/40067

Okay, 

- Adding simu_xxx method
http://codereview.appspot.com/40071
http://codereview.appspot.com/41049
http://codereview.appspot.com/41048
http://codereview.appspot.com/40070
http://codereview.appspot.com/40069
http://codereview.appspot.com/40068
http://codereview.appspot.com/41047
http://codereview.appspot.com/40067
http://codereview.appspot.com/41046
http://codereview.appspot.com/41044
http://codereview.appspot.com/41043

- fix the problem multiple process stop failure
http://codereview.appspot.com/41045


- Cmsg function enhancement
http://codereview.appspot.com/40065
http://codereview.appspot.com/40064
http://codereview.appspot.com/40063
http://codereview.appspot.com/40062
http://codereview.appspot.com/40061

- clear memory in initialization
http://codereview.appspot.com/40060

- add SocketRecvIfTag and SetIfIndex in socket.cc
http://codereview.appspot.com/40059

next time, I'll try to request better than now.
But maybe I have to be careful to commit in local
repository.

If upload.py can select several changset during post, it's
better..


>2) There are obviously pieces missing from the patchset: where is the
>implementation of simu_getopt_long_r ?

Sorry, the following is that.
http://codereview.appspot.com/40071/show

The revision number between local repo and another repo was
different (I'm not sure). It made a wrong title for issues...

>Generally, I think that when you (or anyone else) submits a patch, you
>have to ask yourself: what would I do if I had to review this patch ? Is
>this patch sufficiently self-contained to allow the reviewer to review
>it ? Do I need to provide explanation text ? Can I split this patch in
>separate self-contained smaller pieces ? i.e., the question is: what can
>I do to make it as easy as possible for the reviewer to say 'ACK,
>please, apply' ? If you have good answers to these questions, the
>chances are good that your patches will go in ns-3-dev really quickly
>with few reviews. If you don't, changes are good that it will take a lot
>of work and iterations with a reviewer which is really not good for
>anyone.

I see, you are right.


regards,
hajime

>Mathieu
>
>On Wed, 2009-04-15 at 01:24 +0900, Hajime Tazaki wrote:
>> Hi All,
>> 
>> >http://www.sfc.wide.ad.jp/~tazaki/hg/ns-3-simu-mod/
>> 
>> I post several review requests.
>> 
>> http://codereview.appspot.com/40071
>> http://codereview.appspot.com/41049
>> http://codereview.appspot.com/41048
>> http://codereview.appspot.com/40070
>> http://codereview.appspot.com/40069
>> http://codereview.appspot.com/40068
>> http://codereview.appspot.com/41047
>> http://codereview.appspot.com/40067
>> http://codereview.appspot.com/41046
>> http://codereview.appspot.com/41045
>> http://codereview.appspot.com/40065
>> http://codereview.appspot.com/40064
>> http://codereview.appspot.com/40063
>> http://codereview.appspot.com/41044
>> http://codereview.appspot.com/41043
>> http://codereview.appspot.com/40062
>> http://codereview.appspot.com/40061
>> http://codereview.appspot.com/40060
>> http://codereview.appspot.com/40059
>> 
>> regards,
>> hajime
>> 
>

From mathieu.lacage at sophia.inria.fr  Thu Apr 16 04:42:02 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 16 Apr 2009 13:42:02 +0200
Subject: [Ns-developers] ns-3.5 planning / mac multicast
In-Reply-To: <001201c9bda0$b754e120$25fea360$@ch>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>
	<001201c9bda0$b754e120$25fea360$@ch>
Message-ID: <1239882122.29455.28.camel@diese.inria.fr>

On Wed, 2009-04-15 at 10:03 +0200, Fabian Mauchle wrote:

> I recently worked on multicasting in Wifi networks. The current
> implementation of MAC multicast in Wifi and Csma networks do basically their
> thing, but they do not correctly represent reality.
> 
> 1. The NetDevice is currently responsible for creating the multicast MAC
> address [NetDevice::GetMulticast(Ipv4Address)]. I don't know of any real API
> which would do this.

It is merely responsible for creating a MAC-level multicast address
which matches the higher-layer multicast address. The reason this is
done is to encapsulate the MAC address format from the higher layers. If
you don't do this, you will have to move knowledge of the MAC-level
address format to the ip layer. Linux does this, BSD too, but it's not
very pretty.

> 2. Most NetDevices accept all (or most) multicast frames without any
> selection or configuration. After I have seen some hints in several RFC's
> that a L3 protocol MUST register the multicast addresses (MAC) it wants to
> listen to, I searched for an API for this and found one in Linux [see
> manpage netdevice (7)]

Well, in the real world, there is device-level multicast frame filtering
to avoid transfering too many uneeded frames from the device to the
host. However, in every real device/driver I looked at, there is no
guarantee that this actually works (real device filters usually use a
small local hash cache with 16 entries to accept incoming packets which
means that incoming packets with a matching multicast address but which
are not listened to by the host will be forwarded to the host anyway. To
summarize, this kind of API is merely an optimization: it does not
change the logic which needs to be present in the ip stack to eliminate
multicast packets received which we are not listening to.

> 
> 3. The netdevice API in Linux also allows to enable or disable promiscuous
> mode. The NetDevice API in ns-3 only allows the registration of a
> promiscuous or non-promiscuous receive callback.

Yes: I already argued against the current ns-3 API and for the linux API
but I lost that argument a long time ago so, if you want to put this
back on the table, I would suggest you look in the mailing-list
archives.

> 
> My current plans are as follows:
> - I will try to adapt the NetDevice API to the linux API
> - Any implementation of the NetDeivce is still free how they treat multicast
> frames
> - Revert the creation and control over multicast addresses to the
> Ipv4L3Protocol*
> - I will try to figure out which other components are affected
> - I will try to come up with a patch within 2-3 weeks from now.
> 
> *The use of multicast in IPv4 is relatively rare. This prepares basically
> for IPv6 since it often makes use of multicast.
> 
> What are your feelings about this?

I think that using a promiscuous mode instead of a promiscuous callback
would simplify a lot the reception code in devices and would make sense
but I feel that this change will be an uphill battle. I don't really
understand the purpose of the other changes you mentioned but, I would
be happy to keep discussing these here.

Mathieu


From nbaldo at cttc.es  Thu Apr 16 07:25:08 2009
From: nbaldo at cttc.es (Nicola Baldo)
Date: Thu, 16 Apr 2009 16:25:08 +0200
Subject: [Ns-developers] radiotap [was: ns-3.5 planning]
In-Reply-To: <1239715971.6390.176.camel@diese.inria.fr>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>
Message-ID: <49E73FC4.1080100@cttc.es>

Hi,

Mathieu Lacage wrote:
> if there is an item you are working on and you believe should be
> considered for this new release cycle which will end in mid-june with a
> new release, please, let me/us know _now_.
> 

I have been working on radiotap header support for wifi. The current 
status is that the basic functionality is working. Therefore I am asking 
  for it to be reviewed and considered for inclusion in ns-3.5.

http://codereview.appspot.com/40109
http://code.nsnam.org/nbaldo/ns-3-dev-radiotap/

To see what it does, just run some wifi simulation with pcap output 
(such as examples/wifi-wired-bridging), open one of the pcap files with 
wireshark, and you should see the newly added radiotap header.

Feedback welcome!

Regards,

Nicola

From nbaldo at cttc.es  Thu Apr 16 08:00:50 2009
From: nbaldo at cttc.es (Nicola Baldo)
Date: Thu, 16 Apr 2009 17:00:50 +0200
Subject: [Ns-developers] c0de review submission HOWTO
In-Reply-To: <1239692630.6390.38.camel@diese.inria.fr>
References: <1239692630.6390.38.camel@diese.inria.fr>
Message-ID: <49E74822.4090806@cttc.es>

Hi,

> Since I did not receive screaming emails saying that it was a horribly
> bad idea, I created http://groups.google.com/group/ns-3-reviews/, and I
> would like to suggest everyone who wants to submit a review to:
> 
> 0) download http://codereview.appspot.com/static/upload.py
> 1) record the changes you want to request a review for in a mercurial
> repository: "hg commit ..."
> 2) within the mercurial repository, run upload.py to submit a review
> with http://codereview.appspot.com/. Make sure you specify
> ns-3-reviews at googlegroups.com as a CC.

I had some trouble when submitting the radiotap code for review. In the 
repository I was working I had already pulled changes from ns-3-dev a 
couple of times. Due to limitations in upload.py, also the changesets 
pulled from ns-3-dev were published on codereview, which is of course 
not desirable.

I found the following workaround:

# assumption: DEV_BRANCH_WITH_NEW_FEATURE is in sync with ns-3-dev
hg clone http://code.nsnam.org/ns-3-dev ns-3-tmp
cd ns-3-tmp
export REVNO=`hg tip -q | sed 's/:.*$//'`
hg pull DEV_BRANCH_WITH_NEW_FEATURE
hg merge
hg commit -m "merged new feature"
upload.py --rev=$REVNO --cc=ns-3-reviews at googlegroups.com

Of course if anybody has a better solution I'd be glad to hear about it!

Regards,

Nicola






From gjcarneiro at gmail.com  Thu Apr 16 04:10:57 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Thu, 16 Apr 2009 12:10:57 +0100
Subject: [Ns-developers] code review tool
In-Reply-To: <1239312717.16137.27.camel@mathieu-laptop>
References: <1239312717.16137.27.camel@mathieu-laptop>
Message-ID: <a467ca4f0904160410q62730ff1i6c1e258a6f8f7c82@mail.gmail.com>

Hi,

I have been having problems submitting patches to codereview when behind a
company http proxy (ports 80/443 are firewalled).  Has anyone experienced
such problems, or is it just me?

Traceback (most recent call last):
  File "/home/gjc/bin/codereview-upload.py", line 1387, in <module>
    main()
  File "/home/gjc/bin/codereview-upload.py", line 1379, in main
    RealMain(sys.argv)
  File "/home/gjc/bin/codereview-upload.py", line 1347, in RealMain
    response_body = rpc_server.Send("/upload", body, content_type=ctype)
  File "/home/gjc/bin/codereview-upload.py", line 334, in Send
    self._Authenticate()
  File "/home/gjc/bin/codereview-upload.py", line 349, in _Authenticate
    super(HttpRpcServer, self)._Authenticate()
  File "/home/gjc/bin/codereview-upload.py", line 257, in _Authenticate
    auth_token = self._GetAuthToken(credentials[0], credentials[1])
  File "/home/gjc/bin/codereview-upload.py", line 201, in _GetAuthToken
    response = self.opener.open(req)
  File "/usr/lib/python2.5/urllib2.py", line 381, in open
    response = self._open(req, data)
  File "/usr/lib/python2.5/urllib2.py", line 399, in _open
    '_open', req)
  File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.5/urllib2.py", line 675, in <lambda>
    meth(r, proxy, type))
  File "/usr/lib/python2.5/urllib2.py", line 698, in proxy_open
    return self.parent.open(req)
  File "/usr/lib/python2.5/urllib2.py", line 387, in open
    response = meth(req, response)
  File "/usr/lib/python2.5/urllib2.py", line 498, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.5/urllib2.py", line 425, in error
    return self._call_chain(*args)
  File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.5/urllib2.py", line 506, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 400: Bad Request


2009/4/9 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> hi,
>
> Because the number of pending code reviews is growing quickly, and email
> is a pain to deal with them, tom and I would like to get a code review
> tool up and running. A new collegue of mine, Faker looked at
> review-board.org which looks cool in a demo but is a real pain to setup
> correctly and seems to be problematic to use for our mercurial-based
> workflow.
>
> So, I would like to suggest that we use rietveld instead. I uploaded a
> sample patch: http://codereview.appspot.com/37042
> and anyone can review it if they have a google account. If you have a
> google account, you can also post new patches for review:
> http://codereview.appspot.com/new
>
> I used the upload.py script mentioned in the webpage above to create
> this test review patch:
> hg clone http://code.nsnam.org/mathieu/ns-3-simu
> cd ns-3-simu
> # edit README
> hg ci -m "test" README
> upload.py --rev=4583
>
> The above is pretty straightforward which is why I feel it would be nice
> to pick this tool and just go ahead with actually doing code reviews :)
>
> So, I would like to propose that:
> 1) we create a google group ns-3-reviews: if you want to follow through
> email code reviews, this is where you should subscribe
> 2) we ask those who submit code for review/inclusion to submit it
> through rietveld with upload.py  (I believe that the web interface will
> not work with anything but svn repositories but I would be happy to be
> proven wrong) and make sure they CC ns-3-reviews
>
> One thing some might feel concerned about is adding a dependency on an
> externally-maintained server: I personally don't feel bad about this: we
> can always install a copy of rietveld on a server of our own if we are
> unhappy about google's handling of the corereview.appspot.com server.
>
> It would be nice to hear positive or negative comments about this
> proposal.
>
> Mathieu
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From nbaldo at cttc.es  Fri Apr 17 02:41:41 2009
From: nbaldo at cttc.es (Nicola Baldo)
Date: Fri, 17 Apr 2009 11:41:41 +0200
Subject: [Ns-developers] spectrum modeling [was: ns-3.5 planning]
In-Reply-To: <1239715971.6390.176.camel@diese.inria.fr>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>
Message-ID: <49E84ED5.7010603@cttc.es>

Hi again,

> if there is an item you are working on and you believe should be
> considered for this new release cycle which will end in mid-june with a
> new release, please, let me/us know _now_.

I have also been working on spectrum modeling, as I anticipated some 
time ago on this list. What is available right now is the following:
	
1) a class (ValuesVsFreq) providing the representation of 
frequency-dependent things (such as spectral power density, propagation 
loss, tx/rx mask...);

2) interfaces definitions for the spectrum-aware channel, phy and 
propagation loss model (delay model is the same as wifi);

3) a basic but usable implementation of the channel and the 
spectrum-aware version of the Friis propagation model;

4) two sample PHY layer implementations (WaveformGenerator and 
SpectrumAnalyzer) and a couple of test scripts to test everything and 
show how it works.


What is still missing are PHY layers to be used within a NetDevice 
context, and in particular something that can work with the current wifi 
code -- either some code which can interact with the existing 
YansWifiPhy, or a brand new WifiPhy implementation. I plan to be working 
on this issue the near future.

You can find the code here:
http://code.nsnam.org/nbaldo/ns-3-dev-spectrum/

Any feedback would be very much appreciated, as well as any intent to 
cooperate in this development. I would be happy to have all this code 
included in ns-3-dev at some point, but I am not sure of whether this 
can happen for ns-3.5. The point in favor of this is that the new 
features do not mess up with existing code, so including it does no 
harm. The point against is that at the moment there is still nothing 
which can be really useful for practical purposes; more modules need to 
be developed for this.

Regards,

Nicola





From ruben at net.t-labs.tu-berlin.de  Fri Apr 17 06:09:41 2009
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Fri, 17 Apr 2009 15:09:41 +0200
Subject: [Ns-developers] spectrum modeling [was: ns-3.5 planning]
In-Reply-To: <49E84ED5.7010603@cttc.es>
References: <49D4CA6C.5060405@tomh.org>	<1239715971.6390.176.camel@diese.inria.fr>
	<49E84ED5.7010603@cttc.es>
Message-ID: <49E87F95.1070206@net.t-labs.tu-berlin.de>

Hi Nicola,

Comments below,

On 4/17/09 11:41 AM, Nicola Baldo wrote:
> Hi again,
>
>> if there is an item you are working on and you believe should be
>> considered for this new release cycle which will end in mid-june with a
>> new release, please, let me/us know _now_.
>
> I have also been working on spectrum modeling, as I anticipated some
> time ago on this list. What is available right now is the following:
>
> 1) a class (ValuesVsFreq) providing the representation of
> frequency-dependent things (such as spectral power density, propagation
> loss, tx/rx mask...);
>
> 2) interfaces definitions for the spectrum-aware channel, phy and
> propagation loss model (delay model is the same as wifi);
>
> 3) a basic but usable implementation of the channel and the
> spectrum-aware version of the Friis propagation model;
>
> 4) two sample PHY layer implementations (WaveformGenerator and
> SpectrumAnalyzer) and a couple of test scripts to test everything and
> show how it works.

Could you explain a bit what these two (WaveformGenerator and 
SpectrumAnalyzer) are?

>
> What is still missing are PHY layers to be used within a NetDevice
> context, and in particular something that can work with the current wifi
> code -- either some code which can interact with the existing
> YansWifiPhy, or a brand new WifiPhy implementation. I plan to be working
> on this issue the near future.
>
> You can find the code here:
> http://code.nsnam.org/nbaldo/ns-3-dev-spectrum/
>
> Any feedback would be very much appreciated, as well as any intent to
> cooperate in this development. I would be happy to have all this code

As we already discussed at the ns-3 workshop last month, we are slowly 
moving forward in terms of setting up measurements  for the validation 
of the physical layer. I believe that your code could be the right place 
to start integrating the results of our measurements, especially for 
propagation issues and frequency dependent behavior. What do you think?

Best
Ruben

> included in ns-3-dev at some point, but I am not sure of whether this
> can happen for ns-3.5. The point in favor of this is that the new
> features do not mess up with existing code, so including it does no
> harm. The point against is that at the moment there is still nothing
> which can be really useful for practical purposes; more modules need to
> be developed for this.
>
> Regards,
>
> Nicola
>
>
>
>

-- 
Ruben Merz                   Deutsche Telekom Laboratories
http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml

From craigdo at ee.washington.edu  Fri Apr 17 16:10:36 2009
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Fri, 17 Apr 2009 16:10:36 -0700
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <49E84ED5.7010603@cttc.es>
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr>
	<49E84ED5.7010603@cttc.es>
Message-ID: <005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>

Hi All,

Some of you may have noticed that I've been pondering what to do about validation and verification of ns-3 models.  I've played
around a bit and have an example put together that does some statistical validation of a subset of our random number generators.

Some folks around here have expressed an interest in getting this cleaned up and checked in fairly quickly.  So even though this is
not even close to fully baked I thought I'd socialize what I have.  Feel free to comment or tell me I'm on crack, as another one of
the developers is fond of saying.

The high-level idea is to sharpen our models for what we consider system/integration/regression tests.  Right now we have regression
tests that are basically example programs we have pressed into double duty.  We want to move toward purpose-build verification tests
and away from the trace-file-based example program hacks we have today.  We also want to add some form of validation framework where
people can demonstrate that their models are connected with some kind of reality.  As a byproduct of this validation and
verification test effort, we would like to see something that can be used as a regression suite and as a side-effect also generate
something that can be used on a validation and verification website (pretty pictures).

I've put together some words on the wiki.  They're kind of incomplete ramblings and thoughts right now, but you can probably get a
decent flavor of where I'm going (don't hold me to anything):

http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting

As it stands, the two areas of verification and validation are quite separate, but they'll most likely get folded together as things
develop.

I have random number generator tests built that do statistical validation, generate pretty plots and can be run as regression tests.
I'll eventually integrate them into waf, but they are stand-alone right now.  As an example of a validation wiki, I put together the
following:

http://www.nsnam.org/wiki/index.php/StochasticModelValidation

It's not intended to be complete and thorough (although the chi square tests are real) just a demonstration of where we are headed.

The code can be found at:

http://code.nsnam.org/craigdo/ns-3-valver

with the rng tests in validation/rng and the beginnings of a TCP verification test in verification/tcp (not much there yet).

If you have any plans or ideas please don't hesitate to let me know about them.  If you are doing validation tests on your own, I'd
love to figure out how to make it easy to integrate them.

Regards,

-- Craig


From gjcarneiro at gmail.com  Sat Apr 18 03:44:15 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Sat, 18 Apr 2009 11:44:15 +0100
Subject: [Ns-developers] [Ns-commits] Output of run-tests script: failure
In-Reply-To: <200904181008.n3IA8DsR004316@ns-regression.ee.washington.edu>
References: <200904181008.n3IA8DsR004316@ns-regression.ee.washington.edu>
Message-ID: <a467ca4f0904180344o5ff219cbqcbf82f7c1702e04a@mail.gmail.com>

So it seems that latest changes accidentally fixed the bug of python-based
regression tests not running with valgrind.

Unfortunately python does some memory allocation magic/optimizations that
valgrind does not like but which are perfectly normal.  There is a
suppressions file that we can give to valgrind to ignore the well known
python valgrind errors.

I will investigate this further.

2009/4/18 <tomhend at u.washington.edu>

> Sat Apr 18 02:50:29 PDT 2009
>
> download.py success
> Regression testing for machine: ns-regression
> Linux 2.6.24-19-server x86_64
> g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
> -----------------------------
> Waf: Entering directory
> `/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build'
> [650/672] regression-test (test-csma-bridge)
> [651/672] regression-test (test-csma-broadcast)
> [652/672] regression-test (test-csma-multicast)
> [653/672] regression-test (test-csma-one-subnet)
> ==4280== Memcheck, a memory error detector.
> ==4280== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4280== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4280== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4280== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4280== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4280== For more details, rerun with: -v
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==  Address 0x5b1c020 is 104 bytes inside a block of size 568 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x572DDAB: fclose (in /lib/libc-2.7.so)
> ==4280==    by 0x4A155C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x457421: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==  Address 0x5b1c020 is 104 bytes inside a block of size 568 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x572DDAB: fclose (in /lib/libc-2.7.so)
> ==4280==    by 0x4A155C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x457421: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==  Address 0x5b1c020 is 104 bytes inside a block of size 568 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x572DDAB: fclose (in /lib/libc-2.7.so)
> ==4280==    by 0x4A155C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==  Address 0x5b1c020 is 104 bytes inside a block of size 568 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x572DDAB: fclose (in /lib/libc-2.7.so)
> ==4280==    by 0x4A155C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==  Address 0x5b25020 is 560 bytes inside a block of size 768 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x442259: (within /usr/bin/python2.5)
> ==4280==    by 0x488682: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x488074: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==  Address 0x5b23020 is 224 bytes inside a block of size 568 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x572E7B8: (within /lib/libc-2.7.so)
> ==4280==    by 0x4A0137: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1A41: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x457421: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==  Address 0x5b24020 is not stack'd, malloc'd or (recently) free'd
> ==4280==
> ==4280== Conditional jump or move depends on uninitialised value(s)
> ==4280==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CACBC: PyGrammar_AddAccelerators (in /usr/bin/python2.5)
> ==4280==    by 0x4CBA76: PyParser_New (in /usr/bin/python2.5)
> ==4280==    by 0x414870: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Use of uninitialised value of size 8
> ==4280==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CACBC: PyGrammar_AddAccelerators (in /usr/bin/python2.5)
> ==4280==    by 0x4CBA76: PyParser_New (in /usr/bin/python2.5)
> ==4280==    by 0x414870: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CACBC: PyGrammar_AddAccelerators (in /usr/bin/python2.5)
> ==4280==    by 0x4CBA76: PyParser_New (in /usr/bin/python2.5)
> ==4280==    by 0x414870: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==  Address 0x5b2a020 is 344 bytes inside a block of size 672 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x4CACBC: PyGrammar_AddAccelerators (in /usr/bin/python2.5)
> ==4280==    by 0x4CBA76: PyParser_New (in /usr/bin/python2.5)
> ==4280==    by 0x414870: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x48A71D: (within /usr/bin/python2.5)
> ==4280==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ACB32: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==  Address 0x5b84020 is 11,992 bytes inside a block of size 12,032
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x414BB3: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ACB32: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==  Address 0x5b84020 is 11,992 bytes inside a block of size 12,032
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x414BB3: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4D411E: (within /usr/bin/python2.5)
> ==4280==    by 0x4B262A: (within /usr/bin/python2.5)
> ==4280==    by 0x4B2636: (within /usr/bin/python2.5)
> ==4280==    by 0x443839: PyDict_DelItem (in /usr/bin/python2.5)
> ==4280==    by 0x4438D6: PyDict_DelItemString (in /usr/bin/python2.5)
> ==4280==    by 0x483C35: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==  Address 0x5b84020 is 11,992 bytes inside a block of size 12,032
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x414BB3: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACBA0: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==  Address 0x5b8a020 is 136 bytes inside a block of size 384 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x48A71D: (within /usr/bin/python2.5)
> ==4280==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ACB32: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDACA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==  Address 0x5ab5020 is 720 bytes inside a block of size 776 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x457421: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Conditional jump or move depends on uninitialised value(s)
> ==4280==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1E8C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==
> ==4280== Use of uninitialised value of size 8
> ==4280==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1E8C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x4987E4: (within /usr/bin/python2.5)
> ==4280==    by 0x498AC4: _PyCodec_Lookup (in /usr/bin/python2.5)
> ==4280==    by 0x499027: PyCodec_Encoder (in /usr/bin/python2.5)
> ==4280==    by 0x4AD3F7: Py_InitializeEx (in /usr/bin/python2.5)
> ==4280==  Address 0x5c22020 is 80 bytes inside a block of size 368 free'd
> ==4280==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==4280==    by 0x439708: PyList_Append (in /usr/bin/python2.5)
> ==4280==    by 0x4A4DC8: (within /usr/bin/python2.5)
> ==4280==    by 0x4A3EA6: (within /usr/bin/python2.5)
> ==4280==    by 0x4A47BA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A3EA6: (within /usr/bin/python2.5)
> ==4280==    by 0x4A478E: (within /usr/bin/python2.5)
> ==4280==    by 0x4A5311: PyMarshal_ReadLastObjectFromFile (in
> /usr/bin/python2.5)
> ==4280==    by 0x4A143E: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Conditional jump or move depends on uninitialised value(s)
> ==4280==    at 0x44930B: PyObject_Realloc (in /usr/bin/python2.5)
> ==4280==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==4280==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==4280==    by 0x414906: (within /usr/bin/python2.5)
> ==4280==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Use of uninitialised value of size 8
> ==4280==    at 0x449322: PyObject_Realloc (in /usr/bin/python2.5)
> ==4280==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==4280==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==4280==    by 0x414906: (within /usr/bin/python2.5)
> ==4280==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x449302: PyObject_Realloc (in /usr/bin/python2.5)
> ==4280==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==4280==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==4280==    by 0x414906: (within /usr/bin/python2.5)
> ==4280==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c98020 is 400 bytes inside a block of size 960 free'd
> ==4280==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==4280==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==4280==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==4280==    by 0x414906: (within /usr/bin/python2.5)
> ==4280==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CB38C: (within /usr/bin/python2.5)
> ==4280==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c99020 is 992 bytes inside a block of size 1,440
> free'd
> ==4280==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==4280==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==4280==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==4280==    by 0x414906: (within /usr/bin/python2.5)
> ==4280==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Conditional jump or move depends on uninitialised value(s)
> ==4280==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CB2FE: (within /usr/bin/python2.5)
> ==4280==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Use of uninitialised value of size 8
> ==4280==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CB2FE: (within /usr/bin/python2.5)
> ==4280==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Conditional jump or move depends on uninitialised value(s)
> ==4280==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CB2D4: (within /usr/bin/python2.5)
> ==4280==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Use of uninitialised value of size 8
> ==4280==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CB2D4: (within /usr/bin/python2.5)
> ==4280==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CB3BB: (within /usr/bin/python2.5)
> ==4280==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c56020 is 8,240 bytes inside a block of size 12,032
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x414BB3: (within /usr/bin/python2.5)
> ==4280==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CB48C: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c9a020 is 144 bytes inside a block of size 320 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x4CB38C: (within /usr/bin/python2.5)
> ==4280==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x449302: PyObject_Realloc (in /usr/bin/python2.5)
> ==4280==    by 0x48AC43: (within /usr/bin/python2.5)
> ==4280==    by 0x48D95C: (within /usr/bin/python2.5)
> ==4280==    by 0x48EE45: (within /usr/bin/python2.5)
> ==4280==    by 0x48EDE1: (within /usr/bin/python2.5)
> ==4280==    by 0x48F7C4: (within /usr/bin/python2.5)
> ==4280==    by 0x48F804: (within /usr/bin/python2.5)
> ==4280==    by 0x493309: (within /usr/bin/python2.5)
> ==4280==    by 0x496C6F: (within /usr/bin/python2.5)
> ==4280==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==  Address 0x5ca9020 is 1,352 bytes inside a block of size 1,536
> free'd
> ==4280==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==4280==    by 0x48AC43: (within /usr/bin/python2.5)
> ==4280==    by 0x48FE12: (within /usr/bin/python2.5)
> ==4280==    by 0x48F7C4: (within /usr/bin/python2.5)
> ==4280==    by 0x48F804: (within /usr/bin/python2.5)
> ==4280==    by 0x493309: (within /usr/bin/python2.5)
> ==4280==    by 0x496C6F: (within /usr/bin/python2.5)
> ==4280==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x48A71D: (within /usr/bin/python2.5)
> ==4280==    by 0x496D33: (within /usr/bin/python2.5)
> ==4280==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5ca9020 is 1,352 bytes inside a block of size 1,536
> free'd
> ==4280==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==4280==    by 0x48AC43: (within /usr/bin/python2.5)
> ==4280==    by 0x48FE12: (within /usr/bin/python2.5)
> ==4280==    by 0x48F7C4: (within /usr/bin/python2.5)
> ==4280==    by 0x48F804: (within /usr/bin/python2.5)
> ==4280==    by 0x493309: (within /usr/bin/python2.5)
> ==4280==    by 0x496C6F: (within /usr/bin/python2.5)
> ==4280==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x48A71D: (within /usr/bin/python2.5)
> ==4280==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5caf020 is 3,600 bytes inside a block of size 3,980
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x48CB32: (within /usr/bin/python2.5)
> ==4280==    by 0x48EAF6: (within /usr/bin/python2.5)
> ==4280==    by 0x496D20: (within /usr/bin/python2.5)
> ==4280==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5ca3020 is 648 bytes inside a block of size 768 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x443638: (within /usr/bin/python2.5)
> ==4280==    by 0x4AE149: (within /usr/bin/python2.5)
> ==4280==    by 0x4AE442: (within /usr/bin/python2.5)
> ==4280==    by 0x4B0443: PySymtable_Build (in /usr/bin/python2.5)
> ==4280==    by 0x496FDE: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CB48C: PyNode_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4AAB74: PyParser_ASTFromFile (in /usr/bin/python2.5)
> ==4280==    by 0x4A1254: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==  Address 0x5cb8020 is 9,704 bytes inside a block of size 12,032
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x414BB3: (within /usr/bin/python2.5)
> ==4280==    by 0x4AAB4E: PyParser_ASTFromFile (in /usr/bin/python2.5)
> ==4280==    by 0x4A1254: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4285== Memcheck, a memory error detector.
> ==4285== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4285== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4285== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4285== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4285== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4285== For more details, rerun with: -v
> ==4285==
> ==4285==
> ==4285== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4285== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4285== malloc/free: 6,447 allocs, 6,447 frees, 469,077 bytes allocated.
> ==4285== For counts of detected errors, rerun with: -v
> ==4285== All heap blocks were freed -- no leaks are possible.
> [654/672] regression-test (test-csma-packet-socket)
> ==4280==    by 0x48A71D: (within /usr/bin/python2.5)
> ==4280==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4A126D: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==  Address 0x5cb8020 is 9,704 bytes inside a block of size 12,032
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x414BB3: (within /usr/bin/python2.5)
> ==4280==    by 0x4AAB4E: PyParser_ASTFromFile (in /usr/bin/python2.5)
> ==4280==    by 0x4A1254: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4A126D: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==  Address 0x5cb8020 is 9,704 bytes inside a block of size 12,032
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x414BB3: (within /usr/bin/python2.5)
> ==4280==    by 0x4AAB4E: PyParser_ASTFromFile (in /usr/bin/python2.5)
> ==4280==    by 0x4A1254: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 8
> ==4280==    at 0x4015EFE: (within /lib/ld-2.7.so)
> ==4280==    by 0x400AB93: (within /lib/ld-2.7.so)
> ==4280==    by 0x40061E4: (within /lib/ld-2.7.so)
> ==4280==    by 0x4008677: (within /lib/ld-2.7.so)
> ==4280==    by 0x4012048: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x401191A: (within /lib/ld-2.7.so)
> ==4280==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x50444EC: (within /lib/libdl-2.7.so)
> ==4280==    by 0x5043EF0: dlopen (in /lib/libdl-2.7.so)
> ==4280==    by 0x4B33FB: _PyImport_GetDynLoadFunc (in /usr/bin/python2.5)
> ==4280==  Address 0x5cb9e80 is 88 bytes inside a block of size 89 alloc'd
> ==4280==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==4280==    by 0x4007823: (within /lib/ld-2.7.so)
> ==4280==    by 0x40085CE: (within /lib/ld-2.7.so)
> ==4280==    by 0x4012048: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x401191A: (within /lib/ld-2.7.so)
> ==4280==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x50444EC: (within /lib/libdl-2.7.so)
> ==4280==    by 0x5043EF0: dlopen (in /lib/libdl-2.7.so)
> ==4280==    by 0x4B33FB: _PyImport_GetDynLoadFunc (in /usr/bin/python2.5)
> ==4280==    by 0x4A3997: _PyImport_LoadDynamicModule (in
> /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 8
> ==4280==    at 0x4015EB0: (within /lib/ld-2.7.so)
> ==4280==    by 0x400AB93: (within /lib/ld-2.7.so)
> ==4280==    by 0x40061E4: (within /lib/ld-2.7.so)
> ==4280==    by 0x4008677: (within /lib/ld-2.7.so)
> ==4280==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==4280==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x401191A: (within /lib/ld-2.7.so)
> ==4280==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==  Address 0x5cba490 is 64 bytes inside a block of size 71 alloc'd
> ==4280==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==4280==    by 0x4005F47: (within /lib/ld-2.7.so)
> ==4280==    by 0x400885F: (within /lib/ld-2.7.so)
> ==4280==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==4280==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x401191A: (within /lib/ld-2.7.so)
> ==4280==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x50444EC: (within /lib/libdl-2.7.so)
> ==4280==
> ==4280== Invalid read of size 8
> ==4280==    at 0x4015EE4: (within /lib/ld-2.7.so)
> ==4280==    by 0x400AB93: (within /lib/ld-2.7.so)
> ==4280==    by 0x40061E4: (within /lib/ld-2.7.so)
> ==4280==    by 0x4008677: (within /lib/ld-2.7.so)
> ==4280==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==4280==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x401191A: (within /lib/ld-2.7.so)
> ==4280==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==  Address 0x5cbcf98 is 16 bytes inside a block of size 23 alloc'd
> ==4280==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==4280==    by 0x4008B75: (within /lib/ld-2.7.so)
> ==4280==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==4280==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x401191A: (within /lib/ld-2.7.so)
> ==4280==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x50444EC: (within /lib/libdl-2.7.so)
> ==4280==    by 0x5043EF0: dlopen (in /lib/libdl-2.7.so)
> ==4280==
> ==4280== Invalid read of size 8
> ==4280==    at 0x4015ECA: (within /lib/ld-2.7.so)
> ==4280==    by 0x400522C: (within /lib/ld-2.7.so)
> ==4280==    by 0x40079E5: (within /lib/ld-2.7.so)
> ==4280==    by 0x40089D7: (within /lib/ld-2.7.so)
> ==4280==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==4280==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x401191A: (within /lib/ld-2.7.so)
> ==4280==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==  Address 0x5cc3550 is 8 bytes inside a block of size 9 alloc'd
> ==4280==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==4280==    by 0x4007823: (within /lib/ld-2.7.so)
> ==4280==    by 0x4007979: (within /lib/ld-2.7.so)
> ==4280==    by 0x40089D7: (within /lib/ld-2.7.so)
> ==4280==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==4280==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==    by 0x401191A: (within /lib/ld-2.7.so)
> ==4280==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==4280==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==4280==    by 0x4D5432: (within /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F494: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5caf020 is 3,600 bytes inside a block of size 3,980
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x48CB32: (within /usr/bin/python2.5)
> ==4280==    by 0x48EAF6: (within /usr/bin/python2.5)
> ==4280==    by 0x496D20: (within /usr/bin/python2.5)
> ==4280==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x457421: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==4280==    by 0x4D5432: (within /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F494: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5cac020 is 2,744 bytes inside a block of size 3,072
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x443638: (within /usr/bin/python2.5)
> ==4280==    by 0x48A8B2: (within /usr/bin/python2.5)
> ==4280==    by 0x496D33: (within /usr/bin/python2.5)
> ==4280==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==4280==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4D5432: (within /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5bc2020 is not stack'd, malloc'd or (recently) free'd
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4D5442: (within /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5aa5020 is 96 bytes inside a block of size 464 free'd
> ==4280==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==4280==    by 0x439708: PyList_Append (in /usr/bin/python2.5)
> ==4280==    by 0x4A4DC8: (within /usr/bin/python2.5)
> ==4280==    by 0x4A3EA6: (within /usr/bin/python2.5)
> ==4280==    by 0x4A478E: (within /usr/bin/python2.5)
> ==4280==    by 0x4A3EA6: (within /usr/bin/python2.5)
> ==4280==    by 0x4A478E: (within /usr/bin/python2.5)
> ==4280==    by 0x4A5311: PyMarshal_ReadLastObjectFromFile (in
> /usr/bin/python2.5)
> ==4280==    by 0x4A143E: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5aa3020 is 136 bytes inside a block of size 568 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x572E7B8: (within /lib/libc-2.7.so)
> ==4280==    by 0x4A0137: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1A41: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x41AB3C: PyObject_CallFunctionObjArgs (in
> /usr/bin/python2.5)
> ==4280==    by 0x4A2646: PyImport_Import (in /usr/bin/python2.5)
> ==4280==    by 0x4A27F4: PyImport_ImportModule (in /usr/bin/python2.5)
> ==4280==    by 0x4ABB9D: (within /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x4456A2: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c21020 is 528 bytes inside a block of size 568 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x572DDAB: fclose (in /lib/libc-2.7.so)
> ==4280==    by 0x4A155C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x4987E4: (within /usr/bin/python2.5)
> ==4280==    by 0x498AC4: _PyCodec_Lookup (in /usr/bin/python2.5)
> ==4280==    by 0x499027: PyCodec_Encoder (in /usr/bin/python2.5)
> ==4280==    by 0x4AD3F7: Py_InitializeEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4D5442: (within /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c31020 is 16 bytes inside a block of size 297 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c31020 is 16 bytes inside a block of size 297 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==4280==    by 0x441F6C: (within /usr/bin/python2.5)
> ==4280==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==4280==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x49F6DC: _PyImport_Fini (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA76: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5ab5020 is 720 bytes inside a block of size 776 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x457421: (within /usr/bin/python2.5)
> ==4280==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==4280==    by 0x4A136F: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==4280==    by 0x4D5432: (within /usr/bin/python2.5)
> ==4280==    by 0x435E96: (within /usr/bin/python2.5)
> ==4280==    by 0x4A9FE2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c21020 is 528 bytes inside a block of size 568 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x572DDAB: fclose (in /lib/libc-2.7.so)
> ==4280==    by 0x4A155C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==4284== Memcheck, a memory error detector.
> ==4284== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4284== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4284== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4284== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4284== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4284== For more details, rerun with: -v
> ==4284==
> ==4284==
> ==4284== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4284== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4284== malloc/free: 72,409 allocs, 72,409 frees, 3,491,995 bytes
> allocated.
> ==4284== For counts of detected errors, rerun with: -v
> ==4284== All heap blocks were freed -- no leaks are possible.
> [655/672] regression-test (test-csma-ping)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x4987E4: (within /usr/bin/python2.5)
> ==4280==    by 0x498AC4: _PyCodec_Lookup (in /usr/bin/python2.5)
> ==4280==    by 0x499027: PyCodec_Encoder (in /usr/bin/python2.5)
> ==4280==    by 0x4AD3F7: Py_InitializeEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==4280==    by 0x4D5432: (within /usr/bin/python2.5)
> ==4280==    by 0x435E96: (within /usr/bin/python2.5)
> ==4280==    by 0x4A9FE2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5c4b020 is 48 bytes inside a block of size 64 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x435EA2: (within /usr/bin/python2.5)
> ==4280==    by 0x435E96: (within /usr/bin/python2.5)
> ==4280==    by 0x4620DB: (within /usr/bin/python2.5)
> ==4280==    by 0x4623D5: (within /usr/bin/python2.5)
> ==4280==    by 0x45EB1D: PyType_Ready (in /usr/bin/python2.5)
> ==4280==    by 0x4615ED: (within /usr/bin/python2.5)
> ==4280==    by 0x45C9D2: (within /usr/bin/python2.5)
> ==4280==    by 0x41AB3C: PyObject_CallFunctionObjArgs (in
> /usr/bin/python2.5)
> ==4280==    by 0x484E38: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==4280==    by 0x4D5432: (within /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x459AE6: (within /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x4A9FD2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==4280==  Address 0x5c2f020 is 48 bytes inside a block of size 899 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x4D5442: (within /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x459AE6: (within /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x4A9FD2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==4280==    by 0x4573F0: (within /usr/bin/python2.5)
> ==4280==    by 0x459AE6: (within /usr/bin/python2.5)
> ==4280==    by 0x44361A: (within /usr/bin/python2.5)
> ==4280==    by 0x4A9FD2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==4280==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==4280==  Address 0x5c2d020 is 33,840 bytes inside a block of size 33,907
> free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x4A5339: PyMarshal_ReadLastObjectFromFile (in
> /usr/bin/python2.5)
> ==4280==    by 0x4A143E: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1928: (within /usr/bin/python2.5)
> ==4280==    by 0x4A1E8C: (within /usr/bin/python2.5)
> ==4280==    by 0x4A2039: (within /usr/bin/python2.5)
> ==4280==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==4280==    by 0x481AA8: (within /usr/bin/python2.5)
> ==4280==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==4280==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==4280==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==
> ==4280== Invalid read of size 4
> ==4280==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==4280==    by 0x4CAB31: PyGrammar_RemoveAccelerators (in
> /usr/bin/python2.5)
> ==4280==    by 0x4ABAD8: Py_Finalize (in /usr/bin/python2.5)
> ==4280==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==  Address 0x5b2a020 is 344 bytes inside a block of size 672 free'd
> ==4280==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==4280==    by 0x4CACBC: PyGrammar_AddAccelerators (in /usr/bin/python2.5)
> ==4280==    by 0x4CBA76: PyParser_New (in /usr/bin/python2.5)
> ==4280==    by 0x414870: (within /usr/bin/python2.5)
> ==4280==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==4280==    by 0x4813AC: (within /usr/bin/python2.5)
> ==4280==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==4280==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==4280==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==4280==    by 0x4A134F: (within /usr/bin/python2.5)
> ==4280==
> ==4280== ERROR SUMMARY: 628 errors from 53 contexts (suppressed: 133 from
> 1)
> ==4280== malloc/free: in use at exit: 2,244,444 bytes in 1,209 blocks.
> ==4280== malloc/free: 82,226 allocs, 81,017 frees, 8,824,267 bytes
> allocated.
> ==4280== For counts of detected errors, rerun with: -v
> ==4280== searching for pointers to 1,209 not-freed blocks.
> ==4280== checked 3,301,680 bytes.
> ==4280==
> ==4280==
> ==4280== 14,616 bytes in 50 blocks are possibly lost in loss record 23 of
> 27
> ==4280==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==4280==    by 0x4B6408: _PyObject_GC_Malloc (in /usr/bin/python2.5)
> ==4280==    by 0x4B653C: _PyObject_GC_New (in /usr/bin/python2.5)
> ==4280==    by 0x444AEA: PyDict_New (in /usr/bin/python2.5)
> ==4280==    by 0x4AD159: Py_InitializeEx (in /usr/bin/python2.5)
> ==4280==    by 0x413F20: Py_Main (in /usr/bin/python2.5)
> ==4280==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==4280==
> ==4280== LEAK SUMMARY:
> ==4280==    definitely lost: 0 bytes in 0 blocks.
> ==4280==      possibly lost: 14,616 bytes in 50 blocks.
> ==4280==    still reachable: 2,229,828 bytes in 1,159 blocks.
> ==4280==         suppressed: 0 bytes in 0 blocks.
> ==4280== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==4280== To see them, rerun with: --leak-check=full --show-reachable=yes
> Command ['/usr/bin/valgrind', '--leak-check=full', '--error-exitcode=1',
> '/usr/bin/python',
> '/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/examples/csma-bridge.py']
> exited with code 1
> [656/672] regression-test (test-csma-raw-ip-socket)
> ==4288== Memcheck, a memory error detector.
> ==4288== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4288== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4288== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4288== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4288== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4288== For more details, rerun with: -v
> ==4288==
> ==4288==
> ==4288== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4288== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4288== malloc/free: 101,208 allocs, 101,208 frees, 5,158,321 bytes
> allocated.
> ==4288== For counts of detected errors, rerun with: -v
> ==4288== All heap blocks were freed -- no leaks are possible.
> [657/672] regression-test (test-csma-star)
> ==4286== Memcheck, a memory error detector.
> ==4286== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4286== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4286== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4286== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4286== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4286== For more details, rerun with: -v
> ==4286==
> ==4286==
> ==4286== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4286== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4286== malloc/free: 117,104 allocs, 117,104 frees, 5,945,208 bytes
> allocated.
> ==4286== For counts of detected errors, rerun with: -v
> ==4286== All heap blocks were freed -- no leaks are possible.
> [658/672] regression-test (test-dynamic-global-routing)
> ==4290== Memcheck, a memory error detector.
> ==4290== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4290== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4290== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4290== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4290== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4290== For more details, rerun with: -v
> ==4290==
> ==4290==
> ==4290== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4290== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4290== malloc/free: 4,691 allocs, 4,691 frees, 343,688 bytes allocated.
> ==4290== For counts of detected errors, rerun with: -v
> ==4290== All heap blocks were freed -- no leaks are possible.
> [659/672] regression-test (test-global-routing-slash32)
> ==4289== Memcheck, a memory error detector.
> ==4289== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4289== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4289== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4289== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4289== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4289== For more details, rerun with: -v
> ==4289==
> ==4289==
> ==4289== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4289== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4289== malloc/free: 5,861 allocs, 5,861 frees, 415,141 bytes allocated.
> ==4289== For counts of detected errors, rerun with: -v
> ==4289== All heap blocks were freed -- no leaks are possible.
> [660/672] regression-test (test-ns2-mob)
> ==4296== Memcheck, a memory error detector.
> ==4296== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4296== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4296== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4296== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4296== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4296== For more details, rerun with: -v
> ==4296==
> ==4296==
> ==4296== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4296== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4296== malloc/free: 3,512 allocs, 3,512 frees, 216,520 bytes allocated.
> ==4296== For counts of detected errors, rerun with: -v
> ==4296== All heap blocks were freed -- no leaks are possible.
> [661/672] regression-test (test-realtime-udp-echo)
> ==4294== Memcheck, a memory error detector.
> ==4294== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4294== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4294== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4294== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4294== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4294== For more details, rerun with: -v
> ==4294==
> ==4294==
> ==4294== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4294== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4294== malloc/free: 18,765 allocs, 18,765 frees, 1,123,049 bytes
> allocated.
> ==4294== For counts of detected errors, rerun with: -v
> ==4294== All heap blocks were freed -- no leaks are possible.
> [662/672] regression-test (test-second)
> ==4295== Memcheck, a memory error detector.
> ==4295== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4295== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4295== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4295== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4295== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4295== For more details, rerun with: -v
> ==4295==
> ==4295==
> ==4295== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4295== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4295== malloc/free: 6,558 allocs, 6,558 frees, 453,016 bytes allocated.
> ==4295== For counts of detected errors, rerun with: -v
> ==4295== All heap blocks were freed -- no leaks are possible.
> [663/672] regression-test (test-simple-error-model)
> ==4298== Memcheck, a memory error detector.
> ==4298== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4298== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4298== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4298== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4298== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4298== For more details, rerun with: -v
> ==4298==
> ==4298==
> ==4298== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4298== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4298== malloc/free: 4,989 allocs, 4,989 frees, 357,341 bytes allocated.
> ==4298== For counts of detected errors, rerun with: -v
> ==4298== All heap blocks were freed -- no leaks are possible.
> [664/672] regression-test (test-simple-global-routing)
> ==4297== Memcheck, a memory error detector.
> ==4297== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4297== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4297== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4297== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4297== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4297== For more details, rerun with: -v
> ==4297==
> ==4297==
> ==4297== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4297== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4297== malloc/free: 45,592 allocs, 45,592 frees, 2,404,498 bytes
> allocated.
> ==4297== For counts of detected errors, rerun with: -v
> ==4297== All heap blocks were freed -- no leaks are possible.
> [665/672] regression-test (test-simple-point-to-point-olsr)
> ==4301== Memcheck, a memory error detector.
> ==4301== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4301== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4301== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4301== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4301== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4301== For more details, rerun with: -v
> ==4301==
> ==4301==
> ==4301== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4301== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4301== malloc/free: 87,656 allocs, 87,656 frees, 4,223,386 bytes
> allocated.
> ==4301== For counts of detected errors, rerun with: -v
> ==4301== All heap blocks were freed -- no leaks are possible.
> [666/672] regression-test (test-static-routing-slash32)
> ==4299== Memcheck, a memory error detector.
> ==4299== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4299== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4299== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4299== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4299== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4299== For more details, rerun with: -v
> ==4299==
> ==4299==
> ==4299== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4299== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4299== malloc/free: 178,265 allocs, 178,265 frees, 7,838,432 bytes
> allocated.
> ==4299== For counts of detected errors, rerun with: -v
> ==4299== All heap blocks were freed -- no leaks are possible.
> [667/672] regression-test (test-tcp-large-transfer)
> ==4302== Memcheck, a memory error detector.
> ==4302== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4302== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4302== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4302== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4302== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4302== For more details, rerun with: -v
> ==4302==
> ==4302==
> ==4302== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4302== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4302== malloc/free: 6,433 allocs, 6,433 frees, 449,377 bytes allocated.
> ==4302== For counts of detected errors, rerun with: -v
> ==4302== All heap blocks were freed -- no leaks are possible.
> [668/672] regression-test (test-tcp-nsc-lfn)
> [669/672] regression-test (test-third)
> ==4306== Memcheck, a memory error detector.
> ==4306== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4306== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4306== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4306== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4306== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4306== For more details, rerun with: -v
> ==4306==
> ==4306==
> ==4306== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4306== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4306== malloc/free: 7,424 allocs, 7,424 frees, 519,177 bytes allocated.
> ==4306== For counts of detected errors, rerun with: -v
> ==4306== All heap blocks were freed -- no leaks are possible.
> [670/672] regression-test (test-udp-echo)
> ==4307== Memcheck, a memory error detector.
> ==4307== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4307== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4307== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4307== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4307== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4307== For more details, rerun with: -v
> ==4307==
> ==4307==
> ==4307== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4307== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4307== malloc/free: 5,542 allocs, 5,542 frees, 402,629 bytes allocated.
> ==4307== For counts of detected errors, rerun with: -v
> ==4307== All heap blocks were freed -- no leaks are possible.
> [671/672] regression-test (test-wifi-wired-bridging)
> ==4300== Memcheck, a memory error detector.
> ==4300== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4300== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4300== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4300== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4300== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4300== For more details, rerun with: -v
> ==4300==
> ==4300==
> ==4300== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4300== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4300== malloc/free: 221,539 allocs, 221,539 frees, 9,462,969 bytes
> allocated.
> ==4300== For counts of detected errors, rerun with: -v
> ==4300== All heap blocks were freed -- no leaks are possible.
> ==4308== Memcheck, a memory error detector.
> ==4308== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4308== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4308== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4308== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4308== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4308== For more details, rerun with: -v
> ==4308==
> ==4308==
> ==4308== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4308== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4308== malloc/free: 42,179 allocs, 42,179 frees, 2,739,236 bytes
> allocated.
> ==4308== For counts of detected errors, rerun with: -v
> ==4308== All heap blocks were freed -- no leaks are possible.
> ==4303== Memcheck, a memory error detector.
> ==4303== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4303== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4303== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4303== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4303== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4303== For more details, rerun with: -v
> ==4303==
> ==4303==
> ==4303== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4303== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4303== malloc/free: 280,307 allocs, 280,307 frees, 15,085,203 bytes
> allocated.
> ==4303== For counts of detected errors, rerun with: -v
> ==4303== All heap blocks were freed -- no leaks are possible.
> ==4292== Memcheck, a memory error detector.
> ==4292== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==4292== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==4292== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==4292== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==4292== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==4292== For more details, rerun with: -v
> ==4292==
> ==4292==
> ==4292== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==4292== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==4292== malloc/free: 1,657,589 allocs, 1,657,589 frees, 99,034,604 bytes
> allocated.
> ==4292== For counts of detected errors, rerun with: -v
> ==4292== All heap blocks were freed -- no leaks are possible.
> [672/672] regression-test-collector
> Waf: Leaving directory
> `/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build'
> Build failed
>  -> task failed (err #1):
>        {task: regression_test_collector_task }
> PASS test-csma-multicast
> PASS test-csma-broadcast
> FAIL test-csma-bridge
> PASS test-csma-packet-socket
> PASS test-csma-one-subnet
> PASS test-csma-raw-ip-socket
> PASS test-csma-ping
> PASS test-ns2-mob
> PASS test-dynamic-global-routing
> PASS test-global-routing-slash32
> PASS test-second
> PASS test-realtime-udp-echo
> PASS test-simple-point-to-point-olsr
> PASS test-simple-error-model
> PASS test-static-routing-slash32
> SKIP test-tcp-nsc-lfn (NSC does not get along with valgrind)
> PASS test-third
> PASS test-udp-echo
> PASS test-simple-global-routing
> PASS test-wifi-wired-bridging
> PASS test-tcp-large-transfer
> PASS test-csma-star
> Regression testing summary:
> SKIP: 1 of 22 tests have been skipped (test-tcp-nsc-lfn)
> FAIL: 1 of 22 tests have failed (test-csma-bridge)
> FAILURE: waf -d debug configure; ./waf --valgrind --regression failed on
> ns-3-dev
> _______________________________________________
>



-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From mathieu.lacage at sophia.inria.fr  Mon Apr 20 09:17:27 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Mon, 20 Apr 2009 18:17:27 +0200
Subject: [Ns-developers] c0de review submission HOWTO
In-Reply-To: <1239692630.6390.38.camel@diese.inria.fr>
References: <1239692630.6390.38.camel@diese.inria.fr>
Message-ID: <1240244247.29732.109.camel@mathieu-laptop>

hi all,

After the first round of reviews using rietveld, it became clear that,
while the tool is a nice graphical frontend to the process on commenting
on a patch, it does not really improve the current code review situation
and most reviewees seem to dislike it quite a bit. So, here is a summary
of what problems we face.

It's pretty clear that the big issue with code reviews as of today is
that of preparing patches for review. We have no clear guidelines on
what is a good patch for review so, I think that a first step would be
to try to come up with such guidelines. Here is an attempt: please,
comment, edit, scream, etc.

<recommendations>
1) No whitespace changes, ever, unless the patch is _only_ about
whitespace changes, but even then, don't do it if you can avoid it.

2) Each patch should be as small as possible, and deal with _only_ one
issue. i.e., if the commit message says: "X and Y", it's a big red
warning sign that you should split the commit in two separate commits.

3) Each patch should contain a coherent change: if you need to edit 10
files to get a feature to work, then, the patch should contain changes
for 10 files. Of course, if you can split the feature is sub-features,
then, you should do it to decrease the size of the patch as per 2)
above.

4) Ideally, after each patch is applied, the tree ns-3-dev should still
build and all tests should still pass (this helps bisection
considerably).

5) Big features will require multiple patches for implementation.
Ideally, these would be managed as a set of dependent patches: the first
patches would touch existing code to prepare the ground for the big
feature while the latter patches would add the new code for the big
feature. When this is the case, make sure you point out the rationale
for the initial patches to outline why they are needed later.

6) Read the patch before sending it for review. 

7) Submit patches using one of the following tools:
  - mercurial patchbomb extension to ns-3-reviews at googlegroups.com:
http://hgbook.red-bean.com/read/adding-functionality-with-extensions.html#sec:hgext:patchbomb it's fine to send either a pure ascii fully-inline patchset (one patch per email) or a complete bundle.
  - publish a repository of your changes on a website using hgweb: one
commit per patch

8) Always include a description of what the patch is doing, and why it
is doing it

[more recommendations ?]

</recommendations>

With the above set of recommendations in mind, I have spent a good
amount of time to try to see how other projects do this but I could not
find a magic solution: the process of generating good patches, and
having people produce good reviews for them seems to be uniformly
painful. 

However, there are a couple of tools which have been developed by others
and which could be of use for some people: quilt is the oldest example
of a patch management system but mercurial has a similar functionality
builtin as 'mercurial queues', also known as 'mq'.

A couple of useful links:
http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
http://hgbook.red-bean.com/read/advanced-uses-of-mercurial-queues.html
http://hgbook.red-bean.com/read/adding-functionality-with-extensions.html
http://wiki.sagemath.org/combinat/Mercurial

'mq' looks cool but it also looks fairly complex to use so, I am not
going to recommend it very much for now.

Anyway, if you have experience dealing with similar problems in other
projects or using 'mq' or similar tools, it would be nice to hear about
it.


Mathieu


On Tue, 2009-04-14 at 09:03 +0200, Mathieu Lacage wrote:
> (strange title to go through the ns-dev filters)
> 
> hi,
> 
> Since I did not receive screaming emails saying that it was a horribly
> bad idea, I created http://groups.google.com/group/ns-3-reviews/, and I
> would like to suggest everyone who wants to submit a review to:
> 
> 0) download http://codereview.appspot.com/static/upload.py
> 1) record the changes you want to request a review for in a mercurial
> repository: "hg commit ..."
> 2) within the mercurial repository, run upload.py to submit a review
> with http://codereview.appspot.com/. Make sure you specify
> ns-3-reviews at googlegroups.com as a CC.
> 3) Paste your review request on
> http://www.nsnam.org/wiki/index.php/Reviews or send me an email and I
> will add it there
> 4) announce your review request on ns-developers
> 
> thank you,
> Mathieu
> 


From craigdo at ee.washington.edu  Mon Apr 20 19:40:09 2009
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Mon, 20 Apr 2009 19:40:09 -0700
Subject: [Ns-developers] Emu fonction
In-Reply-To: <96595a82-0f77-4191-81b4-ce2ecd0e7eba@z9g2000yqi.googlegroups.com>
References: <96595a82-0f77-4191-81b4-ce2ecd0e7eba@z9g2000yqi.googlegroups.com>
Message-ID: <3689FBDCF93343A7B82AEBB0EED7BED2@CRAIGVAIO>

Hi Pierre,

It seems that someone got a little carried away in removing "legacy naming"
and mistakenly removed this attribute from the emu device.  I just put it
back.

BTW, ns-3-users at googlegroups.com or ns-developers at isi.edu would be a better
choice for this kind of question than ns-3-reviews ...

-- Craig

> -----Original Message-----
> From: ns-3-reviews at googlegroups.com 
> [mailto:ns-3-reviews at googlegroups.com] On Behalf Of Pierre Weiss
> Sent: Monday, April 20, 2009 12:20 PM
> To: ns-3-reviews
> Subject: Emu fonction
> 
> 
> hello,
> 
> i'm trying simulation with emu fonction.
> With the example emu-udp-echo, i get this message: Could not find
> attribute ns3::EmuNetDevice::DeviceName.
> had the value DeviceName changed ?
> 
> EmuHelper emu;
> emu.SetAttribute ("DeviceName", StringValue (deviceName));
> 
> Thanks.
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the 
> Google Groups "ns-3-reviews" group.
> To post to this group, send email to ns-3-reviews at googlegroups.com
> To unsubscribe from this group, send email to 
> ns-3-reviews+unsubscribe at googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/ns-3-reviews?hl=en
> -~----------~----~----~----~------~----~------~--~---
> 
> 



From mathieu.lacage at sophia.inria.fr  Tue Apr 21 00:30:15 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 21 Apr 2009 09:30:15 +0200
Subject: [Ns-developers] c0de review submission HOWTO
In-Reply-To: <1240244247.29732.109.camel@mathieu-laptop>
References: <1239692630.6390.38.camel@diese.inria.fr>
	<1240244247.29732.109.camel@mathieu-laptop>
Message-ID: <1240299015.317.268.camel@diese.inria.fr>

On Mon, 2009-04-20 at 18:17 +0200, Mathieu Lacage wrote:

> Anyway, if you have experience dealing with similar problems in other
> projects or using 'mq' or similar tools, it would be nice to hear about
> it.

Another interesting approach here is:
http://arrenbrecht.ch/mercurial/pbranch/

Still scary but slightly less than mq.

Mathieu


From gjcarneiro at gmail.com  Tue Apr 21 03:14:50 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Tue, 21 Apr 2009 11:14:50 +0100
Subject: [Ns-developers] [Ns-commits] Output of run-tests script: failure
In-Reply-To: <200904211008.n3LA8gnE006789@ns-regression.ee.washington.edu>
References: <200904211008.n3LA8gnE006789@ns-regression.ee.washington.edu>
Message-ID: <a467ca4f0904210314y7f1a9b80k3854ee8e5d85566e@mail.gmail.com>

Alas, the python valgrind suppressions file alone is not enough, you can't
get away from having to recompile Python.

I've disabled valgrind for python tests, which should fix this problem.

2009/4/21 <tomhend at u.washington.edu>

> Tue Apr 21 02:50:26 PDT 2009
>
> download.py success
> Regression testing for machine: ns-regression
> Linux 2.6.24-19-server x86_64
> g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
> -----------------------------
> Waf: Entering directory
> `/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build'
> [651/673] regression-test (test-csma-bridge)
> [652/673] regression-test (test-csma-broadcast)
> [653/673] regression-test (test-csma-multicast)
> [654/673] regression-test (test-csma-one-subnet)
> ==6756== Memcheck, a memory error detector.
> ==6756== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6756== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6756== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6756== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6756== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6756== For more details, rerun with: -v
> ==6756==
> ==6756== Conditional jump or move depends on uninitialised value(s)
> ==6756==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Use of uninitialised value of size 8
> ==6756==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Conditional jump or move depends on uninitialised value(s)
> ==6756==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Use of uninitialised value of size 8
> ==6756==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Conditional jump or move depends on uninitialised value(s)
> ==6756==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Use of uninitialised value of size 8
> ==6756==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==  Address 0x5b17020 is 136 bytes inside a block of size 568 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x572E7B8: (within /lib/libc-2.7.so)
> ==6756==    by 0x4A0137: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1A41: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==  Address 0x5b17020 is 136 bytes inside a block of size 568 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x572E7B8: (within /lib/libc-2.7.so)
> ==6756==    by 0x4A0137: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1A41: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==  Address 0x5b1a020 is 1,168 bytes inside a block of size 1,184
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x435EA2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A534A: PyMarshal_ReadLastObjectFromFile (in
> /usr/bin/python2.5)
> ==6756==    by 0x4A143E: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==  Address 0x5b1a020 is 1,168 bytes inside a block of size 1,184
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x435EA2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A534A: PyMarshal_ReadLastObjectFromFile (in
> /usr/bin/python2.5)
> ==6756==    by 0x4A143E: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Conditional jump or move depends on uninitialised value(s)
> ==6756==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==
> ==6756== Use of uninitialised value of size 8
> ==6756==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==  Address 0x5b25020 is 240 bytes inside a block of size 768 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x442259: (within /usr/bin/python2.5)
> ==6756==    by 0x488682: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x488074: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==  Address 0x5b23020 is 520 bytes inside a block of size 568 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x572E7B8: (within /lib/libc-2.7.so)
> ==6756==    by 0x4A0137: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1A41: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB42: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==  Address 0x5b24020 is not stack'd, malloc'd or (recently) free'd
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CACBC: PyGrammar_AddAccelerators (in /usr/bin/python2.5)
> ==6756==    by 0x4CBA76: PyParser_New (in /usr/bin/python2.5)
> ==6756==    by 0x414870: (within /usr/bin/python2.5)
> ==6756==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==  Address 0x5b2a020 is 24 bytes inside a block of size 672 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x4CACBC: PyGrammar_AddAccelerators (in /usr/bin/python2.5)
> ==6756==    by 0x4CBA76: PyParser_New (in /usr/bin/python2.5)
> ==6756==    by 0x414870: (within /usr/bin/python2.5)
> ==6756==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x48A71D: (within /usr/bin/python2.5)
> ==6756==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ACB32: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==  Address 0x5b84020 is 11,672 bytes inside a block of size 12,032
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x414BB3: (within /usr/bin/python2.5)
> ==6756==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ACB32: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==  Address 0x5b84020 is 11,672 bytes inside a block of size 12,032
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x414BB3: (within /usr/bin/python2.5)
> ==6756==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4D411E: (within /usr/bin/python2.5)
> ==6756==    by 0x4B262A: (within /usr/bin/python2.5)
> ==6756==    by 0x4B2636: (within /usr/bin/python2.5)
> ==6756==    by 0x443839: PyDict_DelItem (in /usr/bin/python2.5)
> ==6756==    by 0x4438D6: PyDict_DelItemString (in /usr/bin/python2.5)
> ==6756==    by 0x483C35: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==  Address 0x5b84020 is 11,672 bytes inside a block of size 12,032
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x414BB3: (within /usr/bin/python2.5)
> ==6756==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4ACBA0: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==  Address 0x5b8a020 is 296 bytes inside a block of size 432 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ACB32: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDACA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==  Address 0x5ab5020 is 720 bytes inside a block of size 776 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x4987E4: (within /usr/bin/python2.5)
> ==6756==    by 0x498AC4: _PyCodec_Lookup (in /usr/bin/python2.5)
> ==6756==    by 0x499027: PyCodec_Encoder (in /usr/bin/python2.5)
> ==6756==    by 0x4AD3F7: Py_InitializeEx (in /usr/bin/python2.5)
> ==6756==  Address 0x5c22020 is 88 bytes inside a block of size 280 free'd
> ==6756==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==6756==    by 0x439708: PyList_Append (in /usr/bin/python2.5)
> ==6756==    by 0x4A4DC8: (within /usr/bin/python2.5)
> ==6756==    by 0x4A3EA6: (within /usr/bin/python2.5)
> ==6756==    by 0x4A47A4: (within /usr/bin/python2.5)
> ==6756==    by 0x4A3EA6: (within /usr/bin/python2.5)
> ==6756==    by 0x4A478E: (within /usr/bin/python2.5)
> ==6756==    by 0x4A5311: PyMarshal_ReadLastObjectFromFile (in
> /usr/bin/python2.5)
> ==6756==    by 0x4A143E: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Conditional jump or move depends on uninitialised value(s)
> ==6756==    at 0x44930B: PyObject_Realloc (in /usr/bin/python2.5)
> ==6756==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==6756==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==6756==    by 0x414906: (within /usr/bin/python2.5)
> ==6756==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Use of uninitialised value of size 8
> ==6756==    at 0x449322: PyObject_Realloc (in /usr/bin/python2.5)
> ==6756==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==6756==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==6756==    by 0x414906: (within /usr/bin/python2.5)
> ==6756==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x449302: PyObject_Realloc (in /usr/bin/python2.5)
> ==6756==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==6756==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==6756==    by 0x414906: (within /usr/bin/python2.5)
> ==6756==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5c98020 is 80 bytes inside a block of size 960 free'd
> ==6756==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==6756==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==6756==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==6756==    by 0x414906: (within /usr/bin/python2.5)
> ==6756==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Conditional jump or move depends on uninitialised value(s)
> ==6756==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CB2FE: (within /usr/bin/python2.5)
> ==6756==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Use of uninitialised value of size 8
> ==6756==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CB2FE: (within /usr/bin/python2.5)
> ==6756==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Conditional jump or move depends on uninitialised value(s)
> ==6756==    at 0x448D8D: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CB2D4: (within /usr/bin/python2.5)
> ==6756==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Use of uninitialised value of size 8
> ==6756==    at 0x448DA4: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CB2D4: (within /usr/bin/python2.5)
> ==6756==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CB38C: (within /usr/bin/python2.5)
> ==6756==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5c99020 is 672 bytes inside a block of size 1,440
> free'd
> ==6756==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==6756==    by 0x4CB077: PyNode_AddChild (in /usr/bin/python2.5)
> ==6756==    by 0x4CB6CC: PyParser_AddToken (in /usr/bin/python2.5)
> ==6756==    by 0x414906: (within /usr/bin/python2.5)
> ==6756==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CB3BB: (within /usr/bin/python2.5)
> ==6756==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5c57020 is 12,016 bytes inside a block of size 12,032
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x414BB3: (within /usr/bin/python2.5)
> ==6756==    by 0x4ABDCA: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CB48C: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5c9a020 is 1,632 bytes inside a block of size 1,760
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x4CB38C: (within /usr/bin/python2.5)
> ==6756==    by 0x4CB479: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4ABDF2: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x449302: PyObject_Realloc (in /usr/bin/python2.5)
> ==6756==    by 0x48AC43: (within /usr/bin/python2.5)
> ==6756==    by 0x48D95C: (within /usr/bin/python2.5)
> ==6756==    by 0x48EE45: (within /usr/bin/python2.5)
> ==6756==    by 0x48EDE1: (within /usr/bin/python2.5)
> ==6756==    by 0x48F7C4: (within /usr/bin/python2.5)
> ==6756==    by 0x48F804: (within /usr/bin/python2.5)
> ==6756==    by 0x493309: (within /usr/bin/python2.5)
> ==6756==    by 0x496C6F: (within /usr/bin/python2.5)
> ==6756==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==  Address 0x5ca9020 is 1,032 bytes inside a block of size 1,536
> free'd
> ==6756==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==6756==    by 0x48AC43: (within /usr/bin/python2.5)
> ==6756==    by 0x48FE12: (within /usr/bin/python2.5)
> ==6756==    by 0x48F7C4: (within /usr/bin/python2.5)
> ==6756==    by 0x48F804: (within /usr/bin/python2.5)
> ==6756==    by 0x493309: (within /usr/bin/python2.5)
> ==6756==    by 0x496C6F: (within /usr/bin/python2.5)
> ==6756==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x48A71D: (within /usr/bin/python2.5)
> ==6756==    by 0x496D33: (within /usr/bin/python2.5)
> ==6756==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5ca9020 is 1,032 bytes inside a block of size 1,536
> free'd
> ==6756==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==6756==    by 0x48AC43: (within /usr/bin/python2.5)
> ==6756==    by 0x48FE12: (within /usr/bin/python2.5)
> ==6756==    by 0x48F7C4: (within /usr/bin/python2.5)
> ==6756==    by 0x48F804: (within /usr/bin/python2.5)
> ==6756==    by 0x493309: (within /usr/bin/python2.5)
> ==6756==    by 0x496C6F: (within /usr/bin/python2.5)
> ==6756==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x48A71D: (within /usr/bin/python2.5)
> ==6756==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5caf020 is 3,280 bytes inside a block of size 3,980
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x48CB32: (within /usr/bin/python2.5)
> ==6756==    by 0x48EAF6: (within /usr/bin/python2.5)
> ==6756==    by 0x496D20: (within /usr/bin/python2.5)
> ==6756==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5ca3020 is 328 bytes inside a block of size 768 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x443638: (within /usr/bin/python2.5)
> ==6756==    by 0x4AE149: (within /usr/bin/python2.5)
> ==6756==    by 0x4AE442: (within /usr/bin/python2.5)
> ==6756==    by 0x4B0443: PySymtable_Build (in /usr/bin/python2.5)
> ==6756==    by 0x496FDE: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CB48C: PyNode_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4AAB74: PyParser_ASTFromFile (in /usr/bin/python2.5)
> ==6756==    by 0x4A1254: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==  Address 0x5cb8020 is 9,384 bytes inside a block of size 12,032
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x414BB3: (within /usr/bin/python2.5)
> ==6756==    by 0x4AAB4E: PyParser_ASTFromFile (in /usr/bin/python2.5)
> ==6756==    by 0x4A1254: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x48A71D: (within /usr/bin/python2.5)
> ==6756==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4A126D: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==  Address 0x5cb8020 is 9,384 bytes inside a block of size 12,032
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x414BB3: (within /usr/bin/python2.5)
> ==6756==    by 0x4AAB4E: PyParser_ASTFromFile (in /usr/bin/python2.5)
> ==6756==    by 0x4A1254: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x49713C: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4A126D: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==  Address 0x5cb8020 is 9,384 bytes inside a block of size 12,032
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x414BB3: (within /usr/bin/python2.5)
> ==6756==    by 0x4AAB4E: PyParser_ASTFromFile (in /usr/bin/python2.5)
> ==6756==    by 0x4A1254: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 8
> ==6756==    at 0x4015EFE: (within /lib/ld-2.7.so)
> ==6756==    by 0x400AB93: (within /lib/ld-2.7.so)
> ==6756==    by 0x40061E4: (within /lib/ld-2.7.so)
> ==6756==    by 0x4008677: (within /lib/ld-2.7.so)
> ==6756==    by 0x4012048: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x401191A: (within /lib/ld-2.7.so)
> ==6756==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x50444EC: (within /lib/libdl-2.7.so)
> ==6756==    by 0x5043EF0: dlopen (in /lib/libdl-2.7.so)
> ==6756==    by 0x4B33FB: _PyImport_GetDynLoadFunc (in /usr/bin/python2.5)
> ==6756==  Address 0x5cb9fc0 is 88 bytes inside a block of size 89 alloc'd
> ==6756==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==6756==    by 0x4007823: (within /lib/ld-2.7.so)
> ==6756==    by 0x40085CE: (within /lib/ld-2.7.so)
> ==6756==    by 0x4012048: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x401191A: (within /lib/ld-2.7.so)
> ==6756==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x50444EC: (within /lib/libdl-2.7.so)
> ==6756==    by 0x5043EF0: dlopen (in /lib/libdl-2.7.so)
> ==6756==    by 0x4B33FB: _PyImport_GetDynLoadFunc (in /usr/bin/python2.5)
> ==6756==    by 0x4A3997: _PyImport_LoadDynamicModule (in
> /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 8
> ==6756==    at 0x4015EB0: (within /lib/ld-2.7.so)
> ==6756==    by 0x400AB93: (within /lib/ld-2.7.so)
> ==6756==    by 0x40061E4: (within /lib/ld-2.7.so)
> ==6756==    by 0x4008677: (within /lib/ld-2.7.so)
> ==6756==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==6756==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x401191A: (within /lib/ld-2.7.so)
> ==6756==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==  Address 0x5cba5d0 is 64 bytes inside a block of size 71 alloc'd
> ==6756==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==6756==    by 0x4005F47: (within /lib/ld-2.7.so)
> ==6756==    by 0x400885F: (within /lib/ld-2.7.so)
> ==6756==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==6756==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x401191A: (within /lib/ld-2.7.so)
> ==6756==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x50444EC: (within /lib/libdl-2.7.so)
> ==6756==
> ==6756== Invalid read of size 8
> ==6756==    at 0x4015EE4: (within /lib/ld-2.7.so)
> ==6756==    by 0x400AB93: (within /lib/ld-2.7.so)
> ==6756==    by 0x40061E4: (within /lib/ld-2.7.so)
> ==6756==    by 0x4008677: (within /lib/ld-2.7.so)
> ==6756==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==6756==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x401191A: (within /lib/ld-2.7.so)
> ==6756==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==  Address 0x5cbd0d8 is 16 bytes inside a block of size 23 alloc'd
> ==6756==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==6756==    by 0x4008B75: (within /lib/ld-2.7.so)
> ==6756==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==6756==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x401191A: (within /lib/ld-2.7.so)
> ==6756==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x50444EC: (within /lib/libdl-2.7.so)
> ==6756==    by 0x5043EF0: dlopen (in /lib/libdl-2.7.so)
> ==6756==
> ==6756== Invalid read of size 8
> ==6756==    at 0x4015ECA: (within /lib/ld-2.7.so)
> ==6756==    by 0x400522C: (within /lib/ld-2.7.so)
> ==6756==    by 0x40079E5: (within /lib/ld-2.7.so)
> ==6756==    by 0x40089D7: (within /lib/ld-2.7.so)
> ==6756==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==6756==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x401191A: (within /lib/ld-2.7.so)
> ==6756==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==  Address 0x5cc3690 is 8 bytes inside a block of size 9 alloc'd
> ==6756==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==6756==    by 0x4007823: (within /lib/ld-2.7.so)
> ==6756==    by 0x4007979: (within /lib/ld-2.7.so)
> ==6756==    by 0x40089D7: (within /lib/ld-2.7.so)
> ==6756==    by 0x400BE0C: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x400C4D0: (within /lib/ld-2.7.so)
> ==6756==    by 0x40120A8: (within /lib/ld-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==    by 0x401191A: (within /lib/ld-2.7.so)
> ==6756==    by 0x5043F8A: (within /lib/libdl-2.7.so)
> ==6756==    by 0x400DDF5: (within /lib/ld-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4ABE99: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5cb0020 is 32 bytes inside a block of size 268 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x48CB32: (within /usr/bin/python2.5)
> ==6756==    by 0x48EAF6: (within /usr/bin/python2.5)
> ==6756==    by 0x49712A: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==6756==    by 0x4D5432: (within /usr/bin/python2.5)
> ==6756==    by 0x441F6C: (within /usr/bin/python2.5)
> ==6756==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==6756==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x49F494: PyImport_Cleanup (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5caf020 is 3,280 bytes inside a block of size 3,980
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x48CB32: (within /usr/bin/python2.5)
> ==6756==    by 0x48EAF6: (within /usr/bin/python2.5)
> ==6756==    by 0x496D20: (within /usr/bin/python2.5)
> ==6756==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==6756==    by 0x4D5432: (within /usr/bin/python2.5)
> ==6756==    by 0x441F6C: (within /usr/bin/python2.5)
> ==6756==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==6756==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x49F494: PyImport_Cleanup (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5cac020 is 2,424 bytes inside a block of size 3,072
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x443638: (within /usr/bin/python2.5)
> ==6756==    by 0x48A8B2: (within /usr/bin/python2.5)
> ==6756==    by 0x496D33: (within /usr/bin/python2.5)
> ==6756==    by 0x4972CC: PyAST_Compile (in /usr/bin/python2.5)
> ==6756==    by 0x4ABE13: PyRun_FileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4AC0C8: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4145AC: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDAA1: (within /usr/bin/python2.5)
> ==6756==    by 0x4D5432: (within /usr/bin/python2.5)
> ==6756==    by 0x441F6C: (within /usr/bin/python2.5)
> ==6756==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==6756==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5bda020 is not stack'd, malloc'd or (recently) free'd
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4D5442: (within /usr/bin/python2.5)
> ==6756==    by 0x441F6C: (within /usr/bin/python2.5)
> ==6756==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==6756==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5aa5020 is 96 bytes inside a block of size 464 free'd
> ==6756==    at 0x4C23082: realloc (vg_replace_malloc.c:429)
> ==6756==    by 0x439708: PyList_Append (in /usr/bin/python2.5)
> ==6756==    by 0x4A4DC8: (within /usr/bin/python2.5)
> ==6756==    by 0x4A3EA6: (within /usr/bin/python2.5)
> ==6756==    by 0x4A478E: (within /usr/bin/python2.5)
> ==6756==    by 0x4A3EA6: (within /usr/bin/python2.5)
> ==6756==    by 0x4A478E: (within /usr/bin/python2.5)
> ==6756==    by 0x4A5311: PyMarshal_ReadLastObjectFromFile (in
> /usr/bin/python2.5)
> ==6756==    by 0x4A143E: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x441F6C: (within /usr/bin/python2.5)
> ==6756==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==6756==    by 0x44573D: _PyModule_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5aa3020 is 136 bytes inside a block of size 568 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x572E7B8: (within /lib/libc-2.7.so)
> ==6756==    by 0x4A0137: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1A41: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x41AB3C: PyObject_CallFunctionObjArgs (in
> /usr/bin/python2.5)
> ==6756==    by 0x4A2646: PyImport_Import (in /usr/bin/python2.5)
> ==6756==    by 0x4A27F4: PyImport_ImportModule (in /usr/bin/python2.5)
> ==6756==    by 0x4ABB9D: (within /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x441F6C: (within /usr/bin/python2.5)
> ==6756==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==6756==    by 0x4456A2: _PyModule_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x49F311: PyImport_Cleanup (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5c21020 is 208 bytes inside a block of size 568 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x572DDAB: fclose (in /lib/libc-2.7.so)
> ==6756==    by 0x4A155C: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x4987E4: (within /usr/bin/python2.5)
> ==6756==    by 0x498AC4: _PyCodec_Lookup (in /usr/bin/python2.5)
> ==6756==    by 0x499027: PyCodec_Encoder (in /usr/bin/python2.5)
> ==6756==    by 0x4AD3F7: Py_InitializeEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x49F6DC: _PyImport_Fini (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA76: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5ab5020 is 720 bytes inside a block of size 776 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x457421: (within /usr/bin/python2.5)
> ==6756==    by 0x4CDB32: (within /usr/bin/python2.5)
> ==6756==    by 0x4A136F: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x49F6DC: _PyImport_Fini (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA76: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5b03020 is 9,376 bytes inside a block of size 12,288
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x443638: (within /usr/bin/python2.5)
> ==6756==    by 0x4457AA: (within /usr/bin/python2.5)
> ==6756==    by 0x441F6C: (within /usr/bin/python2.5)
> ==6756==    by 0x44398D: PyDict_SetItem (in /usr/bin/python2.5)
> ==6756==    by 0x49F323: PyImport_Cleanup (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA71: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==6756==    by 0x4D5432: (within /usr/bin/python2.5)
> ==6756==    by 0x435E96: (within /usr/bin/python2.5)
> ==6756==    by 0x4A9FE2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5c21020 is 208 bytes inside a block of size 568 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x572DDAB: fclose (in /lib/libc-2.7.so)
> ==6756==    by 0x4A155C: (within /usr/bin/python2.5)
> ==6756==    by 0x4A29E2: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1DFA: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x4987E4: (within /usr/bin/python2.5)
> ==6756==    by 0x498AC4: _PyCodec_Lookup (in /usr/bin/python2.5)
> ==6756==    by 0x499027: PyCodec_Encoder (in /usr/bin/python2.5)
> ==6756==    by 0x4AD3F7: Py_InitializeEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4D5442: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x459AE6: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x4A9FD2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==  Address 0x5c30020 is 456 bytes inside a block of size 1,323
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x4D5442: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x459AE6: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x4A9FD2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CDABA: (within /usr/bin/python2.5)
> ==6756==    by 0x4D5432: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x459AE6: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x4A9FD2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==6756==  Address 0x5c30020 is 456 bytes inside a block of size 1,323
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x4D5442: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x459AE6: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x4A9FD2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3DA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x41F3EA: (within /usr/bin/python2.5)
> ==6756==    by 0x4573F0: (within /usr/bin/python2.5)
> ==6756==    by 0x459AE6: (within /usr/bin/python2.5)
> ==6756==    by 0x44361A: (within /usr/bin/python2.5)
> ==6756==    by 0x4A9FD2: PyInterpreterState_Clear (in /usr/bin/python2.5)
> ==6756==    by 0x4ABA83: Py_Finalize (in /usr/bin/python2.5)
> ==6756==  Address 0x5c2d020 is 33,520 bytes inside a block of size 33,907
> free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x4A5339: PyMarshal_ReadLastObjectFromFile (in
> /usr/bin/python2.5)
> ==6756==    by 0x4A143E: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1928: (within /usr/bin/python2.5)
> ==6756==    by 0x4A1E8C: (within /usr/bin/python2.5)
> ==6756==    by 0x4A2039: (within /usr/bin/python2.5)
> ==6756==    by 0x4A24E4: PyImport_ImportModuleLevel (in /usr/bin/python2.5)
> ==6756==    by 0x481AA8: (within /usr/bin/python2.5)
> ==6756==    by 0x417E32: PyObject_Call (in /usr/bin/python2.5)
> ==6756==    by 0x482051: PyEval_CallObjectWithKeywords (in
> /usr/bin/python2.5)
> ==6756==    by 0x485BF0: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==
> ==6756== Invalid read of size 4
> ==6756==    at 0x448D84: PyObject_Free (in /usr/bin/python2.5)
> ==6756==    by 0x4CAB31: PyGrammar_RemoveAccelerators (in
> /usr/bin/python2.5)
> ==6756==    by 0x4ABAD8: Py_Finalize (in /usr/bin/python2.5)
> ==6756==    by 0x4140B7: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==  Address 0x5b2a020 is 24 bytes inside a block of size 672 free'd
> ==6756==    at 0x4C22B2E: free (vg_replace_malloc.c:323)
> ==6756==    by 0x4CACBC: PyGrammar_AddAccelerators (in /usr/bin/python2.5)
> ==6756==    by 0x4CBA76: PyParser_New (in /usr/bin/python2.5)
> ==6756==    by 0x414870: (within /usr/bin/python2.5)
> ==6756==    by 0x4ACAE7: PyRun_StringFlags (in /usr/bin/python2.5)
> ==6756==    by 0x4813AC: (within /usr/bin/python2.5)
> ==6756==    by 0x48964A: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x488C06: PyEval_EvalFrameEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A405: PyEval_EvalCodeEx (in /usr/bin/python2.5)
> ==6756==    by 0x48A521: PyEval_EvalCode (in /usr/bin/python2.5)
> ==6756==    by 0x4A0B1F: PyImport_ExecCodeModuleEx (in /usr/bin/python2.5)
> ==6756==    by 0x4A134F: (within /usr/bin/python2.5)
> ==6756==
> ==6756== ERROR SUMMARY: 621 errors from 57 contexts (suppressed: 133 from
> 1)
> ==6756== malloc/free: in use at exit: 2,247,796 bytes in 1,211 blocks.
> ==6756== malloc/free: 82,252 allocs, 81,041 frees, 9,091,997 bytes
> allocated.
> ==6756== For counts of detected errors, rerun with: -v
> ==6756== searching for pointers to 1,211 not-freed blocks.
> ==6756== checked 3,307,200 bytes.
> ==6756==
> ==6756==
> ==6756== 14,616 bytes in 50 blocks are possibly lost in loss record 23 of
> 27
> ==6756==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
> ==6756==    by 0x4B6408: _PyObject_GC_Malloc (in /usr/bin/python2.5)
> ==6756==    by 0x4B653C: _PyObject_GC_New (in /usr/bin/python2.5)
> ==6756==    by 0x444AEA: PyDict_New (in /usr/bin/python2.5)
> ==6756==    by 0x4AD159: Py_InitializeEx (in /usr/bin/python2.5)
> ==6756==    by 0x413F20: Py_Main (in /usr/bin/python2.5)
> ==6756==    by 0x56E91C3: (below main) (in /lib/libc-2.7.so)
> ==6756==
> ==6756== LEAK SUMMARY:
> ==6756==    definitely lost: 0 bytes in 0 blocks.
> ==6756==      possibly lost: 14,616 bytes in 50 blocks.
> ==6756==    still reachable: 2,233,180 bytes in 1,161 blocks.
> ==6756==         suppressed: 0 bytes in 0 blocks.
> ==6756== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==6756== To see them, rerun with: --leak-check=full --show-reachable=yes
> Command ['/usr/bin/valgrind', '--leak-check=full', '--error-exitcode=1',
> '/usr/bin/python',
> '/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/examples/csma-bridge.py']
> exited with code 1
> [655/673] regression-test (test-csma-packet-socket)
> ==6762== Memcheck, a memory error detector.
> ==6762== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6762== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6762== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6762== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6762== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6762== For more details, rerun with: -v
> ==6762==
> ==6762==
> ==6762== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6762== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6762== malloc/free: 117,119 allocs, 117,119 frees, 5,946,265 bytes
> allocated.
> ==6762== For counts of detected errors, rerun with: -v
> ==6762== All heap blocks were freed -- no leaks are possible.
> [656/673] regression-test (test-csma-ping)
> ==6760== Memcheck, a memory error detector.
> ==6760== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6760== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6761== Memcheck, a memory error detector.
> ==6760== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6761== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6760== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6761== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6760== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6761== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6760== For more details, rerun with: -v
> ==6761== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6760==
> ==6761== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6760==
> ==6761== For more details, rerun with: -v
> ==6760== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6761==
> ==6760== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6761==
> ==6760== malloc/free: 72,424 allocs, 72,424 frees, 3,493,036 bytes
> allocated.
> ==6761== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6760== For counts of detected errors, rerun with: -v
> ==6761== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6760== All heap blocks were freed -- no leaks are possible.
> ==6761== malloc/free: 6,463 allocs, 6,463 frees, 470,242 bytes allocated.
> ==6761== For counts of detected errors, rerun with: -v
> ==6761== All heap blocks were freed -- no leaks are possible.
> [657/673] regression-test (test-csma-raw-ip-socket)
> [658/673] regression-test (test-csma-star)
> ==6766== Memcheck, a memory error detector.
> ==6766== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6766== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6766== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6766== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6766== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6766== For more details, rerun with: -v
> ==6766==
> ==6766==
> ==6766== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6766== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6766== malloc/free: 4,706 allocs, 4,706 frees, 344,745 bytes allocated.
> ==6766== For counts of detected errors, rerun with: -v
> ==6766== All heap blocks were freed -- no leaks are possible.
> [659/673] regression-test (test-dynamic-global-routing)
> ==6765== Memcheck, a memory error detector.
> ==6765== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6765== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6765== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6765== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6765== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6765== For more details, rerun with: -v
> ==6765==
> ==6765==
> ==6765== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6765== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6765== malloc/free: 5,876 allocs, 5,876 frees, 416,198 bytes allocated.
> ==6765== For counts of detected errors, rerun with: -v
> ==6765== All heap blocks were freed -- no leaks are possible.
> [660/673] regression-test (test-global-routing-slash32)
> ==6769== Memcheck, a memory error detector.
> ==6769== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6769== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6769== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6769== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6769== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6769== For more details, rerun with: -v
> ==6769==
> ==6769==
> ==6769== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6769== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6769== malloc/free: 6,575 allocs, 6,575 frees, 454,153 bytes allocated.
> ==6769== For counts of detected errors, rerun with: -v
> ==6769== All heap blocks were freed -- no leaks are possible.
> [661/673] regression-test (test-ns2-mob)
> ==6768== Memcheck, a memory error detector.
> ==6768== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6768== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6768== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6768== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6768== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6768== For more details, rerun with: -v
> ==6768==
> ==6768==
> ==6768== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6768== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6768== malloc/free: 18,788 allocs, 18,788 frees, 1,124,538 bytes
> allocated.
> ==6768== For counts of detected errors, rerun with: -v
> ==6768== All heap blocks were freed -- no leaks are possible.
> [662/673] regression-test (test-realtime-udp-echo)
> ==6764== Memcheck, a memory error detector.
> ==6764== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6764== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6764== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6764== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6764== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6764== For more details, rerun with: -v
> ==6764==
> ==6764==
> ==6764== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6764== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6764== malloc/free: 101,219 allocs, 101,219 frees, 5,159,074 bytes
> allocated.
> ==6764== For counts of detected errors, rerun with: -v
> ==6764== All heap blocks were freed -- no leaks are possible.
> [663/673] regression-test (test-second)
> ==6770== Memcheck, a memory error detector.
> ==6770== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6770== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6770== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6770== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6770== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6770== For more details, rerun with: -v
> ==6770==
> ==6770==
> ==6770== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6770== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6770== malloc/free: 3,523 allocs, 3,523 frees, 217,273 bytes allocated.
> ==6770== For counts of detected errors, rerun with: -v
> ==6770== All heap blocks were freed -- no leaks are possible.
> [664/673] regression-test (test-simple-error-model)
> ==6772== Memcheck, a memory error detector.
> ==6772== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6772== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6772== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6772== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6772== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6772== For more details, rerun with: -v
> ==6772==
> ==6772==
> ==6772== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6772== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6772== malloc/free: 5,006 allocs, 5,006 frees, 358,510 bytes allocated.
> ==6772== For counts of detected errors, rerun with: -v
> ==6772== All heap blocks were freed -- no leaks are possible.
> [665/673] regression-test (test-simple-global-routing)
> ==6771== Memcheck, a memory error detector.
> ==6771== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6771== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6771== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6771== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6771== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6771== For more details, rerun with: -v
> ==6771==
> ==6771==
> ==6771== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6771== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6771== malloc/free: 45,607 allocs, 45,607 frees, 2,405,555 bytes
> allocated.
> ==6771== For counts of detected errors, rerun with: -v
> ==6771== All heap blocks were freed -- no leaks are possible.
> [666/673] regression-test (test-simple-point-to-point-olsr)
> ==6775== Memcheck, a memory error detector.
> ==6775== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6775== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6775== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6775== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6775== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6775== For more details, rerun with: -v
> ==6775==
> ==6775==
> ==6775== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6775== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6775== malloc/free: 87,675 allocs, 87,675 frees, 4,224,651 bytes
> allocated.
> ==6775== For counts of detected errors, rerun with: -v
> ==6775== All heap blocks were freed -- no leaks are possible.
> [667/673] regression-test (test-static-routing-slash32)
> ==6773== Memcheck, a memory error detector.
> ==6773== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6773== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6773== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6773== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6773== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6773== For more details, rerun with: -v
> ==6773==
> ==6773==
> ==6773== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6773== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6773== malloc/free: 178,282 allocs, 178,282 frees, 7,839,585 bytes
> allocated.
> ==6773== For counts of detected errors, rerun with: -v
> ==6773== All heap blocks were freed -- no leaks are possible.
> [668/673] regression-test (test-tcp-large-transfer)
> ==6776== Memcheck, a memory error detector.
> ==6776== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6776== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6776== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6776== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6776== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6776== For more details, rerun with: -v
> ==6776==
> ==6776==
> ==6776== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6776== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6776== malloc/free: 6,450 allocs, 6,450 frees, 450,514 bytes allocated.
> ==6776== For counts of detected errors, rerun with: -v
> ==6776== All heap blocks were freed -- no leaks are possible.
> [669/673] regression-test (test-tcp-nsc-lfn)
> [670/673] regression-test (test-third)
> ==6783== Memcheck, a memory error detector.
> ==6783== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6783== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6783== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6783== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6783== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6783== For more details, rerun with: -v
> ==6783==
> ==6783==
> ==6783== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6783== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6783== malloc/free: 7,445 allocs, 7,445 frees, 520,586 bytes allocated.
> ==6783== For counts of detected errors, rerun with: -v
> ==6783== All heap blocks were freed -- no leaks are possible.
> [671/673] regression-test (test-udp-echo)
> ==6774== Memcheck, a memory error detector.
> ==6774== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6774== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6774== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6774== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6774== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6774== For more details, rerun with: -v
> ==6774==
> ==6774==
> ==6774== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6774== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6774== malloc/free: 221,556 allocs, 221,556 frees, 9,464,122 bytes
> allocated.
> ==6774== For counts of detected errors, rerun with: -v
> ==6774== All heap blocks were freed -- no leaks are possible.
> [672/673] regression-test (test-wifi-wired-bridging)
> ==6784== Memcheck, a memory error detector.
> ==6784== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6784== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6784== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6784== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6784== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6784== For more details, rerun with: -v
> ==6784==
> ==6784==
> ==6784== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6784== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6784== malloc/free: 5,557 allocs, 5,557 frees, 403,686 bytes allocated.
> ==6784== For counts of detected errors, rerun with: -v
> ==6784== All heap blocks were freed -- no leaks are possible.
> ==6785== Memcheck, a memory error detector.
> ==6785== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6785== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6785== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6785== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6785== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6785== For more details, rerun with: -v
> ==6785==
> ==6785==
> ==6785== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6785== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6785== malloc/free: 42,196 allocs, 42,196 frees, 2,740,421 bytes
> allocated.
> ==6785== For counts of detected errors, rerun with: -v
> ==6785== All heap blocks were freed -- no leaks are possible.
> ==6777== Memcheck, a memory error detector.
> ==6777== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6777== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6777== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6777== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6777== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6777== For more details, rerun with: -v
> ==6777==
> ==6777==
> ==6777== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6777== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6777== malloc/free: 280,322 allocs, 280,322 frees, 15,086,244 bytes
> allocated.
> ==6777== For counts of detected errors, rerun with: -v
> ==6777== All heap blocks were freed -- no leaks are possible.
> ==6767== Memcheck, a memory error detector.
> ==6767== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==6767== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==6767== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==6767== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
> framework.
> ==6767== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==6767== For more details, rerun with: -v
> ==6767==
> ==6767==
> ==6767== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==6767== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==6767== malloc/free: 1,657,696 allocs, 1,657,696 frees, 99,041,469 bytes
> allocated.
> ==6767== For counts of detected errors, rerun with: -v
> ==6767== All heap blocks were freed -- no leaks are possible.
> [673/673] regression-test-collector
> Waf: Leaving directory
> `/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build'
> Build failed
>  -> task failed (err #1):
>        {task: regression_test_collector_task }
> FAIL test-csma-bridge
> PASS test-csma-one-subnet
> PASS test-csma-multicast
> PASS test-csma-broadcast
> PASS test-csma-raw-ip-socket
> PASS test-csma-ping
> PASS test-global-routing-slash32
> PASS test-dynamic-global-routing
> PASS test-csma-packet-socket
> PASS test-ns2-mob
> PASS test-second
> PASS test-realtime-udp-echo
> PASS test-simple-point-to-point-olsr
> PASS test-simple-error-model
> PASS test-static-routing-slash32
> SKIP test-tcp-nsc-lfn (NSC does not get along with valgrind)
> PASS test-third
> PASS test-simple-global-routing
> PASS test-udp-echo
> PASS test-wifi-wired-bridging
> PASS test-tcp-large-transfer
> PASS test-csma-star
> Regression testing summary:
> SKIP: 1 of 22 tests have been skipped (test-tcp-nsc-lfn)
> FAIL: 1 of 22 tests have failed (test-csma-bridge)
> FAILURE: waf -d debug configure; ./waf --valgrind --regression failed on
> ns-3-dev
> _______________________________________________
>



-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From mathieu.lacage at sophia.inria.fr  Tue Apr 21 04:34:20 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 21 Apr 2009 13:34:20 +0200
Subject: [Ns-developers] static builds [take 3]
Message-ID: <1240313660.317.287.camel@diese.inria.fr>

hi,

Here is a very simple minimal patch which adds --enable-static on linux
systems when python is disabled.

bash-3.2$ ./waf configure -d optimized --enable-static --disable-python
[...]
bash-3.2$ ./waf
[...]
bash-3.2$ ./waf shell
bash-3.2$ ./build/optimized/utils/bench-packets --n=10000000
Running bench-packets with n=10000000
a=1.98728e+06 packets/s
b=3.97298e+06 packets/s
c=2.60892e+06 packets/s
d=1.20511e+06 packets/s
bash-3.2$ ./waf configure -d optimized
[...]
bash-3.2$ ./waf
[...]
bash-3.2$ ./build/optimized/utils/bench-packets --n=10000000
Running bench-packets with n=10000000
a=1.78476e+06 packets/s
b=3.465e+06 packets/s
c=2.18866e+06 packets/s
d=910581 packets/s

I feel that this is good-enough for a large set of users, so, I would
like to go ahead and merge this in: comments ?

Mathieu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: static.patch
Type: text/x-patch
Size: 2602 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090421/97c348a3/static.bin

From gjcarneiro at gmail.com  Tue Apr 21 04:40:47 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Tue, 21 Apr 2009 12:40:47 +0100
Subject: [Ns-developers] static builds [take 3]
In-Reply-To: <1240313660.317.287.camel@diese.inria.fr>
References: <1240313660.317.287.camel@diese.inria.fr>
Message-ID: <a467ca4f0904210440s492158eavfa72897f6eac0f03@mail.gmail.com>

-Wl,--whole-archive,-Bstatic

So simple! :o

+1 from me :-)

2009/4/21 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> hi,
>
> Here is a very simple minimal patch which adds --enable-static on linux
> systems when python is disabled.
>
> bash-3.2$ ./waf configure -d optimized --enable-static --disable-python
> [...]
> bash-3.2$ ./waf
> [...]
> bash-3.2$ ./waf shell
> bash-3.2$ ./build/optimized/utils/bench-packets --n=10000000
> Running bench-packets with n=10000000
> a=1.98728e+06 packets/s
> b=3.97298e+06 packets/s
> c=2.60892e+06 packets/s
> d=1.20511e+06 packets/s
> bash-3.2$ ./waf configure -d optimized
> [...]
> bash-3.2$ ./waf
> [...]
> bash-3.2$ ./build/optimized/utils/bench-packets --n=10000000
> Running bench-packets with n=10000000
> a=1.78476e+06 packets/s
> b=3.465e+06 packets/s
> c=2.18866e+06 packets/s
> d=910581 packets/s
>
> I feel that this is good-enough for a large set of users, so, I would
> like to go ahead and merge this in: comments ?
>
> Mathieu
>



-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From mathieu.lacage at sophia.inria.fr  Tue Apr 21 05:35:42 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 21 Apr 2009 14:35:42 +0200
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr> <49E84ED5.7010603@cttc.es>
	<005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
Message-ID: <1240317342.317.345.camel@diese.inria.fr>

hi craig,

On Fri, 2009-04-17 at 16:10 -0700, craigdo at ee.washington.edu wrote:

> http://www.nsnam.org/wiki/index.php/StochasticModelValidation

This looks really really cool !

> It's not intended to be complete and thorough (although the chi square
> tests are real) just a demonstration of where we are headed.
> 
> The code can be found at:
> 
> http://code.nsnam.org/craigdo/ns-3-valver
> 
> with the rng tests in validation/rng and the beginnings of a TCP
> verification test in verification/tcp (not much there yet).

Low-level comments:
-------------------

1) it would be nice to have a shared chi-square facility rather than
re-implementing your own all the time

2) it would be nice to reuse the gnuplot support in src/contrib/gnuplot*


Higher-level comments:
----------------------

1) I am very worried about the content of:
http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting

As a non-native english speaker, I had to lookup many words in a
dictionary and, even when I found the french translation, I had to
lookup the meaning of the french words. I am worried that the above is
overly formal through abstract and generic considerations about abstract
modelization/verification/validation theory. It would be much more
helpful if it could focus on the important things we (users) need to
know within the context of ns-3. Maybe starting (instead of ending) with
real use-cases network researchers are familiar with would help a lot
explain your goal and what you intend to do to achieve it.

2) I am a bit worried by the idea of trying to do too many things at the
same time: "as a side-effect also generate something that can be used on
a validation and verification website (pretty pictures)". It would be
nice to focus on a single tool to do a single thing really well rather
than build a validation system which does everything. I can see that
it's sort of cool to generate graphs for the web, and that it could help
debugging some failing testcases when they fail but, I feel that this
would steer away valuable resources from the crucial issue: that of
increasing the code coverage of our automated test code. 

For example, looking at the code in verification/rng/*.cc, I see that
quite a bit of code is invested in generating the graphs, and enabling
them from the command-line. If we did not try to do this, we could
easily re-use the existing unit test framework to write these rng tests
in src/core/random-variable.cc, and, then, the question becomes: "which
framework should I use ?" which is a problem related to item 3) below.

3) I am not sure I understand the point of knowing the difference
between verification and validation. Specifically, I don't really
understand why we need to split these two kinds of tests in two
different directories: can't we all bundle them in the 'tests'
directory, and, if we have really too many of them one day, split them ?
What I am worried about here is that, as a user, I would spend time
thinking about where I should put my test code while what really matters
is that I should be writing test code.

I suspect that a lot of the issues I pointed out above are things you
are aware of and are working on already, but, just in case you are not,
here they are.

Mathieu


From mk.banchi at gmail.com  Tue Apr 21 07:22:17 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Tue, 21 Apr 2009 16:22:17 +0200
Subject: [Ns-developers] About 802.11 management frame
Message-ID: <49EDD699.2080405@gmail.com>

Hi all,

i've a question about 802.11 management frames. I'll try to explain the
problem by an example. Suppose a sta1 is sending an Association request
to an Ap.
The Ap should send an Association Response frame. But should this happen
in the same TxOp? I mean, between this frames exchange is possible
another frame exchange for example a data frame exchange between sta2
and ap? I read carefully the standard but this is not really explained.
I deduced it in the clause 7.1.4 (point 2):

-------
Within all data or management frames sent in a CP by the QoS STAs
outside of a controlled access phase
(CAP), following a contention access of the channel, the Duration/ID
field is set to one of the following
values:
a) For management frames, frames with QoS Data subfield set to 0, and
unicast data frames with Ack
Policy subfield set to Normal Ack,
1) The time required for the transmission of one ACK frame (including
appropriate IFS values), if
the frame is the final fragment of the TXOP, or
2) The time required for the transmission of one ACK frame plus the time
required for the
transmission of the following MPDU and its response if required
(including appropriate IFS
values).
--------


I think that this is very important! Working with block ack, there's
need to work with management frame in order to negotiate block ack and
i found it's complex if the management frame exchange could be completed
in two different Txops even if i think that this doesn't make sense.
Ns-3 for now works with management frames as they were data frames, so
their exchange (for example association request/ association response)
could not be completed in the same Txop.

Thank you all,

Mirko


-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090421/adbcf8bc/smime.bin

From riley at ece.gatech.edu  Tue Apr 21 07:26:15 2009
From: riley at ece.gatech.edu (George Riley)
Date: Tue, 21 Apr 2009 10:26:15 -0400
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr>
	<49E84ED5.7010603@cttc.es>
	<005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
Message-ID: <3CECB0E2-4206-4EC5-BCA6-444459D17F49@ece.gatech.edu>

Hi Craig,

Some random thoughts about this.

You refer to RFC793 as the TCP specification; while this is true, the  
ns-3 model
is based on RFC2581.

You discuss observing the real-world implementation of the artifact  
being modeled
as the "baseline" or "true" behavior.  There is no TCP implementation  
that I am
aware of that follows the RFC precisely.  For example Linux  
implementations use a
non-standard (no RFC) implementation called "BIC TCP", and later  
"CUBIC TCP".
So it's not clear how the discussion here can reasonably be applied to  
the ns3 TCP.
In our case, the validation is whether or not our model does what is  
specified in
RFC 2581.

Further, there is no randomness at all in TCP, either as implemented  
in ns3 or in
actual implementations. GIven the same set of stimuli, the TCP  
implementations
will always behave in exactly the same way.  The only non- 
deterministic behavior
in implementations of TCP is in the timeout values, which will only  
occur on scheduler
interrupts, and not exactly to the microsecond specified.  So the  
discussion about random
variables, while very nice and correct, is not precisely applicable  
here.  There is randomness
of course in things that happen outside of TCP (for example packet  
losses in a queue that
is overloaded by a large HTTP transfer).

Do you think it might make sense to use a different baseline for the  
discussion, perhaps
the path loss models or something else with true randomness?

George

--------------------------------------------------
George Riley
Associate Professor
Georgia Tech
Electrical and Computer Engineering
riley at ece.gatech.edu
404-894-4767
Klaus Advanced Computing Building
Room 3360
266 Ferst Drive
Atlanta, Georgia 30332-0765

ECE4110 Web page:
http://users.ece.gatech.edu/~riley/ece4110/

ECE4112 Web page:
http://users.ece.gatech.edu/~riley/ece4112/









On Apr 17, 2009, at 7:10 PM, <craigdo at ee.washington.edu> <craigdo at ee.washington.edu 
 > wrote:

> Hi All,
>
> Some of you may have noticed that I've been pondering what to do  
> about validation and verification of ns-3 models.  I've played
> around a bit and have an example put together that does some  
> statistical validation of a subset of our random number generators.
>
> Some folks around here have expressed an interest in getting this  
> cleaned up and checked in fairly quickly.  So even though this is
> not even close to fully baked I thought I'd socialize what I have.   
> Feel free to comment or tell me I'm on crack, as another one of
> the developers is fond of saying.
>
> The high-level idea is to sharpen our models for what we consider  
> system/integration/regression tests.  Right now we have regression
> tests that are basically example programs we have pressed into  
> double duty.  We want to move toward purpose-build verification tests
> and away from the trace-file-based example program hacks we have  
> today.  We also want to add some form of validation framework where
> people can demonstrate that their models are connected with some  
> kind of reality.  As a byproduct of this validation and
> verification test effort, we would like to see something that can be  
> used as a regression suite and as a side-effect also generate
> something that can be used on a validation and verification website  
> (pretty pictures).
>
> I've put together some words on the wiki.  They're kind of  
> incomplete ramblings and thoughts right now, but you can probably  
> get a
> decent flavor of where I'm going (don't hold me to anything):
>
> http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting
>
> As it stands, the two areas of verification and validation are quite  
> separate, but they'll most likely get folded together as things
> develop.
>
> I have random number generator tests built that do statistical  
> validation, generate pretty plots and can be run as regression tests.
> I'll eventually integrate them into waf, but they are stand-alone  
> right now.  As an example of a validation wiki, I put together the
> following:
>
> http://www.nsnam.org/wiki/index.php/StochasticModelValidation
>
> It's not intended to be complete and thorough (although the chi  
> square tests are real) just a demonstration of where we are headed.
>
> The code can be found at:
>
> http://code.nsnam.org/craigdo/ns-3-valver
>
> with the rng tests in validation/rng and the beginnings of a TCP  
> verification test in verification/tcp (not much there yet).
>
> If you have any plans or ideas please don't hesitate to let me know  
> about them.  If you are doing validation tests on your own, I'd
> love to figure out how to make it easy to integrate them.
>
> Regards,
>
> -- Craig
>


From L.Wood at surrey.ac.uk  Tue Apr 21 08:37:18 2009
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Tue, 21 Apr 2009 16:37:18 +0100
Subject: [Ns-developers] First Stab at Validation and Verification
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr><49E84ED5.7010603@cttc.es><005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
	<3CECB0E2-4206-4EC5-BCA6-444459D17F49@ece.gatech.edu>
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B0FDF@EVS-EC1-NODE4.surrey.ac.uk>

initial sequence number?

> Further, there is no randomness at all in TCP, either as implemented  
> in ns3 or in actual implementations.

From riley at ece.gatech.edu  Tue Apr 21 08:55:46 2009
From: riley at ece.gatech.edu (George Riley)
Date: Tue, 21 Apr 2009 11:55:46 -0400
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B0FDF@EVS-EC1-NODE4.surrey.ac.uk>
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr><49E84ED5.7010603@cttc.es><005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
	<3CECB0E2-4206-4EC5-BCA6-444459D17F49@ece.gatech.edu>
	<4835AFD53A246A40A3B8DA85D658C4BE7B0FDF@EVS-EC1-NODE4.surrey.ac.uk>
Message-ID: <56DE0DBA-2A5B-407D-8DCA-E80694AC235F@ece.gatech.edu>

Yep, you are right; but the random ISN does not really affect the way  
packets
are sent, just the contents; the overall observable behavior is the  
same.
So yes, the ISN is random, but I still claim it is not random in the  
sense
that Craig was looking for in is validation writeup.

George

--------------------------------------------------
George Riley
Associate Professor
Georgia Tech
Electrical and Computer Engineering
riley at ece.gatech.edu
404-894-4767
Klaus Advanced Computing Building
Room 3360
266 Ferst Drive
Atlanta, Georgia 30332-0765

ECE4110 Web page:
http://users.ece.gatech.edu/~riley/ece4110/

ECE4112 Web page:
http://users.ece.gatech.edu/~riley/ece4112/









On Apr 21, 2009, at 11:37 AM, <L.Wood at surrey.ac.uk> wrote:

> initial sequence number?
>
> > Further, there is no randomness at all in TCP, either as implemented
> > in ns3 or in actual implementations.
>


From basimjaved at gmail.com  Tue Apr 21 08:58:20 2009
From: basimjaved at gmail.com (Basim Javed)
Date: Tue, 21 Apr 2009 17:58:20 +0200
Subject: [Ns-developers] About 802.11 management frame
In-Reply-To: <49EDD699.2080405@gmail.com>
References: <49EDD699.2080405@gmail.com>
Message-ID: <adbe58370904210858w72bc4de8g65b357e888e47055@mail.gmail.com>

hi

If I correctly understand the situation, I may add:
The concept of TXOP is limited for a given STA which has already won
contention; so there is no chance that "The Ap should send an Association
Response frame. But should this happen in the same TxOp? ". The AP will have
its own TXOP, which may enable sending one response frame only.

regards
B

On Tue, Apr 21, 2009 at 4:22 PM, Mirko Banchi <mk.banchi at gmail.com> wrote:

> Hi all,
>
> i've a question about 802.11 management frames. I'll try to explain the
> problem by an example. Suppose a sta1 is sending an Association request
> to an Ap.
> The Ap should send an Association Response frame. But should this happen
> in the same TxOp? I mean, between this frames exchange is possible
> another frame exchange for example a data frame exchange between sta2
> and ap? I read carefully the standard but this is not really explained.
> I deduced it in the clause 7.1.4 (point 2):
>
> -------
> Within all data or management frames sent in a CP by the QoS STAs
> outside of a controlled access phase
> (CAP), following a contention access of the channel, the Duration/ID
> field is set to one of the following
> values:
> a) For management frames, frames with QoS Data subfield set to 0, and
> unicast data frames with Ack
> Policy subfield set to Normal Ack,
> 1) The time required for the transmission of one ACK frame (including
> appropriate IFS values), if
> the frame is the final fragment of the TXOP, or
> 2) The time required for the transmission of one ACK frame plus the time
> required for the
> transmission of the following MPDU and its response if required
> (including appropriate IFS
> values).
> --------
>
>
> I think that this is very important! Working with block ack, there's
> need to work with management frame in order to negotiate block ack and
> i found it's complex if the management frame exchange could be completed
> in two different Txops even if i think that this doesn't make sense.
> Ns-3 for now works with management frames as they were data frames, so
> their exchange (for example association request/ association response)
> could not be completed in the same Txop.
>
> Thank you all,
>
> Mirko
>
>
> --
> Mirko Banchi
>
> e-mail:    mk.banchi at gmail.com
> e-mail:    mk.banchi at virgilio.it
> id-jabber: mk.banchi at jabber.org
> id-msn:    mb11684 at hotmail.com
>
> PGP key fingerprint:
>
> 308F BFB1 4E67 2522 C88E
> DC69 7631 52ED 32A5 6456
>
>

From mk.banchi at gmail.com  Tue Apr 21 09:05:47 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Tue, 21 Apr 2009 18:05:47 +0200
Subject: [Ns-developers] About 802.11 management frame
In-Reply-To: <adbe58370904210857r4b2d7d2id06ff83085ef0328@mail.gmail.com>
References: <49EDD699.2080405@gmail.com>
	<adbe58370904210857r4b2d7d2id06ff83085ef0328@mail.gmail.com>
Message-ID: <49EDEEDB.9010705@gmail.com>

Basim Javed ha scritto:
> hi
> 
> If I correctly understand the situation, I may add:
> The concept of TXOP is limited for a given STA which has already won
> contention; so there is no chance that "The Ap should send an Association
> Response frame. But should this happen in the same TxOp? ". The AP will have
> its own TXOP, which may enable sending one response frame only.
> 
> regards
> B

Yes, you are right. I use improperly the term TXOP to intend:
the exchange of four frames:

AssocReq
Ack
AssocResp
Ack

is "atomic"?

However i'm persuasing that could be not atomic even if i don't
understand what standards intends when speak about "its response" (see
section 7.1.4 point a2)

Thanks,

Mirko


-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090421/b1f3f3d9/smime.bin

From craigdo at ee.washington.edu  Tue Apr 21 09:20:21 2009
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Tue, 21 Apr 2009 09:20:21 -0700
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <3CECB0E2-4206-4EC5-BCA6-444459D17F49@ece.gatech.edu>
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr>
	<49E84ED5.7010603@cttc.es>
	<005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
	<3CECB0E2-4206-4EC5-BCA6-444459D17F49@ece.gatech.edu>
Message-ID: <41833959137348D3AFBB1E94470AB836@CRAIGVAIO>

Hi George,

> Some random thoughts about this.
> 
> You refer to RFC793 as the TCP specification; while this is 
> true, the  
> ns-3 model
> is based on RFC2581.

That was just intended to be an example of how some version of TCP might
operate according to a "spec"; and not according to a real-world physical
process of some kind.  Thanks for the info, though.

> You discuss observing the real-world implementation of the artifact  
> being modeled
> as the "baseline" or "true" behavior.  There is no TCP 
> implementation  
> that I am
> aware of that follows the RFC precisely.

The point is that the TCP has some defined behavior we are trying to
simulate.  This is the abstract model.  The abstract model might be RFC 793
with Craig's strange changes.  It might be RFC2581 with George's additions.
It might be RFC2581.  This defines the behavior and is the specification.
The goal then becomes to ensure that the implementation behaves according to
abstract model -- i.e., that I implemented RFC2581 and "George's additions"
correctly.

>  For example Linux  
> implementations use a
> non-standard (no RFC) implementation called "BIC TCP", and later  
> "CUBIC TCP".
> So it's not clear how the discussion here can reasonably be 
> applied to  
> the ns3 TCP.

Somewhere we have to decide what ns3 TCP is and what it should do.  Then we
can write verification tests to make sure that the simulation model actual
does what we advertise it to do.  If that is RFC 2581, then we need to write
verification tests to make sure that ns-3 TCP follows RFC 2581.

> In our case, the validation is whether or not our model does what is  
> specified in
> RFC 2581.

Exactly.

> Further, there is no randomness at all in TCP, either as implemented  
> in ns3 or in
> actual implementations. GIven the same set of stimuli, the TCP  
> implementations
> will always behave in exactly the same way.  The only non- 
> deterministic behavior
> in implementations of TCP is in the timeout values, which will only  
> occur on scheduler
> interrupts, and not exactly to the microsecond specified.  So the  
> discussion about random
> variables, while very nice and correct, is not precisely applicable  
> here.  

I tried to explain this, but I guess I didn't do a very good job.  A
software process which is implemented according to some specification, is
not based on physical processes and may not have random variation.  Thus
verification is the real process you would use to make sure that TCP works
according to its spec.  You make sure that the implementation accurately
reflects the abstract model which is the spec.  This is what I called
verification in the document.  I'm not suggesting that there are random
processes in TCP.  That's the distinction I'm trying to draw using the term
verification instead of validation.

> There is randomness
> of course in things that happen outside of TCP (for example packet  
> losses in a queue that
> is overloaded by a large HTTP transfer).

If a model is going to simulate some randomness or physical process then you
need to deal with the randomness.  I called this validation -- and I have in
mind things like wireless transmission range.  If a model is going to
implement a specification without random processes, you need to do a
deterministic tests.  I called this verification and had in mind TCP.

One issue here is that some people seem to want to remove this distinction.
The distinction is important to other people.

> Do you think it might make sense to use a different baseline for the  
> discussion, perhaps
> the path loss models or something else with true randomness?

Actually, TCP is in the document because it doesn't deal with randomness and
illustrates a distinction I wanted to make.  Hopefully, the distinction I'm
making between validation and verification, stochastic and deterministic
processes becomes clear, even if it doesn't manifest in a directory
structure in the final product.  Eventually a wifi test suite might include
tests to validate physical processes that definitely will be based on random
variables (validation of transmission range) and might also have spec-based
tests (verification: if in state X and receive packet type Y then jump to
state S).  We don't want to split up the wifi tests into two different
suites I think.

> 
> George
> 
> --------------------------------------------------
> George Riley
> Associate Professor
> Georgia Tech
> Electrical and Computer Engineering
> riley at ece.gatech.edu
> 404-894-4767
> Klaus Advanced Computing Building
> Room 3360
> 266 Ferst Drive
> Atlanta, Georgia 30332-0765
> 
> ECE4110 Web page:
> http://users.ece.gatech.edu/~riley/ece4110/
> 
> ECE4112 Web page:
> http://users.ece.gatech.edu/~riley/ece4112/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Apr 17, 2009, at 7:10 PM, <craigdo at ee.washington.edu> 
> <craigdo at ee.washington.edu 
>  > wrote:
> 
> > Hi All,
> >
> > Some of you may have noticed that I've been pondering what to do  
> > about validation and verification of ns-3 models.  I've played
> > around a bit and have an example put together that does some  
> > statistical validation of a subset of our random number generators.
> >
> > Some folks around here have expressed an interest in getting this  
> > cleaned up and checked in fairly quickly.  So even though this is
> > not even close to fully baked I thought I'd socialize what 
> I have.   
> > Feel free to comment or tell me I'm on crack, as another one of
> > the developers is fond of saying.
> >
> > The high-level idea is to sharpen our models for what we consider  
> > system/integration/regression tests.  Right now we have regression
> > tests that are basically example programs we have pressed into  
> > double duty.  We want to move toward purpose-build 
> verification tests
> > and away from the trace-file-based example program hacks we have  
> > today.  We also want to add some form of validation framework where
> > people can demonstrate that their models are connected with some  
> > kind of reality.  As a byproduct of this validation and
> > verification test effort, we would like to see something 
> that can be  
> > used as a regression suite and as a side-effect also generate
> > something that can be used on a validation and verification 
> website  
> > (pretty pictures).
> >
> > I've put together some words on the wiki.  They're kind of  
> > incomplete ramblings and thoughts right now, but you can probably  
> > get a
> > decent flavor of where I'm going (don't hold me to anything):
> >
> > http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting
> >
> > As it stands, the two areas of verification and validation 
> are quite  
> > separate, but they'll most likely get folded together as things
> > develop.
> >
> > I have random number generator tests built that do statistical  
> > validation, generate pretty plots and can be run as 
> regression tests.
> > I'll eventually integrate them into waf, but they are stand-alone  
> > right now.  As an example of a validation wiki, I put together the
> > following:
> >
> > http://www.nsnam.org/wiki/index.php/StochasticModelValidation
> >
> > It's not intended to be complete and thorough (although the chi  
> > square tests are real) just a demonstration of where we are headed.
> >
> > The code can be found at:
> >
> > http://code.nsnam.org/craigdo/ns-3-valver
> >
> > with the rng tests in validation/rng and the beginnings of a TCP  
> > verification test in verification/tcp (not much there yet).
> >
> > If you have any plans or ideas please don't hesitate to let 
> me know  
> > about them.  If you are doing validation tests on your own, I'd
> > love to figure out how to make it easy to integrate them.
> >
> > Regards,
> >
> > -- Craig
> >
> 
> 



From craigdo at ee.washington.edu  Tue Apr 21 10:38:46 2009
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Tue, 21 Apr 2009 10:38:46 -0700
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <1240317342.317.345.camel@diese.inria.fr>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>
	<49E84ED5.7010603@cttc.es>
	<005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
	<1240317342.317.345.camel@diese.inria.fr>
Message-ID: <176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO>


> hi craig,
> 
> On Fri, 2009-04-17 at 16:10 -0700, craigdo at ee.washington.edu wrote:
> 
> > http://www.nsnam.org/wiki/index.php/StochasticModelValidation
> 
> This looks really really cool !
> 
> > It's not intended to be complete and thorough (although the 
> chi square
> > tests are real) just a demonstration of where we are headed.
> > 
> > The code can be found at:
> > 
> > http://code.nsnam.org/craigdo/ns-3-valver
> > 
> > with the rng tests in validation/rng and the beginnings of a TCP
> > verification test in verification/tcp (not much there yet).
> 
> Low-level comments:
> -------------------
> 
> 1) it would be nice to have a shared chi-square facility rather than
> re-implementing your own all the time

Yes.  It's really just a very few lines of code, so I haven't worried about
it yet.

> 2) it would be nice to reuse the gnuplot support in 
> src/contrib/gnuplot*

I forgot about that completely.  Thanks ...

> Higher-level comments:
> ----------------------
> 
> 1) I am very worried about the content of:
> http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting
> 
> As a non-native english speaker, I had to lookup many words in a
> dictionary and, even when I found the french translation, I had to
> lookup the meaning of the french words. I am worried that the above is
> overly formal through abstract and generic considerations 
> about abstract
> modelization/verification/validation theory. 

One of the problems I've run into is that the terminology is confused.  I
wanted to try and write down exactly what it was that I was trying to
accomplish and define the terms I was using.  Unfortunately, for example,
validation can mean different things to different people.  I had imagined
that ambiguous terminology translated into French, German or Portuguese
would be a disaster waiting to happen.  I've been known to be mistaken on
this front, though.  Are there specifics that you found unnecessary or
overly pedantic after your translation exercise?  I know there are terms
there to help clarify what I'm *not* doing.

I don't expect this page to remain (perhaps a simplified version could end
up buried in a manual) but I did want to make sure that everyone could
figure out what I was talking about.  Tom commented on the term "Expectation
Value," which seems to be physics jargon.

> It would be much more
> helpful if it could focus on the important things we (users) need to
> know within the context of ns-3. Maybe starting (instead of 
> ending) with
> real use-cases network researchers are familiar with would help a lot
> explain your goal and what you intend to do to achieve it.

I haven't really written a requirements document yet.  What you see is
really an exploration preliminary to writing something like that.  I'll
definitely produce something like that as the ideas come together.  This is
all not even close to being fully baked.

> 2) I am a bit worried by the idea of trying to do too many 
> things at the
> same time: "as a side-effect also generate something that can 
> be used on
> a validation and verification website (pretty pictures)". It would be
> nice to focus on a single tool to do a single thing really well rather
> than build a validation system which does everything. I can see that
> it's sort of cool to generate graphs for the web, and that it 
> could help
> debugging some failing testcases when they fail but, I feel that this
> would steer away valuable resources from the crucial issue: that of
> increasing the code coverage of our automated test code. 

Well, "increasing the code coverage of our automated test code" is a goal.
How important this is depends on how you are looking at the bigger picture.

Another explicit goal I have been given is to produce the beginnings of an
ns-3 validation and verification web site.  We want to give model authors
examples of how to do validation and verification, and give them the tools
to add to the web suite (which is why I made the wiki pages).  The ability
to re-use the code used in validation and verification to provide an
automatic regression test suite is a very nice feature.

What I think you are talking about is reworking the regression test suite to
use a new framework that doesn't rely on pcap traces.  This is a goal.  This
transitions us from the kind of almost accidental testing we do to
purposeful testing that can then be used in an automated way.  So my goal is
really to create a framework that allows one to write code that can
demonstrate that, for example, our TCP is compliant to something (using a
web site), and then provide a way to package up those tests to perform a
regression to ensure that the TCP continues to be compliant over time.

> For example, looking at the code in verification/rng/*.cc, I see that
> quite a bit of code is invested in generating the graphs, and enabling
> them from the command-line. If we did not try to do this, we could
> easily re-use the existing unit test framework to write these 
> rng tests
> in src/core/random-variable.cc, and, then, the question 
> becomes: "which
> framework should I use ?" which is a problem related to item 3) below.

The difference is related to the purpose of the exercise.  In the case of
random number generators, the first goal is to do validation.  One result of
the validation process should be the pretty web site that I showed.  If
someone wonders about the  random number generators they can go to the web
site and see that they have been validated.

It is also nice to use the tests that someone wrote to automatically confirm
that the validated RNGs continue to be validated.  The question is then,
"how do you extract those tests and run them automatically."  This results
in the command-line stuff you see.  Exactly the same code is then used to
validate an RNG and to do regression testing (which isn't implemented yet).

I suppose it is just as reasonable to write validation tests as part of the
unit tests and reuse them "forward" into a validation suite as it is to
write purpose-built validation tests and reuse them "backward" into
regression tests.  The benefit of using the "backward" approach (heh) is
that you do have the environment to generate the pretty pictures for your
validation report on the web site.

I've talked about a "framework" to do this.  Right now the framework is
main(){} so it's not too impressive-looking.

> 3) I am not sure I understand the point of knowing the difference
> between verification and validation. Specifically, I don't really
> understand why we need to split these two kinds of tests in two
> different directories: can't we all bundle them in the 'tests'
> directory, and, if we have really too many of them one day, 
> split them ?

I suspect that eventually these two directories will be merged into one,
with one environment that allows for the different kinds of tests.  I
mentioned this somewhere I think ...

The difference between validation and verification is subtle; but there is a
difference.  Perhaps it is not important enough to worry about, but I'm not
sure yet.  Right now, I have a completely different idea of what it means to
verify that my TCP connection establishment works according to RFC; and that
my wifi model behaves like some given real radio with respect to
transmission range.

I think this is really a design and implementation process choice rather
than something cast in stone.  

> What I am worried about here is that, as a user, I would spend time
> thinking about where I should put my test code while what 
> really matters
> is that I should be writing test code.

Hopefully what I am encouraging is thinking clearly about what kind of
testing to do and what kinds ns-3 supports and encourages.

> I suspect that a lot of the issues I pointed out above are things you
> are aware of and are working on already, but, just in case 
> you are not,
> here they are.

Thanks.

-- Craig



From L.Wood at surrey.ac.uk  Tue Apr 21 10:53:40 2009
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Tue, 21 Apr 2009 18:53:40 +0100
Subject: [Ns-developers] First Stab at Validation and Verification
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr><49E84ED5.7010603@cttc.es><005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu><1240317342.317.345.camel@diese.inria.fr>
	<176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO>
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B0FE0@EVS-EC1-NODE4.surrey.ac.uk>

One terminology thing that's always bugged me is that, while ns has had
validation tests seemingly forever, talk of regression testing was never
around for ns2. And validating the models vs testing for regressions in
behaviour strike me as slightly different in aim.

validation - is this model behaviour useful and realistic?
regression - is this model behaviour consistently unchanged by code
changes not intended to change the model behaviour?

The scope of the tests for these seems different. But they've
both been lumped under 'validation' to date.

> One of the problems I've run into is that the terminology is confused.  I
> wanted to try and write down exactly what it was that I was trying to
> accomplish and define the terms I was using.  Unfortunately, for example,
> validation can mean different things to different people.  I had imagined
> that ambiguous terminology translated into French, German or Portuguese
> would be a disaster waiting to happen.  I've been known to be mistaken on
> this front, though.  Are there specifics that you found unnecessary or
> overly pedantic after your translation exercise?  I know there are terms
> there to help clarify what I'm *not* doing.

From mathieu.lacage at sophia.inria.fr  Tue Apr 21 11:48:13 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 21 Apr 2009 20:48:13 +0200
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr> <49E84ED5.7010603@cttc.es>
	<005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
	<1240317342.317.345.camel@diese.inria.fr>
	<176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO>
Message-ID: <1240339693.6120.24.camel@mathieu-laptop>

On Tue, 2009-04-21 at 10:38 -0700, craigdo at ee.washington.edu wrote:

> > 1) I am very worried about the content of:
> > http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting
> > 
> > As a non-native english speaker, I had to lookup many words in a
> > dictionary and, even when I found the french translation, I had to
> > lookup the meaning of the french words. I am worried that the above is
> > overly formal through abstract and generic considerations 
> > about abstract
> > modelization/verification/validation theory. 
> 
> One of the problems I've run into is that the terminology is confused.  I
> wanted to try and write down exactly what it was that I was trying to
> accomplish and define the terms I was using.  Unfortunately, for example,
> validation can mean different things to different people.  I had imagined
> that ambiguous terminology translated into French, German or Portuguese
> would be a disaster waiting to happen.  I've been known to be mistaken on
> this front, though.  Are there specifics that you found unnecessary or
> overly pedantic after your translation exercise?  I know there are terms
> there to help clarify what I'm *not* doing.

Sentences such as "Prescribed conditions for which the model has been
tested, compared against reality to the extent possible, and judged
suitable for use;" or "Substantiation that a model, within its domain of
applicability, possesses a satisfactory range of accuracy consistent
with the intended application of the model;" make my brain hurt in
french, and explode in english. I had to read/process them multiple
times.

[snip]

> > For example, looking at the code in verification/rng/*.cc, I see that
> > quite a bit of code is invested in generating the graphs, and enabling
> > them from the command-line. If we did not try to do this, we could
> > easily re-use the existing unit test framework to write these 
> > rng tests
> > in src/core/random-variable.cc, and, then, the question 
> > becomes: "which
> > framework should I use ?" which is a problem related to item 3) below.
> 
> The difference is related to the purpose of the exercise.  In the case of
> random number generators, the first goal is to do validation.  One result of
> the validation process should be the pretty web site that I showed.  If
> someone wonders about the  random number generators they can go to the web
> site and see that they have been validated.

I understand that what you are trying to do here is provide
documentation about regression tests to allow third parties to evaluate
the quality of these tests: the kind of website you showed is awesome in
that respect.

So, what I am really asking is whether it's a good idea to invest
resources in this rather than just write tests that you, as a test
writer, feel good about. i.e., I am worried that generating graphs
brings nothing to the writing of good tests which is what I feel really
concerned about.

Mathieu


From mathieu.lacage at sophia.inria.fr  Tue Apr 21 12:04:34 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 21 Apr 2009 21:04:34 +0200
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B0FE0@EVS-EC1-NODE4.surrey.ac.uk>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr><49E84ED5.7010603@cttc.es>
	<005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
	<1240317342.317.345.camel@diese.inria.fr>
	<176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO>
	<4835AFD53A246A40A3B8DA85D658C4BE7B0FE0@EVS-EC1-NODE4.surrey.ac.uk>
Message-ID: <1240340674.6120.40.camel@mathieu-laptop>

On Tue, 2009-04-21 at 18:53 +0100, L.Wood at surrey.ac.uk wrote:
> One terminology thing that's always bugged me is that, while ns has
> had
> validation tests seemingly forever, talk of regression testing was
> never
> around for ns2. And validating the models vs testing for regressions
> in
> behaviour strike me as slightly different in aim.
> 
> validation - is this model behaviour useful and realistic?
> regression - is this model behaviour consistently unchanged by code
> changes not intended to change the model behaviour?
> 
> The scope of the tests for these seems different. But they've
> both been lumped under 'validation' to date.

There are about 20 different adjectives you can use to qualify tests:
unit tests, system tests, integration tests, regression tests,
validation tests, whitebox tests, blackbox tests, etc. You could try to
tag all the blackbox tests and the regression tests with a special
directory, but, then, the problem is that you could also arbitrarily
decide to tag only the blackbox tests in a special directory, etc. My
point is that I don't see any useful obvious single-level classification
system to sort tests so, it seems to me that it's just simpler to dump
them all in the same location (say, randomly, 'tests' :) and, document
in each test what you are testing and how.

Mathieu


From mathieu.lacage at sophia.inria.fr  Tue Apr 21 12:06:54 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 21 Apr 2009 21:06:54 +0200
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <41833959137348D3AFBB1E94470AB836@CRAIGVAIO>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr> <49E84ED5.7010603@cttc.es>
	<005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
	<3CECB0E2-4206-4EC5-BCA6-444459D17F49@ece.gatech.edu>
	<41833959137348D3AFBB1E94470AB836@CRAIGVAIO>
Message-ID: <1240340814.6120.42.camel@mathieu-laptop>

On Tue, 2009-04-21 at 09:20 -0700, craigdo at ee.washington.edu wrote:

> Actually, TCP is in the document because it doesn't deal with randomness and
> illustrates a distinction I wanted to make.  Hopefully, the distinction I'm
> making between validation and verification, stochastic and deterministic
> processes becomes clear, even if it doesn't manifest in a directory
> structure in the final product.  Eventually a wifi test suite might include
> tests to validate physical processes that definitely will be based on random
> variables (validation of transmission range) and might also have spec-based
> tests (verification: if in state X and receive packet type Y then jump to
> state S).  We don't want to split up the wifi tests into two different
> suites I think.

I can't agree more.

Mathieu


From basimjaved at gmail.com  Tue Apr 21 12:24:53 2009
From: basimjaved at gmail.com (Basim Javed)
Date: Tue, 21 Apr 2009 21:24:53 +0200
Subject: [Ns-developers] About 802.11 management frame
In-Reply-To: <49EDEEDB.9010705@gmail.com>
References: <49EDD699.2080405@gmail.com>
	<adbe58370904210857r4b2d7d2id06ff83085ef0328@mail.gmail.com>
	<49EDEEDB.9010705@gmail.com>
Message-ID: <adbe58370904211224g672bc48dk9652a2937b103f26@mail.gmail.com>

hi
I guess by atomic you mean to say that the exchange of four frames is done
consecutively. Intuitively I would expect it to be atomic, but if you can
point out the values of IFS for this exchange, then we can more certainly
say about the situation.

regards
B

On Tue, Apr 21, 2009 at 6:05 PM, Mirko Banchi <mk.banchi at gmail.com> wrote:

> Basim Javed ha scritto:
> > hi
> >
> > If I correctly understand the situation, I may add:
> > The concept of TXOP is limited for a given STA which has already won
> > contention; so there is no chance that "The Ap should send an Association
> > Response frame. But should this happen in the same TxOp? ". The AP will
> have
> > its own TXOP, which may enable sending one response frame only.
> >
> > regards
> > B
>
> Yes, you are right. I use improperly the term TXOP to intend:
> the exchange of four frames:
>
> AssocReq
> Ack
> AssocResp
> Ack
>
> is "atomic"?
>
> However i'm persuasing that could be not atomic even if i don't
> understand what standards intends when speak about "its response" (see
> section 7.1.4 point a2)
>
> Thanks,
>
> Mirko
>
>
> --
> Mirko Banchi
>
> e-mail:    mk.banchi at gmail.com
> e-mail:    mk.banchi at virgilio.it
> id-jabber: mk.banchi at jabber.org
> id-msn:    mb11684 at hotmail.com
>
> PGP key fingerprint:
>
> 308F BFB1 4E67 2522 C88E
> DC69 7631 52ED 32A5 6456
>
>

From L.Wood at surrey.ac.uk  Tue Apr 21 12:23:02 2009
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Tue, 21 Apr 2009 20:23:02 +0100
Subject: [Ns-developers] First Stab at Validation and Verification
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr><49E84ED5.7010603@cttc.es><005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu><1240317342.317.345.camel@diese.inria.fr><176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO><4835AFD53A246A40A3B8DA85D658C4BE7B0FE0@EVS-EC1-NODE4.surrey.ac.uk>
	<1240340674.6120.40.camel@mathieu-laptop>
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B0FE1@EVS-EC1-NODE4.surrey.ac.uk>

My take is that, of all these test types, only the validation
tests are special/different, as they relate to model output more than
internal simulator mechanisms...

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>



-----Original Message-----
From: ns-developers-bounces at ISI.EDU on behalf of Mathieu Lacage
Sent: Tue 2009-04-21 20:04
To: ns-developers at ISI.EDU
Subject: Re: [Ns-developers] First Stab at Validation and Verification
 
On Tue, 2009-04-21 at 18:53 +0100, L.Wood at surrey.ac.uk wrote:
> One terminology thing that's always bugged me is that, while ns has
> had
> validation tests seemingly forever, talk of regression testing was
> never
> around for ns2. And validating the models vs testing for regressions
> in
> behaviour strike me as slightly different in aim.
> 
> validation - is this model behaviour useful and realistic?
> regression - is this model behaviour consistently unchanged by code
> changes not intended to change the model behaviour?
> 
> The scope of the tests for these seems different. But they've
> both been lumped under 'validation' to date.

There are about 20 different adjectives you can use to qualify tests:
unit tests, system tests, integration tests, regression tests,
validation tests, whitebox tests, blackbox tests, etc. You could try to
tag all the blackbox tests and the regression tests with a special
directory, but, then, the problem is that you could also arbitrarily
decide to tag only the blackbox tests in a special directory, etc. My
point is that I don't see any useful obvious single-level classification
system to sort tests so, it seems to me that it's just simpler to dump
them all in the same location (say, randomly, 'tests' :) and, document
in each test what you are testing and how.

Mathieu



From craigdo at ee.washington.edu  Tue Apr 21 12:40:34 2009
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Tue, 21 Apr 2009 12:40:34 -0700
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <1240340674.6120.40.camel@mathieu-laptop>
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr><49E84ED5.7010603@cttc.es><005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu><1240317342.317.345.camel@diese.inria.fr><176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO><4835AFD53A246A40A3B8DA85D658C4BE7B0FE0@EVS-EC1-NODE4.surrey.ac.uk>
	<1240340674.6120.40.camel@mathieu-laptop>
Message-ID: <77F3BC4EE3774776BC89EF06A311578E@CRAIGVAIO>

> > One terminology thing that's always bugged me is that, while ns has
> > had
> > validation tests seemingly forever, talk of regression testing was
> > never
> > around for ns2. And validating the models vs testing for regressions
> > in
> > behaviour strike me as slightly different in aim.
> > 
> > validation - is this model behaviour useful and realistic?
> > regression - is this model behaviour consistently unchanged by code
> > changes not intended to change the model behaviour?
> > 
> > The scope of the tests for these seems different. But they've
> > both been lumped under 'validation' to date.
> 
> There are about 20 different adjectives you can use to qualify tests:
> unit tests, system tests, integration tests, regression tests,
> validation tests, whitebox tests, blackbox tests, etc. You 
> could try to
> tag all the blackbox tests and the regression tests with a special
> directory, but, then, the problem is that you could also arbitrarily
> decide to tag only the blackbox tests in a special directory, etc. My
> point is that I don't see any useful obvious single-level 
> classification
> system to sort tests so, it seems to me that it's just simpler to dump
> them all in the same location (say, randomly, 'tests' :) and, document
> in each test what you are testing and how.

Or you could have 20 different directories representing a detailed taxonomic
decomposition agreed to by everyone ;-)  Seriously, though, I see in another
email that you found one of the places where I said that I don't want to
arrange it so there are multiple directories with tests for a given module
spread across them.

Right now there the statistical tests and the non-statistical tests are in
two different places since I don't have a handle on how similar the
environments will end up being -- I want to address one at a time for
simplicity.  I expect that it will all condense down into something like
"tests."



From mk.banchi at gmail.com  Tue Apr 21 12:52:17 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Tue, 21 Apr 2009 21:52:17 +0200
Subject: [Ns-developers] About 802.11 management frame
In-Reply-To: <adbe58370904211224g672bc48dk9652a2937b103f26@mail.gmail.com>
References: <49EDD699.2080405@gmail.com>	
	<adbe58370904210857r4b2d7d2id06ff83085ef0328@mail.gmail.com>	
	<49EDEEDB.9010705@gmail.com>
	<adbe58370904211224g672bc48dk9652a2937b103f26@mail.gmail.com>
Message-ID: <49EE23F1.5090300@gmail.com>

Basim Javed ha scritto:
> hi
> I guess by atomic you mean to say that the exchange of four frames is done
> consecutively. Intuitively I would expect it to be atomic, but if you can
> point out the values of IFS for this exchange, then we can more certainly
> say about the situation.
> 
> regards
> B
> 

By atomic i mean that between the exchange of first two frames

AssocReq + Ack

and second ones

AssocResp + Ack

other stations don't send other frames. But as i told, i think it isn't
so. Unfortunately exchange of management frames isn't atomic.
Sorry for improrper use of term "atomic" but by email it's difficult
explain all this :).

Thanks,

Mirko

-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090421/4bfa4608/smime.bin

From craigdo at ee.washington.edu  Tue Apr 21 14:42:43 2009
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Tue, 21 Apr 2009 14:42:43 -0700
Subject: [Ns-developers] First Stab at Validation and Verification
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr>
	<49E84ED5.7010603@cttc.es><005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu><1240317342.317.345.camel@diese.inria.fr><176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO>
	<1240339693.6120.24.camel@mathieu-laptop> 
Message-ID: <72967BDE5DBB4F8A87ED05CC7DBA9BD2@CRAIGVAIO>

[ ... ]

> Sentences such as "Prescribed conditions for which the model has been
> tested, compared against reality to the extent possible, and judged
> suitable for use;" or "Substantiation that a model, within 
> its domain of
> applicability, possesses a satisfactory range of accuracy consistent
> with the intended application of the model;" make my brain hurt in
> french, and explode in english. I had to read/process them multiple
> times.

Heh, heh.  It does sound like a lawyer got hold of it, doesn't it?
Unfortunately, these are pretty standard definitions that I've found across
the literature.  You may be surprised if you copy the string,

  prescribed conditions for which the model has been tested compared against
reality to the extent possible

into google and see what comes back -- 152,000 results :-)

It all probably traces back to one paper written in 1835.  I'll attempt to
translate that kind of stuff into something more easily parsed by
non-lawyers.

> I understand that what you are trying to do here is provide
> documentation about regression tests to allow third parties 
> to evaluate
> the quality of these tests: the kind of website you showed is 
> awesome in
> that respect.
> 
> So, what I am really asking is whether it's a good idea to invest
> resources in this rather than just write tests that you, as a test
> writer, feel good about. i.e., I am worried that generating graphs
> brings nothing to the writing of good tests which is what I 
> feel really
> concerned about.

Okay, you have a meta-issue.  Our Fearless Leader is very concerned about
how to present to the rest of the world that all of that work writing good
tests has been done.  He wants to see the graphs and web sites.






From tomh at tomh.org  Tue Apr 21 23:03:33 2009
From: tomh at tomh.org (Tom Henderson)
Date: Tue, 21 Apr 2009 23:03:33 -0700
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <72967BDE5DBB4F8A87ED05CC7DBA9BD2@CRAIGVAIO>
References: <49D4CA6C.5060405@tomh.org><1239715971.6390.176.camel@diese.inria.fr>	<49E84ED5.7010603@cttc.es><005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu><1240317342.317.345.camel@diese.inria.fr><176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO>	<1240339693.6120.24.camel@mathieu-laptop>
	<72967BDE5DBB4F8A87ED05CC7DBA9BD2@CRAIGVAIO>
Message-ID: <49EEB335.2050102@tomh.org>


>>
>> So, what I am really asking is whether it's a good idea to invest
>> resources in this rather than just write tests that you, as a test
>> writer, feel good about. i.e., I am worried that generating graphs
>> brings nothing to the writing of good tests which is what I 
>> feel really
>> concerned about.
> 
> Okay, you have a meta-issue.  Our Fearless Leader is very concerned about
> how to present to the rest of the world that all of that work writing good
> tests has been done.  He wants to see the graphs and web sites.
> 

Nice bullwinkle reference...  I don't think graphs or web sites are 
strictly necessary.  I agree that the focus should be on the tests 
themselves, but the fact that the tests have been done and are being 
maintained (if so) should be documented somehow for users.  That can be 
on the wiki, in the manual, in commented scripts or unit tests, in 
separate technical reports, etc.   Mainly, I'd like to see a few good 
examples of how this can be done, so that code contributors can follow 
the lead.

- Tom

From basimjaved at gmail.com  Wed Apr 22 00:39:19 2009
From: basimjaved at gmail.com (Basim Javed)
Date: Wed, 22 Apr 2009 09:39:19 +0200
Subject: [Ns-developers] About 802.11 management frame
In-Reply-To: <49EE23F1.5090300@gmail.com>
References: <49EDD699.2080405@gmail.com>
	<adbe58370904210857r4b2d7d2id06ff83085ef0328@mail.gmail.com>
	<49EDEEDB.9010705@gmail.com>
	<adbe58370904211224g672bc48dk9652a2937b103f26@mail.gmail.com>
	<49EE23F1.5090300@gmail.com>
Message-ID: <adbe58370904220039q2fea68d1sb124b1963b0a93bd@mail.gmail.com>

Sure.
Could you please point out the relevant section of the standard which says
about the IFS values used to send management frames?



On Tue, Apr 21, 2009 at 9:52 PM, Mirko Banchi <mk.banchi at gmail.com> wrote:

> Basim Javed ha scritto:
> > hi
> > I guess by atomic you mean to say that the exchange of four frames is
> done
> > consecutively. Intuitively I would expect it to be atomic, but if you can
> > point out the values of IFS for this exchange, then we can more certainly
> > say about the situation.
> >
> > regards
> > B
> >
>
> By atomic i mean that between the exchange of first two frames
>
> AssocReq + Ack
>
> and second ones
>
> AssocResp + Ack
>
> other stations don't send other frames. But as i told, i think it isn't
> so. Unfortunately exchange of management frames isn't atomic.
> Sorry for improrper use of term "atomic" but by email it's difficult
> explain all this :).
>
> Thanks,
>
> Mirko
>
> --
> Mirko Banchi
>
> e-mail:    mk.banchi at gmail.com
> e-mail:    mk.banchi at virgilio.it
> id-jabber: mk.banchi at jabber.org
> id-msn:    mb11684 at hotmail.com
>
> PGP key fingerprint:
>
> 308F BFB1 4E67 2522 C88E
> DC69 7631 52ED 32A5 6456
>
>

From mathieu.lacage at sophia.inria.fr  Wed Apr 22 02:06:45 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 22 Apr 2009 11:06:45 +0200
Subject: [Ns-developers] spectrum modeling [was: ns-3.5 planning]
In-Reply-To: <49E84ED5.7010603@cttc.es>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr> <49E84ED5.7010603@cttc.es>
Message-ID: <1240391205.32483.6.camel@diese.inria.fr>

Hi nicola,

I looked carefully at your code but, what is really missing is a picture
of how this would be used in real devices so, I can't really comment on
the overall direction.

On Fri, 2009-04-17 at 11:41 +0200, Nicola Baldo wrote:

> 1) a class (ValuesVsFreq) providing the representation of 
> frequency-dependent things (such as spectral power density, propagation 
> loss, tx/rx mask...);

a) If you intend to use code in src/devices/spectrum as shared, I think
you can move it to src/common instead. The initial idea beyond
src/devices was that each subdirectory would contain a single NetDevice
class. Maybe someone has a better idea.

b) Multiple inheritance !! What happened to you to become evil
overnight ? Instead, please, make std::vector<double> a member of
SetOfFreqs. Make it a public member if you must (or use a struct).

class SetOfFreqs : public RefCountBase, public std::vector<double>
{ 
};

c) It's really a bad idea to make arithmetic operators member methods
(they should be friend functions) because that makes them asymetric (A+B
becomes different from B+A): you should consider reading "more effective
c++", items 6, 7, 21, 22. Also:
http://www.parashift.com/c++-faq-lite/operator-overloading.html#faq-13.9

Now, given the complexity of getting this kind of C++ operator
overloading magic right, I would like to suggest that you don't do it at
all. Yes, I know that we do this in src/simulator/nstime.h but I think I
can comment about this code to say that doing it once taught me to not
do it ever again. I don't claim I never make any mistake but I can claim
that I _try_ to not do the same mistake more than once (ok, maybe,
sometimes, hubris makes me do the same mistake twice, or more).

Ok, what could you do to avoid this ? I have to confess that I don't
know: I am still missing the big picture of your code.

> 2) interfaces definitions for the spectrum-aware channel, phy and 
> propagation loss model (delay model is the same as wifi);

d) How do you envision that SpectrumPhy::StartRx would be used ?

> 3) a basic but usable implementation of the channel and the 
> spectrum-aware version of the Friis propagation model;
> 
> 4) two sample PHY layer implementations (WaveformGenerator and 
> SpectrumAnalyzer) and a couple of test scripts to test everything and 
> show how it works.
> 
> 
> What is still missing are PHY layers to be used within a NetDevice 
> context, and in particular something that can work with the current wifi 
> code -- either some code which can interact with the existing 
> YansWifiPhy, or a brand new WifiPhy implementation. I plan to be working 
> on this issue the near future.
> 
> You can find the code here:
> http://code.nsnam.org/nbaldo/ns-3-dev-spectrum/
> 
> Any feedback would be very much appreciated, as well as any intent to 
> cooperate in this development. I would be happy to have all this code 
> included in ns-3-dev at some point, but I am not sure of whether this 
> can happen for ns-3.5. The point in favor of this is that the new 
> features do not mess up with existing code, so including it does no 
> harm. The point against is that at the moment there is still nothing 
> which can be really useful for practical purposes; more modules need to 
> be developed for this.

I think that we need some real code using this before it can be
included.

Mathieu


From mathieu.lacage at sophia.inria.fr  Wed Apr 22 02:21:32 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 22 Apr 2009 11:21:32 +0200
Subject: [Ns-developers] First Stab at Validation and Verification
In-Reply-To: <49EEB335.2050102@tomh.org>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>	<49E84ED5.7010603@cttc.es>
	<005d01c9bfb1$b767a770$a3d75f80@ee.washington.edu>
	<1240317342.317.345.camel@diese.inria.fr>
	<176A9AF2B0CE421C86D2E70B3E570E83@CRAIGVAIO>
	<1240339693.6120.24.camel@mathieu-laptop>
	<72967BDE5DBB4F8A87ED05CC7DBA9BD2@CRAIGVAIO>
	<49EEB335.2050102@tomh.org>
Message-ID: <1240392092.6756.9.camel@diese.inria.fr>

On Tue, 2009-04-21 at 23:03 -0700, Tom Henderson wrote:
> >>
> >> So, what I am really asking is whether it's a good idea to invest
> >> resources in this rather than just write tests that you, as a test
> >> writer, feel good about. i.e., I am worried that generating graphs
> >> brings nothing to the writing of good tests which is what I 
> >> feel really
> >> concerned about.
> > 
> > Okay, you have a meta-issue.  Our Fearless Leader is very concerned about
> > how to present to the rest of the world that all of that work writing good
> > tests has been done.  He wants to see the graphs and web sites.
> > 
> 
> Nice bullwinkle reference...  I don't think graphs or web sites are 
> strictly necessary.  I agree that the focus should be on the tests 
> themselves, but the fact that the tests have been done and are being 
> maintained (if so) should be documented somehow for users.  That can be 
> on the wiki, in the manual, in commented scripts or unit tests, in 
> separate technical reports, etc.   Mainly, I'd like to see a few good 
> examples of how this can be done, so that code contributors can follow 
> the lead.

Ok, I agree that we need to have a nice reference/howto on the process
of writing good tests which make sense and, having a good complete
detailed step-by-step example is a good idea. 

I think that I also see how a lot of per-test graphs could be
automatically generated with the right framework in place, mainly for
stochastic tests. i.e., I see how I could write a wifi test which
verifies that the wifi MAC reaches the right theoretical upper bound on
the application-level throughput for each physical layer transmission
mode when there are no transmission errors or static packet error rates
and I see how the data generated by these tests could be fed into an
automatic graph generator.

To summarize, if we can move the graph generation code outside of the
testing code into the testing framework, and if the only thing tests
have to be concerned about is generating data and a way to verify that
the data is valid, then, it sounds like the best way to go forward.
i.e., more than that, it's _real_ cool (tm) :)

Mathieu



From f1mauchl at hsr.ch  Wed Apr 22 02:27:47 2009
From: f1mauchl at hsr.ch (Fabian Mauchle)
Date: Wed, 22 Apr 2009 11:27:47 +0200
Subject: [Ns-developers] creating MAC-level multicast addresses (was:
	ns-3.5 planning / mac multicast)
In-Reply-To: <1239882122.29455.28.camel@diese.inria.fr>
References: <49D4CA6C.5060405@tomh.org>	
	<1239715971.6390.176.camel@diese.inria.fr>	
	<001201c9bda0$b754e120$25fea360$@ch>
	<1239882122.29455.28.camel@diese.inria.fr>
Message-ID: <004d01c9c32c$99995530$cccbff90$@ch>

I will split this up to keep a separate focus on each of the topics

-----Urspr?ngliche Nachricht-----
Von: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr] 
Gesendet: Donnerstag, 16. April 2009 13:42
An: Mauchle Fabian (f1mauchl at hsr.ch)
Cc: ns-developers at ISI.EDU
Betreff: Re: [Ns-developers] ns-3.5 planning / mac multicast

On Wed, 2009-04-15 at 10:03 +0200, Fabian Mauchle wrote:

> I recently worked on multicasting in Wifi networks. The current
> implementation of MAC multicast in Wifi and Csma networks do basically
their
> thing, but they do not correctly represent reality.
> 
> 1. The NetDevice is currently responsible for creating the multicast MAC
> address [NetDevice::GetMulticast(Ipv4Address)]. I don't know of any real
API
> which would do this.

It is merely responsible for creating a MAC-level multicast address
which matches the higher-layer multicast address. The reason this is
done is to encapsulate the MAC address format from the higher layers. If
you don't do this, you will have to move knowledge of the MAC-level
address format to the ip layer. Linux does this, BSD too, but it's not
very pretty.
-----Urspr?ngliche Nachricht-----

Currently, some knowledge (mainly the IP address format) of the IP layer is
in the MAC-layer, which I think is neither very pretty. Basically, the
responsibility for mapping IP addresses to MAC addresses is implemented in
the ArpIpv4Interface class (except for multicast).

- A network stack is a layered architecture, therefore the layer n should
not need to know details about the n+1 layer (but the n+1 layer needs to
know about the API (including address format) of the layer n it uses).
- In the actual implementation, the L2 needs to know about the L3, in order
that the L3 is able to use the L2.
- All NetDevice implementations (except one) do exactly the same in the
GetMulticast(...) methods. (I don't like duplicate code)
- The GetMulticast(...) method is only called at one single place within
IPv4 (in ArpIpv4Interface).
- If I wanted (hypothetically) to create a new L3 protocol, I would have to
make changes to the NetDevice interface, and subsequently to all
implementations.

To summarize: I agree with you that knowledge of the MAC-level will not look
pretty in the IP-layer, but in my opinion, the current implementation
violates layer separation.

I don't have a real use-case for this, it's just for refactoring
consideration.

Fabian



From f1mauchl at hsr.ch  Wed Apr 22 02:28:01 2009
From: f1mauchl at hsr.ch (Fabian Mauchle)
Date: Wed, 22 Apr 2009 11:28:01 +0200
Subject: [Ns-developers] promiscuous mode (was: ns-3.5 planning / mac
	multicast)
Message-ID: <004f01c9c32c$a1d18510$e5748f30$@ch>

-----Urspr?ngliche Nachricht-----
Von: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr] 
Gesendet: Donnerstag, 16. April 2009 13:42
An: Mauchle Fabian (f1mauchl at hsr.ch)
Cc: ns-developers at ISI.EDU
Betreff: Re: [Ns-developers] ns-3.5 planning / mac multicast

> 3. The netdevice API in Linux also allows to enable or disable promiscuous
> mode. The NetDevice API in ns-3 only allows the registration of a
> promiscuous or non-promiscuous receive callback.

Yes: I already argued against the current ns-3 API and for the linux API
but I lost that argument a long time ago so, if you want to put this
back on the table, I would suggest you look in the mailing-list
archives.
-----Urspr?ngliche Nachricht-----

I read the mailing list and hopefully didn't miss something important.
Just to recap: we are NOT talking about tracing (this is mainly for watching
from the outside and should not affect the implemented network stack).

Further, I got the feeling that there are 2 things mixed up:
1. Receiving all frames to be able to implement a bridge
2. Receiving all frames for other processing on the host (like tracing)

The second point is known as promiscuous receive mode while I would not call
the first promiscuous (it is for bridging and I think real bridges/switches
implement different MAC functionality than hosts). However, since in ns-3
there are no bridges as such, they have to be built on top of hosts (turning
an normal computer into a switch). For this, we also need the promiscuous
mode.

The actual implementation is mainly designed for bridging. It makes a strong
difference between registered protocols (or the bridging functionality) that
want to receive all frames, and the ones that do not want this(eg. that the
IP protocol is not affected if the same node does some bridging). I think
this is NOT what would happen on real hosts.

If I want to make use of promiscuous mode for further processing on a node,
or more generally, test the behavior of a L3 protocol if the NetDevices are
promiscuous (eg. Simulating a tracing application running on a node to test
sniffer detection methods) I got 2 problems:
1. The Ipv4L3Protocol will register itself as a protocol (non promiscuous),
so I'm not able to activate promiscuous mode for IP.
2. The RegisterProtocolHandler(..., promiscuous = true) requires that a
NetDevice supports 'send from'. This ability orthogonal to promiscuous mode
receive (but both are required for bridges).

I would propose to:
- add a NetDevice::SetPromiscuous(bool) method.
- if promiscuous mode is enabled for a NetDevice, it should forward up all
correctly received packets
Optional:
- clean up the rest:
  - remove the Node::NonPromiscReceiveFromDevice and use only
Node::RedeiveFromDevice
  - either remove the PromiscuousReceiveCallback or rename it to something
like RawReceiveCallback
  - in Node::RegisterProtocolHandler() activate Promiscuous if requested
(but no deactivation)
  - bridges must check themselves if a particular NetDevice supports
SendFrom.

Fabian



From f1mauchl at hsr.ch  Wed Apr 22 02:27:54 2009
From: f1mauchl at hsr.ch (Fabian Mauchle)
Date: Wed, 22 Apr 2009 11:27:54 +0200
Subject: [Ns-developers] mac multicast filtering (was: ns-3.5 planning /
	mac multicast)
Message-ID: <004e01c9c32c$9d4cc040$d7e640c0$@ch>

-----Urspr?ngliche Nachricht-----
Von: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr] 
Gesendet: Donnerstag, 16. April 2009 13:42
An: Mauchle Fabian (f1mauchl at hsr.ch)
Cc: ns-developers at ISI.EDU
Betreff: Re: [Ns-developers] ns-3.5 planning / mac multicast

> 2. Most NetDevices accept all (or most) multicast frames without any
> selection or configuration. After I have seen some hints in several RFC's
> that a L3 protocol MUST register the multicast addresses (MAC) it wants to
> listen to, I searched for an API for this and found one in Linux [see
> manpage netdevice (7)]

Well, in the real world, there is device-level multicast frame filtering
to avoid transfering too many uneeded frames from the device to the
host. However, in every real device/driver I looked at, there is no
guarantee that this actually works (real device filters usually use a
small local hash cache with 16 entries to accept incoming packets which
means that incoming packets with a matching multicast address but which
are not listened to by the host will be forwarded to the host anyway. To
summarize, this kind of API is merely an optimization: it does not
change the logic which needs to be present in the ip stack to eliminate
multicast packets received which we are not listening to.
-----Urspr?ngliche Nachricht-----

I think I can follow you. So this rises one question: Should the NetDevice
API offer such optional functionality or not?

- If yes: There would be some methods AddMulticast() / RemoveMulticast().
NetDevice implementations are free if and how they make use of this. L3
protocols (like IP) would then be required to register their multicast
addresses regardless what the NetDevice will do with it.

- If not: All NetDevices that implement multicast capability MUST guarantee
that they forward up all incoming group frames (no multicast filtering at
all). This condition is currently not true for all NetDevices (at least
CsmaNetDevice and EmuNetDevice).

The second variant (not allowing multicast filtering) is much less difficult
to realize (just remove all multicast related filtering). To avoid further
confusion, the Mac48Address::IsMulticast() method should be removed (or
deprecated) since it's definition and it's actual behavior do not match (it
is only checking for IPv4 derived multicast addresses, but not for ones that
are derived from other L3 addresses like IPv6). 

I will have to make use of this in my current work on Mobile IPv6, where I
need to listen to some (more or less) random multicast addresses. I need
either a possibility to register these multicast addresses or I have to rely
on the fact that they are not filtered at all.

Fabian



From mathieu.lacage at sophia.inria.fr  Wed Apr 22 02:35:11 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 22 Apr 2009 11:35:11 +0200
Subject: [Ns-developers] creating MAC-level multicast addresses (was:
 ns-3.5 planning / mac multicast)
In-Reply-To: <004d01c9c32c$99995530$cccbff90$@ch>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>
	<001201c9bda0$b754e120$25fea360$@ch>
	<1239882122.29455.28.camel@diese.inria.fr>
	<004d01c9c32c$99995530$cccbff90$@ch>
Message-ID: <1240392911.6756.13.camel@diese.inria.fr>

On Wed, 2009-04-22 at 11:27 +0200, Fabian Mauchle wrote:

[snip]

> - If I wanted (hypothetically) to create a new L3 protocol, I would have to
> make changes to the NetDevice interface, and subsequently to all
> implementations.

The current API has been designed to make it easy to add new layer2/1
devices with weird addresses rather than make it easy to add a wholly
different layer 3. The current underwater models from leonard are a
great example of what we set out to encourage.

Mathieu


From mathieu.lacage at sophia.inria.fr  Wed Apr 22 02:37:42 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 22 Apr 2009 11:37:42 +0200
Subject: [Ns-developers] mac multicast filtering (was: ns-3.5 planning /
 mac multicast)
In-Reply-To: <004e01c9c32c$9d4cc040$d7e640c0$@ch>
References: <004e01c9c32c$9d4cc040$d7e640c0$@ch>
Message-ID: <1240393062.6756.16.camel@diese.inria.fr>

On Wed, 2009-04-22 at 11:27 +0200, Fabian Mauchle wrote:

[snip]

> I think I can follow you. So this rises one question: Should the NetDevice
> API offer such optional functionality or not?
> 
> - If yes: There would be some methods AddMulticast() / RemoveMulticast().
> NetDevice implementations are free if and how they make use of this. L3
> protocols (like IP) would then be required to register their multicast
> addresses regardless what the NetDevice will do with it.

yes.

> - If not: All NetDevices that implement multicast capability MUST guarantee
> that they forward up all incoming group frames (no multicast filtering at
> all). This condition is currently not true for all NetDevices (at least
> CsmaNetDevice and EmuNetDevice).

That sounds like a bug. Could you try to provide a patch for this ?

> The second variant (not allowing multicast filtering) is much less difficult
> to realize (just remove all multicast related filtering). To avoid further
> confusion, the Mac48Address::IsMulticast() method should be removed (or
> deprecated) since it's definition and it's actual behavior do not match (it
> is only checking for IPv4 derived multicast addresses, but not for ones that
> are derived from other L3 addresses like IPv6). 

This sounds like a good idea. 

> I will have to make use of this in my current work on Mobile IPv6, where I
> need to listen to some (more or less) random multicast addresses. I need
> either a possibility to register these multicast addresses or I have to rely
> on the fact that they are not filtered at all.

Sounds sensible.

Mathieu


From gjcarneiro at gmail.com  Wed Apr 22 03:09:57 2009
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Wed, 22 Apr 2009 11:09:57 +0100
Subject: [Ns-developers] promiscuous mode (was: ns-3.5 planning / mac
	multicast)
In-Reply-To: <004f01c9c32c$a1d18510$e5748f30$@ch>
References: <004f01c9c32c$a1d18510$e5748f30$@ch>
Message-ID: <a467ca4f0904220309y4877867ct12d38b9552c1d70@mail.gmail.com>

2009/4/22 Fabian Mauchle <f1mauchl at hsr.ch>

> -----Urspr?ngliche Nachricht-----
> Von: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
> Gesendet: Donnerstag, 16. April 2009 13:42
> An: Mauchle Fabian (f1mauchl at hsr.ch)
> Cc: ns-developers at ISI.EDU
> Betreff: Re: [Ns-developers] ns-3.5 planning / mac multicast
>
> > 3. The netdevice API in Linux also allows to enable or disable
> promiscuous
> > mode. The NetDevice API in ns-3 only allows the registration of a
> > promiscuous or non-promiscuous receive callback.
>
> Yes: I already argued against the current ns-3 API and for the linux API
> but I lost that argument a long time ago so, if you want to put this
> back on the table, I would suggest you look in the mailing-list
> archives.
> -----Urspr?ngliche Nachricht-----
>
> I read the mailing list and hopefully didn't miss something important.
> Just to recap: we are NOT talking about tracing (this is mainly for
> watching
> from the outside and should not affect the implemented network stack).
>
> Further, I got the feeling that there are 2 things mixed up:
> 1. Receiving all frames to be able to implement a bridge
> 2. Receiving all frames for other processing on the host (like tracing)
>
> The second point is known as promiscuous receive mode while I would not
> call
> the first promiscuous (it is for bridging and I think real bridges/switches
> implement different MAC functionality than hosts). However, since in ns-3
> there are no bridges as such, they have to be built on top of hosts
> (turning
> an normal computer into a switch). For this, we also need the promiscuous
> mode.
>
> The actual implementation is mainly designed for bridging. It makes a
> strong
> difference between registered protocols (or the bridging functionality)
> that
> want to receive all frames, and the ones that do not want this(eg. that the
> IP protocol is not affected if the same node does some bridging). I think
> this is NOT what would happen on real hosts.
>
> If I want to make use of promiscuous mode for further processing on a node,
> or more generally, test the behavior of a L3 protocol if the NetDevices are
> promiscuous (eg. Simulating a tracing application running on a node to test
> sniffer detection methods) I got 2 problems:
> 1. The Ipv4L3Protocol will register itself as a protocol (non promiscuous),
> so I'm not able to activate promiscuous mode for IP.


Your use case seems "strange".  Should we be designing a simulator around
non-realistic (or at least uncommon) use cases?  I think that "make common
things simple, uncommon things possible".  It should be possible to feed
into IPv4 promiscuous mode packets, and I believe it is possible.  At least
I have done in ns 3.2.1, and if I recall correctly I didn't even need to
modify Ipv4L3Protocol because it already has public Receive method.


>
> 2. The RegisterProtocolHandler(..., promiscuous = true) requires that a
> NetDevice supports 'send from'. This ability orthogonal to promiscuous mode
> receive (but both are required for bridges).
>
> I would propose to:
> - add a NetDevice::SetPromiscuous(bool) method.
> - if promiscuous mode is enabled for a NetDevice, it should forward up all
> correctly received packets
> Optional:
> - clean up the rest:
>  - remove the Node::NonPromiscReceiveFromDevice and use only
> Node::RedeiveFromDevice
>  - either remove the PromiscuousReceiveCallback or rename it to something
> like RawReceiveCallback
>  - in Node::RegisterProtocolHandler() activate Promiscuous if requested
> (but no deactivation)
>  - bridges must check themselves if a particular NetDevice supports
> SendFrom.


I still do not agree that one boolean setting that drastically changes the
behavior of NetDevice is a good idea.  The reason is that activating
promiscuous mode will take by surprise code that was not tested with
promiscuous mode enabled, and bugs will start appearing over time,
especially with 3rd party modules ("I have been using module XPTO, but it
starts breaking when I also use module FOO that enables promiscuous mode;
help me!").

However, the current solution is not exactly what I had first planned, it is
more of a compromise solution.  I would prefer to have two receive callbacks
in NetDevice, one "normal" and one "promiscuous".

Regarding SendFrom vs promiscuous mode, I agree they are orthogonal and one
should not imply the other.  This wasn't clear to me in the beginning, I
have to admit, but makes sense now.

That being said, I have no strong interest in the architecture of ns-3-dev
because I won't be able to use it for a long time yet (still stuck on ns-3.2
for my work).  So don't let my opinion block any refactoring you guys want
to do anyway.

Regards,
-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

From mk.banchi at gmail.com  Wed Apr 22 09:22:30 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Wed, 22 Apr 2009 18:22:30 +0200
Subject: [Ns-developers] Strange behaviour on generation of pcaps
Message-ID: <49EF4446.2040502@gmail.com>

Hi all,

i'm working with pcap tracing and i've a strange problem. I've created a
script to test my 802.11 block ack implementation. Output from terminal
says that all runs but when i open my pcap file with wireshark or read
it by tcpdump seems that last five packets are not captured. In
particular a block ack req, a block ack response and 3 beacon frame.
There is a visible difference between output of the script and pcap.
However i attach .pcap and terminal output.
Any idea?

Thank you all,

Mirko

-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output.txt
Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20090422/a841d37c/output-0001.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-blockack-0-0.pcap
Type: application/octet-stream
Size: 15506 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090422/a841d37c/test-blockack-0-0-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090422/a841d37c/smime-0001.bin

From craigdo at ee.washington.edu  Wed Apr 22 09:56:04 2009
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Wed, 22 Apr 2009 09:56:04 -0700
Subject: [Ns-developers] Strange behaviour on generation of pcaps
In-Reply-To: <49EF4446.2040502@gmail.com>
References: <49EF4446.2040502@gmail.com>
Message-ID: <F7A50CC77D2240CEB736F5492B2A3834@CRAIGVAIO>

This behavior is usually caused by a memory leak.

What happens is that pcap output is buffered to different degrees on
different systems.  The final flush is triggered when the pcap writer is
destroyed.  This happens when the node is destroyed.  If a memory leak
causes a reference to the node to be kept, the node is not deleted and
(eventually) the trace file is not flushed and you lose the last packets.

Run your script under valgrind and you'll most likely see the leak.

Regards,

-- Craig

> -----Original Message-----
> From: ns-developers-bounces at ISI.EDU 
> [mailto:ns-developers-bounces at ISI.EDU] On Behalf Of Mirko Banchi
> Sent: Wednesday, April 22, 2009 9:23 AM
> To: ns-developers mailing list
> Subject: [Ns-developers] Strange behaviour on generation of pcaps
> 
> Hi all,
> 
> i'm working with pcap tracing and i've a strange problem. 
> I've created a
> script to test my 802.11 block ack implementation. Output 
> from terminal
> says that all runs but when i open my pcap file with wireshark or read
> it by tcpdump seems that last five packets are not captured. In
> particular a block ack req, a block ack response and 3 beacon frame.
> There is a visible difference between output of the script and pcap.
> However i attach .pcap and terminal output.
> Any idea?
> 
> Thank you all,
> 
> Mirko
> 
> -- 
> Mirko Banchi
> 
> e-mail:    mk.banchi at gmail.com
> e-mail:    mk.banchi at virgilio.it
> id-jabber: mk.banchi at jabber.org
> id-msn:    mb11684 at hotmail.com
> 
> PGP key fingerprint:
> 
> 308F BFB1 4E67 2522 C88E
> DC69 7631 52ED 32A5 6456
> 
> 



From seongyee067 at yahoo.com  Wed Apr 22 03:36:36 2009
From: seongyee067 at yahoo.com (thejackal)
Date: Wed, 22 Apr 2009 03:36:36 -0700 (PDT)
Subject: [Ns-developers] New 802.11e/n review
Message-ID: <23134348.post@talk.nabble.com>


Hi Mirko,

It seems like the current branch for 802.11n concentrating on the MAC layer.
Is there any plan for 802.11n PHY layer?If only with the MAC layer
implementation, how about the PHY layer which provides high throughput for
802.11n? Or any model that we can utilize now to simulate the enhanced
throughput rates?Would appreciate your reply. Thanks a Million!

Best Regars,
Jackal




Mirko Banchi wrote:
> 
> Basim Javed ha scritto:
>> hello Mirko
>> 
>> Would you say a few words about which specific issues you
>> handled/corrected
>> for 802.11e? I would appreciate your reply.
>> 
>> Thanks in advance.
>> 
>> best
>> B
>> 
> 
> Hi Basim,
> 
> i've added objects in order to use 802.11e Qos facility. It's possible
> to define wifi Stas that use 4 queues to manage Qos traffic. If you want
> to work with a particular kind of traffic you have to mark every packet
> adding a QosTag to it. An application that marks traffic would be
> welcome:) For 802.11n support i've added frame aggregation to a MSDU
> level (A-MSDU), A-MPDU in the future. In a short time i should be able
> to publish code about block ack: Basic variant (802.11e) and Compressed
> variant (802.11n).
> 
> Regards,
> 
> Mirko
> 
> 
> -- 
> Mirko Banchi
> 
> e-mail:    mk.banchi at gmail.com
> e-mail:    mk.banchi at virgilio.it
> id-jabber: mk.banchi at jabber.org
> id-msn:    mb11684 at hotmail.com
> 
> PGP key fingerprint:
> 
> 308F BFB1 4E67 2522 C88E
> DC69 7631 52ED 32A5 6456
> 
> 
>  
> 

-- 
View this message in context: http://www.nabble.com/New-802.11e-n-review-tp23036334p23134348.html
Sent from the ns-developers mailing list archive at Nabble.com.


From tomh at tomh.org  Wed Apr 22 22:57:53 2009
From: tomh at tomh.org (Tom Henderson)
Date: Wed, 22 Apr 2009 22:57:53 -0700
Subject: [Ns-developers] GSOC students announced
Message-ID: <49F00361.5050501@tomh.org>

All,
I apologize for the delay in announcing this to the list, but I'd like 
to announce and welcome our 2009 Google Summer of Code students and 
mentors.  The 2009 selection process wrapped up on Monday; we ended up 
with three positions, and they are
- Qasim Javed (mentor Adrian Sai-wah Tam)
- Flavio Kubota (mentor Juliana Freitag Borin)
- Duy Nguyen (mentor Ruben Merz)

We could not make offers to everyone we would have liked; we ended up 
with more students and mentors than slots.  Our project had 27 
applications this year.

I appreciate all of the time that many people put into this process, 
including Joe's work as organizational admin, the many reviews conducted 
by our mentoring team (this also includes Marcello, Florian, and Nicola, 
who also volunteered to mentor and who helped during the review 
process), and of course, the student applications.

I expect that Joe can follow up with more specifics to the program 
participants about the next steps.  Sometime before the start of the 
program, it would be nice if each of our students could introduce 
themselves on the list and summarize what their summer goals are.

- Tom

From mathieu.lacage at sophia.inria.fr  Thu Apr 23 02:15:30 2009
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 23 Apr 2009 11:15:30 +0200
Subject: [Ns-developers] status update: ns-3.5 planning
In-Reply-To: <1239715971.6390.176.camel@diese.inria.fr>
References: <49D4CA6C.5060405@tomh.org>
	<1239715971.6390.176.camel@diese.inria.fr>
Message-ID: <1240478130.27316.13.camel@diese.inria.fr>

On Tue, 2009-04-14 at 15:32 +0200, Mathieu Lacage wrote:

> 1) ipv4 rework: tom and I agreed to try to split it, and specifically,
> try to split the API changes from the implementation changes. Right now,
> the proposal is to merge the following trees:
>   - mathieu/ns-3-olsr
>   - tomh/ns-3-ip-interfaces: my main comment for this tree is that I am
> still unsure I understand what the peer field is supposed to represent
> and how it is expected to be used.

Both of the above have been merged.

>   - tomh/ns-3-ip-routing: missing a README.api. Ipv4Route should derive
> from src/node/ref-count-based.h instead of implementing Ref+Unref.

Tom is working on the above

> Needed followup patches:
>   - new src/helper/ipv4-routing-helper.h 
>   - move src/internet-stack/static-routing-protocol.h to src/node,
> modify it to implement a linux-like routing table API

I have done both below at http://code.nsnam.org/mathieu/ns-3-ip-loopback
This patchset changes most regression tests because it introduces a new
'loopback' device which thus changes the index of all other devices, and
thus, changing the output of all traces and the names of all pcap files.
(note: I also did fix a couple of XXX from the multi-address merge)

>   - introduce a loopback device, remove Ipv4LoopbackInterface
>   - remove virtual methods from Ipv4Interface

I am going to work on these below next:

>   - add src/node/arp.h, implement it in ArpL3Protocol
>   - remove ::SetNode in src/internet-stack/*.h|cc: all these objects are
> aggregated to a node, so, they can call GetObject.
>   - remove src/internet-stack/internet-stack.cc:
>       a) make UdpL4Protocol aggregate UdpSocketFactory to self from
> constructor. Same for TcpL4Protocol/TcpSocketFactory.
>       b) add src/core/object.h: call NotifyNewAggregate from
> AggregateObject
>       c) Hook in NotifyNewAggregate from UdpL4Protocol, check for
> Ipv4L3Protocol, register new l4 protocol when Ipv4L3Protocol is
> aggregated or when they are created
> 
> If you are scared, you are right: it's a scary big work item.
> 
> 2) The 802.11n work is progressing nicely: I expect it can be merged in
> a couple of weeks after one or two more review iterations

Final review is underway for the above

> 
> 3) The 802.11s work has progressed too: I will do a review of the wifi
> part once the non-wifi part has been reviewed by others. I expect tom
> and gustavo to provide reviews on the non-wifi part because I can see
> some aspects of the non-wifi part being somewhat related to bridging.
> 
> 4) virtual devices was sent here for review a long time ago:
> http://code.nsnam.org/gjc/ns-3-virtual-netdevice/ I think that it could
> be useful to more users so, I would support merging it and would be
> happy to help gustavo port this to ns-3-dev.
> 
> 5) various wifi PHY patches are left in bugzilla. These need to be
> merged. 

The below is being aggressively pursued by craig.

> 6) validation improvements: the plan layed out in
> http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting#What_Does_it_Look_Like looks great. I am worried that this is new development and that it might be hard to make sure it matures sufficiently for this release cycle.
> 

Bugzilla is getting under control: a lot of small bugs are getting
fixed.

> 7) small patches: I expect faker to help me get a better grasp of what
> we can help merge soon, and what we should just drop.
> 
> 8) so far, ipv6 is blocked on item 1) and item 1. is far from being
> finished. If I put my realistic hat on, I predict that there is zero
> chance to complete 1) sufficiently early to allow ipv6 to go in this
> release cycle.
> 
> 9) An initial review: we need to see how long it will take to get all
> the already-identified items to get fixed before considering this
> feature for this release cycle
> 
> 10) This was posted a while ago: tom agreed on the basic idea with minor
> comments, and there were no other comments. I think that it could go in
> in a couple of days once we have fixed the identified issues.


The above did not make progress: ipv4 work is getting higher priority.

> pfew ! That was long, but it's quite likely that I forgot something so,
> if there is an item you are working on and you believe should be
> considered for this new release cycle which will end in mid-june with a
> new release, please, let me/us know _now_.

other items were raised:

1) multicast-related issues by Fabian Mauchle: some of these look like
bugs we can fix for this release. Others need API discussion on list.

2) multi-device radio interference modelization by Nicola Baldo: It is
not ready to be really reviewed yet and I doubt it will be ready for
this cycle. Hopefully, we can aim for the next cycle for this feature.

If you feel I forgot something, please, let me know.

regards,
Mathieu


From mk.banchi at gmail.com  Thu Apr 23 03:55:03 2009
From: mk.banchi at gmail.com (Mirko Banchi)
Date: Thu, 23 Apr 2009 12:55:03 +0200
Subject: [Ns-developers] New 802.11e/n review
In-Reply-To: <23134348.post@talk.nabble.com>
References: <23134348.post@talk.nabble.com>
Message-ID: <49F04907.5040104@gmail.com>

thejackal ha scritto:
> Hi Mirko,
> 
> It seems like the current branch for 802.11n concentrating on the MAC layer.
> Is there any plan for 802.11n PHY layer?If only with the MAC layer
> implementation, how about the PHY layer which provides high throughput for
> 802.11n? Or any model that we can utilize now to simulate the enhanced
> throughput rates?Would appreciate your reply. Thanks a Million!
> 
> Best Regars,
> Jackal

Hi Jackal,

for now our efforts are on 802.11n MAC layer. Our goal is
implementations of three features:

A-MSDU aggregation (under review)
A-MPDU
Block ack: basic and compressed variants.

About PHY layer, as you know 802.11n adopts a MIMO technology and its
implementation is very complex. Unfortunately for now the only rates
that you can use are 802.11a rates. However MIMO implementation is
scheduled for the future.

Regards,

Mirko


-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090423/cb45376b/smime.bin

From kirillano at yandex.ru  Thu Apr 23 09:04:34 2009
From: kirillano at yandex.ru (kirillano)
Date: Thu, 23 Apr 2009 20:04:34 +0400
Subject: [Ns-developers] Ack Timeout bug
Message-ID: <18961240502674@webmail129.yandex.ru>

Hi All,
I have tested multple queues (DcaTxops) in wifi and have faced with a bug:
  when MacLow sends a packet while ACK timeout has not expired (In 802.11 standard in chapter 9.2.8 was said, that we must wait ack timeout before next transmission).
I have added NS_ASSERT(false) after line, which cancels ACK timeout in CancelAllEvents () method in MacLow, which is called from StartTransmission () and my simulation has failed with tis assert.
When I have looked through output more detailed - I have seen that a packet from another queue (beacon queue) has accessed the medium before ACK timeout of data packet has expired after crash of ACK. I think, that the problem may be resolved by adding a moment of time when AckTimeout expires in DcfManager. Now DcfManager knows nothing about AckTimeout and can grant access before ACK timeout has expired.

This problem seems serious to me, because when AckTimeout is cancelled, the m_currentPacket in DcaTxop shall never be zero - so, the queue is blocked and no data packets can be sent.

Regards, Kirill Andreev
Wireless Software R&D Group,
IITP RAS

From flaviokubota at gmail.com  Thu Apr 23 19:38:45 2009
From: flaviokubota at gmail.com (Flavio Kubota)
Date: Thu, 23 Apr 2009 23:38:45 -0300
Subject: [Ns-developers] GSOC students announced
In-Reply-To: <49F00361.5050501@tomh.org>
References: <49F00361.5050501@tomh.org>
Message-ID: <ef7bdcb60904231938l3b7456b4x3b1b764eb6466cbe@mail.gmail.com>

Hi all,

I am Flavio, I am 22 year old and I live in Campinas - Brazil.
I am a MSc Computer Science Student at State University of
Campinas(UNICAMP). I am part of the group of Computer Networks Laboratory
(LRC) of Institute of Computing - UNICAMP.
My main research interest is wireless networks/WiMAX networks. I'm currently
working on ns-2.

This is my second Summer of Code. In 2008, I have worked with Joomla!. This
year, I will work on Uplink scheduler for WiMAX module for ns-3.

In the end of this summer, I want contribute to ns-3 community with a useful
code, get experience with mercurial and get experience working with a open
source organization, and incentive people migrate to ns-3.

--
Flavio Kubota
MSc Computer Science Student
LRC / IC / UNICAMP


On Thu, Apr 23, 2009 at 2:57 AM, Tom Henderson <tomh at tomh.org> wrote:

> All,
> I apologize for the delay in announcing this to the list, but I'd like to
> announce and welcome our 2009 Google Summer of Code students and mentors.
>  The 2009 selection process wrapped up on Monday; we ended up with three
> positions, and they are
> - Qasim Javed (mentor Adrian Sai-wah Tam)
> - Flavio Kubota (mentor Juliana Freitag Borin)
> - Duy Nguyen (mentor Ruben Merz)
>
> We could not make offers to everyone we would have liked; we ended up with
> more students and mentors than slots.  Our project had 27 applications this
> year.
>
> I appreciate all of the time that many people put into this process,
> including Joe's work as organizational admin, the many reviews conducted by
> our mentoring team (this also includes Marcello, Florian, and Nicola, who
> also volunteered to mentor and who helped during the review process), and of
> course, the student applications.
>
> I expect that Joe can follow up with more specifics to the program
> participants about the next steps.  Sometime before the start of the
> program, it would be nice if each of our students could introduce themselves
> on the list and summarize what their summer goals are.
>
> - Tom
>

From dnlove at gmail.com  Thu Apr 23 20:29:47 2009
From: dnlove at gmail.com (Duy Nguyen)
Date: Thu, 23 Apr 2009 20:29:47 -0700
Subject: [Ns-developers] GSOC students announced
In-Reply-To: <49F00361.5050501@tomh.org>
References: <49F00361.5050501@tomh.org>
Message-ID: <70f6a1ed0904232029o7eb3c235t8fb85159d5a6e7bb@mail.gmail.com>

Hi everyone,

My name is Duy, I am a third year graduate student,  I am part of the
Computer Communication Research Group(CCRG) at University of
California in Santa Cruz.  My current research is on multichannel MAC
and multi-rate control algorithms.  I've been using ns-2 for the last
two years, I am really excited to embark on a new journey of exploring
and learning ns-3 for my research.  I am going to be working on a
minstrel port