Nabble - ns-developers

OLSR/AODV routing fails with mobility induced path changes

2009-12-16T13:10:43Z

Hi all,

I posted the following message to ns-3 users list, but realized that it is
perhaps better suited to the developers list.

We have been running mobile adhoc simulations with ns3 in order to document
baseline performance in certain mobility scenarios. Unfortunately, we are
seeing very low performance (in terms of packet delivery ratios) in cases
where the mobility results in one or more path changes. We ruled out (or so
we think) the usual suspects by considering factors such as constant rate
controller, 1Mbps mode for 802.11b, unicast/non-unicast modes, RTS/CTS,
analytically calculated and experimentally verified transmission ranges. The
short description of the issue that we observed is that both OLSR and AODV
(using the latest ns-3-dev version) have very high route reconvergence times
(45 - 90 seconds) and in many cases don't converge at all. Furthermore, the
convergence seems flaky at best - meaning that in some cases routes are
discovered as intended, in some cases there is a really long delay and in
some case, no routes are found.

In a simulation scenario where paths between nodes change every so often
(a.k.a MANETs), this reduces the throughput/PDR to almost zero. We were
wondering if any of the users or developers have tested a full fledged
mobile adhoc scenario with success. By full fledged, we mean in terms of
mobility - with more than a few mobile nodes such that routes change over
the duration of the simulation.

Thats the short story. Now for the long one, here is an example that
demonstrates this problem and the simulation script we are using.

We place 3 nodes in a linear fashion.

1 ----------------- 2 ----------------- 3
(0,0) (250,0) (500,0)
d=250 m d=250m

After an initial settling time of 50 seconds (just to be safe), we start
both the traffic and mobility (constant velocity mobility model via
SetVelocity method).

The transmission range is set to 300-350 meters and we send traffic from
every node to every other node (staggered in time, of course) at a rate of 1
pkt/sec. With a pkt size of 500 B, this results in an aggregate traffic rate
of 24Kbps , which is far less than (approx.) 0.5 Mbps expected throughput
from a 1 Mbps 802.11b network.

We then move nodes 2 and 3 such that they end up interchanging their
positions...

First we bring node 3 very close to node 2. In fact, we bring 2 to the same
node coordinates as 3.

1 ----------------- 2 -3

And then move the node 2 away until it reaches the original position of node
3.

1 ----------------- 3 ----------------- 2
(0,0) (250,0) (500,0)

At this point, we set the velocity of all the nodes to zero, till the end of
the simulation. We let the simulation run for couple hundred seconds after
this point. And OLSR still doesn't converge on the routes! Note that
throughout the simulation, there are no network partitions. There is always
a path between every node pair.

We expected to see 100% packet delivery ratio in this case. However, what we
see is much less. We used both flow monitor as well as our own scripts to
process the ascii trace files to calculate PDRs. The exact number depends on
the specific scenario. During the mobility part of the simulation, the PDR
is as low as 0.5. AODV ultimately reconverges after 70 seconds and OLSR
never reconverges and PDR remains 0.666 throughout the simulation. Again,
this behaviour is flaky.

I am assuming that we are making some fundamental mistake in the simulation.
Could anyone please point us to what we are doing wrong? Any help is highly
appreciated. Below is our simulation script:

Thanks,
Abdul.

======================

/*This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation;
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Texport
'NS_LOG=*=level_function|prefix_func|prefix_time'emple Place, Suite
330,
Boston, MA 02111-1307 USA
*
*/

#include <fstream>
#include <iostream>
#include "ns3/core-module.h"
#include "ns3/common-module.h"
#include "ns3/node-module.h"
#include "ns3/helper-module.h"
#include "ns3/mobility-module.h"
#include "ns3/contrib-module.h"
#include "ns3/wifi-module.h"
#include "ns3/global-route-manager.h"

using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("adhoc_simple_test");

static void
SetVelocity (Ptr<Node> node, Vector vel)
{
Ptr<ConstantVelocityMobilityModel> mobility =
node->GetObject<ConstantVelocityMobilityModel> ();
mobility->SetVelocity (vel);
}

int main (int argc, char *argv[])
{

//srand(time(NULL));
SeedManager::SetSeed(time(NULL));

int nWifis = 3;
double SimTime = 200.0;
std::string phyMode ("wifib-1mbs");

//sending one packets per sec

Config::SetDefault ("ns3::OnOffApplication::PacketSize",StringValue
("500"));
Config::SetDefault ("ns3::OnOffApplication::DataRate", StringValue
("4kb/s"));

// Fix non-unicast data rate to be the same as that of unicast
Config::SetDefault ("ns3::WifiRemoteStationManager::RtsCtsThreshold",
StringValue ("400"));

//Set Non-unicastMode rate to unicast mode
//Config::SetDefault
("ns3::WifiRemoteStationManager::NonUnicastMode",StringValue (phyMode));

NS_LOG_INFO ("creating nodes");
CommandLine cmd;
cmd.AddValue ("nWifis", "Number of wifi networks", nWifis);
cmd.AddValue ("SimTime", "Total Simulation time", SimTime);
cmd.Parse (argc, argv);

NodeContainer adhocNodes;
adhocNodes.Create (nWifis);

NS_LOG_INFO ("setting the default phy and channel parameters ");
WifiHelper wifi;
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel ;
wifiChannel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel");
wifiChannel.AddPropagationLoss ("ns3::FriisPropagationLossModel");
wifiPhy.SetChannel (wifiChannel.Create ());

// Add a non-QoS upper mac, and disable rate control
NqosWifiMacHelper wifiMac = NqosWifiMacHelper::Default ();
wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",
"DataMode",StringValue(phyMode),
"ControlMode",StringValue(phyMode));

