ns-3 performance - execution time

1,999 views
Skip to first unread message

Miguel

unread,
Sep 30, 2008, 10:05:49 AM9/30/08
to ns-3-users
Dear colleagues,

My name is Miguel and I am new in ns-3, although I have experience
with ns-2.

We are testing the performance and scalability of current version of
ns-3 but the results we have obtained are a bit strange. It seems to
me strange because the wifi-adhoc.cc script provided in the ‘examples’
of ns-3.2 takes several minutes to finish a very simple simulation
with only 2 WiFi nodes… It seems too much time compared with the time
needed by ns-2 or OMNET. I tried to increase the number of nodes and
the execution time increases a lot… Several questions then to the
people who has already tested more in detail ns-3:

- Do you think I may be doing something wrong or the
simulator is not yet prepared for ‘acceptable’ execution times?

- Do you know/have any other study of the execution time
needed by ns-3 to simulate a given number of simulation seconds for a
varying number of nodes using WiFi in adhoc mode?

- Do you know/have any other ns-3 script that considers a
given number of WiFi adhoc nodes (number of nodes chosen by the user)?

Any help would be appreciated.

Many thanks in advance.

Regards,

Miguel

Weng Gavin

unread,
Sep 30, 2008, 10:30:41 AM9/30/08
to ns-3-...@googlegroups.com
It is not several minutes, but roughly 10 mins or even more (core 2 duo 2.0GHz).....
 
I suppose it's because the simulator has to generate enough bits for packets, that is 250.0s * 6 Mbps bits.It needs to take care of all the packets. Maybe that's why it's quite slow.
 
I don't have any idea if it could be solved by running on multi machines, say cloud computing...

Gustavo Carneiro

unread,
Sep 30, 2008, 10:35:23 AM9/30/08
to ns-3-...@googlegroups.com


2008/9/30 Miguel <miguels...@gmail.com>


Dear colleagues,

My name is Miguel and I am new in ns-3, although I have experience
with ns-2.

We are testing the performance and scalability of current version of
ns-3 but the results we have obtained are a bit strange. It seems to
me strange because the wifi-adhoc.cc script provided in the 'examples'
of ns-3.2 takes several minutes to finish a very simple simulation
with only 2 WiFi nodes… It seems too much time compared with the time
needed by ns-2 or OMNET. I tried to increase the number of nodes and
the execution time increases a lot… Several questions then to the
people who has already tested more in detail ns-3:

-          Do you think I may be doing something wrong or the
simulator is not yet prepared for 'acceptable' execution times?

The simulator is prepared.

You should look more closely to that simulation script.  You'll notice it runs 11 experiments, each with 250 seconds of simulation time.  So you are in actual fact simulating a total of 2750 seconds, or 45 minutes, of simulated time.  Also the traffic rate plays an important role in simulation execution time; the more packets are simulated, the more time it takes.  Number of nodes is just one of many parameters affecting simulation speed, so you shouldn't judge the simulator by this parameter alone.


-          Do you know/have any other study of the execution time
needed by ns-3 to simulate a given number of simulation seconds for a
varying number of nodes using WiFi in adhoc mode?

I did benchmark early when ns-3 was just starting (couple of years ago) and only had point-to-point links and UDP, and found it to be much faster than the alternatives.  Unfortunately I have not made further comparisons, not with wireless and recent ns 3.  I think it is still much faster than alternatives (and especially uses much less RAM per node) than alternatives, but I have no proof.
 


-          Do you know/have any other ns-3 script that considers a
given number of WiFi adhoc nodes (number of nodes chosen by the user)?

No but it shouldn't be hard to modify one.  Take a look at examples/wifi-ap.cc, for instance.  You need to be proficient with such modifications anyway if you're going to get anywhere with NS 3, so there's a good exercise for you to start practicing... ;-)

Hope it helps.  Regards.

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

Miguel

unread,
Sep 30, 2008, 10:42:49 AM9/30/08
to ns-3-users
Thanks. Ok, I understand what you mean, but as far as I know ns-3 is
being designed with 'scalability' issues in mind... However, what
would happen if I want to simulate 1000 nodes during 1h?....

Of course parallelization would be a solution to reduce execution
time, but parallel simulations in ns-3 seem not to be ready yet:
http://www.nsnam.org/wiki/index.php/Parallel_Simulations

Regards,

Miguel




On 30 sep, 16:30, "Weng Gavin" <gavinw...@gmail.com> wrote:
> It is not several minutes, but roughly 10 mins or even more (core 2 duo
> 2.0GHz).....
>
> I suppose it's because the simulator has to generate enough bits for
> packets, that is 250.0s * 6 Mbps bits.It needs to take care of all the
> packets. Maybe that's why it's quite slow.
>
> I don't have any idea if it could be solved by running on multi machines,
> say cloud computing...
>

