Nsnam - User contributions [en]

Troubleshooting

2008-11-19T02:21:49Z

SamJansen: /* Run-time errors */

{{TOC}}

This is a wiki; if you find items not adequately covered below, please consider adding an entry.

== Platform-specific issues ==

=== Cygwin ===

'''Python bindings'''

Python bindings do not build successfully due to a gccxml bug. See the [[NS-3_Python_Bindings#Caveats]] page.

If you see "resolving vtable" messages while linking such as the below when you compile on Cygwin, you can safely ignore them:

<pre>
[530/535] cxx_link: build/debug/examples/wifi-wired-bridging_23.o -> build/debug
/examples/wifi-wired-bridging.exe
Info: resolving vtable for ns3::EmptyAttributeValueby linking to __imp___ZTVN3ns
319EmptyAttributeValueE (auto-import)
Info: resolving vtable for ns3::RandomVariableValueby linking to __imp___ZTVN3ns
319RandomVariableValueE (auto-import)
Info: resolving vtable for ns3::RectangleValueby linking to __imp___ZTVN3ns314Re
ctangleValueE (auto-import)
Info: resolving vtable for ns3::TimeValueby linking to __imp___ZTVN3ns39TimeValu
eE (auto-import)
Info: resolving vtable for ns3::BooleanValueby linking to __imp___ZTVN3ns312Bool
eanValueE (auto-import)

etc.
</pre>

'''NSC'''

The Network Simulation Cradle is not supported under Cygwin. It is advised to use a Unix-based platform instead. Windows users can use a virtual machine to run e.g. Linux. See e.g. http://www.virtualbox.org/ for a free virtual machine.

== General build problems ==

* Q. What is this kind of build error representative of?
assert failed. file=../src/core/type-id.cc, line=389, cond="uid != 0"
Command ['/ns-3-dev/build/debug/examples/mixed-wireless'] exited with code -5
* A. The system can't find the specified TypeId. Check spelling, and whether it is prefixed with the namespace "ns3::"
* Q. A required software package is in a non-standard place. How to get waf to find the packages?
* A. To compile with non-standard link path, use the environment variable LINKFLAGS. Example for bash shell:
LINKFLAGS="-L/tmp" ./waf configure

== Run-time errors ==

* Q. What is this assertion indicating?
assert failed. file=debug/ns3/tags.h, line=105, cond="sizeof (T) <= Tags::SIZE"
* A. The packet tag may be greater than Tags::SIZE (16 bytes)

* Q. Why does valgrind fail with SIGILL on a simulation using NSC?
* A. Valgrind does not work under 64-bit mode when running NSC due to lack of support for all the opcodes used. This has been confirmed to work in 32-bit mode.

== Debugging tips ==

* Q. Is there a way to dereference a Ptr when in gdb?
* A. yes: p *ptr->m_ptr

Troubleshooting

2008-11-19T02:17:37Z

SamJansen: /* Cygwin */

{{TOC}}

This is a wiki; if you find items not adequately covered below, please consider adding an entry.

== Platform-specific issues ==

=== Cygwin ===

'''Python bindings'''

Python bindings do not build successfully due to a gccxml bug. See the [[NS-3_Python_Bindings#Caveats]] page.

If you see "resolving vtable" messages while linking such as the below when you compile on Cygwin, you can safely ignore them:

<pre>
[530/535] cxx_link: build/debug/examples/wifi-wired-bridging_23.o -> build/debug
/examples/wifi-wired-bridging.exe
Info: resolving vtable for ns3::EmptyAttributeValueby linking to __imp___ZTVN3ns
319EmptyAttributeValueE (auto-import)
Info: resolving vtable for ns3::RandomVariableValueby linking to __imp___ZTVN3ns
319RandomVariableValueE (auto-import)
Info: resolving vtable for ns3::RectangleValueby linking to __imp___ZTVN3ns314Re
ctangleValueE (auto-import)
Info: resolving vtable for ns3::TimeValueby linking to __imp___ZTVN3ns39TimeValu
eE (auto-import)
Info: resolving vtable for ns3::BooleanValueby linking to __imp___ZTVN3ns312Bool
eanValueE (auto-import)

etc.
</pre>

'''NSC'''

The Network Simulation Cradle is not supported under Cygwin. It is advised to use a Unix-based platform instead. Windows users can use a virtual machine to run e.g. Linux. See e.g. http://www.virtualbox.org/ for a free virtual machine.

== General build problems ==

* Q. What is this kind of build error representative of?
assert failed. file=../src/core/type-id.cc, line=389, cond="uid != 0"
Command ['/ns-3-dev/build/debug/examples/mixed-wireless'] exited with code -5
* A. The system can't find the specified TypeId. Check spelling, and whether it is prefixed with the namespace "ns3::"
* Q. A required software package is in a non-standard place. How to get waf to find the packages?
* A. To compile with non-standard link path, use the environment variable LINKFLAGS. Example for bash shell:
LINKFLAGS="-L/tmp" ./waf configure

== Run-time errors ==

* Q. What is this assertion indicating?
assert failed. file=debug/ns3/tags.h, line=105, cond="sizeof (T) <= Tags::SIZE"
* A. The packet tag may be greater than Tags::SIZE (16 bytes)

== Debugging tips ==

* Q. Is there a way to dereference a Ptr when in gdb?
* A. yes: p *ptr->m_ptr

Ns-3.3

2008-11-18T05:58:19Z

SamJansen: Removed my bug entry that is now closed.

{{TOC}}

== The Release ==
This page summarizes the ongoing release planning for the third stable release of ns-3.

* ns-3-dev is currently in the maintenance phase of the ns-3.3 release. Only bugfixes for bugs reported in the tracker are allowed.

* The first release candidate for ns-3.3 is scheduled for release on December 1, 2008

* ns-3.3 is scheduled for release in December 17, 2008.

== The Hot List ==
ns-3.3 is currently in the maintenance phase of the release. The next phase, the code-freeze phase starts on December 1, 2008. By definition, all priority one bugs should be fixed by that time. As I type this, it is November 17, and we have nine working days left until code freeze (seven days in the U.S. due to the Thanksgiving holiday).

As soon as ns-3.2.1 is released, the bugs in the tracker marked as priority two will be elevated to priority one and therefore be blockers for ns-3.3 as defined. We have accumulated quite a list of such bugs. I have broken out the list under the maintainers who are responsible for the bugs. This is a friendly reminder that this list really needs to be close to zero bugs by November 30.

Bhattacharjea:

# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=250 250 Tcp breaks if you set the delackcount > 2]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=341 341 Get unexpected dropped packets when using SetSendCallback with heavy traffic]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=358 358 calling listen on non-closed TCP sockets sends resets, should fail and do nothing]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=365 365 TcpSocketImpl::Recv returns 0 without setting m_errno]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=392 392 Example star.cc confuses TCP]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=410 410 Doxygen is not picking up class OnOffHelper]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=411 411 OnOffApplication::OnTime does not work]

Carniero:

# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=348 348 regression tests do not work in private or disconnected networks]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=289 289 CommandLine::AddValue is not wrapped]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=325 325 regression code should be moved into regression/wscript]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=387 387 Build fails with junk subdirectories in "scratch" directory]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=407 407 OLSR may select wrong interface in MID context]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=413 413 python bindings not portable to OS X]

Dowell:

# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=66 66 improve granularity of GlobalRouteManager::PopulateRoutes]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=114 114 global routing doesn't handle multi-hop layer-2 subnets]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=187 187 Need 'perfect' ARP]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=241 241 Trace sources not clearly documented, trace sinks not clearly documented]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=263 263 XxxAddress::ConvertFrom are prone to subtle bugs]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=383 <s>383 Please make _all_ header structures public</s>] -- Fixed
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=391 <s>391 Example csma-star kills global routing</s>] -- Fixed
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=401 <s>401 add InternetStackHelper::EnableAscii ()</s>] -- Fixed
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=403 <s>403 Ipv4AddressHelper cannot assign /32 addresses</s>] -- Fixed
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=404 <s>404 ErrorModel attribute name is not consistent across devices</s>] -- Fixed