//set the tx range to 300
wifiPhy.Set ("TxPowerStart",DoubleValue (-0.1615));
wifiPhy.Set ("TxPowerEnd", DoubleValue (-0.1615));

// Set it to adhoc mode
wifiMac.SetType ("ns3::AdhocWifiMac");
NetDeviceContainer adhocDevices = wifi.Install (wifiPhy, wifiMac,
adhocNodes);

AodvHelper aodv;
OlsrHelper olsr;
Ipv4StaticRoutingHelper staticRouting;

Ipv4ListRoutingHelper list;
list.Add (staticRouting, 0);
list.Add (olsr, 10);
//list.Add (aodv,10);

InternetStackHelper internet;
internet.SetRoutingHelper (list);
internet.Install (adhocNodes);

NS_LOG_INFO ("setting the address");
Ipv4AddressHelper addressAdhoc;
addressAdhoc.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer adhocInterfaces;
adhocInterfaces = addressAdhoc.Assign (adhocDevices);

MobilityHelper mobilityAdhoc;
NS_LOG_INFO ("Installing the mobility model");

Ptr<ListPositionAllocator> positionAlloc_Adhoc =
CreateObject<ListPositionAllocator>();
double distance = 0.0;
for (uint32_t i = 0;i <= adhocNodes.GetN();i++){
positionAlloc_Adhoc->Add(Vector(distance,0.0,0.0));
distance += 250.0;
}

mobilityAdhoc.SetMobilityModel ("ns3::ConstantVelocityMobilityModel");
mobilityAdhoc.SetPositionAllocator(positionAlloc_Adhoc);
mobilityAdhoc.Install (adhocNodes);

//At 50 sec node 3 moves towards node 2
Simulator::Schedule (Seconds (50.0), &SetVelocity, adhocNodes.Get(2)
,Vector(-5.0,0.0,0.0));

//AT 100 sec set node 3 with zero velocity
Simulator::Schedule (Seconds (100.0), &SetVelocity, adhocNodes.Get(2)
,Vector(0.0,0.0,0.0));

//Move node2 away from node 3
Simulator::Schedule (Seconds (100.0), &SetVelocity, adhocNodes.Get(1)
,Vector(5.0,0.0,0.0));

//AT 150 sec set node 2 with zero velocity
Simulator::Schedule (Seconds (150.0), &SetVelocity, adhocNodes.Get(1) ,
Vector(0.0,0.0,0.0));

//Configure the application on each node

uint16_t port = 9;

for(int i =0; i< nWifis-1; i++)
{
PacketSinkHelper sink ("ns3::UdpSocketFactory",
InetSocketAddress(Ipv4Address::GetAny (), port));
ApplicationContainer apps_sink = sink.Install (adhocNodes.Get (i));
apps_sink.Start (Seconds (0.0));
apps_sink.Stop (Seconds (SimTime));
}

for(int clientNode=0; clientNode <= nWifis-1;clientNode++)
{
for (int j=0;j<=nWifis-1;j++)
{
std::cout << "J::" << j << std::endl;
OnOffHelper onoff1 ("ns3::UdpSocketFactory",Address (InetSocketAddress
(adhocInterfaces.GetAddress (j), port)));
onoff1.SetAttribute ("OnTime", RandomVariableValue (ConstantVariable
(1)));
onoff1.SetAttribute ("OffTime", RandomVariableValue (ConstantVariable
(0)));

if (j!= clientNode)
{
std::cout << "cleint node:" << clientNode << std::endl;
ApplicationContainer apps1 = onoff1.Install (adhocNodes.Get
(clientNode));
//apps1.Start (Seconds (90.0));
UniformVariable var;
//std::cout <<"random :" << var.GetValue(50.0,51.0) <<std::endl;
apps1.Start (Seconds (var.GetValue(50.0,51.0)));
apps1.Stop (Seconds (SimTime));
}
}
}

//configure flowmonitor

Ptr<FlowMonitor> flowmon;
FlowMonitorHelper flowmonHelper;
flowmon = flowmonHelper.InstallAll ();

NS_LOG_INFO ("Configure Tracing.");
std::ofstream ascii;
ascii.open ("adhoc_olsr_mob_test.tr");
YansWifiPhyHelper::EnableAsciiAll (ascii);
MobilityHelper::EnableAsciiAll (ascii);
//YansWifiPhyHelper::EnablePcapAll ("adhoc_test_case1_200");

NS_LOG_INFO ("Run Simulation.");
Simulator::Stop (Seconds (SimTime));
Simulator::Run ();
flowmon->SerializeToXmlFile ("mobtest_aovd-flowmon.xml", true, true);
Simulator::Destroy ();
}
=========================================

VANET Mobility and Wifi Communications in Highways [A complex example for ns-3]

2009-12-15T15:02:39Z

Please,
See http://codereview.appspot.com/179068

The patch is also attached.
In addtion, I have attached a html document regarding the code which
describes this design and corresponding classes.
There are changes done related to the code style in comparison to the
previous version which matches ns-3 format now.

Thank you,
Hadi

vanet-highway.patch (231K) Download Attachment

Re: pcap trace refalgamization

2009-12-14T06:13:06Z