Miguel

unread,
Sep 30, 2008, 10:56:32 AM9/30/08
to ns-3-users
Thanks for the information.

I forgot to mention that I disabled all the 'Experiments' in the
script and only ran the first (54mb)...

You are completely right. Not only the number of nodes impacts the
execution time but also other parameters. For us the number of nodes
is the main parameter because the data rate and packet rate are kept
constant during the simulations for all nodes :)

I'll try to send to the mailing list more detailed information about
the execution times I have obtained.

Regards,

Miguel

Gustavo Carneiro

unread,
Sep 30, 2008, 11:46:25 AM9/30/08
to ns-3-...@googlegroups.com


2008/9/30 Miguel <miguels...@gmail.com>


Thanks for the information.

I forgot to mention that I disabled all the 'Experiments' in the
script and only ran the first (54mb)...

You are completely right. Not only the number of nodes impacts the
execution time but also other parameters. For us the number of nodes
is the main parameter because the data rate and packet rate are kept
constant during the simulations for all nodes :)

I'll try to send to the mailing list more detailed information about
the execution times I have obtained.

Also don't forget to enable optimized build (./waf configure -d optimized).
 

Miguel

unread,
Sep 30, 2008, 2:41:33 PM9/30/08
to ns-3-users

I am still doing tests and the execution time now seems to be
considerably decreased with just doing what Gustavo said:

./waf configure -d optimized

So thanks again for the information Gustavo.

Anyway, we are doing also scalability tests in terms of number of
nodes (number of transmitted packets, etc.) that the simulator can
run. What we have seen is that ns-2 crashes above certain number of
nodes in our scenario without returning any specific error. Do you
have any idea about what could be the reasons for that 'crash'? Maybe
the operating system or the PC cannot manage a very huge running
process.We are using an HP Proliant Quad core with 8 GB of RAM
memory...

Regarding ns-3, as far as I know, it is being designed to support
large-scale simulations. Any idea about the 'expected' number of nodes
(and transmitted packets, etc.) that it could support? Does anyone has
tested if ns-3 'crashes' at certain point when increasing the
computing requirements (as ns-2 does)? I suppose the answer is 'ns-3
is prepared to run a huge quantity of nodes, but just to confirm and
know other user experiences :)

Best regards

Miguel




On 30 sep, 17:46, "Gustavo Carneiro" <gjcarne...@gmail.com> wrote:
> 2008/9/30 Miguel <miguelsepul...@gmail.com>

Gustavo Carneiro

unread,
Sep 30, 2008, 4:47:28 PM9/30/08
to ns-3-...@googlegroups.com


2008/9/30 Miguel <miguels...@gmail.com>



I am still doing tests and the execution time now seems to be
considerably decreased with just doing what Gustavo said:

./waf configure -d optimized

So thanks again for the information Gustavo.

Anyway, we are doing also scalability tests in terms of number of
nodes (number of transmitted packets, etc.) that the simulator can
run. What we have seen is that ns-2 crashes above certain number of
nodes in our scenario without returning any specific error. Do you
have any idea about what could be the reasons for that 'crash'? Maybe
the operating system or the PC cannot manage a very huge running
process.We are using an HP Proliant Quad core with 8 GB of RAM
memory...

Regarding ns-3, as far as I know, it is being designed to support
large-scale simulations. Any idea about the 'expected' number of nodes
(and transmitted packets, etc.) that it could support? Does anyone has
tested if ns-3 'crashes' at certain point when increasing the
computing requirements (as ns-2 does)? I suppose the answer is 'ns-3
is prepared to run a huge quantity of nodes, but just to confirm and
know other user experiences :)

ns-3 crashes when the kernel's OOMK (out of memory killer) kills it, i.e. when virtual memory becomes more than what the system can handle.  Normally you want to use 'ulimit -v' to limit vmem available to the process before it is killed, otherwise the system might enter a state where it uses a slow swap memory and progresses very slowly.

I have simulated 500 OLSR nodes in ns-3 with 2GB of RAM.  But OLSR is a protocol that demands much computational effort.  Without OLSR I suspect you would  simulate thousands of nodes with the same hardware.

Miguel

unread,
Sep 30, 2008, 8:40:44 PM9/30/08
to ns-3-users

I see what you mean regarding the memory. The point is that ns-2
crashed with still free RAM memory (ns2 was using around 3.5GB and the
server has 8GB of RAM).

I have just prepared a very simple simulation script. Let's see the
power of ns-3... :)




On 30 sep, 22:47, "Gustavo Carneiro" <gjcarne...@gmail.com> wrote:
> 2008/9/30 Miguel <miguelsepul...@gmail.com>
>
>
>
>
>

Miguel

unread,
Oct 1, 2008, 7:38:31 AM10/1/08
to ns-3-users

