From tomh at tomh.org Sun Aug 1 15:25:11 2010 From: tomh at tomh.org (Tom Henderson) Date: Sun, 01 Aug 2010 15:25:11 -0700 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: <4C52E722.6030506@kit.edu> References: <4C2D6E09.7040104@tomh.org> <201007301401.37532.boyko@iitp.ru> <4C52A9A4.6070006@kit.edu> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> Message-ID: <4C55F447.7030504@tomh.org> On 7/30/10 7:52 AM, Jens Mittag wrote: > Hi Pavel, > > On 30.07.2010 15:10, Pavel Boyko wrote: >> Hi, Jens, >> >> On Friday, July 30, 2010 02:29:56 pm Jens Mittag wrote: >>> The "energy" model uses this layout, and is currently in ns-3-dev under >>> src/contrib/energy/ . We used the same layout for our upcoming physical >>> layer model contribution. >> >> Thank you! Unfortunately that model does not include examples, so >> wscript is >> pretty trivial. M.b. you already have an enhanced version of module >> wscript >> including example rules? > > Find attached the wscript file that we use. What you are looking for I > guess is the following: > > def build(bld): > ... > obj = bld.create_ns3_program('physim-1sender-only-pathloss', > ['core', 'simulator', 'mobility', 'wifi', 'physim-wifi']) > obj.source = 'example/physim-1sender-only-pathloss.cc' > > which compiles the example under > 'example/physim-1sender-only-pathloss.cc' under the alias > 'physim-1sender-only-pathloss', such that you can do > > ./waf --run physim-1sender-only-pathloss > > to run it. Thanks for the instructions; we did not merge the underwater acoustic device according to this new structure because we thought it would require some build system modifications (to incorporate the examples properly), but it seems to be straightforward. > > Currently, I am trying to figure out how to add documentation to the > main manual and how to add an additional module description in the > doxygen generated html documentation. > To add a chapter to the main manual, create the new texi file and include it in the appropriate place in manual.texi. To add an additional module description in the Doxygen, if it is a top-level module, see how groups are defined in the file doc/modules. If you want to add a subgroup under an existing group, there are several examples of this in the current code. A good example is in src/routing/aodv/aodv.h, where a header file consists only of Doxygen module documentation. AODV defines its own group and associates with the routing group as follows: /** * \ingroup routing * \defgroup aodv AODV * * ... - Tom From tomh at tomh.org Sun Aug 1 20:54:56 2010 From: tomh at tomh.org (Tom Henderson) Date: Sun, 01 Aug 2010 20:54:56 -0700 Subject: [Ns-developers] ns-3.9 bug fixing week Message-ID: <4C564190.4010804@tomh.org> I went through the tracker and built this list of issues that would be nice to try to close out this week: http://www.nsnam.org/wiki/index.php/Ns-3.9#Bug_fixing_list Many of these are in a "patch waiting" state or else shouldn't be too hard to close out. I've spoken to various maintainers about most of these, and Josh and I will be checking in this week on the status. We haven't made much of a dent in the missing Doxygen backlog, and some of the maintainers have told us that they cannot possibly attend to all of these in the near term, so I would like to propose that we not hold up the release for this. The schedule for trying to freeze the code is by Friday, Aug. 6, and we plan to make a first release candidate next Monday Aug. 9, so please let us know if you think that fixing any of these is not likely to happen by the end of the week. Thanks, Tom and Josh From boyko at iitp.ru Sun Aug 1 22:38:18 2010 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 2 Aug 2010 09:38:18 +0400 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: <4C52E722.6030506@kit.edu> References: <4C2D6E09.7040104@tomh.org> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> Message-ID: <201008020938.19014.boyko@iitp.ru> Hi, Jens, On Friday, July 30, 2010 06:52:18 pm Jens Mittag wrote: > Find attached the wscript file that we use. What you are looking for I > guess is the following: > > def build(bld): > ... > obj = bld.create_ns3_program('physim-1sender-only-pathloss', > ['core', 'simulator', 'mobility', 'wifi', 'physim-wifi']) > obj.source = 'example/physim-1sender-only-pathloss.cc' Exactly, thank you. The final stroke was to account for ./waf --disable- examples option checking bld.env['ENABLE_EXAMPLES'] variable. I attach my current stub for wscript. Pavel -------------- next part -------------- ## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*- def build(bld): module_name = 'my-module' # TODO: substitude by your module name module_deps = ['node', 'internet-stack'] # TODO: keep correct deps. # Library module = bld.create_ns3_module(module_name, module_deps) module.includes = '.' module.source = [ # TODO: list all .cc files here ] # Headers headers = bld.new_task_gen('ns3header') headers.module = module_name headers.source = [ # TODO: list all exported headers here ] # Examples if (bld.env['ENABLE_EXAMPLES']): example_deps = [module_name, 'node', 'wifi', 'internet-stack'] # TODO: keep correct deps. obj = bld.create_ns3_program('my-example', example_deps) obj.source = 'example/my-example.cc' # build other examples here ... From mathieu.lacage at sophia.inria.fr Mon Aug 2 09:43:15 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 02 Aug 2010 18:43:15 +0200 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: <4C55F447.7030504@tomh.org> References: <4C2D6E09.7040104@tomh.org> <201007301401.37532.boyko@iitp.ru> <4C52A9A4.6070006@kit.edu> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> <4C55F447.7030504@tomh.org> Message-ID: <1280767395.3345.4.camel@diese.inria.fr> On Sun, 2010-08-01 at 15:25 -0700, Tom Henderson wrote: > > Currently, I am trying to figure out how to add documentation to the > > main manual and how to add an additional module description in the > > doxygen generated html documentation. > > > > To add a chapter to the main manual, create the new texi file and > include it in the appropriate place in manual.texi. To add an I think that the question was more along the lines of whether or not it was possible to define a new section in the manual without having to hack the main manual documentation. i.e., could we put the model .texi file in model/doc and then, make the toplevel/doc/manual.texi file magically detect that other file and include it ? That would be cool. Mathieu From alina.quereilhac at sophia.inria.fr Mon Aug 2 10:55:30 2010 From: alina.quereilhac at sophia.inria.fr (Alina Quereilhac) Date: Mon, 02 Aug 2010 19:55:30 +0200 Subject: [Ns-developers] GSOC - Code review request Message-ID: <4C570692.4090507@sophia.inria.fr> Hello everybody, As some of you might know the end of the GSoC 2010 program is near, and this is why feedback at this point can be very useful to help the ns-3 students projects to succeed. For those that can find some time to review the code here are the links to the code review site for each project: *UAN Framework: AUV simulator and power management layer*: - Code Review: http://codereview.appspot.com/1875047 - Wiki page : http://www.nsnam.org/wiki/index.php/GSOC2010UANFramework *ns-3-OpenFlow * - Code Review: http://codereview.appspot.com/1872049 - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010OpenFlow *MAC and PHY models for LTE* - Code Review: http://codereview.appspot.com/1866042 - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010MACPHYforLTE *NS-3 Click Modular Router Integration * - Code Review: http://codereview.appspot.com/1690056 - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010Click Thanks, Alina. From tomh at tomh.org Mon Aug 2 11:35:58 2010 From: tomh at tomh.org (Tom Henderson) Date: Mon, 02 Aug 2010 12:35:58 -0600 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: <1280767395.3345.4.camel@diese.inria.fr> References: <4C2D6E09.7040104@tomh.org> <201007301401.37532.boyko@iitp.ru> <4C52A9A4.6070006@kit.edu> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> <4C55F447.7030504@tomh.org> <1280767395.3345.4.camel@diese.inria.fr> Message-ID: <78c757318de6c0273d4ea20d15b72e33@tomh.org> On Mon, 02 Aug 2010 18:43:15 +0200, Mathieu Lacage wrote: > On Sun, 2010-08-01 at 15:25 -0700, Tom Henderson wrote: > >> > Currently, I am trying to figure out how to add documentation to the >> > main manual and how to add an additional module description in the >> > doxygen generated html documentation. >> > >> >> To add a chapter to the main manual, create the new texi file and >> include it in the appropriate place in manual.texi. To add an > > I think that the question was more along the lines of whether or not it > was possible to define a new section in the manual without having to > hack the main manual documentation. i.e., could we put the model .texi > file in model/doc and then, make the toplevel/doc/manual.texi file > magically detect that other file and include it ? That would be cool. > OK, I wasn't thinking of conditionally including such documentation in the manual (instead, I was thinking that the documentation would just be part of the model library even if a package manager was used to add the code to the ns-3 build). For now, I would suggest to put the new texi file in the model/doc/ subdirectory if you want, and just edit the manual.texi file to pull in the file from the relative path (if that works; haven't tested it). Once we experiment with making these new models into full blown ns-3 packages we can look at auto-generating the master texi file. - Tom From jpelkey at gatech.edu Tue Aug 3 10:50:18 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Tue, 3 Aug 2010 13:50:18 -0400 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: <78c757318de6c0273d4ea20d15b72e33@tomh.org> References: <4C2D6E09.7040104@tomh.org> <201007301401.37532.boyko@iitp.ru> <4C52A9A4.6070006@kit.edu> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> <4C55F447.7030504@tomh.org> <1280767395.3345.4.camel@diese.inria.fr> <78c757318de6c0273d4ea20d15b72e33@tomh.org> Message-ID: Regarding this new structure: > uan/model > uan/doc > uan/helper > uan/test > uan/example How will the helper module work here? Including ns3/helper-module won't be sufficient, because we've moved some helper files into uan/helper (for example). Another really (really) minor point: Should it be uan/examples? I noticed for most of the thread it was mentioned as singular. I like the plural version better. -- Josh On Mon, Aug 2, 2010 at 2:35 PM, Tom Henderson wrote: > On Mon, 02 Aug 2010 18:43:15 +0200, Mathieu Lacage > wrote: >> On Sun, 2010-08-01 at 15:25 -0700, Tom Henderson wrote: >> >>> ?> Currently, I am trying to figure out how to add documentation to the >>> ?> main manual and how to add an additional module description in the >>> ?> doxygen generated html documentation. >>> ?> >>> >>> To add a chapter to the main manual, create the new texi file and >>> include it in the appropriate place in manual.texi. ?To add an >> >> I think that the question was more along the lines of whether or not it >> was possible to define a new section in the manual without having to >> hack the main manual documentation. i.e., could we put the model .texi >> file in model/doc and then, make the toplevel/doc/manual.texi file >> magically detect that other file and include it ? That would be cool. >> > > OK, I wasn't thinking of conditionally including such documentation in the > manual (instead, I was thinking that the documentation would just be part > of the model library even if a package manager was used to add the code to > the ns-3 build). ?For now, I would suggest to put the new texi file in the > model/doc/ subdirectory if you want, and just edit the manual.texi file to > pull in the file from the relative path (if that works; haven't tested it). > Once we experiment with making these new models into full blown ns-3 > packages we can look at auto-generating the master texi file. > > - Tom > From jpelkey at gatech.edu Tue Aug 3 11:07:21 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Tue, 3 Aug 2010 14:07:21 -0400 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: References: <4C2D6E09.7040104@tomh.org> <201007301401.37532.boyko@iitp.ru> <4C52A9A4.6070006@kit.edu> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> <4C55F447.7030504@tomh.org> <1280767395.3345.4.camel@diese.inria.fr> <78c757318de6c0273d4ea20d15b72e33@tomh.org> Message-ID: > How will the helper module work here? ?Including ns3/helper-module > won't be sufficient, because we've moved some helper files into > uan/helper (for example). ^^ Disregard this one. Including uan-module of course. -- Josh On Tue, Aug 3, 2010 at 1:50 PM, Josh Pelkey wrote: > Regarding this new structure: > >> uan/model >> uan/doc >> uan/helper >> uan/test >> uan/example > > How will the helper module work here? ?Including ns3/helper-module > won't be sufficient, because we've moved some helper files into > uan/helper (for example). > > Another really (really) minor point: Should it be uan/examples? ?I > noticed for most of the thread it was mentioned as singular. ?I like > the plural version better. > > -- > Josh > > On Mon, Aug 2, 2010 at 2:35 PM, Tom Henderson wrote: >> On Mon, 02 Aug 2010 18:43:15 +0200, Mathieu Lacage >> wrote: >>> On Sun, 2010-08-01 at 15:25 -0700, Tom Henderson wrote: >>> >>>> ?> Currently, I am trying to figure out how to add documentation to the >>>> ?> main manual and how to add an additional module description in the >>>> ?> doxygen generated html documentation. >>>> ?> >>>> >>>> To add a chapter to the main manual, create the new texi file and >>>> include it in the appropriate place in manual.texi. ?To add an >>> >>> I think that the question was more along the lines of whether or not it >>> was possible to define a new section in the manual without having to >>> hack the main manual documentation. i.e., could we put the model .texi >>> file in model/doc and then, make the toplevel/doc/manual.texi file >>> magically detect that other file and include it ? That would be cool. >>> >> >> OK, I wasn't thinking of conditionally including such documentation in the >> manual (instead, I was thinking that the documentation would just be part >> of the model library even if a package manager was used to add the code to >> the ns-3 build). ?For now, I would suggest to put the new texi file in the >> model/doc/ subdirectory if you want, and just edit the manual.texi file to >> pull in the file from the relative path (if that works; haven't tested it). >> Once we experiment with making these new models into full blown ns-3 >> packages we can look at auto-generating the master texi file. >> >> - Tom >> > From jpelkey at gatech.edu Tue Aug 3 11:52:15 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Tue, 3 Aug 2010 14:52:15 -0400 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: <201008020938.19014.boyko@iitp.ru> References: <4C2D6E09.7040104@tomh.org> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> <201008020938.19014.boyko@iitp.ru> Message-ID: I think it might be better to have a separate wscript in the example directory of the module. This way you can do ./waf --run path/to/example, along with just typing the example name. If you don't use a separate wscript in the example directory, you can't specify the correct full path to the example (it ends up expecting the path, minus the example directory). So I would modify the module's root wscript to build the example subdirectory. Something like this: ==================== src/devices/uan/wscript ==================== same as before with this at the bottom: ... if (bld.env['ENABLE_EXAMPLES']): bld.add_subdirs('example') ==================== src/devices/uan/example/wscript ==================== def build(bld): obj = bld.create_ns3_program('uan-cw-example', ['core', 'simulator', 'mobility', 'uan']) obj.source = 'uan-cw-example.cc' obj = bld.create_ns3_program('uan-rc-example', ['core', 'simulator', 'mobility', 'uan']) obj.source = 'uan-rc-example.cc' -- Josh On Mon, Aug 2, 2010 at 1:38 AM, Pavel Boyko wrote: > ?Hi, Jens, > > On Friday, July 30, 2010 06:52:18 pm Jens Mittag wrote: >> Find attached the wscript file that we use. What you are looking for I >> guess is the following: >> >> ? ?def build(bld): >> ? ? ? ... >> ? ? ? obj = bld.create_ns3_program('physim-1sender-only-pathloss', >> ? ? ? ['core', 'simulator', 'mobility', 'wifi', 'physim-wifi']) >> ? ? ? obj.source = 'example/physim-1sender-only-pathloss.cc' > > ?Exactly, thank you. The final stroke was to account for ./waf --disable- > examples option checking bld.env['ENABLE_EXAMPLES'] variable. I attach my > current stub for wscript. > > ?Pavel > From naimorai at gmail.com Tue Aug 3 17:24:54 2010 From: naimorai at gmail.com (Blake Hurd) Date: Tue, 3 Aug 2010 20:24:54 -0400 Subject: [Ns-developers] ns-3-openflow Code Review Message-ID: Hello everyone! I request that the ns-3-openflow code be reviewed at http://codereview.appspot.com/1872049/show, for anyone who has the opportunity to take a look at it. Your feedback would be much appreciated! Let me know if you have any questions. Links: http://codereview.appspot.com/1872049/show ns-3-openflow Code Review http://www.nsnam.org/wiki/index.php/GSOC2010OpenFlow ns-3-openflow Project Wiki http://code.nsnam.org/bhurd/ns-3-openflow ns-3-openflow Repository Blake From tomh at tomh.org Tue Aug 3 21:12:47 2010 From: tomh at tomh.org (Tom Henderson) Date: Tue, 03 Aug 2010 21:12:47 -0700 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: References: <4C2D6E09.7040104@tomh.org> <201007301401.37532.boyko@iitp.ru> <4C52A9A4.6070006@kit.edu> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> <4C55F447.7030504@tomh.org> <1280767395.3345.4.camel@diese.inria.fr> <78c757318de6c0273d4ea20d15b72e33@tomh.org> Message-ID: <4C58E8BF.2010601@tomh.org> On 8/3/10 10:50 AM, Josh Pelkey wrote: > Regarding this new structure: > >> uan/model >> uan/doc >> uan/helper >> uan/test >> uan/example > > How will the helper module work here? Including ns3/helper-module > won't be sufficient, because we've moved some helper files into > uan/helper (for example). > > Another really (really) minor point: Should it be uan/examples? I > noticed for most of the thread it was mentioned as singular. I like > the plural version better. I'm pretty neutral about this but Pavel previously suggested to make all of these singular so it seems to make sense from consistency standpoint. - Tom From andrea.sacco85 at gmail.com Wed Aug 4 02:01:32 2010 From: andrea.sacco85 at gmail.com (Andrea Sacco) Date: Wed, 4 Aug 2010 11:01:32 +0200 Subject: [Ns-developers] UAN Framework weekly update Message-ID: Hello everybody, I'm quite at the end of the implementation phase of the project. I'm currently coding a Li-Ion battery model. Regarding that, I've found a little bit restrictive the interface purposed from the energy layer authors. In particular the DecreaseEnergy method only take as parameter the Joule to decrement from the total energy stored in the battery. This can be useful for "basic" battery model but, implementing the Li-Ion model, I've found the information given to the model are too few. So I've modified the interface of the model putting into the DecreaseEnergy methods not the Joule value but the duration plus power values. This doesn't change anything into the functioning of the model but give some more information instead that compressing them into a "laconic" Joule value. At the end of the day I should be done with the model modification and I will upload the modification to the codereview project. Moreover, I'm finishing the examples for the UAN Framework, ultimating a comprehensive example where a seaglider AUV submerge to 1000m an then emerge up to the surface and, during the travel, it will sends generic aloha packets to a surface gateway station. This will give an overall idea of everything, the new mobility model, the energy consumption management, the energy source, etc. When I'm done with the code, I will create a new codereview issue containing *all* the UAN Framework modifications. I'm going to heavily update the wiki and missing documentation starting from tomorrow. Comments are welcome. Regards, Andrea From sunnmy at iitp.ru Wed Aug 4 05:30:10 2010 From: sunnmy at iitp.ru (Elena Buchatskaya) Date: Wed, 4 Aug 2010 16:30:10 +0400 Subject: [Ns-developers] Importance of processing delays accounting. Message-ID: Whether models are designed with the objective of measuring performance or?analyzing behavior, it is often important to accurately model delays associated?with key actions to obtain representative results.?Common performance metrics,?such as links resource utilization and end-to-end?delay of messages, are largely a function of various delays. Behavior of the system is also tied to delays, because?timing of communications between components may critically affect the order in which actions are taken, and even which ones are taken. So now all re-transmissions of broadcast packets ?occur simultaneously in the ns-3 simulator.?Large number of exactly simultaneous transmissions leads to significantly overestimated collision probability and even to wrong protocol operation. For example, this is the place for RREQ and RERR (in the case where there is more than one precursor) messages when using AODV routing and leads to poor protocol performance. One solution of this problem is jittering periodic broadcast transmissions (as already done for AODV Hello messages). Also ?applying randomness was proposed for all packets sent in response to the reception of a broadcast packet. For example, Kevin Peters manually added randomness in AODV RERR transmissions for more correct AODV simulation. However, it are a significant protocol improvements and make the implementation not compliant with the RFC. Note that this is not only AODV issue, but apply to all protocols which perform broadcast packet re-transmissions and/or periodically send broadcast packets. Generally speaking none of the ns-3 models?account for processing delays. The necessity of adding random delay in Wi-Fi module has already been discussed (see bug 912), but I think the more general solution is desirable. We need to model ?non-deterministic processing delays at various OSI layers. I propose to add a adjustable delay: 1) between the IP ?and Wi-Fi MAC layers to accommodate the processing time at the IP layer. This is the time needed to to look up routes in a routing table, to recompute the checksum of the IP header as well as the time needed to prepare the packet for further transmission. 2) between MAC and PHY layers to accommodate the processing time at the MAC layer and time required to copy packet for kernel space to the device. It is also necessary to select meaningful default value of delays and their distributions. Note that some default values for the Wi-Fi module delay are given in bug 912 description. I will appreciate your comments on this proposal. -- Best regards, Elena Buchatskaya From elias.weingaertner at cs.rwth-aachen.de Thu Aug 5 01:24:45 2010 From: elias.weingaertner at cs.rwth-aachen.de (=?ISO-8859-15?Q?Elias_Weing=E4rtner?=) Date: Thu, 05 Aug 2010 10:24:45 +0200 Subject: [Ns-developers] BitTorrent? Message-ID: <4C5A754D.70108@cs.rwth-aachen.de> Hey, we're about to implement a BitTorrent client for ns-3. Just to double check: Is somebody else already doing that? There's nothing listed on the Wiki. -- Elias -- Dipl.-Inf. Elias Weingaertner Research Assistant Distributed Systems Group RWTH Aachen Germany http://ds.informatik.rwth-aachen.de/members/weingaertner From andrea.sacco85 at gmail.com Thu Aug 5 03:51:02 2010 From: andrea.sacco85 at gmail.com (Andrea Sacco) Date: Thu, 5 Aug 2010 12:51:02 +0200 Subject: [Ns-developers] GSOC - Code review request Message-ID: Hello everybody, I would like to request an formal review of my GSoC project's code to merge it into main ns-3-dev tree. The new codereview issue is http://codereview.appspot.com/1743057 This review contains all the changes I've made to the ns-3-dev tree with my project. I've merged also the changes from the two previous codereview issues so, please consider this one as the current one. As from the project's deliverables the review contains: - Two AUV mobility models (glider-mobility-model and remus-mobility-model) - An WHOI modem energy model (micro-modem-energy-model) - Helper classes for AUV simulator (auv-mobility-helper, auv-glider-helper and auv-remus-helper) - Test case for mobility models (auv-mobility-test) - Example scripts (auv-mobility, auv-energy-model, li-ion-energy-source and uan-energy-auv) It contains also some extras: - A Li-Ion energy source model (li-ion-energy-source) - Two AUV energy models (glider-energy-model and remus-energy-model) Thanks for your time. Best Regards, Andrea 2010/8/3 > Hello everybody, > > As some of you might know the end of the GSoC 2010 program is near, and > this is why feedback at this point can be very useful to help the ns-3 > students projects to succeed. > For those that can find some time to review the code here are the links > to the code review site for each project: > > *UAN Framework: AUV simulator and power management layer*: > - Code Review: http://codereview.appspot.com/1875047 > - Wiki page : http://www.nsnam.org/wiki/index.php/GSOC2010UANFramework > From g.piro at poliba.it Sat Aug 7 02:47:26 2010 From: g.piro at poliba.it (Giuseppe Piro) Date: Sat, 7 Aug 2010 11:47:26 +0200 Subject: [Ns-developers] GSoC - LTE module update Message-ID: Dear all, I finished the implementation of all the functionality proposed for GSoC 2010. Several examples (see files in example/lte folder) and test suites (see test suites in src/device/lte/ or run ./test.phy) have been developed to show the effectiveness of the implemented module. The follows new aspects have been addressed: - fixed all the comments of the Nicola's review (including modifications on spectrum model and interaction among MAC, RRC and RLC); - fixed coding style with the check-style.py tool - improved the doxygen documentation The revised code has been uploaded on codereview: http://codereview.appspot.com/1869054/show I ask officially to all developers to review my code. Best Regards, Giuseppe Piro From tomh at tomh.org Sat Aug 7 10:27:46 2010 From: tomh at tomh.org (Tom Henderson) Date: Sat, 07 Aug 2010 10:27:46 -0700 Subject: [Ns-developers] ns-3.9 bug fixing week In-Reply-To: <4C564190.4010804@tomh.org> References: <4C564190.4010804@tomh.org> Message-ID: <4C5D9792.30505@tomh.org> On 8/1/10 8:54 PM, Tom Henderson wrote: > I went through the tracker and built this list of issues that would be > nice to try to close out this week: > http://www.nsnam.org/wiki/index.php/Ns-3.9#Bug_fixing_list We've made a lot of progress on the bug list, and for the ones not crossed off yet, there are solutions being actively worked for many of them. I think we can hold open the bug fixing window until Monday for these pending checkins. We still are aiming for an initial release candidate later on Monday. After that time, we'll list open issues (for which we'll still accept a patch next week) on the wiki, and all checkins will need to go through Josh. Recall that we merged the energy model to src/contrib for this release. There is some discussion between the maintainers of this model and Andrea about trying to line this API up better for the UAN GSOC project that is nearing completion: http://groups.google.com/group/ns-3-reviews/browse_thread/thread/45a18f80f1e4507e We are also reviewing the above patch or determining whether it should wait until post-release; if anyone has opinions on this, please let us know. - Tom From tomh at tomh.org Sun Aug 8 20:33:56 2010 From: tomh at tomh.org (Tom Henderson) Date: Sun, 08 Aug 2010 20:33:56 -0700 Subject: [Ns-developers] Importance of processing delays accounting. In-Reply-To: References: Message-ID: <4C5F7724.1010602@tomh.org> On 8/4/10 5:30 AM, Elena Buchatskaya wrote: > I propose to add a adjustable delay: > 1) between the IP and Wi-Fi MAC layers to accommodate the processing > time at the IP layer. This is the time needed to to look up routes in > a routing table, to recompute the checksum of the IP header as well as > the time needed to prepare the packet for further transmission. > 2) between MAC and PHY layers to accommodate the processing time at > the MAC layer and time required to copy packet for kernel space to the > device. Elena, I agree that additions such as you suggest should be considered; I added bug 977 to the tracker for future discussions and patches. We already have bug 912 open for WiFi-specific ones. - Tom From alina.quereilhac at sophia.inria.fr Mon Aug 9 07:10:57 2010 From: alina.quereilhac at sophia.inria.fr (Alina Quereilhac) Date: Mon, 09 Aug 2010 16:10:57 +0200 Subject: [Ns-developers] GSOC - Request for code reviews - 'pencils down' next week Message-ID: <4C600C71.5010009@sophia.inria.fr> Hello everybody, The end of GSoC 2010 program is in one week from now (August 16th) and it would be really helpful to get some code reviews from the community in the next days. Please consider taking a look at the projects source code for reviewing: UAN Framework: AUV simulator and power management layer - Andrea Sacco - Code Review: http://codereview.appspot.com/1743057 - Wiki page : http://www.nsnam.org/wiki/index.php/GSOC2010UANFramework ns-3-OpenFlow - Blake Hurd - Code Review: http://codereview.appspot.com/1872049 - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010OpenFlow * MAC and PHY models for LTE - Giuseppe Piro - Code Review: http://codereview.appspot.com/1869054 - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010MACPHYforLTE NS-3 Click Modular Router Integration - Lalith Suresh Puthalath - Code Review: http://codereview.appspot.com/1690056 - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010Click Your feedback would be most appreciated. Thank you, Alina. From jens.mittag at kit.edu Mon Aug 9 08:26:19 2010 From: jens.mittag at kit.edu (Jens Mittag) Date: Mon, 09 Aug 2010 17:26:19 +0200 Subject: [Ns-developers] ns-3.9 release update In-Reply-To: <1280767395.3345.4.camel@diese.inria.fr> References: <4C2D6E09.7040104@tomh.org> <201007301401.37532.boyko@iitp.ru> <4C52A9A4.6070006@kit.edu> <201007301710.22225.boyko@iitp.ru> <4C52E722.6030506@kit.edu> <4C55F447.7030504@tomh.org> <1280767395.3345.4.camel@diese.inria.fr> Message-ID: <4C601E1B.5080203@kit.edu> Hi, On 02.08.2010 18:43, Mathieu Lacage wrote: > On Sun, 2010-08-01 at 15:25 -0700, Tom Henderson wrote: > >> > Currently, I am trying to figure out how to add documentation to the >> > main manual and how to add an additional module description in the >> > doxygen generated html documentation. >> > >> >> To add a chapter to the main manual, create the new texi file and >> include it in the appropriate place in manual.texi. To add an > > I think that the question was more along the lines of whether or not it > was possible to define a new section in the manual without having to > hack the main manual documentation. i.e., could we put the model .texi > file in model/doc and then, make the toplevel/doc/manual.texi file > magically detect that other file and include it ? That would be cool. Exactly. However, apart from that we see the need to restructure the main manual and make the manual more modular. For instance, the WiFi section currently covers MAC, PHY and Channel, without having a really strict separation. So in our case, where should we include our additional Physical Layer description? And if you think further, e.g. for other model contributions which will be modules, how do we integrate such documentation in the manual? Where should they be inserted? To avoid this problem, we will now provide a separate overall documentation as PDF inside the doc/ directory, which is not built via LaTeX. In other frameworks or systems (e.g. the Typo3 CMS Framework), a similar approach is used and we think this should be done as well in NS-3. The main NS-3 manual should then only cover the officially supported stuff. Jens -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Zirkel 1, 76131 Karlsruhe, Germany Building 20.20, Room 356.1 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5833 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20100809/349ee5c7/smime.bin From jpelkey at gatech.edu Mon Aug 9 18:25:13 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Mon, 9 Aug 2010 21:25:13 -0400 Subject: [Ns-developers] ns-3.9 release updates Message-ID: Hi all, We are working hard to try and get ns-3-dev in a stable state for the first RC tomorrow. Tom is planning on checking in a few more fixes (bug 911, waypoint stuff, etc) later this evening. If you think you need something in ns-3-dev, please go through me first. We aren't officially freezing ns-3-dev just yet, but we would like to keep it as stable as possible while we make these release candidates. I hope to get RC1 out tomorrow morning (EDT), and I will post again when this happens. *** PLEASE *** do not check in to ns-3-dev without sending me an email first and confirming. Thanks. -- Josh From bikovevg at iitp.ru Tue Aug 10 04:32:27 2010 From: bikovevg at iitp.ru (Evgeni Bikov) Date: Tue, 10 Aug 2010 15:32:27 +0400 Subject: [Ns-developers] [ns-3-simu] random, if_nametoindex, netlink socket patches Message-ID: <1281439947.20238.5.camel@evgeni-ws> Hi, Mathieu. I'd like to propose three patches for ns3simu. 01_random.patch: Solves the problem in case when several processes sequentially seed with srand and then using the same system random stream. My fix consist in adding RandomVariable for each executing process. Simple unit test added. 02_nametoindex.patch: Adds if_nametoindex() implementation. Helps executing process (application) to identify ns3 interfaces correctly. Executing processes are supposed to know names of interfaces such as ath0 or lo. Interfaces are supposed to be named inside ns3 by user. 03_netlink.patch: Adds fixes with netlink route message handling. Simple fix with netlink message family determining. Different priority order applied. Changes while processing netlink message of type ADD. NETLINK_MSG_F_CREATE and NETLINK_MSG_F_REPLACE are processing correctly. Works fine with indexes acquired by if_nametoindex(). Case when no index is available is handling with Hajime Tazaki code from http://code.nsnam.org/thehajime/ns-3-simu-quagga Thanks in advance Evgeni Bikov -------------- next part -------------- A non-text attachment was scrubbed... Name: 02_nametoindex.patch Type: text/x-patch Size: 3136 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20100810/ea6275a1/02_nametoindex.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 01_random.patch Type: text/x-patch Size: 6171 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20100810/ea6275a1/01_random.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 03_netlink.patch Type: text/x-patch Size: 11882 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20100810/ea6275a1/03_netlink.bin From mathieu.lacage at sophia.inria.fr Tue Aug 10 05:37:34 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 10 Aug 2010 14:37:34 +0200 Subject: [Ns-developers] [ns-3-simu] random, if_nametoindex, netlink socket patches In-Reply-To: <1281439947.20238.5.camel@evgeni-ws> References: <1281439947.20238.5.camel@evgeni-ws> Message-ID: <1281443854.5971.5.camel@diese.inria.fr> On Tue, 2010-08-10 at 15:32 +0400, Evgeni Bikov wrote: > I'd like to propose three patches for ns3simu. pushed, thanks. Mathieu From jpelkey at gatech.edu Tue Aug 10 14:08:09 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Tue, 10 Aug 2010 17:08:09 -0400 Subject: [Ns-developers] ns-3 valgrind issue Message-ID: Hi all, Does anyone know why I am getting valgrind failures in test.py, even though I know that most of these tests pass? Perhaps it is my version of valgrind (3.5.0)? This is what it is showing for most test cases: ==7121== 120 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==7121== at 0x4C25153: malloc (vg_replace_malloc.c:195) ==7121== by 0xA4F5F18: getdelim (iogetdelim.c:68) ==7121== by 0xC602322: ??? (in /lib/libselinux.so.1) ==7121== by 0xC60A8D5: ??? (in /lib/libselinux.so.1) ==7121== by 0xC5FA2AA: ??? (in /lib/libselinux.so.1) ==7121== by 0x7FF0003B7: ??? ==7121== by 0x65722F79656B6C64: ??? ==7121== by 0x332D736E2F736F6F: ??? ==7121== by 0x6E6F6E696C6C612C: ??? ==7121== by 0x642D332D736E2F64: ??? ==7121== by 0x646C6975622F7664: ??? ==7121== by 0x752F67756265642E: ??? ==7121== ==7121== LEAK SUMMARY: ==7121== definitely lost: 120 bytes in 1 blocks ==7121== indirectly lost: 0 bytes in 0 blocks ==7121== possibly lost: 0 bytes in 0 blocks ==7121== still reachable: 0 bytes in 0 blocks ==7121== suppressed: 0 bytes in 0 blocks Thanks for any help. -- Josh Pelkey From lentracy at u.washington.edu Tue Aug 10 15:12:35 2010 From: lentracy at u.washington.edu (Leonard Tracy) Date: Tue, 10 Aug 2010 15:12:35 -0700 Subject: [Ns-developers] ns-3 valgrind issue In-Reply-To: References: Message-ID: I got the same errors after install of newer Ubuntu awhile back. I'm interested to know the source as well :). I think I saw this lost 120 bytes for every test I ran. Leonard On Tue, Aug 10, 2010 at 2:08 PM, Josh Pelkey wrote: > Hi all, > > Does anyone know why I am getting valgrind failures in test.py, even > though I know that most of these tests pass? Perhaps it is my version > of valgrind (3.5.0)? This is what it is showing for most test cases: > > ==7121== 120 bytes in 1 blocks are definitely lost in loss record 1 of 1 > ==7121== at 0x4C25153: malloc (vg_replace_malloc.c:195) > ==7121== by 0xA4F5F18: getdelim (iogetdelim.c:68) > ==7121== by 0xC602322: ??? (in /lib/libselinux.so.1) > ==7121== by 0xC60A8D5: ??? (in /lib/libselinux.so.1) > ==7121== by 0xC5FA2AA: ??? (in /lib/libselinux.so.1) > ==7121== by 0x7FF0003B7: ??? > ==7121== by 0x65722F79656B6C64: ??? > ==7121== by 0x332D736E2F736F6F: ??? > ==7121== by 0x6E6F6E696C6C612C: ??? > ==7121== by 0x642D332D736E2F64: ??? > ==7121== by 0x646C6975622F7664: ??? > ==7121== by 0x752F67756265642E: ??? > ==7121== > ==7121== LEAK SUMMARY: > ==7121== definitely lost: 120 bytes in 1 blocks > ==7121== indirectly lost: 0 bytes in 0 blocks > ==7121== possibly lost: 0 bytes in 0 blocks > ==7121== still reachable: 0 bytes in 0 blocks > ==7121== suppressed: 0 bytes in 0 blocks > > Thanks for any help. > > -- > Josh Pelkey > From tomh at tomh.org Tue Aug 10 21:16:27 2010 From: tomh at tomh.org (Tom Henderson) Date: Tue, 10 Aug 2010 21:16:27 -0700 Subject: [Ns-developers] Importance of processing delays accounting. In-Reply-To: References: <4C5F7724.1010602@tomh.org> Message-ID: <4C62241B.3000104@tomh.org> On 8/9/10 3:35 AM, Stein Kristiansen wrote: > Hello, > > So, I guess my main question is whether you know of anyone which was > planning to do the work Elena proposed? Elsewise, this would naturally > be something I would need to do in my work, and I was thinking of > proposing something related to our masters students. Hi Stein, I'm hoping that you can contribute in this area. It would be nice to have a framework for delay profiles with a suitable default but ability to add different profiles. Some related work that I'm aware of is the black-box router profiler work by Chertov et al. a few years ago: Roman Chertov, Sonia Fahmy, and Ness B. Shroff, "A Black-box Router Profiler," In Proceedings of the IEEE Global Internet Symposium, May 2007. - Tom From jpelkey at gatech.edu Tue Aug 10 21:26:53 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Wed, 11 Aug 2010 00:26:53 -0400 Subject: [Ns-developers] ns-3.9 release updates In-Reply-To: References: Message-ID: Hello again, Well this morning quickly turned in to the afternoon and then the evening without managing to get an RC ready. I ran in to a couple of issues, but thankfully most of the builds are green now. I plan to get RC1 out tomorrow, but there will still be some issues that need to be fixed: 1) Bug 980 NSC compilation fails on 32-bit machines http://www.nsnam.org/bugzilla/show_bug.cgi?id=980 Note: This isn't just an NSC issue. Although NSC is failing (and that is being worked separately), ns-3 isn't handling this case, and it is still enabling nsc when it shouldn't. 2) Bug 976 - wifi-wired-bridging regression test fails because of rounding errors in mobility model http://www.nsnam.org/bugzilla/show_bug.cgi?id=976 I removed the .mob trace from the regression in order to get this to pass. This still needs a fix. 3) Bug 953 - WiMAX channel scanning overflow http://www.nsnam.org/bugzilla/show_bug.cgi?id=953 Flavio checked in a change, but I had to revert a part of it to get tests to pass. From what I've heard from Flavio, this should be ok, but I reopened this bug anyway. Will wait for another ack to close this one again. Here is what I changed: http://code.nsnam.org/ns-3-dev/rev/d4a75eecfa7d I'm sure I am forgetting one or two more things, and I'll post again when I remember. -- Josh On Mon, Aug 9, 2010 at 9:25 PM, Josh Pelkey wrote: > Hi all, > > We are working hard to try and get ns-3-dev in a stable state for the > first RC tomorrow. ?Tom is planning on checking in a few more fixes > (bug 911, waypoint stuff, etc) later this evening. ?If you think you > need something in ns-3-dev, please go through me first. ?We aren't > officially freezing ns-3-dev just yet, but we would like to keep it as > stable as possible while we make these release candidates. > > I hope to get RC1 out tomorrow morning (EDT), and I will post again > when this happens. > > *** PLEASE *** do not check in to ns-3-dev without sending me an email > first and confirming. ?Thanks. > > -- > Josh > From alina.quereilhac at sophia.inria.fr Wed Aug 11 00:27:32 2010 From: alina.quereilhac at sophia.inria.fr (Alina Quereilhac) Date: Wed, 11 Aug 2010 09:27:32 +0200 Subject: [Ns-developers] GSOC - Request for code reviews - 'pencils down' next week In-Reply-To: <4C600C71.5010009@sophia.inria.fr> References: <4C600C71.5010009@sophia.inria.fr> Message-ID: <4C6250E4.9060300@sophia.inria.fr> Hi people, We got some reviews but still some more are needed, specially for the ns-3-OpenFlow[1] project. So if someone can find time to do some code reviewing the contribution would be really helpful. Thanks to everybody and specially to the persons that took the time for reviewing GSoC code :) Alina. [1] http://codereview.appspot.com/1872049 Alina Quereilhac wrote: > Hello everybody, > > The end of GSoC 2010 program is in one week from now (August 16th) and > it would be really helpful to get some code reviews from the community > in the next days. > Please consider taking a look at the projects source code for reviewing: > > UAN Framework: AUV simulator and power management layer - Andrea Sacco > - Code Review: http://codereview.appspot.com/1743057 > - Wiki page : http://www.nsnam.org/wiki/index.php/GSOC2010UANFramework > > ns-3-OpenFlow - Blake Hurd > - Code Review: http://codereview.appspot.com/1872049 > - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010OpenFlow > > * MAC and PHY models for LTE - Giuseppe Piro > - Code Review: http://codereview.appspot.com/1869054 > - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010MACPHYforLTE > > NS-3 Click Modular Router Integration - Lalith Suresh Puthalath > - Code Review: http://codereview.appspot.com/1690056 > - Wiki Page: http://www.nsnam.org/wiki/index.php/GSOC2010Click > > Your feedback would be most appreciated. > > Thank you, > Alina. From bernhard.kloiber at googlemail.com Wed Aug 11 02:11:36 2010 From: bernhard.kloiber at googlemail.com (Bernhard Kloiber) Date: Wed, 11 Aug 2010 11:11:36 +0200 Subject: [Ns-developers] Nakagami propagation loss model Message-ID: Dear developers, I'm not sure if the calculation of the RX-power in ns-3 by using the Nakagami propagation loss model is done correctly! In the literature I looked up the correlation between Nakagami and Gamma distribution. They adapt the parameters and then they take the square root of the gamma distributed value to get the nakagami distributed value. It seems to me that the step of taking the square root is missing in the class NakagamiPropagationLossModel. Only the parameters will be adapted there and that was it. May be that I've overlooked something. Can some experts check this? ;-) Thanks in advance! Best regards, Bernhard Kloiber From jens.mittag at kit.edu Wed Aug 11 12:16:36 2010 From: jens.mittag at kit.edu (Jens Mittag) Date: Wed, 11 Aug 2010 21:16:36 +0200 Subject: [Ns-developers] Nakagami propagation loss model In-Reply-To: References: Message-ID: <4C62F714.5040207@kit.edu> Hi Bernhard, > I'm not sure if the calculation of the RX-power in ns-3 by using the > Nakagami propagation loss model is done correctly! > In the literature I looked up the correlation between Nakagami and > Gamma distribution. They adapt the parameters and then they take the > square root of the gamma distributed value to get the nakagami > distributed value. > It seems to me that the step of taking the square root is missing in > the class NakagamiPropagationLossModel. Only the parameters will be > adapted there and that was it. The literature typically uses the Nakagami distribution to describe the fading of the amplitude of a signal. Since we have a network simulator, were we have packets instead of signals, we do not look at the amplitude, but at the energy of the signal, which you typically get by taking the amplitude to the square. As such, the square root can be "saved" in the calculation. I hope that clarifies it. Jens -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Zirkel 1, 76131 Karlsruhe, Germany Building 20.20, Room 356.1 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5833 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20100811/729b665f/smime.bin From jpelkey at gatech.edu Wed Aug 11 14:25:04 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Wed, 11 Aug 2010 17:25:04 -0400 Subject: [Ns-developers] ns-3.9 release candidate 1 Message-ID: Greetings everyone, I am happy to announce release candidate 1 for ns-3.9! The ns-3-allinone version of this release candidate can be downloaded as a compressed (.tar.bz2) [http://www.nsnam.org/releases/ns-allinone-3.9-RC1.tar.bz2]. Alternatively, you can use mercurial to clone ns-3-allinone or ns-3.9-RC1 and ns-3.9-RC1-ref-traces. I am currently aware of some issues on gcc-3.4 machines during test.py and possibly some issues with 32-bit regression tests. Let's try to get these fixed for RC2. Thank you to everyone who has helped out so far. Please take some time to test this release candidate on as many target machines as you can manage and report issues, in order to ensure a stable release. Here are two more things marked as "to do": 1) Address Mathieu's comments for bugs 892, 893: http://codereview.appspot.com/144064 2) Determine if blockers (non-workarounds) in the Emulation and Tap Bridge (bugs 959, 903, 975, 939) Thanks again, Josh Pelkey From sam.jansen at gmail.com Thu Aug 12 13:54:28 2010 From: sam.jansen at gmail.com (Sam Jansen) Date: Thu, 12 Aug 2010 21:54:28 +0100 Subject: [Ns-developers] Network Simulation Cradle 0.5.2 released Message-ID: The Network Simulation Cradle version 0.5.2 has now been released. The download is in the usual place: http://research.wand.net.nz/software/nsc.php NSC is a project that allows real world TCP/IP stacks to be used in simulation. More information can be found at http://www.wand.net.nz/~stj2/nsc/. Changes in this version include various bug fixes from the last 12 months. It is suggested that this become the default version included in ns-3. -- Sam Jansen WAND Network Research Group. From jpelkey at gatech.edu Fri Aug 13 14:05:34 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Fri, 13 Aug 2010 17:05:34 -0400 Subject: [Ns-developers] ns-3.9 update Message-ID: Hello everyone, We released RC1 two days ago with some known issues, most of which have been fixed! We plan to officially freeze on Monday and put out another RC. Assuming no P1s show up, we hope to make it the eventual final ns-3.9 release. In the meantime, we have a few minor issues to address: 1) Merge bug fixes 892, 893. This is pretty much all but merged. Waiting for an ack from Pavel. 2) Realtime/Emulation bugs 939, 959, 903/975. I believe the first two may go in somewhat easily, while the last two may not make it (I think). Tom is planning to look a bit into these, but we would appreciate help from others on these. We will continue to accept documentation/tutorial/manual updates through the weekend. -- Josh From andrea.sacco85 at gmail.com Sat Aug 14 06:07:33 2010 From: andrea.sacco85 at gmail.com (Andrea Sacco) Date: Sat, 14 Aug 2010 15:07:33 +0200 Subject: [Ns-developers] GSOC UAN Framework final update Message-ID: Hello everybody, I've submitted the last patchset to the project's codereview http://codereview.appspot.com/1743057/show. This last patchset includes tests for auv-energy-model and li-ion-energy-source, I've added all the documentation required and removed all the doxygen warnings. Moreover I've write a biref overview of the framework components into the uan.h doxygen file with links to the main classes and to the project's wiki. Since I'm not at home now, I've been unable to connect via ssh to my repository and upload the last changes. However, the last patchset of the project is based on ns-3-dev 6469 revision with the energy model patchset 13 merged. I've also added a wiki page for the Li-Ion model's fitting at http://www.nsnam.org/wiki/index.php/Li-Ion_model_fitting I hope everything is fine. Best Regards and thanks to all, Andrea From mathieu.lacage at sophia.inria.fr Sat Aug 14 11:13:49 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sat, 14 Aug 2010 20:13:49 +0200 Subject: [Ns-developers] ns-3.9 update In-Reply-To: References: Message-ID: <1281809629.3017.15.camel@localhost.localdomain> On Fri, 2010-08-13 at 17:05 -0400, Josh Pelkey wrote: > 1) Merge bug fixes 892, 893. This is pretty much all but merged. > Waiting for an ack from Pavel. On thing that did occur to me suddendly is that the performance concerns philipp expressed could be dealt with without adding the lazy option. We could also add MobilityModel::HasCourseChangeListeners method and call it before scheduling an event to call NotifyListeners to avoid scheduling them if there are no listeners. Mathieu -- Mathieu Lacage Tel: +33 4 9238 5056 From tomh at tomh.org Sun Aug 15 14:52:22 2010 From: tomh at tomh.org (Tom Henderson) Date: Sun, 15 Aug 2010 14:52:22 -0700 Subject: [Ns-developers] ns-3.9 update In-Reply-To: <1281809629.3017.15.camel@localhost.localdomain> References: <1281809629.3017.15.camel@localhost.localdomain> Message-ID: <4C686196.60106@tomh.org> On 8/14/10 11:13 AM, Mathieu Lacage wrote: > On Fri, 2010-08-13 at 17:05 -0400, Josh Pelkey wrote: > >> 1) Merge bug fixes 892, 893. This is pretty much all but merged. >> Waiting for an ack from Pavel. > > On thing that did occur to me suddendly is that the performance concerns > philipp expressed could be dealt with without adding the lazy option. We > could also add MobilityModel::HasCourseChangeListeners method and call > it before scheduling an event to call NotifyListeners to avoid > scheduling them if there are no listeners. > I would be fine with your proposal but it seems that if Pavel and Phillip were to concur, we will still need a patch immediately to fix this during this release, or else slip this bug fix. What would people like to do here? - Tom From phillip.sitbon at gmail.com Sun Aug 15 21:00:46 2010 From: phillip.sitbon at gmail.com (Phillip Sitbon) Date: Sun, 15 Aug 2010 21:00:46 -0700 Subject: [Ns-developers] ns-3.9 update In-Reply-To: <4C686196.60106@tomh.org> References: <1281809629.3017.15.camel@localhost.localdomain> <4C686196.60106@tomh.org> Message-ID: Well, the idea seems good but what if a waypoint is added before a listener exists? It seems that only some of the waypoints would have notifications, and I'm not sure how notification subscriptions after waypoint creation *should* behave. It is an interesting proposition however. My input would be to leave it as-is if everyone agrees with the current setup (I'm still happy with having the Lazy option available to me regardless of default), then we leave it as-is for this release and talk more about Mathieu's suggestion when we have more time to try it out. I'm also open to other opinions if you have any. Cheers, Phillip On Sun, Aug 15, 2010 at 2:52 PM, Tom Henderson wrote: > On 8/14/10 11:13 AM, Mathieu Lacage wrote: >> >> On Fri, 2010-08-13 at 17:05 -0400, Josh Pelkey wrote: >> >>> 1) Merge bug fixes 892, 893. ?This is pretty much all but merged. >>> Waiting for an ack from Pavel. >> >> On thing that did occur to me suddendly is that the performance concerns >> philipp expressed could be dealt with without adding the lazy option. We >> could also add MobilityModel::HasCourseChangeListeners method and call >> it before scheduling an event to call NotifyListeners to avoid >> scheduling them if there are no listeners. >> > > I would be fine with your proposal but it seems that if Pavel and Phillip > were to concur, we will still need a patch immediately to fix this during > this release, or else slip this bug fix. ?What would people like to do here? > > - Tom > From boyko at iitp.ru Sun Aug 15 22:01:42 2010 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 16 Aug 2010 09:01:42 +0400 Subject: [Ns-developers] ns-3.9 update In-Reply-To: References: <4C686196.60106@tomh.org> Message-ID: <201008160901.42447.boyko@iitp.ru> On Monday, August 16, 2010 08:00:46 am Phillip Sitbon wrote: > Well, the idea seems good but what if a waypoint is added before a > listener exists? It seems that only some of the waypoints would have > notifications, and I'm not sure how notification subscriptions after > waypoint creation *should* behave. It is an interesting proposition > however. > > My input would be to leave it as-is if everyone agrees with the > current setup (I'm still happy with having the Lazy option available > to me regardless of default), then we leave it as-is for this release > and talk more about Mathieu's suggestion when we have more time to try > it out. I'm also open to other opinions if you have any. I vote to keep waypoint mobility model as is and release ns-3.9. We can refactor course change notifications later if users will demand that. Pavel From mathieu.lacage at sophia.inria.fr Sun Aug 15 23:38:58 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Aug 2010 08:38:58 +0200 Subject: [Ns-developers] ns-3.9 update In-Reply-To: References: <1281809629.3017.15.camel@localhost.localdomain> <4C686196.60106@tomh.org> Message-ID: <1281940738.25000.21.camel@diese.inria.fr> On Sun, 2010-08-15 at 21:00 -0700, Phillip Sitbon wrote: > and talk more about Mathieu's suggestion when we have more time to try > it out. I'm also open to other opinions if you have any. +1 From jpelkey at gatech.edu Mon Aug 16 17:06:16 2010 From: jpelkey at gatech.edu (Josh Pelkey) Date: Mon, 16 Aug 2010 20:06:16 -0400 Subject: [Ns-developers] ns-3.9 release candidate 2 Message-ID: Hi all, ns-3.9-RC2 is now available for download: [http://www.nsnam.org/releases/ns-allinone-3.9-RC2.tar.bz2] or through mercurial (ns-3.9-RC2 and ns-3.9-RC2-ref-traces). Please download and test if you have time. This version seems very stable and may end up being repackaged as the final release. -- Josh Pelkey On Wed, Aug 11, 2010 at 5:25 PM, Josh Pelkey wrote: > Greetings everyone, > > I am happy to announce release candidate 1 for ns-3.9! ?The > ns-3-allinone version of this release candidate can be downloaded as a > compressed (.tar.bz2) > [http://www.nsnam.org/releases/ns-allinone-3.9-RC1.tar.bz2]. > Alternatively, you can use mercurial to clone ns-3-allinone or > ns-3.9-RC1 and ns-3.9-RC1-ref-traces. > > I am currently aware of some issues on gcc-3.4 machines during test.py > and possibly some issues with 32-bit regression tests. ?Let's try to > get these fixed for RC2. > > Thank you to everyone who has helped out so far. ?Please take some > time to test this release candidate on as many target > machines as you can manage and report issues, in order to ensure a > stable release. Here are two more things marked as "to do": > > 1) Address Mathieu's comments for bugs 892, 893: > http://codereview.appspot.com/144064 > 2) Determine if blockers (non-workarounds) in the Emulation and Tap > Bridge (bugs 959, 903, 975, 939) > > Thanks again, > > Josh Pelkey > From gjcarneiro at gmail.com Tue Aug 17 04:39:20 2010 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 17 Aug 2010 12:39:20 +0100 Subject: [Ns-developers] strange ARP requests from emu-ping example In-Reply-To: <201008171316.56761.andreas@genua.de> References: <161ff88b-f005-49d2-9459-ec8728cccbf6@d8g2000yqf.googlegroups.com> <201008171316.56761.andreas@genua.de> Message-ID: On Tue, Aug 17, 2010 at 12:16, Andreas Fiessler wrote: > On Tuesday, 17. August 2010, Gustavo Carneiro wrote: > > On Tue, Aug 17, 2010 at 10:24, andreas > wrote: > > > Hi, > > > I just tried to use the examples/emulation/emu-ping.cc to get some > > > traffic to my network. > > > After some debugging I figured out the arp requests sent by ns-3 > > > are not answered by the > > > target host (which receives it, already checked that). > > > From the same host where ns-3 is installed, an arp packet sent by > > > the OS (default linux) > > > to the same target IP address looks like this: > > > 0000 ff ff ff ff ff ff 00 07 e9 19 9f ee 08 06 00 01 > > > 0010 08 00 06 04 00 01 00 07 e9 19 9f ee 0a fd 01 95 > > > 0020 00 00 00 00 00 00 0a fd 00 01 > > > This one gets a reply. > > > > > > From ns-3: > > > 0000 ff ff ff ff ff ff 00 07 e9 19 9f ee 00 24 aa aa > > > 0010 03 00 00 00 08 06 00 01 08 00 06 04 00 01 00 07 > > > 0020 e9 19 9f ee 0a fd 01 95 ff ff ff ff ff ff 0a fd > > > 0030 00 03 > > > This one not. > > > > > > Note that after the sender MAC, the ns-3 generated packet contains > > > something > > > else than the "08 06" which would be an arp request. It does not > > > look like > > > a standard Ethernet II frame. > > > > > > Any ideas what could be wrong here? Thanks in advance. > > > > It is probably that EmuNetDevice uses LLC/SNAP encapsulation by > > default. You can change it via an attribute: > > > > .AddAttribute ("EncapsulationMode", > > "The link-layer encapsulation type to use.", > > EnumValue (LLC), > > MakeEnumAccessor > > (&EmuNetDevice::SetEncapsulationMode), MakeEnumChecker (DIX, "Dix", > > LLC, "Llc")) > Thanks! It works with DIX. > Anyway, is LLC a good choice for the default setting? I tried several > different hosts, they all seem to ignore those LLC encapsulated > arp requests. > I think that LLC/SNAP has been historically the more "canonical" encapsulation, at least in theory. However, you are right; in practice LLC/SNAP is almost never used nowadays in real equipment. I am inclined to agree with you in that probably DIX should be the default encapsulation. > > -- > Andreas Fie?ler, GeNUA GmbH, Domagkstr. 7, 85551 Kirchheim, > Tel: +49 (89) 991950-124, Fax: +49 (89) 991950-999 > andreas at genua.de, http://www.genua.de > > Gesch?ftsf?hrer: Dr. Magnus Harlander, Dr. Michaela Harlander, > Bernhard Schneck. Amtsgericht M?nchen HRB 98238 > > -- > You received this message because you are subscribed to the Google Groups > "ns-3-users" group. > To post to this group, send email to ns-3-users at googlegroups.com. > To unsubscribe from this group, send email to > ns-3-users+unsubscribe at googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/ns-3-users?hl=en. > > -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert From mk.banchi at gmail.com Tue Aug 17 10:46:00 2010 From: mk.banchi at gmail.com (Mirko Banchi) Date: Tue, 17 Aug 2010 19:46:00 +0200 Subject: [Ns-developers] MacRxMiddle::SequenceControlSmaller method Message-ID: <587D5338-C278-4DE1-9C62-B9BE6360283D@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mathieu and all, i'd like take a look at the function MacRxMiddle::SequenceControlSmaller. The first question is: what this function does? I suppose that it is used to figure out if a packet is an "old" packet or not. Standard specifies that range of sequence number are splitted in two parts: one corresponds to packets that can be considered new and one to packets that can be considered old. For simplicity we can consider a smaller range, for example, of 10 sequence numbers so with an initial sequence number equals to 7 suppose to have next situation: 0 1 2 3 4 5 6 7 8 9 * * | | | | | * * * * = new packet | = old packet Now i used that function to discover if the packet number 2 is old or new in comparison to packet number 7. So i used that logic (modified accordingly) but the function returns the following results: SequenceControlSmaller (7<<4, 2<<4) = true SequenceControlSmaller (2<<4, 7<<4) = false I think that the function should return always true because if 7 is an old packet 2 in a new one and vice versa. What do you think about? Second question: who uses this function?It seems that it never used...this function would be very useful to me... what do you think about moving it to qos-utils.h? Regards, M. - -- Mirko Banchi e-mail: mk.banchi at gmail.com id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkxqytkACgkQdjFS7TKlZFZ3AQCbBKDiQK4toH7Cqz64xbAiwLga srEAn2znmXijDYpqVyS25sVe39h7ZqF4 =pBBA -----END PGP SIGNATURE----- From gjcarneiro at gmail.com Wed Aug 18 02:38:14 2010 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 18 Aug 2010 10:38:14 +0100 Subject: [Ns-developers] strange ARP requests from emu-ping example In-Reply-To: References: <161ff88b-f005-49d2-9459-ec8728cccbf6@d8g2000yqf.googlegroups.com> <201008171316.56761.andreas@genua.de> Message-ID: On Wed, Aug 18, 2010 at 08:14, Mathieu Lacage wrote: > On Tue, Aug 17, 2010 at 13:39, Gustavo Carneiro > wrote: > >> Thanks! It works with DIX. > >> Anyway, is LLC a good choice for the default setting? I tried several > >> different hosts, they all seem to ignore those LLC encapsulated > >> arp requests. > > > > I think that LLC/SNAP has been historically the more "canonical" > > encapsulation, at least in theory. However, you are right; in practice > > LLC/SNAP is almost never used nowadays in real equipment. I am inclined > to > > agree with you in that probably DIX should be the default encapsulation. > > Would someone mind file a bug to keep track of this issue ? > -> http://www.nsnam.org/bugzilla/show_bug.cgi?id=984 > > Mathieu > -- > Mathieu Lacage > > -- > You received this message because you are subscribed to the Google Groups > "ns-3-users" group. > To post to this group, send email to ns-3-users at googlegroups.com. > To unsubscribe from this group, send email to > ns-3-users+unsubscribe at googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/ns-3-users?hl=en. > > -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert From craigdo at gmail.com Wed Aug 18 09:54:50 2010 From: craigdo at gmail.com (Craig Dowell) Date: Wed, 18 Aug 2010 09:54:50 -0700 Subject: [Ns-developers] strange ARP requests from emu-ping example In-Reply-To: References: <161ff88b-f005-49d2-9459-ec8728cccbf6@d8g2000yqf.googlegroups.com> <201008171316.56761.andreas@genua.de> Message-ID: <1282150490.3202.6.camel@ubuntu> > I think that LLC/SNAP has been historically the more "canonical" > encapsulation, at least in theory. However, you are right; in > practice LLC/SNAP is almost never used nowadays in real equipment. I > am inclined to agree with you in that probably DIX should be the > default encapsulation. The reason that LLC/SNAP is the default is only because this encapsulation was used in the original device (since ns-3.0?) and everyone (including regression tests) expected it to be that way. Adding DIX encapsulation was required when we started the emulation work because, as Gustavo says, LLC/SNAP is almost never used nowadays in real equipment. +1 for changing the default (and regenerating all of the trace files). -- Craig From tomh at tomh.org Wed Aug 18 22:35:24 2010 From: tomh at tomh.org (Tom Henderson) Date: Wed, 18 Aug 2010 22:35:24 -0700 Subject: [Ns-developers] ns-3.9 release candidate 3 available Message-ID: <4C6CC29C.4020100@tomh.org> ns-3.9-RC3 is ready for testing: http://www.nsnam.org/releases/ns-allinone-3.9-RC3.tar.bz2 There are no known remaining issues blocking a release, so unless there are issues discovered and reported, we will make the release on Friday August 20. - Tom From tazaki at sfc.wide.ad.jp Thu Aug 19 09:54:10 2010 From: tazaki at sfc.wide.ad.jp (Hajime Tazaki) Date: Fri, 20 Aug 2010 01:54:10 +0900 Subject: [Ns-developers] patch for ns-3-linux Message-ID: Hi Mathieu, Below is the patch for ns-3-linux. I'm currently trying to work with UMIP (MIP6/NEMO daemon for linux) with ns-3-linux. the patch prevents double-queuing to workqueue. it is occurred by workqueue in net/xfrm/xfrm_policy.c . UMIP almost works fine with several fixes into ns-3-linux, although it includes a bunch of my quick hacks such as poll/select. my current patchqueue is available at http://www.sfc.wide.ad.jp/~tazaki/hg/ns-3-linux-patches/ regards, hajime diff -r 781cad83d36c sim/workqueue.c --- a/sim/workqueue.c Thu Aug 12 16:12:16 2010 +0200 +++ b/sim/workqueue.c Wed Aug 18 01:25:11 2010 +0900 @@ -79,8 +79,11 @@ int schedule_work(struct work_struct *work) { - list_add_tail(&work->entry, &g_work); - sim_task_wakeup (workqueue_task ()); + if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) + { + list_add_tail(&work->entry, &g_work); + sim_task_wakeup (workqueue_task ()); + } return 0; } void flush_scheduled_work(void) From mk.banchi at gmail.com Thu Aug 19 12:44:52 2010 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 19 Aug 2010 21:44:52 +0200 Subject: [Ns-developers] Hot to compare two uint64_t with NS_TEST_EXPECT_MSG_EQ Message-ID: <1783F5BB-B383-40D7-B9D0-8520391C6A6D@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, i need in a test to compare two uint64_t values with the macro NS_TEST_EXPECT_MSG_EQ but the compiler is not happy of this :( the error i obtain is : integer constant is too large for ?long? type. What is the way to do that? Thank you all. Mirko - -- Mirko Banchi e-mail: mk.banchi at gmail.com id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkxtibYACgkQdjFS7TKlZFZdGgCfQ/HYvTO5al4Zb/8HX5yRvHtm nOAAnipgC+SGex4VEw1kJ+g1GuYmBTY/ =eAta -----END PGP SIGNATURE----- From mathieu.lacage at sophia.inria.fr Thu Aug 19 23:18:28 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 20 Aug 2010 08:18:28 +0200 Subject: [Ns-developers] Hot to compare two uint64_t with NS_TEST_EXPECT_MSG_EQ In-Reply-To: <1783F5BB-B383-40D7-B9D0-8520391C6A6D@gmail.com> References: <1783F5BB-B383-40D7-B9D0-8520391C6A6D@gmail.com> Message-ID: <1282285108.10076.0.camel@diese.inria.fr> On Thu, 2010-08-19 at 21:44 +0200, Mirko Banchi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, i need in a test to compare two uint64_t values with the macro > NS_TEST_EXPECT_MSG_EQ but the compiler is not happy of this :( the > error i obtain is : > > integer constant is too large for ?long? type. > > What is the way to do that? append the LL keyword at the end of your constant value. i.e., uint64_t f = 168LL; Mathieu From tomh at tomh.org Fri Aug 20 18:56:47 2010 From: tomh at tomh.org (Tom Henderson) Date: Fri, 20 Aug 2010 18:56:47 -0700 Subject: [Ns-developers] ns-3.9 released Message-ID: <4C6F325F.6080605@tomh.org> ns-3.9 has been released and is available from the releases directory: http://www.nsnam.org/releases/ns-allinone-3.9.tar.bz2. A short list of new features is shown below. For a more complete changelog, please look at the full RELEASE_NOTES: http://code.nsnam.org/ns-3.9/raw-file/9c325569fb01/RELEASE_NOTES - a new OFDM error rate model for WiFi based on an underlying NIST model - a new mobility trace reader for reading ns-2, BonnMotion, SUMO, and TraNS mobility trace files - an energy model for nodes and devices, including an energy source model and device energy models - Rocketfuel topology dataset support for the Rocketfuel ISP topology mapping engine - an underwater acoustic network (UAN) model Thanks to Josh Pelkey for serving as release manager, and for the usual strong support from maintainers and contributors. - Tom From bushsf at research.ge.com Mon Aug 23 07:01:36 2010 From: bushsf at research.ge.com (Bush, Stephen F (GE Global Research)) Date: Mon, 23 Aug 2010 10:01:36 -0400 Subject: [Ns-developers] [Ns-announce] ns-3.9 released In-Reply-To: <4C6F325F.6080605@tomh.org> References: <4C6F325F.6080605@tomh.org> Message-ID: <71BEE88C279BEB479AE8A5405B2DA0DA02A13DCC@CINMLVEM12.e2k.ad.ge.com> Tom, I receive a cmalloc error during the linking phase when I install ns-3. (It seems to work ok in optimized mode.) [Versions ns3.8 and 9 on Windows using Cygwin.] I'm wondering if I'm running out of memory -- or if the code is getting too large? If you have any work arounds, I would appreciate it. Thanks, Steve (www.research.ge.com/~bushsf) (www.comsoc.org/nano) -----Original Message----- From: ns-announce-bounces at ISI.EDU [mailto:ns-announce-bounces at ISI.EDU] On Behalf Of Tom Henderson Sent: Friday, August 20, 2010 9:57 PM To: ns-developers; ns-3-users at googlegroups.com; ns-announce at ISI.EDU Subject: [Ns-announce] ns-3.9 released ns-3.9 has been released and is available from the releases directory: http://www.nsnam.org/releases/ns-allinone-3.9.tar.bz2. A short list of new features is shown below. For a more complete changelog, please look at the full RELEASE_NOTES: http://code.nsnam.org/ns-3.9/raw-file/9c325569fb01/RELEASE_NOTES - a new OFDM error rate model for WiFi based on an underlying NIST model - a new mobility trace reader for reading ns-2, BonnMotion, SUMO, and TraNS mobility trace files - an energy model for nodes and devices, including an energy source model and device energy models - Rocketfuel topology dataset support for the Rocketfuel ISP topology mapping engine - an underwater acoustic network (UAN) model Thanks to Josh Pelkey for serving as release manager, and for the usual strong support from maintainers and contributors. - Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4425 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20100823/f3a1d29a/smime.bin From tomh at tomh.org Mon Aug 23 18:21:44 2010 From: tomh at tomh.org (Tom Henderson) Date: Mon, 23 Aug 2010 19:21:44 -0600 Subject: [Ns-developers] [Ns-announce] ns-3.9 released In-Reply-To: <71BEE88C279BEB479AE8A5405B2DA0DA02A13DCC@CINMLVEM12.e2k.ad.ge.com> References: <4C6F325F.6080605@tomh.org> <71BEE88C279BEB479AE8A5405B2DA0DA02A13DCC@CINMLVEM12.e2k.ad.ge.com> Message-ID: <1c8431e9184ea582944268fafcd97d48@tomh.org> On Mon, 23 Aug 2010 10:01:36 -0400, "Bush, Stephen F (GE Global Research)" wrote: > Tom, > > I receive a cmalloc error during the linking phase when I install ns-3. (It > seems to work ok in optimized mode.) > > [Versions ns3.8 and 9 on Windows using Cygwin.] > > I'm wondering if I'm running out of memory -- or if the code is getting too > large? Yes, this problem has been observed earlier this year: http://mailman.isi.edu/pipermail/ns-developers/2010-February/007427.html > > If you have any work arounds, I would appreciate it. We don't have any documented workarounds. The long term solution is to move towards more modular builds, but that won't be available in release form until ns-3.10 at the earliest. In the interim, we might make this easier for someone to manually remove unwanted models, if we organized more of our optional components such as we have been discussing, in self-contained directories. For instance, try removing the UAN device by removing line 46 of src/wscript, and by building without python bindings (./waf configure --disable-python). If we can come up with a modular solution for the bindings, we at least may have a way to allow users to trim out models that they do not want, manually. - Tom From tpecorella at mac.com Tue Aug 24 12:10:44 2010 From: tpecorella at mac.com (Tommaso Pecorella) Date: Tue, 24 Aug 2010 21:10:44 +0200 Subject: [Ns-developers] Question about 802.11 Holland Message-ID: <6810FC3A-338D-4C16-ABC5-8164F355739A@mac.com> Hi all, I guess the question is more or less directed only to Mathieu Lacage, but if anyone know the answer, please enlighten me. I was crawling (again( WiFi code to clean up some stuff, and I found (again) the "802.11 Holland" stuff. Now, from what I can see it's "just" an 802.11a with a few less modcods. Now, the question is: where in the standard it is defined? I tried googling it... no success. It doesn't really bother me too much, it's just curiosity. I assume that a normal user isn't so dumb to use an 802.11 flavor without knowing what it is (checking the code maybe), so it's harmless to have a "strange" 802.11 flavor in the code. On the other hand, I'm curious about it. Does anyone know where it comes from ? Best regards, Tommaso -------------------------------------------------------------- $25: for you a pizza and some beers with friends, for someone might change their lives. Think about it. Kiva.org - Loans That Change Lives -------------------------------------------------------------- Tommaso Pecorella - Ph.D. Assistant professor Dpt. Elettronica e Telecomunicazioni Universit? di Firenze CNIT - Universit? di Firenze Unit via di S. Marta 3 50139, Firenze ITALY email: tommaso.pecorella at unifi.it tommaso.pecorella at cnit.it phone : +39-055-4796412 mobile: +39-320-4379803 fax : +39-055-494569 From ruben at net.t-labs.tu-berlin.de Tue Aug 24 12:27:44 2010 From: ruben at net.t-labs.tu-berlin.de (Ruben Merz) Date: Tue, 24 Aug 2010 21:27:44 +0200 Subject: [Ns-developers] Question about 802.11 Holland In-Reply-To: <6810FC3A-338D-4C16-ABC5-8164F355739A@mac.com> References: <6810FC3A-338D-4C16-ABC5-8164F355739A@mac.com> Message-ID: <4C741D30.4090701@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Tommaso, I suspect this might be a reference to this paper: A Rate-Adaptive MAC Protocol for Wireless Networks at http://portal.acm.org/citation.cfm?id=892952 On 8/24/10 9:10 PM, Tommaso Pecorella wrote: > Hi all, > > I guess the question is more or less directed only to Mathieu Lacage, but if anyone know the answer, please enlighten me. > > I was crawling (again( WiFi code to clean up some stuff, and I found (again) the "802.11 Holland" stuff. > > Now, from what I can see it's "just" an 802.11a with a few less modcods. Now, the question is: where in the standard it is defined? I tried googling it... no success. > > It doesn't really bother me too much, it's just curiosity. I assume that a normal user isn't so dumb to use an 802.11 flavor without knowing what it is (checking the code maybe), so it's harmless to have a "strange" 802.11 flavor in the code. > > On the other hand, I'm curious about it. > > Does anyone know where it comes from ? > > Best regards, > > Tommaso > > -------------------------------------------------------------- > > $25: for you a pizza and some beers with friends, for someone > might change their lives. Think about it. > > Kiva.org - Loans That Change Lives > > -------------------------------------------------------------- > > Tommaso Pecorella - Ph.D. > > Assistant professor > Dpt. Elettronica e Telecomunicazioni > Universit? di Firenze > > CNIT - Universit? di Firenze Unit > > via di S. Marta 3 > 50139, Firenze > ITALY > > email: tommaso.pecorella at unifi.it > tommaso.pecorella at cnit.it > > phone : +39-055-4796412 > mobile: +39-320-4379803 > fax : +39-055-494569 > > > > > > > - -- Ruben Merz Deutsche Telekom Laboratories http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMdB0wAAoJEF+2tk4uvSJPYvQIAI6kaUBKOmGVFaMe0x2hiw7N HjuKDsq/CANWAJvT78GErmeVn1HgJqRYWav/1y9F01bG7zQV4vDxyp0XywplZ9jO JKGklfqg9axvJAm8K0P7woF8EuqdL4kiee93HbpR87rmDdY/ZN6kimaHalI8Wx/Z EmgJ9T+E9UmHbkmcnsiZ7Sr3xONWD4L/Ap1zvJ0+qT2xPiNFUv5lllOfls7kjM4A bgWeDOe29yjrcDO4vSUJCmBh8VlJiFWey9956+/I0B8J+6BJubb7PYTXvBkS9LA/ 7a10+jPIwvFa0WYvpwZP7QQdaS23WEAfLyB1IgDo94eeBG+fvy6NNZnudZDAvpQ= =lsVi -----END PGP SIGNATURE----- From tpecorella at mac.com Tue Aug 24 13:44:05 2010 From: tpecorella at mac.com (Tommaso Pecorella) Date: Tue, 24 Aug 2010 22:44:05 +0200 Subject: [Ns-developers] Question about 802.11 Holland In-Reply-To: <4C741D30.4090701@net.t-labs.tu-berlin.de> References: <6810FC3A-338D-4C16-ABC5-8164F355739A@mac.com> <4C741D30.4090701@net.t-labs.tu-berlin.de> Message-ID: Hi Ruben, that was one of my guess, but the paper doesn't have anything to do with phy layer. On the other hand probably you're right, as Holland used ns-2 for his simulations, so maybe (maybe) it's a dinosaur, as is a piece of code inherited from ns-2 (or yans) that Holland wrote for his simulations. If this is so, probably the question would be if it is wise to keep it in ns-3 as it doesn't match any standard version (to my best knowledge, correct me if I'm wrong). As I said, it's harmless. However, is it useful or it is just some unnecessary code ? In my opinion, unnecessary code, even if harmless, should be killed on sight, but again, this is just my opinion. Best regards, Tommaso On 24/ago/2010, at 21.27, Ruben Merz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear Tommaso, > > I suspect this might be a reference to this paper: A Rate-Adaptive MAC > Protocol for Wireless Networks at > http://portal.acm.org/citation.cfm?id=892952 > > > > On 8/24/10 9:10 PM, Tommaso Pecorella wrote: >> Hi all, >> >> I guess the question is more or less directed only to Mathieu Lacage, but if anyone know the answer, please enlighten me. >> >> I was crawling (again( WiFi code to clean up some stuff, and I found (again) the "802.11 Holland" stuff. >> >> Now, from what I can see it's "just" an 802.11a with a few less modcods. Now, the question is: where in the standard it is defined? I tried googling it... no success. >> >> It doesn't really bother me too much, it's just curiosity. I assume that a normal user isn't so dumb to use an 802.11 flavor without knowing what it is (checking the code maybe), so it's harmless to have a "strange" 802.11 flavor in the code. >> >> On the other hand, I'm curious about it. >> >> Does anyone know where it comes from ? >> >> Best regards, >> >> Tommaso >> >> -------------------------------------------------------------- >> >> $25: for you a pizza and some beers with friends, for someone >> might change their lives. Think about it. >> >> Kiva.org - Loans That Change Lives >> >> -------------------------------------------------------------- >> >> Tommaso Pecorella - Ph.D. >> >> Assistant professor >> Dpt. Elettronica e Telecomunicazioni >> Universit? di Firenze >> >> CNIT - Universit? di Firenze Unit >> >> via di S. Marta 3 >> 50139, Firenze >> ITALY >> >> email: tommaso.pecorella at unifi.it >> tommaso.pecorella at cnit.it >> >> phone : +39-055-4796412 >> mobile: +39-320-4379803 >> fax : +39-055-494569 >> >> >> >> >> >> >> > > - -- > Ruben Merz Deutsche Telekom Laboratories > http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJMdB0wAAoJEF+2tk4uvSJPYvQIAI6kaUBKOmGVFaMe0x2hiw7N > HjuKDsq/CANWAJvT78GErmeVn1HgJqRYWav/1y9F01bG7zQV4vDxyp0XywplZ9jO > JKGklfqg9axvJAm8K0P7woF8EuqdL4kiee93HbpR87rmDdY/ZN6kimaHalI8Wx/Z > EmgJ9T+E9UmHbkmcnsiZ7Sr3xONWD4L/Ap1zvJ0+qT2xPiNFUv5lllOfls7kjM4A > bgWeDOe29yjrcDO4vSUJCmBh8VlJiFWey9956+/I0B8J+6BJubb7PYTXvBkS9LA/ > 7a10+jPIwvFa0WYvpwZP7QQdaS23WEAfLyB1IgDo94eeBG+fvy6NNZnudZDAvpQ= > =lsVi > -----END PGP SIGNATURE----- -------------------------------------------------------------- The nice thing about standards is that there are so many to choose from. And if you really don't like all the standards you just have to wait another year until the one arises you are looking for. -- A. Tanenbaum, "Introduction to Computer Networks" -------------------------------------------------------------- Tommaso Pecorella - Ph.D. Assistant professor Dpt. Elettronica e Telecomunicazioni Universit? di Firenze CNIT - Universit? di Firenze Unit via di S. Marta 3 50139, Firenze ITALY email: tommaso.pecorella at unifi.it tommaso.pecorella at cnit.it phone : +39-055-4796412 mobile: +39-320-4379803 fax : +39-055-494569 From alina.quereilhac at sophia.inria.fr Wed Aug 25 01:02:35 2010 From: alina.quereilhac at sophia.inria.fr (Alina Quereilhac) Date: Wed, 25 Aug 2010 10:02:35 +0200 Subject: [Ns-developers] GSOC 2010 has finished Message-ID: <4C74CE1B.2020708@sophia.inria.fr> Hello all, This year's Google Summer of Code has finished with four successful students projects for ns-3. Thanks to the students Andrea Sacco, Blake Hurd, Giuseppe Piro and Lalith Suresh Puthalath, and to the mentors Leonard Tracy, Josh Pelkey, Nicola Baldo, Marco Miozzo and Ruben Merz for all their effort. You can visit the wiki[1] to obtain more information on the student projects for ns-3 on GSoC 2010. Regards, Alina. [1]http://www.nsnam.org/wiki/index.php/GSOC2010AcceptedProjects From alina.quereilhac at sophia.inria.fr Wed Aug 25 07:26:33 2010 From: alina.quereilhac at sophia.inria.fr (Alina Quereilhac) Date: Wed, 25 Aug 2010 16:26:33 +0200 Subject: [Ns-developers] Problem generating python bindings Message-ID: <4C752819.1040308@sophia.inria.fr> Hello, I am implementing a new device class for ns-3 and when I try to generate the python bindings I am getting some pybindgen errors. This device needs to provide a binding for the methods that convert an abstract socket name to string encoding and vice versa. The signature definitions of the methods are analogue to the ones provided in the tap bridge and emu devices: std::string BufferToString (struct sockaddr_un un, int len) const; bool StringToBuffer (std::string s, uint8_t *buffer, uint32_t *len); The bindings API definitions that are generated automatically using python-scan target with waf look like: ## file-descriptor-net-device.h: std::string ns3::FileDescriptorNetDevice::BufferToString(sockaddr_un un, int len) const [member function] cls.add_method('BufferToString', 'std::string', [param('sockaddr_un', 'un'), param('int', 'len')], is_const=True) ## file-descriptor-net-device.h: bool ns3::FileDescriptorNetDevice::StringToBuffer(std::string s, uint8_t * buffer, uint32_t * len) [member function] cls.add_method('StringToBuffer', 'bool', [param('std::string', 's'), param('uint8_t *', 'buffer'), param('uint32_t *', 'len')]) But when generating the python bindings I get the two following errors: ---- location: File "../bindings/python/ns3modulegen.py", line 176, in main() File "../bindings/python/ns3modulegen.py", line 111, in main register_methods(root_module) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3modulegen_generated.py", line 790, in register_methods ns3_module_file_descriptor.register_methods(root_module) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor.py", line 100, in register_methods register_Ns3FileDescriptorNetDevice_methods(root_module, root_module['ns3::FileDescriptorNetDevice']) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor.py", line 117, in register_Ns3FileDescriptorNetDevice_methods is_const=True) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/cppclass.py", line 1369, in add_method meth = CppMethod(*args, **kwargs) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/cppmethod.py", line 115, in __init__ parameters = [utils.eval_param(param, self) for param in parameters] File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", line 231, in eval_param TypeLookupError)) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", line 148, in call_with_error_handling if settings.error_handler.handle_error(wrapper, ex, traceback): File "../bindings/python/ns3modulegen.py", line 30, in handle_error traceback.print_stack() ---- error: File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", line 144, in call_with_error_handling return callback(*args, **kwargs) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/typehandlers/base.py", line 1241, in new param_type_matcher.lookup(ctype) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/typehandlers/base.py", line 1404, in lookup raise TypeLookupError(tried_names) ../bindings/python/ns3_module_file_descriptor.py:117: TypeLookupError(['sockaddr_un'],) ---- location: File "../bindings/python/ns3modulegen.py", line 176, in main() File "../bindings/python/ns3modulegen.py", line 111, in main register_methods(root_module) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3modulegen_generated.py", line 790, in register_methods ns3_module_file_descriptor.register_methods(root_module) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor.py", line 100, in register_methods register_Ns3FileDescriptorNetDevice_methods(root_module, root_module['ns3::FileDescriptorNetDevice']) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor.py", line 251, in register_Ns3FileDescriptorNetDevice_methods [param('std::string', 's'), param('uint8_t *', 'buffer'), param('uint32_t *', 'len')]) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/cppclass.py", line 1369, in add_method meth = CppMethod(*args, **kwargs) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/cppmethod.py", line 115, in __init__ parameters = [utils.eval_param(param, self) for param in parameters] File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", line 231, in eval_param TypeLookupError)) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", line 148, in call_with_error_handling if settings.error_handler.handle_error(wrapper, ex, traceback): File "../bindings/python/ns3modulegen.py", line 30, in handle_error traceback.print_stack() ---- error: File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", line 144, in call_with_error_handling return callback(*args, **kwargs) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/typehandlers/base.py", line 1248, in new return type_handler_class(*args, **kwargs) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/typehandlers/inttype.py", line 530, in __init__ raise TypeConfigurationError("direction not given") ../bindings/python/ns3_module_file_descriptor.py:251: TypeConfigurationError('direction not given',) I am not sure about how to solve this problems. For the first error it seems that 'sockaddr_un' is not wrapped. What should I do in this case? For the second error I am not sure what the problem is as I could not find any related information. Any directions on how to deal with this problems would be helpful. Thanks, Alina. From David.Ros at telecom-bretagne.eu Wed Aug 25 00:26:55 2010 From: David.Ros at telecom-bretagne.eu (David Ros) Date: Wed, 25 Aug 2010 09:26:55 +0200 Subject: [Ns-developers] Importance of processing delays accounting In-Reply-To: References: Message-ID: <43BE3A04-6DB9-4DCC-BA03-2BCE26A2B17B@telecom-bretagne.eu> Le 11 ao?t 2010 ? 23:28, ns-developers-request at ISI.EDU a ?crit : > > On 8/9/10 3:35 AM, Stein Kristiansen wrote: >> Hello, >> >> So, I guess my main question is whether you know of anyone which was >> planning to do the work Elena proposed? Elsewise, this would naturally >> be something I would need to do in my work, and I was thinking of >> proposing something related to our masters students. > > Hi Stein, > I'm hoping that you can contribute in this area. It would be nice to > have a framework for delay profiles with a suitable default but ability > to add different profiles. > > Some related work that I'm aware of is the black-box router profiler > work by Chertov et al. a few years ago: > Roman Chertov, Sonia Fahmy, and Ness B. Shroff, "A Black-box Router > Profiler," In Proceedings of the IEEE Global Internet Symposium, May 2007. > > - Tom > Hi, FYI, there is a more recent version of the above work: http://www.cs.purdue.edu/homes/fahmy/papers/tomacs2.pdf as future work, they say that they plan to integrate their models into ns-3... Regards, David. ================================================================= David ROS http://www.rennes.enst-bretagne.fr/~dros/ I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams From mathieu.lacage at sophia.inria.fr Wed Aug 25 08:44:44 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 25 Aug 2010 17:44:44 +0200 Subject: [Ns-developers] time management Message-ID: <1282751084.29095.54.camel@diese.inria.fr> hi, This week, I had to run extensive micro benchmarks on ns-3 and while these things are very boring, they turned up one interesting old issue that has been bugging pavel and andrey for a while: http://www.nsnam.org/bugzilla/show_bug.cgi?id=826 This bug still appears to be a real issue: applying the patch attached to this bug report (as well as a small change to the WifiMacQueue::Cleanup function to avoid the Time code in there too) triggers a 40% runtime reduction on a 32bit system while it is less than a 5% reduction on a 64bit system. Needless to say, this is all my fault. More specifically, it is all coming from the src/simulator/high-precision* crap that is slow as hell on 32bit systems and that is overused, leading to these (unacceptable) slowdowns. The Time class does many things: - hide the simulation time resolution with the Get* methods and the construction functions (Seconds, MicroSeconds, etc.). - provide 128 bit arithmetic to perform complex calculations on time objects that do not involve floating point arithmetic to avoid changes in simulation output on different systems. This is problematic as pointed in bug 445 because Scalar is not a good name but no other name appears to be great. This is also problematic (bug 826) for performance reasons because it forces us to support always 128bit arithmetic even when we really don't need it. Furthermore, bug 976 points to a problem that is bound to become more prevalent: other models use floating point arithmetic because they need to perform multiplications and divisions that need high precision, but this leads to varying simulation results on different platforms. So, the proposal involves: 1) move out the HighPrecision code that provides 128bit arithemtic to a separate class. I moved it to src/core/int64x64.h. This header defines the type int64x64_t that implements all the C++ arithmetic operators and behaves like a double or an int except that its behavior does not change on different platforms and it provides 64bits of fractional precision. This paves the way for a fix for bug 976 that replaces doubles with uint64x64_t. 2) change the Time class to store the simulation time as a 64bit integer (instead of 128 bits). This fixes bug 826 (performance regression). 3) remove the multiplication and division operators from the Time class. Time objects can now be added, substracted, compared, but other operations require first a conversion to int64x64_t. This removes the need for Scalar, TimeInvert, etc, hence fixing bug 445. I converted the few users in ns-3-dev that make use of the Scalar class and pushed the code in http://code.nsnam.org/mathieu/ns-3-time (one adov test is still failing because I did not have enough time to track it down) If you are merely a user of the Scalar class, it's simple to convert your code to the new API: before: Scalar (0.1) * Seconds (10) after: 0.1 * Seconds (10).To () the method Time::To returns an int64x64_t object that can be used to perform further arithmetic computations. There are also a couple of overloaded methods Time::To (enum Time::Unit unit) which can be used as follows: int64x64_t v = time.To (Time::S); int64x64_t v = time.To (Time::NS); There are probably some portability issues to fix in this code but I think that decoupling the functionality provided by the Time class addresses a number of problems that have cropped up over time so, I would like to merge this in ns-3-dev early on in this release cycle to shake out all the bugs in it and give plenty of time to everyone to adapt to the new API if needed. Comments ? If I really get none, I intend to proceed with merging within one or two weeks from now, and earlier if I get positive feedback. Note also that the latest version of the HighPrecision code is giving real trouble to --python-scan, so, the python bindings do not work. Mathieu From gjcarneiro at gmail.com Wed Aug 25 08:57:02 2010 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 25 Aug 2010 16:57:02 +0100 Subject: [Ns-developers] Problem generating python bindings In-Reply-To: <4C752819.1040308@sophia.inria.fr> References: <4C752819.1040308@sophia.inria.fr> Message-ID: On Wed, Aug 25, 2010 at 15:26, Alina Quereilhac < alina.quereilhac at sophia.inria.fr> wrote: > Hello, > > I am implementing a new device class for ns-3 and when I try to generate > the python bindings I am getting some pybindgen errors. > This device needs to provide a binding for the methods that convert an > abstract socket name to string encoding and vice versa. > The signature definitions of the methods are analogue to the ones provided > in the tap bridge and emu devices: > > std::string BufferToString (struct sockaddr_un un, int len) const; > bool StringToBuffer (std::string s, uint8_t *buffer, uint32_t *len); > > The bindings API definitions that are generated automatically using > python-scan target with waf look like: > > ## file-descriptor-net-device.h: std::string > ns3::FileDescriptorNetDevice::BufferToString(sockaddr_un un, int len) const > [member function] > cls.add_method('BufferToString', > 'std::string', > [param('sockaddr_un', 'un'), param('int', 'len')], > is_const=True) > > ## file-descriptor-net-device.h: bool > ns3::FileDescriptorNetDevice::StringToBuffer(std::string s, uint8_t * > buffer, uint32_t * len) [member function] > cls.add_method('StringToBuffer', > 'bool', > [param('std::string', 's'), param('uint8_t *', 'buffer'), > param('uint32_t *', 'len')]) > > But when generating the python bindings I get the two following errors: > > ---- location: > File "../bindings/python/ns3modulegen.py", line 176, in > main() > File "../bindings/python/ns3modulegen.py", line 111, in main > register_methods(root_module) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3modulegen_generated.py", > line 790, in register_methods > ns3_module_file_descriptor.register_methods(root_module) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor.py", > line 100, in register_methods > register_Ns3FileDescriptorNetDevice_methods(root_module, > root_module['ns3::FileDescriptorNetDevice']) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor.py", > line 117, in register_Ns3FileDescriptorNetDevice_methods > is_const=True) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/cppclass.py", > line 1369, in add_method > meth = CppMethod(*args, **kwargs) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/cppmethod.py", > line 115, in __init__ > parameters = [utils.eval_param(param, self) for param in parameters] > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", > line 231, in eval_param > TypeLookupError)) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", > line 148, in call_with_error_handling > if settings.error_handler.handle_error(wrapper, ex, traceback): > File "../bindings/python/ns3modulegen.py", line 30, in handle_error > traceback.print_stack() > ---- error: > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", > line 144, in call_with_error_handling > return callback(*args, **kwargs) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/typehandlers/base.py", > line 1241, in new > param_type_matcher.lookup(ctype) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/typehandlers/base.py", > line 1404, in lookup > raise TypeLookupError(tried_names) > ../bindings/python/ns3_module_file_descriptor.py:117: > TypeLookupError(['sockaddr_un'],) > > > ---- location: > File "../bindings/python/ns3modulegen.py", line 176, in > main() > File "../bindings/python/ns3modulegen.py", line 111, in main > register_methods(root_module) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3modulegen_generated.py", > line 790, in register_methods > ns3_module_file_descriptor.register_methods(root_module) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor.py", > line 100, in register_methods > register_Ns3FileDescriptorNetDevice_methods(root_module, > root_module['ns3::FileDescriptorNetDevice']) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor.py", > line 251, in register_Ns3FileDescriptorNetDevice_methods > [param('std::string', 's'), param('uint8_t *', 'buffer'), param('uint32_t > *', 'len')]) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/cppclass.py", > line 1369, in add_method > meth = CppMethod(*args, **kwargs) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/cppmethod.py", > line 115, in __init__ > parameters = [utils.eval_param(param, self) for param in parameters] > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", > line 231, in eval_param > TypeLookupError)) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", > line 148, in call_with_error_handling > if settings.error_handler.handle_error(wrapper, ex, traceback): > File "../bindings/python/ns3modulegen.py", line 30, in handle_error > traceback.print_stack() > ---- error: > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/utils.py", > line 144, in call_with_error_handling > return callback(*args, **kwargs) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/typehandlers/base.py", > line 1248, in new > return type_handler_class(*args, **kwargs) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/aquereil/repos/ns-3-allinone/pybindgen/pybindgen/typehandlers/inttype.py", > line 530, in __init__ > raise TypeConfigurationError("direction not given") > ../bindings/python/ns3_module_file_descriptor.py:251: > TypeConfigurationError('direction not given',) > > > I am not sure about how to solve this problems. For the first error it > seems that 'sockaddr_un' is not wrapped. What should I do in this case? > You need to manually register the type. One way is to create a "module local" customization file, in your case it would be bindings/python/apidefs/gcc-LP64/ns3_module_file_descriptor__local.py Add a register_types(module) function, thus: def register_types(module): sockaddr_un = module.add_struct("sockaddr_un", foreign_cpp_namespace="::") sockaddr_un.add_instance_attribute('attrname, 'attrype') #... etc... def register_functions(module): pass def register_methods(module): pass > For the second error I am not sure what the problem is as I could not find > any related information. > pybindgen knows how to deal with pointer types, but usually assumes the pointer points to a single element, and there is in/out/inout value transfer semantics. This is a pair pointer/length pair of parameters, pybindgen does not have code to deal with it directly. This has been asked for pybindgen and I submitted a possible workaround: https://answers.launchpad.net/pybindgen/+question/120783 > Any directions on how to deal with this problems would be helpful. > > > Thanks, > Alina. > > -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert From gjcarneiro at gmail.com Wed Aug 25 09:13:28 2010 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 25 Aug 2010 17:13:28 +0100 Subject: [Ns-developers] time management In-Reply-To: <1282751084.29095.54.camel@diese.inria.fr> References: <1282751084.29095.54.camel@diese.inria.fr> Message-ID: On Wed, Aug 25, 2010 at 16:44, Mathieu Lacage < mathieu.lacage at sophia.inria.fr> wrote: > hi, > > This week, I had to run extensive micro benchmarks on ns-3 and while > these things are very boring, they turned up one interesting old issue > that has been bugging pavel and andrey for a while: > http://www.nsnam.org/bugzilla/show_bug.cgi?id=826 > > This bug still appears to be a real issue: applying the patch attached > to this bug report (as well as a small change to the > WifiMacQueue::Cleanup function to avoid the Time code in there too) > triggers a 40% runtime reduction on a 32bit system while it is less than > a 5% reduction on a 64bit system. Needless to say, this is all my fault. > More specifically, it is all coming from the > src/simulator/high-precision* crap that is slow as hell on 32bit systems > and that is overused, leading to these (unacceptable) slowdowns. > > The Time class does many things: > - hide the simulation time resolution with the Get* methods and the > construction functions (Seconds, MicroSeconds, etc.). > - provide 128 bit arithmetic to perform complex calculations on time > objects that do not involve floating point arithmetic to avoid changes > in simulation output on different systems. This is problematic as > pointed in bug 445 because Scalar is not a good name but no other name > appears to be great. This is also problematic (bug 826) for performance > reasons because it forces us to support always 128bit arithmetic even > when we really don't need it. > > Furthermore, bug 976 points to a problem that is bound to become more > prevalent: other models use floating point arithmetic because they need > to perform multiplications and divisions that need high precision, but > this leads to varying simulation results on different platforms. > > So, the proposal involves: > > 1) move out the HighPrecision code that provides 128bit arithemtic to a > separate class. I moved it to src/core/int64x64.h. This header defines > the type int64x64_t that implements all the C++ arithmetic operators and > behaves like a double or an int except that its behavior does not change > on different platforms and it provides 64bits of fractional precision. > This paves the way for a fix for bug 976 that replaces doubles with > uint64x64_t. > > 2) change the Time class to store the simulation time as a 64bit integer > (instead of 128 bits). This fixes bug 826 (performance regression). > > 3) remove the multiplication and division operators from the Time class. > Time objects can now be added, substracted, compared, but other > operations require first a conversion to int64x64_t. This removes the > need for Scalar, TimeInvert, etc, hence fixing bug 445. > > I converted the few users in ns-3-dev that make use of the Scalar class > and pushed the code in http://code.nsnam.org/mathieu/ns-3-time > (one adov test is still failing because I did not have enough time to > track it down) > > If you are merely a user of the Scalar class, it's simple to convert > your code to the new API: > > before: Scalar (0.1) * Seconds (10) > after: 0.1 * Seconds (10).To () > This is completely unreadable. To what? What is the return type, int64x64_t or Time? int64x64_t is hard to type, can't you find a simpler name? :-/ Maybe time128_t ? > > the method Time::To returns an int64x64_t object that can be used to > perform further arithmetic computations. There are also a couple of > overloaded methods Time::To (enum Time::Unit unit) which can be used as > follows: > int64x64_t v = time.To (Time::S); > int64x64_t v = time.To (Time::NS); > Why can't we keep the Time::GetSeconds (), Time::GetNanoseconds () naming convention that we always used and was more readable? > > > There are probably some portability issues to fix in this code but I > think that decoupling the functionality provided by the Time class > addresses a number of problems that have cropped up over time so, I > would like to merge this in ns-3-dev early on in this release cycle to > shake out all the bugs in it and give plenty of time to everyone to > adapt to the new API if needed. > > Comments ? If I really get none, I intend to proceed with merging within > one or two weeks from now, and earlier if I get positive feedback. > > Note also that the latest version of the HighPrecision code is giving > real trouble to --python-scan, so, the python bindings do not work. > > Mathieu > > -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert From mazo at iitp.ru Wed Aug 25 10:17:23 2010 From: mazo at iitp.ru (Andrey Mazo) Date: Wed, 25 Aug 2010 21:17:23 +0400 Subject: [Ns-developers] time management In-Reply-To: References: <1282751084.29095.54.camel@diese.inria.fr> Message-ID: On Wed, 25 Aug 2010 20:13:28 +0400, Gustavo Carneiro wrote: > int64x64_t is hard to type, can't you find a simpler name? :-/ > > Maybe time128_t ? I guess, it may be ambiguous for people thinking of 128-bit time_t and 292471210647 year problem.:) -- Andrey Mazo. From mathieu.lacage at sophia.inria.fr Wed Aug 25 10:21:37 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 25 Aug 2010 19:21:37 +0200 Subject: [Ns-developers] time management In-Reply-To: References: <1282751084.29095.54.camel@diese.inria.fr> Message-ID: <1282756897.2562.24.camel@mathieu-laptop> On Wed, 2010-08-25 at 17:13 +0100, Gustavo Carneiro wrote: > > If you are merely a user of the Scalar class, it's simple to > convert > your code to the new API: > > before: Scalar (0.1) * Seconds (10) > after: 0.1 * Seconds (10).To () > > > This is completely unreadable. To what? What is the return type, > int64x64_t or Time? as explained below in my original mail, it returns int64x64_t. > > int64x64_t is hard to type, can't you find a simpler name? :-/ > > Maybe time128_t ? I would be happy to find a good name for the type but time128_t is not correct because it implies that you can use this type only for time. As I pointed out above in my original mail, I split this type to make it possible to use fixed-point integer arithmetic in non-time cases and the int64x64_t name makes it at least clear that we are not talking about only time anymore and it comes pretty naturally if you are used to uint64_t, int32_t, etc. The naming convention used here is also fairly widespread by fixed-point arithmetic libraries. (yyxzz indicates the size of the integer and fractional parts of a fixed-point integer). Of course, int128_t is completely out of question to avoid potential conflicts with C/C++ language extensions. In the end, int64x64_t is at least very descriptive and unambiguous and, really, not so painful to type (I have had to type it a lot recently). However, I agree that the naming for the To methods is critical and not yet optimal. > the method Time::To returns an int64x64_t object that can be > used to > perform further arithmetic computations. There are also a > couple of > overloaded methods Time::To (enum Time::Unit unit) which can > be used as > follows: > int64x64_t v = time.To (Time::S); > int64x64_t v = time.To (Time::NS); > > > Why can't we keep the Time::GetSeconds (), Time::GetNanoseconds () > naming convention that we always used and was more readable? I did not remove them and I did not change the signature of these methods that still return a double and an int64_t respectively. I merely added a new one to return the int64x64_t and, yes, a better name would be nice. It should be trivial to add methods for this: int64x64_t v = time.ToS (); int64x64_t v = time.ToNs (); or: int64x64_t v = time.GetS (); int64x64_t v = time.GetNs (); And, no, we can't overload the GetSeconds etc. methods with a different return type, sadly. Method overloading works only for the arguments to the method. I could be convinced to _change_ the signature of the existing Get* methods but, I don't want to be the one who has to deal with the API breakage for users in this case :/ A small remark here: these methods are fairly different from the Time::To (void) method introduced first since they perform a unit conversion while uint64x64_t Time::To (void) does not and allows you instead to do a roundtrip: Time a = ...; Time b = a.To () * 2; Yes, you could also do a roundtrip with: Time b = Seconds (a.GetS () * 2); (I overloaded the Seconds/NanoSeconds functions) but the above is pretty painful to write, makes complex arithmetic operations unreadable (I tried), and is potentially going to destroy information because of the two unit conversions. i.e., the following assert is likely to fail: NS_ASSERT (a == Seconds (a.GetS () * 1)); while this one will never fail: NS_ASSERT (a == a.To () * 1); If you want to ask why you can't write instead: Time b = a * 2; it's because this would require one of: - an implicit conversion operator to int64x64_t from Time which would wreck havoc in the arithmetic operators defined for Time that conflict with those defined for int64x64_t. - multiplication and division operators for Time that would be confusing because they already exist and are already used: existing code would then suddendly get 64 bit arithmetic instead of 128bit which would be nice from a performance perspective but catastrophic from the perspective of finding out what broke and how when they upgrade to a new version of ns-3. As such, I remove the multiplication and division operators from Time to make sure that user code that used to have 128bit semantics stops compiling instead of silently switching to 64bit arithmetic. thanks for your comments, Mathieu -- Mathieu Lacage Tel: +33 4 9238 5056 From mathieu.lacage at sophia.inria.fr Wed Aug 25 12:38:48 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 25 Aug 2010 21:38:48 +0200 Subject: [Ns-developers] time management In-Reply-To: <1282756897.2562.24.camel@mathieu-laptop> References: <1282751084.29095.54.camel@diese.inria.fr> <1282756897.2562.24.camel@mathieu-laptop> Message-ID: <1282765128.2694.6.camel@mathieu-laptop> On Wed, 2010-08-25 at 19:21 +0200, Mathieu Lacage wrote: [snip] > If you want to ask why you can't write instead: > > Time b = a * 2; > > it's because this would require one of: [snip] hrm, I had one of these aha moments and pushed a patch that allows you to write the above and gets rid of the need for the To method. The only downside (which I think is an upside actually) is that you are now forced to use an explicit Time constructor for the above: Time a = ...; Time b = Time (a * 2); which mirrors our current use of the Seconds/MicroSeconds/NanoSeconds functions. Mathieu -- Mathieu Lacage Tel: +33 4 9238 5056 From gjcarneiro at gmail.com Wed Aug 25 13:23:37 2010 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 25 Aug 2010 21:23:37 +0100 Subject: [Ns-developers] time management In-Reply-To: <1282765128.2694.6.camel@mathieu-laptop> References: <1282751084.29095.54.camel@diese.inria.fr> <1282756897.2562.24.camel@mathieu-laptop> <1282765128.2694.6.camel@mathieu-laptop> Message-ID: On Wed, Aug 25, 2010 at 20:38, Mathieu Lacage < mathieu.lacage at sophia.inria.fr> wrote: > On Wed, 2010-08-25 at 19:21 +0200, Mathieu Lacage wrote: > > [snip] > > > If you want to ask why you can't write instead: > > > > Time b = a * 2; > > > > it's because this would require one of: > > [snip] > > hrm, I had one of these aha moments and pushed a patch that allows you > to write the above and gets rid of the need for the To method. The only > downside (which I think is an upside actually) is that you are now > forced to use an explicit Time constructor for the above: > > Time a = ...; > Time b = Time (a * 2); > > which mirrors our current use of the Seconds/MicroSeconds/NanoSeconds > functions. > +1 Conversion from Time to int64x64_t never leads to loss of precision, so it makes sense to be made implicitly. The reverse isn't true, so an explicit constructor is better. And it is reasonably readable, once you learn that Time*int = int64x64_t. Perhaps a case could be made for adding an additional operator for the case of multiplying by integer: Time operator* (Time, int); But I haven't thought out the full implications... > Mathieu > -- > Mathieu Lacage > Tel: +33 4 9238 5056 > > -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert From mathieu.lacage at sophia.inria.fr Wed Aug 25 23:45:01 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 26 Aug 2010 08:45:01 +0200 Subject: [Ns-developers] time management In-Reply-To: References: <1282751084.29095.54.camel@diese.inria.fr> <1282756897.2562.24.camel@mathieu-laptop> <1282765128.2694.6.camel@mathieu-laptop> Message-ID: <1282805101.28929.16.camel@diese.inria.fr> On Wed, 2010-08-25 at 21:23 +0100, Gustavo Carneiro wrote: > int64x64_t. Perhaps a case could be made for adding an additional > operator for the case of multiplying by integer: > > > Time operator* (Time, int); > > > But I haven't thought out the full implications... That would lead to conflicting operator * that would make the compiler refuse to compile your code with a message saying something like "ambiguous operator overloading". I have been fighting against this type of messages all day long yesterday. Btw, do you have preferences for the int64x64_t Time::To(enum Time::Unit unit) method names ? I would tend to leave them as-is since they should be used very little (we have exactly _one_ use in the entire ns-3) but, hey, if you have a preference, it's better to change it now :) Mathieu From mazo at iitp.ru Thu Aug 26 02:17:59 2010 From: mazo at iitp.ru (Andrey Mazo) Date: Thu, 26 Aug 2010 13:17:59 +0400 Subject: [Ns-developers] time management In-Reply-To: <1282751084.29095.54.camel@diese.inria.fr> References: <1282751084.29095.54.camel@diese.inria.fr> Message-ID: On Wed, 25 Aug 2010 19:44:44 +0400, Mathieu Lacage wrote: > Furthermore, bug 976 points to a problem that is bound to become more > prevalent: other models use floating point arithmetic because they need > to perform multiplications and divisions that need high precision, but > this leads to varying simulation results on different platforms. Should we consider adding -mfpmath=sse to CXXFLAGS (on CPUs that support it) if we want a little bit more floating point numerical stability? (although, some performance benchmarks are required on various CPUs to ensure we're not slowing down significantly) > Note also that the latest version of the HighPrecision code is giving > real trouble to --python-scan, so, the python bindings do not work. Do you mean, it will be impossible to use python bindings without a patch and a version bump for pybindgen? -- Andrey Mazo. From mathieu.lacage at sophia.inria.fr Thu Aug 26 02:35:03 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 26 Aug 2010 11:35:03 +0200 Subject: [Ns-developers] time management In-Reply-To: References: <1282751084.29095.54.camel@diese.inria.fr> Message-ID: <1282815303.30065.4.camel@diese.inria.fr> On Thu, 2010-08-26 at 13:17 +0400, Andrey Mazo wrote: > On Wed, 25 Aug 2010 19:44:44 +0400, Mathieu Lacage wrote: > > > Furthermore, bug 976 points to a problem that is bound to become more > > prevalent: other models use floating point arithmetic because they need > > to perform multiplications and divisions that need high precision, but > > this leads to varying simulation results on different platforms. > Should we consider adding -mfpmath=sse to CXXFLAGS (on CPUs that > support it) if we want a little bit more floating point numerical > stability? It might help but it's not going to solve the underlying problem. I would like to see what happens if you convert a couple of mobility models to use int64x64_t instead of double. I don't know if it will work well enough or efficiently enough but it would be a really interesting experiment. > (although, some performance benchmarks are required on various CPUs to > ensure we're not slowing down significantly) I am not too worried about this given the low amount of floating point computations we do. ns-3 appears to be very jump and integer-dominated with little intensive floating point computations. > > > Note also that the latest version of the HighPrecision code is giving > > real trouble to --python-scan, so, the python bindings do not work. > Do you mean, it will be impossible to use python bindings without a > patch and a version bump for pybindgen? I do not know. I am just saying that it does not work in my branch and I have no idea why. I do plan to fix this before merging in ns-3-dev though. Mathieu From gjcarneiro at gmail.com Thu Aug 26 04:16:04 2010 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 26 Aug 2010 12:16:04 +0100 Subject: [Ns-developers] time management In-Reply-To: <1282805101.28929.16.camel@diese.inria.fr> References: <1282751084.29095.54.camel@diese.inria.fr> <1282756897.2562.24.camel@mathieu-laptop> <1282765128.2694.6.camel@mathieu-laptop> <1282805101.28929.16.camel@diese.inria.fr> Message-ID: On Thu, Aug 26, 2010 at 07:45, Mathieu Lacage < mathieu.lacage at sophia.inria.fr> wrote: > On Wed, 2010-08-25 at 21:23 +0100, Gustavo Carneiro wrote: > > > int64x64_t. Perhaps a case could be made for adding an additional > > operator for the case of multiplying by integer: > > > > > > Time operator* (Time, int); > > > > > > But I haven't thought out the full implications... > > > That would lead to conflicting operator * that would make the compiler > refuse to compile your code with a message saying something like > "ambiguous operator overloading". I have been fighting against this type > of messages all day long yesterday. > > Btw, do you have preferences for the int64x64_t Time::To(enum Time::Unit > unit) method names ? I would tend to leave them as-is since they should > be used very little (we have exactly _one_ use in the entire ns-3) but, > hey, if you have a preference, it's better to change it now :) > For the sake of readability of code, I would rename to Time::ConvertTo, and make sure the unit parameter does not have any default value. Else time1.To () or time1.ConvertTo () is too cryptic, but time1.ConvertTo (Time::SECONDS) is readable. I also prefer SECONDS and NANOSECONDS instead of S and NS. If, as you say, these are not used very often, the extra typing should not be a problem. > > Mathieu > > > -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc "The universe is always one step beyond logic." -- Frank Herbert From mk.banchi at gmail.com Sat Aug 28 08:43:00 2010 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sat, 28 Aug 2010 17:43:00 +0200 Subject: [Ns-developers] Check-style.py and empty methods Message-ID: <8FE95199-A0CE-4306-95E8-7D74361CDE70@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, these days i'm using check-style.py script in order to correct bad coding style in wifi section. I can see that the script treats empty braces of empty methods on two lines: void MyClass::MyEmptyMethod { } rather than: void MyClass::MyEmptyMethod {} Is this correct? Regards, Mirko - -- Mirko Banchi e-mail: mk.banchi at gmail.com id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkx5LoYACgkQdjFS7TKlZFYSNACfa+OoFQXexxiDmDHGwM6yCQj1 mhUAnjPKJPyTk0pQh0MmQjArN099laeY =gQDY -----END PGP SIGNATURE----- From mathieu.lacage at sophia.inria.fr Sat Aug 28 11:37:40 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sat, 28 Aug 2010 20:37:40 +0200 Subject: [Ns-developers] Check-style.py and empty methods In-Reply-To: <8FE95199-A0CE-4306-95E8-7D74361CDE70@gmail.com> References: <8FE95199-A0CE-4306-95E8-7D74361CDE70@gmail.com> Message-ID: <1283020660.2656.0.camel@mathieu-laptop> On Sat, 2010-08-28 at 17:43 +0200, Mirko Banchi wrote: > Hi all, these days i'm using check-style.py script in order to correct > bad coding style in wifi section. I can see that the script treats > empty braces of empty methods on two lines: > > void > MyClass::MyEmptyMethod > { > } > > rather than: > > void > MyClass::MyEmptyMethod > {} > > Is this correct? It is the way it does it. I don't think we can change this so you have to learn to live with it. Mathieu -- Mathieu Lacage Tel: +33 4 9238 5056 From mk.banchi at gmail.com Sat Aug 28 11:52:01 2010 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sat, 28 Aug 2010 20:52:01 +0200 Subject: [Ns-developers] Check-style.py and empty methods In-Reply-To: <1283020660.2656.0.camel@mathieu-laptop> References: <8FE95199-A0CE-4306-95E8-7D74361CDE70@gmail.com> <1283020660.2656.0.camel@mathieu-laptop> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il giorno 28/ago/10, alle ore 20:37, Mathieu Lacage ha scritto: > On Sat, 2010-08-28 at 17:43 +0200, Mirko Banchi wrote: > >> Hi all, these days i'm using check-style.py script in order to >> correct >> bad coding style in wifi section. I can see that the script treats >> empty braces of empty methods on two lines: >> >> void >> MyClass::MyEmptyMethod >> { >> } >> >> rather than: >> >> void >> MyClass::MyEmptyMethod >> {} >> >> Is this correct? > > It is the way it does it. I don't think we can change this so you have > to learn to live with it. > Ok. I will learn :) Mirko - -- Mirko Banchi e-mail: mk.banchi at gmail.com id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkx5WtIACgkQdjFS7TKlZFa/5gCeOthixZmcq3XDSjmO1qxQvCJl /2wAn26WrlZv2XEk/4mudNxeYJLoQcVP =u+lj -----END PGP SIGNATURE----- From L.Wood at surrey.ac.uk Sat Aug 28 17:01:48 2010 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Sun, 29 Aug 2010 01:01:48 +0100 Subject: [Ns-developers] Check-style.py and empty methods In-Reply-To: <8FE95199-A0CE-4306-95E8-7D74361CDE70@gmail.com> References: <8FE95199-A0CE-4306-95E8-7D74361CDE70@gmail.com> Message-ID: <97CAAF61-8AFF-42A0-BAA4-9C625E5305C3@surrey.ac.uk> The first style - two lines - is correct. On 28 Aug 2010, at 16:43, Mirko Banchi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, these days i'm using check-style.py script in order to correct > bad coding style in wifi section. I can see that the script treats > empty braces of empty methods on two lines: > > void > MyClass::MyEmptyMethod > { > } > > rather than: > > void > MyClass::MyEmptyMethod > {} > > Is this correct? > > Regards, > > Mirko > > - -- > Mirko Banchi > > e-mail: mk.banchi at gmail.com > id-jabber: mk.banchi at jabber.org > > PGP key fingerprint: > > 308F BFB1 4E67 2522 C88E > DC69 7631 52ED 32A5 6456 > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkx5LoYACgkQdjFS7TKlZFYSNACfa+OoFQXexxiDmDHGwM6yCQj1 > mhUAnjPKJPyTk0pQh0MmQjArN099laeY > =gQDY > -----END PGP SIGNATURE----- > Lloyd Wood L.Wood at surrey.ac.uk http://sat-net.com/L.Wood From L.Wood at surrey.ac.uk Sat Aug 28 17:03:25 2010 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Sun, 29 Aug 2010 01:03:25 +0100 Subject: [Ns-developers] Check-style.py and empty methods In-Reply-To: <97CAAF61-8AFF-42A0-BAA4-9C625E5305C3@surrey.ac.uk> References: <8FE95199-A0CE-4306-95E8-7D74361CDE70@gmail.com> <97CAAF61-8AFF-42A0-BAA4-9C625E5305C3@surrey.ac.uk> Message-ID: <44D597FC-DDA3-47FA-B134-61A955D81C8C@surrey.ac.uk> On 29 Aug 2010, at 01:01, Wood L Dr (Electronic Eng) wrote: > The first style - two lines - is correct. ...because it's all about minimising the number of lines changed in a diff/patch. > > On 28 Aug 2010, at 16:43, Mirko Banchi wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, these days i'm using check-style.py script in order to correct >> bad coding style in wifi section. I can see that the script treats >> empty braces of empty methods on two lines: >> >> void >> MyClass::MyEmptyMethod >> { >> } >> >> rather than: >> >> void >> MyClass::MyEmptyMethod >> {} >> >> Is this correct? >> >> Regards, >> >> Mirko >> >> - -- >> Mirko Banchi >> >> e-mail: mk.banchi at gmail.com >> id-jabber: mk.banchi at jabber.org >> >> PGP key fingerprint: >> >> 308F BFB1 4E67 2522 C88E >> DC69 7631 52ED 32A5 6456 >> >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> >> iEYEARECAAYFAkx5LoYACgkQdjFS7TKlZFYSNACfa+OoFQXexxiDmDHGwM6yCQj1 >> mhUAnjPKJPyTk0pQh0MmQjArN099laeY >> =gQDY >> -----END PGP SIGNATURE----- >> > > Lloyd Wood > L.Wood at surrey.ac.uk > http://sat-net.com/L.Wood > > > Lloyd Wood L.Wood at surrey.ac.uk http://sat-net.com/L.Wood From nbaldo at cttc.es Mon Aug 30 08:29:55 2010 From: nbaldo at cttc.es (Nicola Baldo) Date: Mon, 30 Aug 2010 17:29:55 +0200 Subject: [Ns-developers] MacRxMiddle::SequenceControlSmaller method In-Reply-To: <587D5338-C278-4DE1-9C62-B9BE6360283D@gmail.com> References: <587D5338-C278-4DE1-9C62-B9BE6360283D@gmail.com> Message-ID: <4C7BCE73.40308@cttc.es> I filed bug 988 to keep track of this issue. Please continue the discussion there: http://www.nsnam.org/bugzilla/show_bug.cgi?id=988 Nicola On 08/17/2010 07:46 PM, Mirko Banchi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Mathieu and all, > > i'd like take a look at the function > MacRxMiddle::SequenceControlSmaller. The first question is: what this > function does? I suppose that it is used to figure out if a packet is an > "old" packet or not. Standard specifies that range of sequence number > are splitted in two parts: one corresponds to packets that can be > considered new and one to packets that can be considered old. For > simplicity we can consider a smaller range, for example, of 10 sequence > numbers so with an initial sequence number equals to 7 suppose to have > next situation: > > 0 1 2 3 4 5 6 7 8 9 > * * | | | | | * * * > > * = new packet > | = old packet > > Now i used that function to discover if the packet number 2 is old or > new in comparison to packet number 7. So i used that logic (modified > accordingly) but the function returns the following results: > > SequenceControlSmaller (7<<4, 2<<4) = true > SequenceControlSmaller (2<<4, 7<<4) = false > > I think that the function should return always true because if 7 is an > old packet 2 in a new one and vice versa. What do you think about? > > Second question: who uses this function?It seems that it never > used...this function would be very useful to me... what do you think > about moving it to qos-utils.h? > > Regards, > > M. > > - -- > Mirko Banchi > > e-mail: mk.banchi at gmail.com > id-jabber: mk.banchi at jabber.org > > PGP key fingerprint: > > 308F BFB1 4E67 2522 C88E > DC69 7631 52ED 32A5 6456 > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkxqytkACgkQdjFS7TKlZFZ3AQCbBKDiQK4toH7Cqz64xbAiwLga > srEAn2znmXijDYpqVyS25sVe39h7ZqF4 > =pBBA > -----END PGP SIGNATURE----- From nbaldo at cttc.es Mon Aug 30 09:41:10 2010 From: nbaldo at cttc.es (Nicola Baldo) Date: Mon, 30 Aug 2010 18:41:10 +0200 Subject: [Ns-developers] Importance of processing delays accounting. In-Reply-To: References: Message-ID: <4C7BDF26.6020707@cttc.es> Hi Elena, sorry for the late reply. Please find a few comments below. On 08/04/2010 02:30 PM, Elena Buchatskaya wrote: > Generally speaking none of the ns-3 models account for processing > delays. The necessity of adding random delay in Wi-Fi module has > already been discussed (see bug 912), but I think the more general > solution is desirable. We need to model non-deterministic processing > delays at various OSI layers. I propose to add a adjustable delay: > 1) between the IP and Wi-Fi MAC layers to accommodate the processing > time at the IP layer. This is the time needed to to look up routes in > a routing table, to recompute the checksum of the IP header as well as > the time needed to prepare the packet for further transmission. > 2) between MAC and PHY layers to accommodate the processing time at > the MAC layer and time required to copy packet for kernel space to the > device. I agree with modeling the time required to copy packet from kernel space to the device; I think the right point to do it is upon enqueueing the packet onto DcaTxop. However, I am not sure about adding a random delay between the MAC and the PHY. In my experience, most of the delay at the MacLow level and below is due to the processing done by the MAC (e.g., CRC calculation), is tightly bounded by the standard (e.g., by SIFS timing) and in commercial devices it is almost deterministic (some colleagues of mine measured a standard deviation below one microsecond for the delay between a DATA packet and its ACK). What would be the purpose of introducing such a model in ns-3? Regards, Nicola From tpecorella at mac.com Mon Aug 30 17:15:18 2010 From: tpecorella at mac.com (Tommaso Pecorella) Date: Tue, 31 Aug 2010 02:15:18 +0200 Subject: [Ns-developers] Update on ns-3 802.11n Message-ID: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> Hi all, After the summer I'm back on track (I hope) and I count on starting some serious work toward 802.11n support in ns-3. So I guessed to give news about the current status and the path to achieve it. There are some major points to handle to achieve 11n support, so any feedback is appreciated. In order of importance, they are: 1) new preambles. 2) new coding schemes (and the various related timings) 3) mixed mode operations (b/g/n) 4) 20/40 support 5) MIMO support 6) AMPDU aggregation Even if from a "user" point of view probably the most exciting and interesting thing would be to have the raw power of 11n, as is the MIMO and 20/40 stuff, they are not the first thing in my list, and that for a number of reasons. Preambles and coding schemes are blocking features, as is they *have* to be implemented. Coding schemes, being quite similar to 11a ones, should not be a big issue. Preambles on the contrary are quite harder, as to my best knowledge ns-3 use everywhere the long preambles. Hence first I'll have to figure out how to let the nodes decide about the preambles. Btw, in the process probably we'll have the support for the short preambles as well as an "unplanned" feature. Mixed modes should go smooth as well, as it is a feature coming directly from negotiations. On this point however I have some doubts. How much do we need to support the case of an 11n AP having mixed nodes associated, as is some 11n, some 11g and some 11b? Theoretically they're backward compatible, so it's only a matter of choosing what is the degree of flexibility we want to have in the simulations. BTW, this raises also another point, also 11b have the short preambles as optionals, so we also should have an attribute or something to allow/forbid the use of short preambles in 11b nodes. Maybe I should open a bug just for this. After solving the preambles things ofc, right now it's pointless. 20/40 support is planned, but not immediately. Moreover it will probably have to be managed alongside with... MIMO :P Now, MIMO support is really giving me headaches, as: a) it will basically mean to have up to 4 data flows (and more attributes to set the number of antennas in a node). b) there are also the combinations of different coding rates, not only the sum of the basic ones. If we handle them as more possible modcods, we'll end up with thousands of them. If we handle them "just" as parallel flows it will require some heavy work on the lower layers. And that's why I wouldn't mind delaying those features, consolidating first points 1 and 2. As for the missing aggregation, I feel that this is not a big issue. We can live without it for the time being, or work on it in parallel with the other features. So, the plan right now is to concentrate on having a basic support for the 1 antenna terminals, with the right preambles, modcods and mixed mode operations. When that will be consolidated, we will start adding the missing features. Comments and feedbacks are greatly appreciated. Best regards, Tommaso -------------------------------------------------------------- The nice thing about standards is that there are so many to choose from. And if you really don't like all the standards you just have to wait another year until the one arises you are looking for. -- A. Tanenbaum, "Introduction to Computer Networks" -------------------------------------------------------------- Tommaso Pecorella - Ph.D. Assistant professor Dpt. Elettronica e Telecomunicazioni Universit? di Firenze CNIT - Universit? di Firenze Unit via di S. Marta 3 50139, Firenze ITALY email: tommaso.pecorella at unifi.it tommaso.pecorella at cnit.it phone : +39-055-4796412 mobile: +39-320-4379803 fax : +39-055-494569 From tpecorella at mac.com Mon Aug 30 17:33:34 2010 From: tpecorella at mac.com (Tommaso Pecorella) Date: Tue, 31 Aug 2010 02:33:34 +0200 Subject: [Ns-developers] ns-3, 802.15.4 + 6LoWPAN Message-ID: <1C7AD4B2-B409-430C-BD77-8D70D147B006@mac.com> Hi all, just a short news: due to a project we're involved with, we'll start developing/porting the 802.15.4 stack support in ns-3. I know there was a quite good 802.15.4 stack for ns-2, so we'll probably start with that one. Right now I can't be totally sure about how far we'll go into it, but the plan (a rather ambitious one considering the amount of people involved, as is always too few) is: 1) 802.15.4 stack 2) 6LoWPAN (not the full stack probably, but the basic support for sure) 3) ?IP (very unsure about it, as "normal" IPv6 stacks might be good enough) To my best knowledge no one is working on it, but I'd be happy to be proven wrong. We do *not* plan to integrate in it fancy stuff like RPL and other routing schemes, or at least we don't plan to do it right now as it's not the focus of the project we're in. Of course this doesn't mean we're not interested in routing, just that we have some time constraints, so we can't fit in also that one. BTW, by "we" I mean our Laboratory, so hopefully I'll not be the one (or not the only one) pestering for code suggestions and reviews. Best regards, Tommaso -------------------------------------------------------------- The nice thing about standards is that there are so many to choose from. And if you really don't like all the standards you just have to wait another year until the one arises you are looking for. -- A. Tanenbaum, "Introduction to Computer Networks" -------------------------------------------------------------- Tommaso Pecorella - Ph.D. Assistant professor Dpt. Elettronica e Telecomunicazioni Universit? di Firenze CNIT - Universit? di Firenze Unit via di S. Marta 3 50139, Firenze ITALY email: tommaso.pecorella at unifi.it tommaso.pecorella at cnit.it phone : +39-055-4796412 mobile: +39-320-4379803 fax : +39-055-494569 From mathieu.lacage at sophia.inria.fr Mon Aug 30 22:49:11 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 31 Aug 2010 07:49:11 +0200 Subject: [Ns-developers] Update on ns-3 802.11n In-Reply-To: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> References: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> Message-ID: <1283233751.2545.1.camel@mathieu-laptop> On Tue, 2010-08-31 at 02:15 +0200, Tommaso Pecorella wrote: > There are some major points to handle to achieve 11n support, so any > feedback is appreciated. In order of importance, they are: > 1) new preambles. > 2) new coding schemes (and the various related timings) > 3) mixed mode operations (b/g/n) > 4) 20/40 support > 5) MIMO support > 6) AMPDU aggregation > > Even if from a "user" point of view probably the most exciting and > interesting thing would be to have the raw power of 11n, as is the > MIMO and 20/40 stuff, they are not the first thing in my list, and > that for a number of reasons. > > Preambles and coding schemes are blocking features, as is they *have* > to be implemented. Coding schemes, being quite similar to 11a ones, > should not be a big issue. Preambles on the contrary are quite harder, > as to my best knowledge ns-3 use everywhere the long preambles. Hence The PHY should use the preambles that the MAC programs and the MAC was designed so that it uses the preambles that the WifiRemoteStationManager tells. i.e., you would need to add support for dynamically choosing the preamble to usein that class and use it from the MAC. Mathieu -- Mathieu Lacage Tel: +33 4 9238 5056 From wzssyqa at gmail.com Tue Aug 31 00:44:23 2010 From: wzssyqa at gmail.com (YunQiang Su) Date: Tue, 31 Aug 2010 15:44:23 +0800 Subject: [Ns-developers] About nsc on Debian/Kfreebsd Message-ID: How to use nsc in ns-3? Just link to them when need? After builded, it have liblinux2.6.18.so and liblinux2.6.18.so. And on Debian/Kfreebsd it still attemps to build liblinux but freebsd5 ? why? https://buildd.debian.org/fetch.cgi?pkg=ns3;ver=3.9-1;arch=kfreebsd-i386;stamp=1283153974 -- YunQiang Su From nbaldo at cttc.es Tue Aug 31 03:16:37 2010 From: nbaldo at cttc.es (Nicola Baldo) Date: Tue, 31 Aug 2010 12:16:37 +0200 Subject: [Ns-developers] Update on ns-3 802.11n In-Reply-To: <1283233751.2545.1.camel@mathieu-laptop> References: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> <1283233751.2545.1.camel@mathieu-laptop> Message-ID: <4C7CD685.8040403@cttc.es> On 08/31/2010 07:49 AM, Mathieu Lacage wrote: > On Tue, 2010-08-31 at 02:15 +0200, Tommaso Pecorella wrote: >> >> Preambles and coding schemes are blocking features, as is they *have* >> to be implemented. Coding schemes, being quite similar to 11a ones, >> should not be a big issue. Preambles on the contrary are quite harder, >> as to my best knowledge ns-3 use everywhere the long preambles. Hence > > The PHY should use the preambles that the MAC programs and the MAC was > designed so that it uses the preambles that the WifiRemoteStationManager > tells. i.e., you would need to add support for dynamically choosing the > preamble to usein that class and use it from the MAC. > In principle yes, but I am not sure whether this approach is practical. Please have a look at the discussion for bug 917, which is about the setting of the TX power (which has exactly the same problems as the preamble): http://www.nsnam.org/bugzilla/show_bug.cgi?id=917 To summarize my position on the topic, I wonder whether we should avoid passing TX power and preamble as arguments to WifiPhy::SendPacket(), and have them as WifiPhy attributes instead. Nicola From mathieu.lacage at sophia.inria.fr Tue Aug 31 04:43:44 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 31 Aug 2010 13:43:44 +0200 Subject: [Ns-developers] Update on ns-3 802.11n In-Reply-To: <4C7CD685.8040403@cttc.es> References: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> <1283233751.2545.1.camel@mathieu-laptop> <4C7CD685.8040403@cttc.es> Message-ID: <1283255024.14071.5.camel@diese.inria.fr> On Tue, 2010-08-31 at 12:16 +0200, Nicola Baldo wrote: > In principle yes, but I am not sure whether this approach is practical. > Please have a look at the discussion for bug 917, which is about the > setting of the TX power (which has exactly the same problems as the > preamble): > http://www.nsnam.org/bugzilla/show_bug.cgi?id=917 I honestly don't have time to read the details of that lengthy bug report but it looks like you are mostly concerned about complexity of delegating the tx power decision to the remote station vs using a constant in the PHY. Yes, it's more complex. > To summarize my position on the topic, I wonder whether we should avoid > passing TX power and preamble as arguments to WifiPhy::SendPacket(), and > have them as WifiPhy attributes instead. My personal experience is that if you don't take time to do this yourself, none of those with experience in this kind of rate control/tx power adaptation will do it. i.e., the onus of providing a clean API is on the maintainer :) That being said, it's your call, not mine. my 2 cents, Mathieu From nbaldo at cttc.es Tue Aug 31 05:30:33 2010 From: nbaldo at cttc.es (Nicola Baldo) Date: Tue, 31 Aug 2010 14:30:33 +0200 Subject: [Ns-developers] Update on ns-3 802.11n In-Reply-To: <1283255024.14071.5.camel@diese.inria.fr> References: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> <1283233751.2545.1.camel@mathieu-laptop> <4C7CD685.8040403@cttc.es> <1283255024.14071.5.camel@diese.inria.fr> Message-ID: <4C7CF5E9.5090103@cttc.es> On 08/31/2010 01:43 PM, Mathieu Lacage wrote: > On Tue, 2010-08-31 at 12:16 +0200, Nicola Baldo wrote: > >> In principle yes, but I am not sure whether this approach is practical. >> Please have a look at the discussion for bug 917, which is about the >> setting of the TX power (which has exactly the same problems as the >> preamble): >> http://www.nsnam.org/bugzilla/show_bug.cgi?id=917 > > I honestly don't have time to read the details of that lengthy bug > report but it looks like you are mostly concerned about complexity of > delegating the tx power decision to the remote station vs using a > constant in the PHY. Yes, it's more complex. The real issue is that the problem is not well defined. The WifiManager API was developed for Rate Adaptation in mind, and with several well-defined use cases (all those WifiMangers that you implemented). Now, we are just talking about a feature request: "it would be nice to have an API for TX power adaptation and preamble adaptation". But, I see no real use case as of now: is anybody interesting in implementing a TX power adaptation algorithm? A preamble adapatation algorithm? I would be glad if somebody were, but so far nobody said that. I am not interested in implementing these algorithms. I wouldn't even know what algorithm to implement, if I were to implement one. An API designed in such a situation is just a guess. > >> To summarize my position on the topic, I wonder whether we should avoid >> passing TX power and preamble as arguments to WifiPhy::SendPacket(), and >> have them as WifiPhy attributes instead. > > My personal experience is that if you don't take time to do this > yourself, none of those with experience in this kind of rate control/tx > power adaptation will do it. i.e., the onus of providing a clean API is > on the maintainer :) I already spent some time coming up with API proposals for the case where all adaptation is done in WifiManager. I just don't like the resulting API, and have strong doubts that people will actually use it. That's why I am wondering whether simpler solutions, such as having the TX power and preamble in WifiPhy, might be better. Regards, Nicola From jens.mittag at kit.edu Tue Aug 31 05:50:31 2010 From: jens.mittag at kit.edu (Jens Mittag) Date: Tue, 31 Aug 2010 14:50:31 +0200 Subject: [Ns-developers] Update on ns-3 802.11n In-Reply-To: <4C7CF5E9.5090103@cttc.es> References: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> <1283233751.2545.1.camel@mathieu-laptop> <4C7CD685.8040403@cttc.es> <1283255024.14071.5.camel@diese.inria.fr> <4C7CF5E9.5090103@cttc.es> Message-ID: <4C7CFA97.5070300@kit.edu> Hi Nicola, On 31.08.2010 14:30, Nicola Baldo wrote: > I already spent some time coming up with API proposals for the case > where all adaptation is done in WifiManager. I just don't like the > resulting API, and have strong doubts that people will actually use it. > That's why I am wondering whether simpler solutions, such as having the > TX power and preamble in WifiPhy, might be better. I would keep the possibility to set the TX power on a per packet base, since this is also the way how a real chipset implements it. Afaik, the TXpower parameters is also part of the transmission request interface in 802.11 PHY. For preamble format, I agree to follow your proposal. An adaptation mechanism can still adapt these parameters through the attribute system if it wants to. Another solution would be to use a cross-layer information base that stores the WiFi configuration parameters that are not provided on a per packet base... Just my 2 cents Jens -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Zirkel 1, 76131 Karlsruhe, Germany Building 20.20, Room 356.1 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5833 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20100831/8fb48dc1/smime-0001.bin From mathieu.lacage at sophia.inria.fr Tue Aug 31 06:06:24 2010 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 31 Aug 2010 15:06:24 +0200 Subject: [Ns-developers] Update on ns-3 802.11n In-Reply-To: <4C7CF5E9.5090103@cttc.es> References: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> <1283233751.2545.1.camel@mathieu-laptop> <4C7CD685.8040403@cttc.es> <1283255024.14071.5.camel@diese.inria.fr> <4C7CF5E9.5090103@cttc.es> Message-ID: <1283259984.14071.28.camel@diese.inria.fr> On Tue, 2010-08-31 at 14:30 +0200, Nicola Baldo wrote: > The real issue is that the problem is not well defined. The WifiManager > API was developed for Rate Adaptation in mind, and with several > well-defined use cases (all those WifiMangers that you implemented). I actually did it that way also with the tx power and preamble thing in mind. At least, that was the plan from the start. I just never got to work on this kind of algorithm or implement an existing one (yes, there is some published stuff). > Now, we are just talking about a feature request: "it would be nice to > have an API for TX power adaptation and preamble adaptation". But, I see > no real use case as of now: is anybody interesting in implementing a TX > power adaptation algorithm? A preamble adapatation algorithm? I would be > glad if somebody were, but so far nobody said that. I am not interested > in implementing these algorithms. I wouldn't even know what algorithm to > implement, if I were to implement one. An API designed in such a > situation is just a guess. What I would have expected is merely a delegate to the WifiRemoteStationManager with a default stupid implementation (say, use the constant you want to put in the PHY) that can be overriden entirely by subclasses should they want to. Something like the maximum retry threshold. For tx power, it should be sufficient. For the preamble thing, it's more tricky because the preamble type should be chosen depending also on the capabilities of the remote station. The short preamble is allowed only when the remote side explicitely supports it so you need to keep track of the supported preambles for each remote. > >> To summarize my position on the topic, I wonder whether we should avoid > >> passing TX power and preamble as arguments to WifiPhy::SendPacket(), and > >> have them as WifiPhy attributes instead. > > > > My personal experience is that if you don't take time to do this > > yourself, none of those with experience in this kind of rate control/tx > > power adaptation will do it. i.e., the onus of providing a clean API is > > on the maintainer :) > > I already spent some time coming up with API proposals for the case Those proposals were in the bug report, I presume ? > where all adaptation is done in WifiManager. I just don't like the > resulting API, and have strong doubts that people will actually use it. This is the old egg or chicken first dilemma... > That's why I am wondering whether simpler solutions, such as having the > TX power and preamble in WifiPhy, might be better. It is certainly simpler. Anyway, I don't intend to force the decision in any direction but I wanted to point out what the original intention was when the code was written. Again, whether or not you intend to go in that direction is your call: I don't intend to work on any of that stuff anymore :) Mathieu From tpecorella at mac.com Tue Aug 31 08:09:20 2010 From: tpecorella at mac.com (Tommaso Pecorella) Date: Tue, 31 Aug 2010 17:09:20 +0200 Subject: [Ns-developers] Update on ns-3 802.11n In-Reply-To: <1283259984.14071.28.camel@diese.inria.fr> References: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> <1283233751.2545.1.camel@mathieu-laptop> <4C7CD685.8040403@cttc.es> <1283255024.14071.5.camel@diese.inria.fr> <4C7CF5E9.5090103@cttc.es> <1283259984.14071.28.camel@diese.inria.fr> Message-ID: I didn't look at the power issues, but for the preamble I think it's not a problem of "adaptation", as their use is a feature/capabilities thing. Let's consider the case of 802.11b/g case. An 802.11g terminal (either AP or UT) must be able to use both short and long preambles. On the contrary 802.11b have only long preambles as mandatory, short are optionals. So the "logic" behind the preambles is quite hardcoded: use short ones unless the AP have an 11b UT associated that does not have the short preambles capabilities. As far as I know, that is the only case where long preambles have to be used (I should recheck the RTS/CTS and other control frames tho, I'm not totally sure). The very same goes for 11n. Anyway, beside the case of association / deassociation of terminals, I can't really see why we should have an algorithm to choose dynamically the preamble type. On the opposite, it could be interesting to vary the dynamic tx power dynamically, even at packet-level (not at a smaller scale, it's unrealistic). Said so, I'll think about the possible points on where to place the preamble type, but for sure we'll need two informations: the terminal capabilities and the actual preamble used, with the latter being changed by the actual working simulation. I'll be away for some days, but I'll try to find out in the standards the exact way the preambles are chosen (and dynamically changed) in both 11g and 11n. Best regards, Tommaso On 31/ago/2010, at 15.06, Mathieu Lacage wrote: > On Tue, 2010-08-31 at 14:30 +0200, Nicola Baldo wrote: > >> The real issue is that the problem is not well defined. The WifiManager >> API was developed for Rate Adaptation in mind, and with several >> well-defined use cases (all those WifiMangers that you implemented). > > I actually did it that way also with the tx power and preamble thing in > mind. At least, that was the plan from the start. I just never got to > work on this kind of algorithm or implement an existing one (yes, there > is some published stuff). > >> Now, we are just talking about a feature request: "it would be nice to >> have an API for TX power adaptation and preamble adaptation". But, I see >> no real use case as of now: is anybody interesting in implementing a TX >> power adaptation algorithm? A preamble adapatation algorithm? I would be >> glad if somebody were, but so far nobody said that. I am not interested >> in implementing these algorithms. I wouldn't even know what algorithm to >> implement, if I were to implement one. An API designed in such a >> situation is just a guess. > > What I would have expected is merely a delegate to the > WifiRemoteStationManager with a default stupid implementation (say, use > the constant you want to put in the PHY) that can be overriden entirely > by subclasses should they want to. Something like the maximum retry > threshold. For tx power, it should be sufficient. For the preamble > thing, it's more tricky because the preamble type should be chosen > depending also on the capabilities of the remote station. The short > preamble is allowed only when the remote side explicitely supports it so > you need to keep track of the supported preambles for each remote. > >>>> To summarize my position on the topic, I wonder whether we should avoid >>>> passing TX power and preamble as arguments to WifiPhy::SendPacket(), and >>>> have them as WifiPhy attributes instead. >>> >>> My personal experience is that if you don't take time to do this >>> yourself, none of those with experience in this kind of rate control/tx >>> power adaptation will do it. i.e., the onus of providing a clean API is >>> on the maintainer :) >> >> I already spent some time coming up with API proposals for the case > > Those proposals were in the bug report, I presume ? > >> where all adaptation is done in WifiManager. I just don't like the >> resulting API, and have strong doubts that people will actually use it. > > This is the old egg or chicken first dilemma... > >> That's why I am wondering whether simpler solutions, such as having the >> TX power and preamble in WifiPhy, might be better. > > It is certainly simpler. > > Anyway, I don't intend to force the decision in any direction but I > wanted to point out what the original intention was when the code was > written. Again, whether or not you intend to go in that direction is > your call: I don't intend to work on any of that stuff anymore :) > > Mathieu > -------------------------------------------------------------- $25: for you a pizza and some beers with friends, for someone might change their lives. Think about it. Kiva.org - Loans That Change Lives -------------------------------------------------------------- Tommaso Pecorella - Ph.D. Assistant professor Dpt. Elettronica e Telecomunicazioni Universit? di Firenze CNIT - Universit? di Firenze Unit via di S. Marta 3 50139, Firenze ITALY email: tommaso.pecorella at unifi.it tommaso.pecorella at cnit.it phone : +39-055-4796412 mobile: +39-320-4379803 fax : +39-055-494569 From g.piro at poliba.it Tue Aug 31 09:15:27 2010 From: g.piro at poliba.it (Giuseppe Piro) Date: Tue, 31 Aug 2010 18:15:27 +0200 Subject: [Ns-developers] Request a review for LTE module Message-ID: Dear all, after the GSoC project I would like to merge the LTE module to the ns-3-dev. I hope that there are people available for the review and that I can merge the code for the ns-3.10 release. In the wollows there are some information about the code and the description of the module: repository: http://code.nsnam.org/giuseppepiro/ns-3-lte/ code review: http://codereview.appspot.com/1869054/show module description: http://www.nsnam.org/wiki/index.php/GSOC2010MACPHYforLTEand http://www.nsnam.org/wiki/index.php/GSOC2010MACPHYforLTE/MidTermReport Any suggestions and feedbacks are welcomed! Best regards, Giuseppe Piro From nbaldo at cttc.es Tue Aug 31 09:39:12 2010 From: nbaldo at cttc.es (Nicola Baldo) Date: Tue, 31 Aug 2010 18:39:12 +0200 Subject: [Ns-developers] Update on ns-3 802.11n In-Reply-To: <1283259984.14071.28.camel@diese.inria.fr> References: <30BE3DF5-1C4A-4C6B-AF15-72A8C58E675B@mac.com> <1283233751.2545.1.camel@mathieu-laptop> <4C7CD685.8040403@cttc.es> <1283255024.14071.5.camel@diese.inria.fr> <4C7CF5E9.5090103@cttc.es> <1283259984.14071.28.camel@diese.inria.fr> Message-ID: <4C7D3030.8000301@cttc.es> On 08/31/2010 03:06 PM, Mathieu Lacage wrote: > On Tue, 2010-08-31 at 14:30 +0200, Nicola Baldo wrote: >> I already spent some time coming up with API proposals for the >> case > > Those proposals were in the bug report, I presume ? Yes. Mathieu Lacage wrote: > What I would have expected is merely a delegate to the > WifiRemoteStationManager with a default stupid implementation (say, > use the constant you want to put in the PHY) that can be overriden > entirely by subclasses should they want to. Something like the > maximum retry threshold. For tx power, it should be sufficient. I had started with this idea and came out with this patch: http://www.nsnam.org/bugzilla/attachment.cgi?id=946 the patch is largely incomplete because I didn't like what was coming out. In particular, I was concerned with the difficulting of implementing joint power and rate adaptation with such an API. I had tried to summarize the pros and cons of this approach in this comment: http://www.nsnam.org/bugzilla/show_bug.cgi?id=917#c13 feedback would be very much appreciated. Jens Mittag wrote: > I would keep the possibility to set the TX power on a per packet > base, since this is also the way how a real chipset implements it. > Afaik, the TXpower parameters is also part of the transmission > request interface in 802.11 PHY. You mean the TXVECTOR defined in the standard, right? This is what I tried to introduce with this other patch: http://www.nsnam.org/bugzilla/attachment.cgi?id=947 pros and cons were discussed in this comment: http://www.nsnam.org/bugzilla/show_bug.cgi?id=917#c14 again, feedback would be very much appreciated. Mathieu Lacage wrote: > For the preamble thing, it's more tricky because the preamble type > should be chosen depending also on the capabilities of the remote > station. The short preamble is allowed only when the remote side > explicitely supports it so you need to keep track of the supported > preambles for each remote. > I don't think this is mandated by the standard. See IEEE Std. 802.11-2007, Section 18.2.1: "The optional short preamble and header is intended for applications where maximum throughput is desired and interoperability with legacy and nonshort-preamble-capable equipment is not a consideration. That is, it is expected to be used only in networks of like equipment, which can all handle the optional mode". Jens Mittag wrote: > For preamble format, I agree to follow your proposal. An adaptation mechanism can still adapt these parameters through the attribute system if it wants to. It might make sense to do what you propose, i.e., leave TX power in WifiPhy::SendPacket, but take the preamble out. In fact, according to the standard, the preamble is not part of the TXVECTOR. It would be also to know what is done in drivers such as madwifi and ath5k. Nicola From perrone at bucknell.edu Tue Aug 31 12:30:24 2010 From: perrone at bucknell.edu (Felipe Perrone) Date: Tue, 31 Aug 2010 15:30:24 -0400 Subject: [Ns-developers] terminating an ns-3 run Message-ID: <015C709E-9A51-495F-82CA-D3BA867D460C@bucknell.edu> Hello ns-3 developers, I'm working on a external mechanism to determine the length of an ns-3 run automatically. This mechanism will analyze a collection of samples stored in a database to determine if the ns-3 run can end and then take action to interrupt, that is, terminate, the run. One could install a signal handler for the ns-3 run (SIGKILL perhaps) and have this handler go through the appropriate sequence of actions to shut down the simulation properly (that is, make calls to Stop() and Destroy(), flush output streams, etc.) Please let me know if you have suggestions/advice on how this should be implemented. Cheers, Felipe ------------------------------------------------------------ Luiz Felipe Perrone, Associate Professor Dept. of Computer Science, Breakiron 68 Bucknell University, Lewisburg, PA 17837 Voice: +1-570-577-1687 Fax: +1-570-577-1258 Skype: luiz.felipe.perrone Web: http://www.eg.bucknell.edu/~perrone/ ------------------------------------------------------------