On Mon, 2009-12-14 at 06:09 -0800, Tom Henderson wrote:

> > when you add the header for pcap output because the byte buffer
> > is shared with other packet instances and you can't avoid this. You
> > really can't.
> or whether it can be reworked a bit by trying to preserve the current
> write behavior.

I think that it would be less work to prove that craig's proposed change
is neutral from the point of view of performance. I really like the idea
of getting rid of this non-header stuff.

Mathieu

Re: pcap trace refalgamization

2009-12-14T06:09:36Z

Mathieu Lacage wrote:

> On Mon, 2009-12-14 at 10:06 +0100, Nicola Baldo wrote:
>
>> I think Mathieu refers to the fact that both the radiotap and prism
>> headers add some receiver-specific information, such as RSSI and noise
>> measurements. If radiotap/prism are implemented with a ns3::Header, then
>> adding this receiver-specific information implies that a full packet
>> copy will be triggered at every receiver. This was the way I initially
>
> Yes, when you call Packet::AddHeader (radiotapHeader), this triggers a
> full copy of the byte buffer of the packet.

Yes, I see that but I guess I was wondering whether this could be
avoided by avoiding the AddHeader() call even at the mid-layer helper,
and whether we can preserve existing operations sufficiently. That is,
if the (optional) header could be provided such as
+bool PcapFileObject::WriteWithHeader (Time t, Ptr<const Packet> p,
const Header &header)

I guess that I am wondering whether this is truly a restriction on this
approach in general:
> when you add the header for pcap output because the byte buffer
> is shared with other packet instances and you can't avoid this. You
> really can't.
or whether it can be reworked a bit by trying to preserve the current
write behavior.

Tom

Re: pcap trace refalgamization

2009-12-14T05:48:31Z

On Sun, 2009-12-13 at 22:34 -0800, Tom Henderson wrote:

> Regarding some of the other points of the proposed rework, they seem
> useful to me, especially concerning the proposed PcapHelper. In
> general, it would be nice to add some generic helper classes for
> managing filestreams of various sorts. For instance, to avoid having to
> try (and fail) to pass references to filestreams as arguments to bound
> callbacks or Schedule() calls.

I agree.

Mathieu

Re: pcap trace refalgamization

2009-12-14T05:48:02Z

On Mon, 2009-12-14 at 10:06 +0100, Nicola Baldo wrote:

> I think Mathieu refers to the fact that both the radiotap and prism
> headers add some receiver-specific information, such as RSSI and noise
> measurements. If radiotap/prism are implemented with a ns3::Header, then
> adding this receiver-specific information implies that a full packet
> copy will be triggered at every receiver. This was the way I initially

Yes, when you call Packet::AddHeader (radiotapHeader), this triggers a
full copy of the byte buffer of the packet.

> implemented radiotap/prism support, though I have to confess that I
> didn't bother measuring the difference in performance with the current
> implementation.

I did not either.

Mathieu

Status of block ack review

2009-12-14T03:59:15Z

Hi Mathieu and all,

I'd like to know about the status of block ack review. Currently i'm
planning support for basic block ack variant even if it seems to be
very complex. Maybe we could start to incrementally merge support for
compressed block ack.

Thank you all,

Mirko

--
Mirko Banchi

e-mail: mk.banchi@...
id-jabber: mk.banchi@...

PGP key fingerprint:

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

smime.p7s (3K) Download Attachment

Re: pcap trace refalgamization

2009-12-14T01:06:05Z

Hi all,

>> As I explained when I nacked the orginal patch, the issue is not calling
>> Packet::Copy (which you _must_ do because a trace sink must _not_ modify
>> the content of a packet from the callee perspective) because this does
>> not trigger a full copy. The issue is triggering a deep copy of the byte
>> buffer when you add the header for pcap output because the byte buffer
>> is shared with other packet instances and you can't avoid this. You
>> really can't. So, you have to take this performance hit. Maybe it's not
>> relevant in practice: we just need to measure it. If so, all my concerns
>> are moot and I will support your proposal about the PcapWriter class.
>>
>
> If I understand correctly, it basically boils down to that you are
> concerned about the copy into the intermediate buffer below before that
> buffer is written to the ofstream in file.Write() ? Because in the
> current code, the CopyData writes directly into the ofstream?
>

I think Mathieu refers to the fact that both the radiotap and prism
headers add some receiver-specific information, such as RSSI and noise
measurements. If radiotap/prism are implemented with a ns3::Header, then
adding this receiver-specific information implies that a full packet
copy will be triggered at every receiver. This was the way I initially
implemented radiotap/prism support, though I have to confess that I
didn't bother measuring the difference in performance with the current
implementation.

Nicola

Re: pcap trace refalgamization

2009-12-13T22:34:33Z

Mathieu Lacage wrote:

> On Fri, 2009-12-11 at 13:01 -0800, craigdo@... wrote:
>
>> As a reviewer, this is exactly what I would have liked to see.
>
> My comment was a generic comment about the need to mimize the cost/pain
> of a reviewer to maximize the probability of him looking at it. In this
> context, it is helpful to not put more than what is needed in the
> patchset. i.e., python rescans are just noise.
>
>> The pcap format is actually a nice generic format for storing timestamped
>> BLOBs. It has already been used that way in the test framework and it seems
>> to be potentially quite useful for storing and retrieving data. It would
>> not be nearly as useful if a user had to change the simulation core to use
>> this facility.
>
> I do understand this concern and, as I said above, I share it. I just
> don't see this as a practical problem _today_. I thus don't feel that it
> needs solving now. Do you have practical use-cases which hit this issue
> today ?
>
>
>> I'll implement the header version and take some numbers. I'm not very
>> worried about a header serialization -- are you concerned about a possible
>> packet copy? I was planning on avoiding this.
>
> As I explained when I nacked the orginal patch, the issue is not calling
> Packet::Copy (which you _must_ do because a trace sink must _not_ modify
> the content of a packet from the callee perspective) because this does
> not trigger a full copy. The issue is triggering a deep copy of the byte
> buffer when you add the header for pcap output because the byte buffer
> is shared with other packet instances and you can't avoid this. You
> really can't. So, you have to take this performance hit. Maybe it's not
> relevant in practice: we just need to measure it. If so, all my concerns
> are moot and I will support your proposal about the PcapWriter class.
>

If I understand correctly, it basically boils down to that you are
concerned about the copy into the intermediate buffer below before that
buffer is written to the ofstream in file.Write() ? Because in the
current code, the CopyData writes directly into the ofstream?

+bool
+PcapFileObject::Write (Time t, Ptr<const Packet> p)
+{
+ uint64_t current = t.GetMicroSeconds ();
+ uint64_t s = current / 1000000;
+ uint64_t us = current % 1000000;
+
+ uint32_t bufferSize = p->GetSize ();
+ uint8_t *buffer = new uint8_t[bufferSize];
+ p->CopyData (buffer, bufferSize);
+ bool rc = file.Write (s, us, buffer, bufferSize);
+ delete [] buffer;
+ return rc;
+}
+

Regarding some of the other points of the proposed rework, they seem
useful to me, especially concerning the proposed PcapHelper. In
general, it would be nice to add some generic helper classes for
managing filestreams of various sorts. For instance, to avoid having to
try (and fail) to pass references to filestreams as arguments to bound
callbacks or Schedule() calls.

Tom

vanet-highway patch

2009-12-12T11:47:02Z

I have attched the vanet-highway.patch in addition to the recently submitted
code for reveiw (http://codereview.appspot.com/176060/show)

Hadi

vanet-highway.patch (219K) Download Attachment

added vanet-highway; an ability to simulate vehicular ad-hoc networks in highways (mobility and communication) with ns-3

2009-12-12T11:28:58Z

(newer)
See: http://codereview.appspot.com/176060/show

I have add a directory "vanet-highway" which contains:
Vehicle Obstacle, IDM/MOBIL Model and LaneChange, Highway (.cc/.h) which are
main components of the design
vanet-highway-test and Controller are sample codes showing how to create
VANET scenarios in highways and run the vechicular networks.

Hadi

Re: pcap trace refalgamization

2009-12-12T05:54:29Z

On Fri, 2009-12-11 at 13:01 -0800, craigdo@... wrote:

> As a reviewer, this is exactly what I would have liked to see.

My comment was a generic comment about the need to mimize the cost/pain
of a reviewer to maximize the probability of him looking at it. In this
context, it is helpful to not put more than what is needed in the
patchset. i.e., python rescans are just noise.

> The pcap format is actually a nice generic format for storing timestamped
> BLOBs. It has already been used that way in the test framework and it seems
> to be potentially quite useful for storing and retrieving data. It would
> not be nearly as useful if a user had to change the simulation core to use
> this facility.

I do understand this concern and, as I said above, I share it. I just
don't see this as a practical problem _today_. I thus don't feel that it
needs solving now. Do you have practical use-cases which hit this issue
today ?

> I'll implement the header version and take some numbers. I'm not very
> worried about a header serialization -- are you concerned about a possible
> packet copy? I was planning on avoiding this.

As I explained when I nacked the orginal patch, the issue is not calling
Packet::Copy (which you _must_ do because a trace sink must _not_ modify
the content of a packet from the callee perspective) because this does
not trigger a full copy. The issue is triggering a deep copy of the byte
buffer when you add the header for pcap output because the byte buffer
is shared with other packet instances and you can't avoid this. You
really can't. So, you have to take this performance hit. Maybe it's not
relevant in practice: we just need to measure it. If so, all my concerns
are moot and I will support your proposal about the PcapWriter class.

Mathieu

Re: pcap trace refalgamization

2009-12-11T13:01:38Z

> > I created an issue at http://codereview.appspot.com/171049 to solicit
> > comments on the approach so far. There are lots of changed files,
> most of
> > which can just be ignored.
>
> If you really care about getting timely reviews, adding a new minimal
> version of the patch to this "review issue" will help. I will try to
> look at it asap anyway.

I wasn't really asking for a review, I was asking for preliminary comments
before I continue the process and package this and ascii trace changes up
for a review. What I really wanted to do was to avoid a situation where I
have this all completed, packaged up with the bow tied and someone tells me
I'm on crack :-)

I added all the files because I thought the information provided was
important. I thought it was important to show that I was dealing with
bindings (which many people forget), a lot of files were going to be
touched, but in an extraordinarily trivial way; and that I had thought about
it the required changes and actually addressed them instead of hand-waving
about it. I included all the files and mentioned that it passes test.py and
regression to show that I'm not hand-waving about how much is hidden or
breaking something. Since the scope was large, I included a narrative in my
posting explaining what I thought were the important files to look at, which
were only a very few.

As a reviewer, this is exactly what I would have liked to see.

> > I propose resurrecting the radiotap / prism headers and using them
> for pcap
> > tracing.
>
> Overall, I doubt very much that we will need that many different kinds
> of pcap-level encapsulations so, I am perfectly happy with the current
> situation which, as you point out, requires some kind of editing to a
> common file when new pcap encapsulation formats need to be supported. I
> feel that we are still in control of this potential explosion but you
> are obviously right that from a modularity perspective, it would be
> better to do otherwise.

The pcap format is actually a nice generic format for storing timestamped
BLOBs. It has already been used that way in the test framework and it seems
to be potentially quite useful for storing and retrieving data. It would
not be nearly as useful if a user had to change the simulation core to use
this facility.

> Now, if you could show that there is really no performance impact or,
> at
> least, evaluate and quantify that impact on our examples, that would
> allow us to make a clear and conscious decision about this issue.
>
> My current position on this kind of performance issue is the following:
> I am worried about more than 5 to 10% runtime overhead. Less than 5% is
> acceptable. From 5 to 10 would need careful thinking. More than 10
> would
> not be ok.

I'll implement the header version and take some numbers. I'm not very
worried about a header serialization -- are you concerned about a possible
packet copy? I was planning on avoiding this.

-- C

Re: AODV test failing under Cygwin

2009-12-11T07:34:19Z

Hi, Faker,

On Friday 11 December 2009 06:10:28 pm you wrote:
> Actually there is only a hex trace (down) and while debugging with
> Cygwin, that's the only readable trace that I got (take a look at the
> picture attached). It looks like there is some problems with Cygwin
> itself, what do you think?