The very basic test I have done says that ns-3.2 runs around 4 times
slower than ns-2.33, using a quite similar scenario (number of nodes,
node mobility, transmission rate, packet rate, transmission power/
propagation range etc.). The scenario is very simple: a given number
of wifi mobile nodes periodically sending 1-hop broadcast messages. No
more data transmitted than these 'beacons'.

For the implementation I have used APs (ns3::NqapWifiMac) because of
their 'beaconperiod' and so on. The N nodes/APs are moving using the
RandomWalk2dMobilityModel. The traces (both .tr and .pcap) seem to be
right...

Any more ideas?

Does anybody know if parallel simulations in ns-3 are already working?
This could be a solution if at least ns-3.2 does not crash when
increasing the number of nodes as ns-2.33......

Thanks a lot for your help

Miguel

Gustavo Carneiro

unread,
Oct 1, 2008, 8:02:17 AM10/1/08
to ns-3-...@googlegroups.com


2008/10/1 Miguel <miguels...@gmail.com>



The very basic test I have done says that ns-3.2 runs around 4 times
slower than ns-2.33, using a quite similar scenario (number of nodes,
node mobility, transmission rate, packet rate, transmission power/
propagation range etc.). The scenario is very simple: a given number
of wifi mobile nodes periodically sending 1-hop broadcast messages. No
more data transmitted than these 'beacons'.

For the implementation I have used APs (ns3::NqapWifiMac) because of
their 'beaconperiod' and so on. The N nodes/APs are moving using the
RandomWalk2dMobilityModel. The traces (both .tr and .pcap) seem to be
right...

Any more ideas?

How do they compare wrt. memory consumption.  I bet NS 3 wins in this department with a big difference... ;-)

The performance difference is puzzling.  Perhaps it's just the WiFi implementation not sufficiently optimized yet.  It would be interesting to compare with wired links as well.

Tom Henderson

unread,
Oct 1, 2008, 9:30:34 AM10/1/08
to ns-3-...@googlegroups.com
Miguel wrote:
>
> The very basic test I have done says that ns-3.2 runs around 4 times
> slower than ns-2.33, using a quite similar scenario (number of nodes,
> node mobility, transmission rate, packet rate, transmission power/
> propagation range etc.). The scenario is very simple: a given number
> of wifi mobile nodes periodically sending 1-hop broadcast messages. No
> more data transmitted than these 'beacons'.

What ns-2 models did you use? There are two 802.11 models in ns-2.33.

>
> For the implementation I have used APs (ns3::NqapWifiMac) because of
> their 'beaconperiod' and so on. The N nodes/APs are moving using the
> RandomWalk2dMobilityModel. The traces (both .tr and .pcap) seem to be
> right...
>
> Any more ideas?

If you are willing to share your comparison scripts, we could have a
look at them and see what is going on.


>
> Does anybody know if parallel simulations in ns-3 are already working?
> This could be a solution if at least ns-3.2 does not crash when
> increasing the number of nodes as ns-2.33......

They are not working yet.

Tom

Miguel

unread,
Oct 1, 2008, 10:34:05 AM10/1/08
to ns-3-users
Thanks for your help. Below some comments and scripts.

Regards

Miguel


On 1 oct, 15:30, Tom Henderson <t...@tomh.org> wrote:
> Miguel wrote:
>
> > The very basic test I have done says that ns-3.2 runs around 4 times
> > slower than ns-2.33, using a quite similar scenario (number of nodes,
> > node mobility, transmission rate, packet rate, transmission power/
> > propagation range etc.). The scenario is very simple: a given number
> > of wifi mobile nodes periodically sending 1-hop broadcast messages. No
> > more data transmitted than these 'beacons'.
>
> What ns-2 models did you use?  There are two 802.11 models in ns-2.33.

I am using the broadcast_validation.tcl script included in the last
release of ns-2.33 (tcl/ex/802.11/ directory). It uses the new Mac/
802_11Ext. We also tried with Mac/802_11 (ns-2.29) but it is slower
than Mac/802_11Ext.


> If you are willing to share your comparison scripts, we could have a
> look at them and see what is going on.

****************************************************************************************************
****************************************************************************************************
ns-2.33: broadcast_validation.tcl script included in the last release
of ns-2.33 (tcl/ex/802.11/ directory) with minor modifications


# Copyright (C) 2007
# Mercedes-Benz Research & Development North America, Inc. and
# University of Karlsruhe (TH)
# All rights reserved.
#
# Qi Chen : qi....@daimler.com
# Felix Schmidt-Eisenlohr : felix.schmi...@kit.edu
# Daniel Jiang : daniel...@daimler.com
#
# For further information see:
# http://dsn.tm.uni-karlsruhe.de/english/Overhaul_NS-2.php

# Parameters: seed nn stop


set val(seed) [lindex $argv 0]
puts $val(seed)