Henderson:

# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=188 188 global routing does not handle ip aliasing]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=400 400 Wifi Muti-Hop Network not forwaring packets (atleast ARP)]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=406 406 GlobalRouteManager behaviour after Ipv4 interface SetDown and SetUp procedure]

Lacage:

# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=215 215 Node names patch]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=218 218 wifi PHY base class must be virtualized and subclass renamed]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=230 230 Simulator::Now() Updating and Simulator::Stop()]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=257 257 log time printer, can we optionally support output of time in seconds?]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=395 395 log distance propagation loss model complex to use.]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=396 396 Weird WiFi error state with STA slowing approaching the wifi range of an AP]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=397 397 Custom WifiModes apparently not possible in infrastructure mode]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=398 398 NqstaWifiMac does not filter received frames by BSSID]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=405 405 wifi log messages improvements]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=408 408 No duplicate filtering for managament frames]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=409 409 Simulation fails depending on number of wireless nodes]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=412 412 Extend number of template parameters in xxxCallback classes]

Westphal:

# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=320 320 getsockname returns a port number in network byte order]
# [http://www.nsnam.org/bugzilla/show_bug.cgi?id=356 356 tcp-nsc-lfn fails with --valgrind selected]

== The Release Manager ==
Craig Dowell (craigdo at ee.washington.edu) is the release manager for ns-3.3 and is the contact for any release issues.