I have no ideas. Is it stable? Can you try to find what commit has introduced
it (m.b. aa227ef4f60f)?

Pavel

Re: AODV test failing under Cygwin

2009-12-11T07:10:28Z

Pavel Boyko wrote:
> Hi, Faker,
>
> SIGABRT (recognized by waf as "returncode = -6") should produce a coredump
> -- can I see backtrace from it? Unfortunately I have no access to cygwin
> platform to reproduce this bug.
>
> Pavel
>
>
Hi Pavel,
Actually there is only a hex trace (down) and while debugging with
Cygwin, that's the only readable trace that I got (take a look at the
picture attached). It looks like there is some problems with Cygwin
itself, what do you think?
Thanks
Faker Moatamri

Here is the aodv.exe.stackdump stacktrace, I'm not sure that it is
decodable for a normal human being:
Stack trace:

Frame Function Args
0027C518 610979E2 (00000000, 768212A0, 77A804A2, 000000A4)
0027C608 61095AEB (00000000, 0053002B, 002B002B, 0027CE68)
0027C668 61095FCB (0027C680, 00000000, 00000094, 61020C1B)
0027C728 61096182 (00000C34, 00000006, 0027C758, 61096383)
0027C738 610961AC (00000006, 0027CE88, 00000001, 0000002D)
0027C758 61096383 (6C4CCBC0, 00000001, 0000002D, 61103150)
0027C788 6C48B60C (00FDA0F4, 062672A0, 0027C7D8, 610A0620)
0027C7A8 6C48652A (6C48B4C0, 0000001B, 0027C7D8, 6C4C1627)
0027C7B8 6C4BE1D3 (00000002, 6C4CCB44, 0000001B, 011407F1)
0027C7D8 6C4C1627 (06262608, 062626C8, 0027C874, 0027C7F8)
0027C828 00A210C1 (013C5B40, 0027C874, 06280CEC, 06280C60)
0027C8B8 00AF81ED (013C5BA0, 00000010, 0027C8E8, 01141D3B)
0027C988 00AF8A3F (0628D098, 0628D0D8, 0027C9D8, 00B0BFDC)
0027C998 00AEA9FF (0628D098, 00000000, 0027C9D8, 009F0684)
0027C9D8 00B0BFDC (0628D070, 06267328, 0027CA18, 00000000)
0027CA38 00E14497 (0628CD00, 06230000, 00000012, 0628D758)
End of stack trace (more stack frames may be present)

Error.jpg (67K) Download Attachment

Operation patch killing in bugzilla :-)

2009-12-11T06:42:10Z

Operation patch killing in bugzilla :-)

2009-12-11T06:03:28Z

Re: pcap trace refalgamization

2009-12-10T00:54:30Z

craig,

thanks for this detailed heads-up. Comments below.

On Wed, 2009-12-09 at 16:32 -0800, craigdo@... wrote:

> I created an issue at http://codereview.appspot.com/171049 to solicit
> comments on the approach so far. There are lots of changed files, most of
> which can just be ignored.

If you really care about getting timely reviews, adding a new minimal
version of the patch to this "review issue" will help. I will try to
look at it asap anyway.

> I propose resurrecting the radiotap / prism headers and using them for pcap
> tracing.

Overall, I doubt very much that we will need that many different kinds
of pcap-level encapsulations so, I am perfectly happy with the current
situation which, as you point out, requires some kind of editing to a
common file when new pcap encapsulation formats need to be supported. I
feel that we are still in control of this potential explosion but you
are obviously right that from a modularity perspective, it would be
better to do otherwise.

Now, if you could show that there is really no performance impact or, at
least, evaluate and quantify that impact on our examples, that would
allow us to make a clear and conscious decision about this issue.

My current position on this kind of performance issue is the following:
I am worried about more than 5 to 10% runtime overhead. Less than 5% is
acceptable. From 5 to 10 would need careful thinking. More than 10 would
not be ok.