Mac/802_11 set CWMin_ 15
Mac/802_11 set CWMax_ 1023
Mac/802_11 set SlotTime_ 0.000009
Mac/802_11 set SIFS_ 0.000016
Mac/802_11 set ShortRetryLimit_ 7
Mac/802_11 set LongRetryLimit_ 4
Mac/802_11 set PreambleLength_ 60
Mac/802_11 set PLCPHeaderLength_ 60
Mac/802_11 set PLCPDataRate_ 6.0e6
Mac/802_11 set RTSThreshold_ 2000
Mac/802_11 set basicRate_ 6.0e6
Mac/802_11 set dataRate_ 6.0e6

Mac/802_11Ext set CWMin_ 15
Mac/802_11Ext set CWMax_ 1023
Mac/802_11Ext set SlotTime_ 0.000009
Mac/802_11Ext set SIFS_ 0.000016
Mac/802_11Ext set ShortRetryLimit_ 7
Mac/802_11Ext set LongRetryLimit_ 4
Mac/802_11Ext set HeaderDuration_ 0.000020
Mac/802_11Ext set SymbolDuration_ 0.000004
Mac/802_11Ext set BasicModulationScheme_ 0
Mac/802_11Ext set use_802_11a_flag_ true
Mac/802_11Ext set RTSThreshold_ 2000
Mac/802_11Ext set MAC_DBG 0

Phy/WirelessPhy set CSThresh_ 6.30957e-12
Phy/WirelessPhy set Pt_ 0.001
Phy/WirelessPhy set freq_ 5.18e9
Phy/WirelessPhy set L_ 1.0
Phy/WirelessPhy set RXThresh_ 3.652e-10
Phy/WirelessPhy set bandwidth_ 20e6
Phy/WirelessPhy set CPThresh_ 10.0

Phy/WirelessPhyExt set CSThresh_ 6.30957e-12
Phy/WirelessPhyExt set Pt_ 0.25
Phy/WirelessPhyExt set freq_ 5.18e9
Phy/WirelessPhyExt set noise_floor_ 2.51189e-13
Phy/WirelessPhyExt set L_ 1.0
Phy/WirelessPhyExt set PowerMonitorThresh_ 2.10319e-12
Phy/WirelessPhyExt set HeaderDuration_ 0.000020
Phy/WirelessPhyExt set BasicModulationScheme_ 0
Phy/WirelessPhyExt set PreambleCaptureSwitch_ 1
Phy/WirelessPhyExt set DataCaptureSwitch_ 0
Phy/WirelessPhyExt set SINR_PreambleCapture_ 2.5118
Phy/WirelessPhyExt set SINR_DataCapture_ 100.0
Phy/WirelessPhyExt set trace_dist_ 1e6
Phy/WirelessPhyExt set PHY_DBG_ 0
Phy/WirelessPhyExt set CPThresh_ 0 ;# not used at the moment
Phy/WirelessPhyExt set RXThresh_ 0 ;# not used at the moment


#=====================================================================

#configure RF model parameters
Antenna/OmniAntenna set Gt_ 1.0
Antenna/OmniAntenna set Gr_ 1.0

Propagation/Nakagami set use_nakagami_dist_ false
Propagation/Nakagami set gamma0_ 2.0
Propagation/Nakagami set gamma1_ 2.0
Propagation/Nakagami set gamma2_ 2.0

Propagation/Nakagami set d0_gamma_ 200
Propagation/Nakagami set d1_gamma_ 500

Propagation/Nakagami set m0_ 1.0
Propagation/Nakagami set m1_ 1.0
Propagation/Nakagami set m2_ 1.0

Propagation/Nakagami set d0_m_ 80
Propagation/Nakagami set d1_m_ 200

#=======================================================================


set val(chan) Channel/WirelessChannel
set val(prop) Propagation/TwoRayGround

set val(netif) Phy/WirelessPhyExt
set val(mac) Mac/802_11Ext
set val(ifq) Queue/DropTail/PriQueue
set val(ll) LL
set val(ant) Antenna/OmniAntenna
set val(ifqlen) 20 ;# max packet in ifq
set val(nn) [lindex $argv 1] ;# how many nodes are
simulated
puts $val(nn)
set val(x) 10000 ;# X dimension of the topography 6750
set val(y) 10000 ;# Y dimension of the topography
set val(rtg) DumbAgent
set val(stop) [lindex $argv 2] ;# simulation time
puts $val(stop)
#
=====================================================================
# Main Program
#
======================================================================

#
# Initialize Global Variables
#

global defaultRNG
$defaultRNG seed $val(seed)

set ns_ [new Simulator]
set topo [new Topography]
#set tracefd stdout
$ns_ use-newtrace
set tracefd [open broadcast-nn$val(nn)-nn_port$val(nn)-t$val(stop)-
b225-s3375-w1-v70-seed$val(seed)-mov-2.33.tr w]
$ns_ trace-all $tracefd