== The ns-3.3 Release Schedule ==
ns-3 releases are based on date-driven schedules as opposed to feature-driven schedules. We decide on a release date and then the release manager works backward to define windows during which time certain activites related to the release can happen. This has been done for ns-3.3 and the important milestones are:

# September 22 -- ns-3.2 posted;
# September 22 -- ns-3.3 '''''Open phase begins''''';
# October 20 -- Recommended cutoff for new feature submission;
# October 27 -- Deadline for new feature submissions that require design review;
# November 3 -- Approved new feature ready-for-merge deadline;
# November 3 -- Late merge period begins ('''''Merge Week Begins''''');
# November 10 -- Late merge period ends;
# November 10 -- '''''Open phase ends''''';
# November 10 -- '''''Maintenance phase begins''''';
# December 1 -- '''''Maintenance phase ends''''';
# December 1 -- '''''Code freeze phase begins''''';
# December 1 -- ns-3.3-RC1;
# December 4 -- ns-3.3-RC2;
# December 8 -- ns-3.3-RC3;
# December 11 -- ns-3.3-RC4;
# December 17 -- ns-3.3 posted;
# December 17 -- '''''Code freeze phase ends''''';
# December 17 -- ns-3.4 Open phase begins.

As described in the [[Roadmap]] there are three broad sections in the release schedule. During the open phase, people wanting to include a new feature in ns-3.3 should contact craigdo and arrange to have their features merged into ns-3-dev. You will be expected to provide the following:

* A mercurial patch or bundle against the current version of ns-3-dev that contains your proposed feature addition. You need to make sure that I can apply this patch and build and run (debug and optimized as appropriate) all unit and regression tests sucessfully on all of our target machines;
* A summary of the additions you are proposing and an explanation of any changes to existing code that had to be done in order to support your feature (this will be used to genenerate release notes and will be provided to maintainers if a code review is indicated);
* Some kind of unit or regression test that I can use to determine if your feature is actually working at each stage of the integration.

I will take a quick look at your proposed addition and determine if a code review is required. According to the ''book of instructions'' a code review requiring positive acknowledgement by maintainers is indicated if:

* Your proposed feature does not work with all models or on all platforms;
* Your feature changes pre-existing APIs;
* Your feature crosses maintainer boundaries.

Just to be safe, I will probably run a feature submission by at least one maintainer according to the general area of applicability of the feature. For example, if you submit an entirely new device driver model, as a courtesy I will run this submission by the maintainers of the current devices. The maintainers won't have any responsibility to positively ack the submission, but I will take some time to allow a reasonable review.

I will coordinate new feature merges beginning at the start of the open phase (September 22, 2008). The absolute final deadline for feature inclusion in ns-3.3 is the start of the "Late merge period." This is the time during which I merge the code from all of those people who have waited until the last minute and work out any system integration issues that pop up. If you miss the start of the late merge period, or have a feature that is not design-reviewed by the start of the late merge period, well, sorry. You get to wait until the ns-3.4 open period to try again.