Mathieu

Re: AODV test failing under Cygwin

2009-12-10T00:35:27Z

Hi, Faker,

SIGABRT (recognized by waf as "returncode = -6") should produce a coredump
-- can I see backtrace from it? Unfortunately I have no access to cygwin
platform to reproduce this bug.

Pavel

On Wednesday 09 December 2009 07:42:15 pm Faker Moatamri wrote:

> Hi all,
> When running test.py under cygwin, we get the following error:
> Building: ./waf --target=aodv
> NS3_ACTIVE_VARIANT == optimized
> NS3_BUILDDIR == /home/mathieu/buildslave/full-cygwin-g++/build/build
> NS3_MODULE_PATH ==
> ['/home/mathieu/buildslave/full-cygwin-g++/build/build/optimized']
> ENABLE_NSC == False
> ENABLE_REAL_TIME == False
> ENABLE_EXAMPLES == True
> os.environ["PATH"] ==
> /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program Files
> (x86)/Windows Resource
> Kits/Tools/:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Wi
> ndows/System32/Wbem:/cygdrive/c/Program Files
> (x86)/TortoiseHg:/cygdrive/c/Program Files
> (x86)/Bazaar:/usr/lib/lapack:/home/mathieu/buildslave/full-cygwin-g++/build
> /build/optimized Queue
> Launch examples/routing/aodv
> Synchronously execute
> /home/mathieu/buildslave/full-cygwin-g++/build/build/optimized/examples/rou
> ting/aodv Return code = -6
> stderr = pure virtual method called
> terminate called without an active exception
>
> returncode = -6
> ---------- beign standard out ----------
> Creating 10 nodes 120 m apart.
> Starting simulation for 10 s ...
> PING 10.0.0.10 56(84) bytes of data.
> 64 bytes from 10.0.0.10: icmp_seq=0 ttl=56 time=22 ms
> 64 bytes from 10.0.0.10: icmp_seq=1 ttl=56 time=7 ms
> 64 bytes from 10.0.0.10: icmp_seq=2 ttl=56 time=7 ms
> 64 bytes from 10.0.0.10: icmp_seq=3 ttl=56 time=7 ms
>
> ---------- begin standard err ----------
> pure virtual method called
> terminate called without an active exception
>
> ---------- end standard err ----------
> CRASH: Example routing/aodv
> 0 of 1 tests passed (0 passed, 0 skipped, 0 failed, 1 crashed, 0
> valgrind errors)
>
> Anyone has any idea about this error?
>
> Thanks
> Faker Moatamri
>

pcap trace refalgamization

2009-12-09T16:32:05Z

Hi All,

I have previously mentioned that I am working on a cleanup of the way pcap
tracing is been done. The ultimate goals are:

1) To introduce object names into pcap file names;
2) To get away from the situation we are in where we need to modify some
large number of source files to change tracing;
3) To use a common trace file base class previously introduced in the test
framework work;
4) To move away from an all-knowledgeable trace-writer that has to be
modified to add or change trace formats;
5) To provide a mid-level helper to make it easier to make the connection
between trace hooks and pcap files.

While I am at it, I want to apply the same kind of treatment to ascii trace
files and add a mid-level helper that makes it easy to write really any kind
of traced information to disk (not having such a thing seems to be a common
hurdle that must be crossed in order to use custom tracing successfully).

I created an issue at http://codereview.appspot.com/171049 to solicit
comments on the approach so far. There are lots of changed files, most of
which can just be ignored.

- Don't bother to look at any of the bindings/* files -- this is just noise.

- Don't bother to look at the examples/* files unless I point to one below.
These are all just changes from a static function EnablePcap call to a
method invocation.

Added files to implement this patch are:

1) src/common/pcap-file-object.{cc,h}

This is the beginning of a higher level interface to pcap files. There
already exists a low-level pcap file class but it doesn't use Packet or Time
objects since it was designed to be available at a very low level for the
test framework and not depend on anything really ns-3-like. i.e., you don't
want your test framework to depend on what it is testing.

The pcap-file-object is more oriented to being used by ns-3 code, and so
when you write packets to the file, you provide a Time and a Ptr<Packet>.

2) src/helper/pcap-helper.{cc,h}

This is the mid-level helper that makes life easy for someone who wants to
write pcap files. This tiny helper in conjunction with the pcap-file-object
do the heavy lifting. All that is required to enable pcap tracing in a
typical net device is:

CsmaHelper::EnablePcapInternal (std::string prefix, Ptr<NetDevice> nd, bool
promiscuous)
{
Ptr<CsmaNetDevice> device = nd->GetObject<CsmaNetDevice> ();
PcapHelper pcapHelper;
std::string filename = pcapHelper.GetFilename (prefix, device);
Ptr<PcapFileObject> file = pcapHelper.CreateFile (filename, "w",
PcapHelper::DLT_EN10MB);
if (promiscuous)
{
pcapHelper.HookDefaultSink<CsmaNetDevice> (device, "PromiscSniffer",
file);
}
else
{
pcapHelper.HookDefaultSink<CsmaNetDevice> (device, "Sniffer", file);
}
}

The GetFilename() method figures out the right thing to do with respect to
object names.

3) src/helper/pcap-user-helper.{cc,h}

This helper implements all of the various flavors of EnablePcap that we have
in our system. To implement a consistent
pcap interface a device helper just inherits from PcapUserHelper and defines
an EnablePcapInternal method.