$topo load_flatgrid $val(x) $val(y)
set god_ [create-god $val(nn)]
$god_ off

set chan [new $val(chan)]
$ns_ node-config -adhocRouting $val(rtg) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channel $chan \
-topoInstance $topo \
-agentTrace OFF \
-routerTrace OFF \
-macTrace ON \
-phyTrace OFF

for {set i 0} {$i < $val(nn) } {incr i} {
set ID_($i) $i
set vehicle_($i) [$ns_ node]
$vehicle_($i) set id_ $ID_($i)
$vehicle_($i) set address_ $ID_($i)
#$vehicle_($i) set X_ [expr $i * $val(x)/($val(nn)+1.0)]
#$vehicle_($i) set Y_ 10
#$vehicle_($i) set Z_ 0
$vehicle_($i) nodeid $ID_($i)

set agent_($i) [new Agent/PBC]
$ns_ attach-agent $vehicle_($i) $agent_($i)
$agent_($i) set Pt_ 0.25
$agent_($i) set payloadSize 100
$agent_($i) set peroidcaBroadcastInterval 0.1
$agent_($i) set peroidcaBroadcastVariance 0.05
$agent_($i) set modulationScheme 1
$agent_($i) PeriodicBroadcast ON
$ns_ at $val(stop).0 "$vehicle_($i) reset";

}

puts "Reading Matlab patern file..."
source "manh_matlab-nn$val(nn)-nn_port$val(nn)-t$val(stop)-b225-s3375-
w1-v70-seed$val(seed)-mov-2.33.tcl"

for {set i 1} {$i <= 10} {incr i} {
$ns_ at [expr $i*$val(stop)/10.0] "puts \" $i/10. Simulated
time: [expr $i*$val(stop)/10.0] secs. \""
}

$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
$ns_ at $val(stop).0003 "$ns_ flush-trace"
puts "Starting Simulation..."
$ns_ run



****************************************************************************************************
****************************************************************************************************
ns-3.2: this is the script (based on third.cc)


#include "ns3/core-module.h"
#include "ns3/simulator-module.h"
#include "ns3/node-module.h"
#include "ns3/helper-module.h"
#include "ns3/global-routing-module.h"
#include "ns3/wifi-module.h"
#include "ns3/mobility-module.h"

#include "stdio.h"


using namespace ns3;

NS_LOG_COMPONENT_DEFINE ("ThirdScriptExample");

int
main (int argc, char *argv[])
{
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);

char cadena[50];

double tiempo = 10.0;
uint32_t nWifi = 3;
CommandLine cmd;
cmd.AddValue ("tiempo", "Simulation time", tiempo);
cmd.AddValue ("nWifi", "Number of wifi STA devices", nWifi);
cmd.Parse (argc,argv);


NodeContainer wifiStaNodes;
wifiStaNodes.Create (nWifi);

Ptr<WifiChannel> channel = CreateObject<WifiChannel> ();

channel->SetPropagationDelayModel (
CreateObject<ConstantSpeedPropagationDelayModel> ());

Ptr<LogDistancePropagationLossModel> log =
CreateObject<LogDistancePropagationLossModel> ();

log->SetReferenceModel (CreateObject<FriisPropagationLossModel> ());

channel->SetPropagationLossModel (log);

WifiHelper wifi;
wifi.SetPhy ("ns3::WifiPhy");
wifi.SetRemoteStationManager ("ns3::ArfWifiManager");

Ssid ssid;
NetDeviceContainer apDevices;


int k=0;
UniformVariable x(0.09 , 0.11);

for(k=0 ; k<(int)nWifi ; k++) {
sprintf(cadena, "ns-3-ssid-%d", k);
ssid = Ssid (cadena);

wifi.SetMac ("ns3::NqapWifiMac",
"Ssid", SsidValue (ssid),
"BeaconGeneration", BooleanValue (true),
"BeaconInterval", TimeValue (Seconds (x.GetValue()) ) );

//apDevices = wifi.Install (wifiStaNodes.Get(k), channel);
apDevices.Add( wifi.Install (wifiStaNodes.Get(k), channel) );
}

/*
ssid = Ssid ("ns-3-ssid");
wifi.SetMac ("ns3::NqapWifiMac",
"Ssid", SsidValue (ssid),
"BeaconGeneration", BooleanValue (true),
"BeaconInterval", TimeValue (Seconds (0.1)));

apDevices = wifi.Install (wifiStaNodes, channel);
*/

MobilityHelper mobility;

