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)?
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.
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 :)
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?
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
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
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
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