4) examples/naming/object-names.cc shows the non-effort required to get
trace files with names like

object-names-client-eth0.pcap

i.e., the code change is a comment saying that it will happen automatically.

Moving from EnablePcap as a function to a method is the user visible API
change for this patch. This was already done in the yans wifi stuff, so now
all of the EnablePcap calls look the same. Moving away from static function
calls was required to add template and virtual methods which are used to
allow one EnablePcapInternal method for each device helper. The existing
PcapEnable APIs are implemented automagically in PcapUserHelper.

As an example of what needs to be done in a device helper, see
src/helper/csma-helper.{cc,h} for the simple (and common) case (seen above)
where the helper doesn't even have to define a trace sink. See
src/helper/yans-wifi-helper.{cc,h} for a special case where the helper needs
to define a custom trace sink with a non-standard signature.

One issue that concerns me is the current approach to pushing the radiotap
and prism header writing down to the pcap-writer level. This seems exactly
the wrong way to attack the problem to me. What it means is that if one
wants to add a new pcap packet format, one must edit a file in the deepest
bowels of the system. This seems very wrong. I would expect that one would
want to do this at the user or helper level. For example, if the
YansWifiPhyHelper wants to enable some alternate form of tracing, I would
not think it would be a good idea to have to edit the simulation core.

I know that the original implementation of radiotap and prism used packet
headers to add the required information to the pcap packets. This seems to
me to be the preferable way to do it. I think Mathieu vetoed the approach
due to performance considerations, but I want to push back on this decision.
I did not implement yet another layer of Write8, Write16, Write32, etc., for
the pcap-file-object because I think that packet headers fit this bill
nicely. Having a user specify extensions to packets becomes simple and
straightforward with no hacking on the core required.

I propose resurrecting the radiotap / prism headers and using them for pcap
tracing.

FYI all test.py and waf --regression tests pass except the single test that
uses the raidiotap headers.

Comments? Suggestions?

-- Craig

AODV test failing under Cygwin

2009-12-09T08:42:15Z

Hi all,
When running test.py under cygwin, we get the following error:
Building: ./waf --target=aodv
NS3_ACTIVE_VARIANT == optimized
NS3_BUILDDIR == /home/mathieu/buildslave/full-cygwin-g++/build/build
NS3_MODULE_PATH ==
['/home/mathieu/buildslave/full-cygwin-g++/build/build/optimized']
ENABLE_NSC == False
ENABLE_REAL_TIME == False
ENABLE_EXAMPLES == True
os.environ["PATH"] ==
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program Files
(x86)/Windows Resource
Kits/Tools/:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Program
Files (x86)/TortoiseHg:/cygdrive/c/Program Files
(x86)/Bazaar:/usr/lib/lapack:/home/mathieu/buildslave/full-cygwin-g++/build/build/optimized
Queue
Launch examples/routing/aodv
Synchronously execute
/home/mathieu/buildslave/full-cygwin-g++/build/build/optimized/examples/routing/aodv
Return code = -6
stderr = pure virtual method called
terminate called without an active exception

returncode = -6
---------- beign standard out ----------
Creating 10 nodes 120 m apart.
Starting simulation for 10 s ...
PING 10.0.0.10 56(84) bytes of data.
64 bytes from 10.0.0.10: icmp_seq=0 ttl=56 time=22 ms
64 bytes from 10.0.0.10: icmp_seq=1 ttl=56 time=7 ms
64 bytes from 10.0.0.10: icmp_seq=2 ttl=56 time=7 ms
64 bytes from 10.0.0.10: icmp_seq=3 ttl=56 time=7 ms

---------- begin standard err ----------
pure virtual method called
terminate called without an active exception

---------- end standard err ----------
CRASH: Example routing/aodv
0 of 1 tests passed (0 passed, 0 skipped, 0 failed, 1 crashed, 0
valgrind errors)

Anyone has any idea about this error?

Thanks
Faker Moatamri

Re: Buildbot finally all green :-)

2009-12-09T02:07:01Z

Tom Henderson wrote:

> On Tue, 08 Dec 2009 15:42:19 +0100, Faker Moatamri
> <faker.moatamri@...> wrote:
>
>> Hi all,
>> I'm happy to announce that after some patches/fixes (thanks for all
>> contributors), the buildbot automatic builder is green for all the
>> automatic builders:
>>
>> - Fedora Core 10 with g++-3.4.6, 4.0.4, 4.1.2, 4.2.4, 4.3.2 and 4.4.0
>> - OSX ppc with g++-4.0, 4.2
>> - Cygwin
>> - Mingw
>>
>> You can take a look at the build results on the
>> http://ns-regression.ee.washington.edu:8010/
>>
>
> Thanks, FYI, I added a Fedora Core 12 vm to the ns-regression farm today,
> but I haven't enabled buildbot on it. Is there a HOWTO? (maintainers, let
> me know if you want to access it)
>
>

Cool, I think having more platforms is a plus for having more reliable
release. Buildbot needs configuration both in the slave and master ends,
here is a small how to:
**Installing buildbot (python must be installed already):

-Download the package from
http://downloads.sourceforge.net/buildbot/buildbot-0.7.10p1.tar.gz

-uncompress and untar in your preferred directory

-Change the permission of the directory for it to be fully controlled by
/root/:/chmod -R a+w buildbot-0.7.10p1//

-Login as /root/

-/python setup.py build/

-should install the package+ twisted matrix: /python setup.py install/

-test: /buildbot --version/