mobility.SetPositionAllocator ("ns3::GridPositionAllocator",
"MinX", DoubleValue (0.0),
"MinY", DoubleValue (0.0),
"DeltaX", DoubleValue (75.0),
"DeltaY", DoubleValue (75.0),
"GridWidth", UintegerValue (44),
"LayoutType", StringValue ("RowFirst"));

// mobility.SetMobilityModel ("ns3::RandomWalk2dMobilityModel",
"Bounds", RectangleValue (Rectangle (0, 3375, 0, 3375)));

mobility.SetMobilityModel ("ns3::RandomWalk2dMobilityModel",
"Bounds", RectangleValue (Rectangle (0, 3375, 0, 3375)) ,
"Speed", RandomVariableValue (ConstantVariable (19.44)));

mobility.Install (wifiStaNodes);

InternetStackHelper stack;
stack.Install (wifiStaNodes);

Ipv4AddressHelper address;

address.SetBase ("10.1.0.0", "255.255.0.0");
address.Assign (apDevices);

GlobalRouteManager::PopulateRoutingTables ();

Simulator::Stop (Seconds (tiempo));


sprintf(cadena, "third-nn-%d.tr", nWifi);
std::ofstream ascii;
ascii.open (cadena);
WifiHelper::EnableAscii(ascii, wifiStaNodes.Get(1));


sprintf(cadena, "third-nn-%d", nWifi);
WifiHelper::EnablePcap (cadena , wifiStaNodes.Get(1) );
//WifiHelper::EnablePcap ("third-nn", wifiStaNodes.Get (nWifi - 1)-
>GetId (), 0);

Simulator::Run ();
Simulator::Destroy ();
return 0;
}



Gustavo Carneiro

unread,
Oct 1, 2008, 10:45:24 AM10/1/08
to ns-3-...@googlegroups.com
I know very little of NS 2, but I see two things that may affect performance of the NS 3 script:

 1- You are enabling pcap output in the NS 3 program (WifiHelper::EnablePcap), but obviously there is no pcap output in NS 2.  This could explain differences, as NS 3 is doing more work;

 2- Similarly, you are enabling "ascii output" in NS 3 (WifiHelper::EnableAscii).  This is great for debugging and regression testing, but researchers looking for performance in NS 3 should instead be collecting data in C++ trace callbacks and writing data to a file from such callbacks.  The simple fact of enabling ascii output enables the "packet metadata" which makes things slower.

2008/10/1 Miguel <miguels...@gmail.com>

Miguel

unread,
Oct 1, 2008, 12:02:18 PM10/1/08
to ns-3-users
Yes, I enabled them to ckeck that everithing was going well with the
beacons transmissions and I was not creating some kind of broadcast
storm problem or something like that... Anyway, the traces were also
enabled in ns-2.33 at the MAC level...

There is not significant improvement in the execution time when I
disable the .pcap and ascii output. The gain is around 5 minutes out
of around one hour of execution time.

A significant improvement in RAM memory (but not too much in execution
time) can be obtained if the packets were only 'received' by
wifidevices within a given range. For example, if we have a
10.000mx10.000m scenario, the execution time could be improved if the
transmitted packets were only be replicated in those interfaces closer
than L=1000m (for example) to the transmitting node. If L is selected
adequately (considering the propagation environment, the transmission
power levels, the modulation schemes used, etc.), almost the same
results could be obtained. If I correctly understood the code, ns-3.2
creates a copy of all transmitted packets in all interfaces in
"WifiChannel::Send" function. Then the following part of this
function:

for (DeviceList::const_iterator i = m_deviceList.begin (); i !=
m_deviceList.end (); i++)
{
if (sender != i->second)
{
Ptr<MobilityModel> receiverMobility = i->first->GetNode ()-
>GetObject<MobilityModel> ();

Time delay = m_delay->GetDelay (senderMobility,
receiverMobility);
double rxPowerDbm = txPowerDbm + m_loss->GetLoss
(senderMobility, receiverMobility);
NS_LOG_DEBUG ("propagation:
txPower="<<txPowerDbm<<"dbm, rxPower="<<rxPowerDbm<<"dbm, "<<
"distance="<<senderMobility-
>GetDistanceFrom (receiverMobility)<<"m, delay="<<delay);
Ptr<Packet> copy = packet->Copy ();
Simulator::Schedule (delay, &WifiChannel::Receive,
this,
j, copy, rxPowerDbm, wifiMode,
preamble);
}
j++;
}

could be replaced with:

for (DeviceList::const_iterator i = m_deviceList.begin (); i !=
m_deviceList.end (); i++)
{
if (sender != i->second)
{
Ptr<MobilityModel> receiverMobility = i->first->GetNode ()-
>GetObject<MobilityModel> ();

double distance = senderMobility->GetDistanceFrom
(receiverMobility); // new

if (distance <= 1000.0){ // new
Time delay = m_delay->GetDelay (senderMobility,
receiverMobility);
double rxPowerDbm = txPowerDbm + m_loss->GetLoss
(senderMobility, receiverMobility);
NS_LOG_DEBUG ("propagation:
txPower="<<txPowerDbm<<"dbm, rxPower="<<rxPowerDbm<<"dbm, "<<
"distance="<<senderMobility-
>GetDistanceFrom (receiverMobility)<<"m, delay="<<delay);
Ptr<Packet> copy = packet->Copy ();
Simulator::Schedule (delay, &WifiChannel::Receive,
this,
j, copy, rxPowerDbm, wifiMode,
preamble);
} // new
}
j++;
}








On 1 oct, 16:45, "Gustavo Carneiro" <gjcarne...@gmail.com> wrote:
> I know very little of NS 2, but I see two things that may affect performance
> of the NS 3 script:
>
>  1- You are enabling pcap output in the NS 3 program
> (WifiHelper::EnablePcap), but obviously there is no pcap output in NS 2.
> This could explain differences, as NS 3 is doing more work;
>
>  2- Similarly, you are enabling "ascii output" in NS 3
> (WifiHelper::EnableAscii).  This is great for debugging and regression
> testing, but researchers looking for performance in NS 3 should instead be
> collecting data in C++ trace callbacks and writing data to a file from such
> callbacks.  The simple fact of enabling ascii output enables the "packet
> metadata" which makes things slower.
>
> 2008/10/1 Miguel <miguelsepul...@gmail.com>
> > # Qi Chen                 : qi.c...@daimler.com
> > # Felix Schmidt-Eisenlohr : felix.schmidt-eisenl...@kit.edu
> > # Daniel Jiang            : daniel.ji...@daimler.com
> > #
> > # For further information see:
> > #http://dsn.tm.uni-karlsruhe.de/english/Overhaul_NS-2.php
> ...
>
> leer más »

Miguel

unread,
Oct 1, 2008, 2:47:48 PM10/1/08
to ns-3-users
One more comment. When I run something like:

./waf --run "scratch/third-nn --nWifi=1000 --tiempo=40.0"

using the ns-3.2 script I provided above, the simulation does not stop
runing eevn after 2 hours...:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26618 miguel 25 0 26516 15m 4420 R 100 0.2 125:25.89 third-nn

However, if I comment the following lines in the script:

/*
InternetStackHelper stack;
stack.Install (wifiStaNodes);
Ipv4AddressHelper address;
address.SetBase ("10.1.0.0", "255.255.0.0");
address.Assign (apDevices);
GlobalRouteManager::PopulateRoutingTables ();
*/

then look what the 'top' command gives us:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26888 miguel 25 0 250m 240m 4568 R 99 6.1 10:15.92 third-nn

Now the simulation seems to be working (not blocked), but as I said,
slower than ns-2 and using more RAM memory.....

Regards,

Miguel
> ...
>
> leer más »

Mathieu Lacage

unread,
Oct 1, 2008, 8:26:38 AM10/1/08
to ns-3-...@googlegroups.com
On Wed, 2008-10-01 at 04:38 -0700, Miguel wrote:
>
> The very basic test I have done says that ns-3.2 runs around 4 times
> slower than ns-2.33, using a quite similar scenario (number of nodes,
> node mobility, transmission rate, packet rate, transmission power/
> propagation range etc.). The scenario is very simple: a given number
> of wifi mobile nodes periodically sending 1-hop broadcast messages. No
> more data transmitted than these 'beacons'.
>
> For the implementation I have used APs (ns3::NqapWifiMac) because of
> their 'beaconperiod' and so on. The N nodes/APs are moving using the
> RandomWalk2dMobilityModel. The traces (both .tr and .pcap) seem to be
> right...
>
> Any more ideas?

1) If you are serious about running large scale simulations, you should
check that the trace file generation is not a bottleneck: harddisk
bandwidth and seek times are much slower than CPU performance.

2) if harddisk is not the bottleneck, just run oprofile and look at the
top CPU hotspots.

Mathieu

Mathieu Lacage

unread,
Oct 1, 2008, 9:10:26 AM10/1/08
to ns-3-...@googlegroups.com, Fei Ye

Do you have evidence that the below is an improvement ? I suspect that
it might not be an improvement.

>
> for (DeviceList::const_iterator i = m_deviceList.begin (); i !=
> m_deviceList.end (); i++)
> {
> if (sender != i->second)
> {
> Ptr<MobilityModel> receiverMobility = i->first->GetNode ()-
> >GetObject<MobilityModel> ();
>
> double distance = senderMobility->GetDistanceFrom
> (receiverMobility); // new
>
> if (distance <= 1000.0){ // new
> Time delay = m_delay->GetDelay (senderMobility,
> receiverMobility);
> double rxPowerDbm = txPowerDbm + m_loss->GetLoss
> (senderMobility, receiverMobility);
> NS_LOG_DEBUG ("propagation:
> txPower="<<txPowerDbm<<"dbm, rxPower="<<rxPowerDbm<<"dbm, "<<
> "distance="<<senderMobility-
> >GetDistanceFrom (receiverMobility)<<"m, delay="<<delay);
> Ptr<Packet> copy = packet->Copy ();
> Simulator::Schedule (delay, &WifiChannel::Receive,
> this,
> j, copy, rxPowerDbm, wifiMode,
> preamble);
> } // new
> }
> j++;
> }