The end of the late merge period coincides with the beginning of the maintenance phase. No new features may be added, but the maintainers may check in fixes to bugs; and people with new features that have been accepted and merged may fix bugs in existing features. Please don't try to sneak in more new features or you may have your whole feature set removed at the release manager's discretion. You can ask me if you want to add small, self-contained features, but there are no guarantees that I will okay them.

On December 1st, we are going to enter the code freeze phase. This indicates that we are in the final stages of the release and our primary goal is stability. During the code freeze phase, only P1 bugfixes will be allowed to be checked in. I will begin my daily annoying emails listing all of the priority one bugs that are outstanding. Our ''goal'' will be to reduce the number of P1 bugs to zero before the release of ns-3.3.

'''''I reserve the right to veto (and remove) any new feature addition if it begins to cause problems and looks like it threatens the stability of the release at any time in the release process.'''''

== Candidates for Merge into ns-3.3 ==
As you can see in the [[Roadmap]], we have identified several candidates for inclusion in ns-3.3. As time passes, I will add more status regarding the progress of these new features.

* IPv6 Address Support -- Merged
* Emulation Mode Support -- Merged
* ICMP Support -- Merged
* <s>Build System Refactoring</s> -- Dropped from ns-3.3
* <s>IPv4/Routing Refactoring + Basic IPv6 Support</s> -- Dropped from ns-3-3
* <s>Random Number Generator and RandomVariable Changes</s> -- Dropped from ns-3.3

== IPv6 Address Support ==
=== Status as of November 7, 2008 ===
IPv6 Address Support merged into ns-3-dev.

== Emulation Mode Support ==
=== Status as of November 5, 2008 ===
Emulation Mode Support merged into ns-3-dev.

== ICMP Support ==
=== Status as of October 29, 2008 ===
ICMP Support merged into ns-3-dev.

----

[[User:Craigdo|Craigdo]] 05:52, 18 November 2008 (UTC)

Performance Evaluation and Optimization

2008-03-27T17:05:50Z

SamJansen:

Our goal here is to improve the performance of our simulation core and of our models, both from a cpu and a memory perspective. Since this is a very broad project, interested students will have to start by defining better the scope of what they would like to achieve.

There are lots of components of the simulator which could benefit from careful optimizations:
* some of the core parts, most likely the event scheduler (see the directory src/simulator/)
* some of the models

While it would be nice to work on the models, focusing the core components of the simulator would be much more useful because it will benefit many more users. Some potential projects related to the event scheduler:
* implement and carefully optimize a so-called Calendar Queue (R. Brown. Calendar Queues: A Fast O(1) Priority Queue Implementation for the Simulation Event Set Problem. Communications of the ACM (CACM), volume 31, number 10, pages 1220--1227, October 1988.).
* implement a "Dynamic Calendar Queue" event scheduler. The reference paper is: JongSuk Ahn, SeungHyun Oh, "Dynamic Calendar Queue," ss, p. 20, Thirty-Second Annual Simulation Symposium, 1999.
Both of the above projects will require that the candidate implement a new subclass of the src/simulator/scheduler.h base class. Testing of the new subclass will be done by instantiating the new CalendarQueueScheduler and calling Simulator::SetScheduler before scheduling any event.

We expect, however, all proposals to be based on the following workflow:
* define reference application-level scenarios and establish reference benchmarks for them
* perform cpu and memory profiling of the reference scenarios. Observe hotspots, explain the hotspots.
* propose and implement a solution to decrease the impact of the observed hotspots.
* re-run reference scenarios: if no improvement, hotspot explanation or implementation are most likely buggy. Understand why proposed solution did not improve things. If improvement, go back to profiling.

Typical profiling tools on linux include:
* oprofile
* sysprof
* gprof
* valgrind/kcachegrind
* See also the Google Performance Tools: http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools

A good proposal will most likely integrate results from very early reference scenario definition, profiling, and hotspot explaination. i.e. it should contain a simple rough first iteration of the above workflow.