-This will run unit testing for buildbot, it will take 5
minutes:/PYTHONPATH=. trial buildbot.test
/

/
/**Install the slave:

/-/create user buildslave

-/buildbot create-slave/ BASEDIR MASTERHOST:PORT SLAVENAME PASSWORD
(slavename and password are configured in the master.cfg file)

-example: buildbot create-slave /home/buildslave/buildslave/
localhost:9989 bot1slave bot1passwd

-run the slave: /buildbot start BASEDIR/

/-/To get the regression tests to work, you need to download the package
all in one:

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

-Then you untar the directories and you copy the folder

**Automatically start buildbot when the machine reboots:

Once you get everything running, you will want to arrange for the
buildbot daemons to be started at boot time. One way is to use |cron|,
by putting them in a @reboot crontab entry:

@reboot buildbot start BASEDIR

For example you do /crontab -e /then you write:

@reboot /usr/bin/buildbot start /path/to/buildslave/config

**Install the master:

Once your slave is up and running you need to configure the master:

c['slaves'] = [ ............., BuildSlave("bot1name", "bot1passwd")]

You need also to add commands to the master as it is done for other
builders.

If you need also to add several gcc's for your builder machine, I can
help you with that if you want.

You can give me access to the slave virtual machine and I will setup
buildbot if that helps.

Best regards

Faker Moatamri

> Tom
>
>

Re: Buildbot finally all green :-)

2009-12-08T23:27:30Z

hehe, it looks like I broke it yesterday night when I forgot to rescan
the python bindings.

Mathieu

On Tue, 2009-12-08 at 15:42 +0100, Faker Moatamri wrote:

> Hi all,
> I'm happy to announce that after some patches/fixes (thanks for all
> contributors), the buildbot automatic builder is green for all the
> automatic builders:
>
> - Fedora Core 10 with g++-3.4.6, 4.0.4, 4.1.2, 4.2.4, 4.3.2 and 4.4.0
> - OSX ppc with g++-4.0, 4.2
> - Cygwin
> - Mingw
>
> You can take a look at the build results on the
> http://ns-regression.ee.washington.edu:8010/
>
>
> Best regards
>
> Faker Moatamri

Re: 2.34 warning fix AND valgrind "Conditional jump or move" bug fix AND xgraph compilation fix with gcc 4.4

2009-12-08T23:00:45Z

Maxime de Roucy wrote:
> Hello
>
> I am new on this mailing list
>
> I am actually working on ns2 for my M.Sc.A (and moving from 2.30 to
> 2.34).
>
> All the program I talk about are form the allinone ns-2.34 package.

Hi Maxime, thanks for your ns-2 patches for gcc-4.4. I will try to
review and apply them shortly.

- Tom

buildbot failure in NsNam on osx-ppc-g++-4.2

2009-12-08T21:17:47Z

The Buildbot has detected a new failure of osx-ppc-g++-4.2 on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.2/builds/236

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: darwin-ppc

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15

sincerely,
-The Buildbot

buildbot failure in NsNam on cygwin-g++

2009-12-08T19:47:27Z

The Buildbot has detected a new failure of cygwin-g++ on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/270

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: cygwin

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_4 shell_8

sincerely,
-The Buildbot

buildbot failure in NsNam on osx-ppc-g++-4.0

2009-12-08T18:40:09Z

The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/230

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: darwin-ppc

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15

sincerely,
-The Buildbot

buildbot failure in NsNam on mingw-g++

2009-12-08T18:33:31Z

The Buildbot has detected a new failure of mingw-g++ on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/mingw-g%2B%2B/builds/267

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: mingw

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11

sincerely,
-The Buildbot

buildbot failure in NsNam on fc10-g++-4.4.0

2009-12-08T18:11:43Z

The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/300

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: rahan

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11

sincerely,
-The Buildbot

buildbot failure in NsNam on fc10-g++-4.3.2

2009-12-08T18:00:28Z

The Buildbot has detected a new failure of fc10-g++-4.3.2 on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.3.2/builds/282

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: rahan

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11

sincerely,
-The Buildbot

buildbot failure in NsNam on fc10-g++-4.2.4

2009-12-08T17:48:45Z

The Buildbot has detected a new failure of fc10-g++-4.2.4 on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.2.4/builds/285

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: rahan

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11

sincerely,
-The Buildbot

buildbot failure in NsNam on fc10-g++-4.1.2

2009-12-08T17:35:49Z

The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/308

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: rahan

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11

sincerely,
-The Buildbot

buildbot failure in NsNam on fc10-g++-4.0.4

2009-12-08T17:23:44Z

The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/286

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: rahan

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11

sincerely,
-The Buildbot

buildbot failure in NsNam on fc10-g++-3.4.6

2009-12-08T17:12:21Z

The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam.
Full details are available at:
http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/302

Buildbot URL: http://ns-regression.ee.washington.edu:8010/

Buildslave for this Build: rahan

Build Reason: The Nightly scheduler named 'before-work-fr' triggered this build
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11

sincerely,
-The Buildbot

Re: Buildbot finally all green :-)

2009-12-08T14:48:24Z

On Tue, 08 Dec 2009 15:42:19 +0100, Faker Moatamri
<faker.moatamri@...> wrote:

Thanks, FYI, I added a Fedora Core 12 vm to the ns-regression farm today,
but I haven't enabled buildbot on it. Is there a HOWTO? (maintainers, let
me know if you want to access it)

Tom