And before you ask the obvious question which is "why don't we do this
already ?", the answer is that the goal of the current PHY model is to
be accurate and detailed, not really fast. Its main characteristic is
that it is O(n2) where n is the number of interfering nodes. (see
http://cutebugs.net/files/wns2-yans.pdf for a detailed description of
the PHY interference model implemented). If you want a simpler PHY
distance-threshold based model, I would be happy to take a patch which
implements one.

Since I don't really have much time to run this code myself and look at
it in detail, I can't really tell you exactly what is going on but I can
suggest two leads:

1) consider changing the ed threshold value to make it smaller to
decrease the interference range. Fye who is CCed to this email recently
complained privately about the inadequacy of the default EDthreshold
value and we came up with a value which seemed to make him happy (I
don't remember what that value was). Since he did not file a bug [hint],
that issue fell through the cracks.

2) If you look at performance problems, jumping to conclusions just by
reading the code is most likely a waste of your time. Use the right tool
for the job instead: a profiler. On linux, I would suggest "oprofile".

regards,
Mathieu

Miguel

unread,
Oct 4, 2008, 2:02:01 PM10/4/08
to ns-3-users
Thanks Mathieu for your very good suggestions. I am triying to
understand how oprofile works and then I will see what is happening
inside ns-2 and ns-3...

Regarding the trace, I understand what you mean. However, I am tracing
only the packets transmitted/received by one node (the output trace is
only around 2MB after 2h of execution time). Anyway, I will need the
traces to analyse the results, so disabling them may reduce the
execution time for the tests I am doing now but I will have to enable
them for doing the final simulations (if no other option is available
for tracing variables/parameters/messages)...

Regarding de detailed PHY interference model, I see that it is quite
detailed and could be the reason for the slower simulation times I am
geting (I will check that with oprofile).

The code I provided changing the "WifiChannel::Send" function in fact
reduces the execution time required (it reduces the number of vehicles
that detect each message, but take care with the selection of the
range). I did a quick simulation and the execution time was reduced
from 2h:30 to 30min or similar with just changing what I proposed.
Actually, ns-2 does something similar for deterministic propagation
models (tworayground, friis, etc). I will try to provide you more
details about the gain and about how results could be affected because
of the lose of accuracy.

Thank you very much again.

Regards,

On 1 oct, 15:10, Mathieu Lacage <mathieu.lac...@sophia.inria.fr>
wrote:
> that it is O(n2) where n is the number of interfering nodes. (seehttp://cutebugs.net/files/wns2-yans.pdffor a detailed description of

Mathieu Lacage

unread,
Oct 7, 2008, 9:18:20 AM10/7/08
to ns-3-...@googlegroups.com
hi,

sorry for this late answer,

On Sat, 2008-10-04 at 11:02 -0700, Miguel wrote:
> Thanks Mathieu for your very good suggestions. I am triying to
> understand how oprofile works and then I will see what is happening
> inside ns-2 and ns-3...
>
> Regarding the trace, I understand what you mean. However, I am tracing
> only the packets transmitted/received by one node (the output trace is
> only around 2MB after 2h of execution time). Anyway, I will need the

ok, that is pretty reasonable. 40MB/s is a typical IO bdwidth upper
bound for low-end hard disks.

> traces to analyse the results, so disabling them may reduce the
> execution time for the tests I am doing now but I will have to enable
> them for doing the final simulations (if no other option is available
> for tracing variables/parameters/messages)...
>
> Regarding de detailed PHY interference model, I see that it is quite
> detailed and could be the reason for the slower simulation times I am
> geting (I will check that with oprofile).
>
> The code I provided changing the "WifiChannel::Send" function in fact
> reduces the execution time required (it reduces the number of vehicles
> that detect each message, but take care with the selection of the
> range). I did a quick simulation and the execution time was reduced
> from 2h:30 to 30min or similar with just changing what I proposed.
> Actually, ns-2 does something similar for deterministic propagation
> models (tworayground, friis, etc). I will try to provide you more
> details about the gain and about how results could be affected because
> of the lose of accuracy.

I see. So, yes, I guess that the real issue here is the interference
calculation. I would be curious to know if you can get a similar
performance boost by changing the ed threshold.

regards,
Mathieu

Reply all
Reply to author
Forward
0 new messages