From oriandmish at gmail.com Sat Aug 1 10:21:21 2009 From: oriandmish at gmail.com (ori and mish bgu) Date: Sat, 1 Aug 2009 20:21:21 +0300 Subject: [Ns-developers] Statistics Module for Mac layers In-Reply-To: References: Message-ID: Hi Everybody We tried to ask at ns-users, google it and searched in some books without any luck, maybe someone here can help us abit .. We want to build a module (object) that gatheres statistics from all our mac layers, but we can't get a pointer to our mac layers from above. We tried to access mac layer from God, because God has pointers to all mobilenodes but we can't access from there to mac because we don't know how to access to our mac from mobilenode :/ What are we missing ? anyone has any idea how can we implement it ? Thanks in advance Ori and Michael From mathieu.lacage at sophia.inria.fr Mon Aug 3 03:04:18 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 03 Aug 2009 03:04:18 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200908031004.n73A4JJ0021371@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/127 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed failed slave lost sincerely, -The Buildbot From dnlove at gmail.com Wed Aug 5 16:18:48 2009 From: dnlove at gmail.com (Duy Nguyen) Date: Wed, 5 Aug 2009 16:18:48 -0700 Subject: [Ns-developers] bug: udp close socket is not working Message-ID: <70f6a1ed0908051618q277d4113w3f73264fd7f976c5@mail.gmail.com> Hi everyone, the udp close socket function does not work. I look it up in src/internet-stack/udp-socket-impl.cc, and realize that there is no implementation of close socket. in the file src/internet-stack/udp-socket-impl.cc, Close(void) is an empty function. int UdpSocketImpl::Close(void) { NS_LOG_FUNCTION_NOARGS (); return 0; } Duy From tomh at tomh.org Wed Aug 5 20:57:51 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 05 Aug 2009 20:57:51 -0700 Subject: [Ns-developers] bug: udp close socket is not working In-Reply-To: <70f6a1ed0908051618q277d4113w3f73264fd7f976c5@mail.gmail.com> References: <70f6a1ed0908051618q277d4113w3f73264fd7f976c5@mail.gmail.com> Message-ID: <4A7A54BF.3040505@tomh.org> Duy Nguyen wrote: > Hi everyone, the udp close socket function does not work. I look it up > in src/internet-stack/udp-socket-impl.cc, and realize that there is no > implementation of close socket. > > in the file src/internet-stack/udp-socket-impl.cc, Close(void) is an > empty function. > > int > UdpSocketImpl::Close(void) > { > NS_LOG_FUNCTION_NOARGS (); > return 0; > } > > > Duy > > Is this patch adequate? http://www.nsnam.org/bugzilla/show_bug.cgi?id=649 From tomh at tomh.org Thu Aug 6 14:50:33 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 06 Aug 2009 15:50:33 -0600 Subject: [Ns-developers] NetDevice link change callback In-Reply-To: <1248773029.8162.8.camel@localhost.localdomain> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> Message-ID: <87e5008df199e72b24526a238b4e9221@tomh.org> (sorry for the delay in replying) On Tue, 28 Jul 2009 11:23:49 +0200, Mathieu Lacage wrote: > On Mon, 2009-07-27 at 14:46 -0700, Tom Henderson wrote: > >> 1) use of TracedCallback? >> Another option is to use a TracedCallback here, which some other >> developers have recommended in the past to use when there needs to be a >> list of callbacks. >> >> I don't have a strong opinion but this question keeps popping up (also >> in Qasim's conntrack code) so I think we should clarify whether >> TracedCallback should also be used in non-tracing scenarios whenever you >> want a std::list of callbacks, or whether we want another general >> CallbackList of some sort that is not used by tracing code. > > I think that all you would need to make TracedCallback generic is change > its name to something which does not include 'Trace'. i.e., its API and > implementation has no dependency on the tracing code. Maybe what would be best is to add something like the CallbackList suggested but allow user to optionally specify order or priority of callbacks-- if no priority is specified, they all get priority 0 and it behaves like TracedCallback. > >> 2) should we report link change, or link up? >> The method name is not really suggestive of how the callback works, >> which does not call when the link changes in all cases but only when the >> link goes to up. So, I would suggest either "AddLinkUpCallback" or >> "SetLinkChangeCallback" with an extra argument such as an enum for Up or >> Down. > > The current implementation reports link change events, not link up > events. i.e., see src/devices/wifi/wifi-net-devices.cc. The current API > documentation in src/node/net-device.h should be improved instead of > changing the method name I think. Only WifiNetDevice reports all link changes, but you can't tell from the callback what type of event it was. The other devices (PointToPoint, Csma, Emu) just call it upon going up, perhaps because they can't go down (it is really only used at node startup time). > >> I think others have raised the question "can I put a NetDevice into down >> state?" and presently the answer is no, but in practice, IFF_UP flag of >> a netdevice is settable, and it seems like we might want to add the >> capability to configure an interface to down state, which would trigger >> upcalls to both Ipv4 and Ipv6 stacks (and to the routing protocols). > > What would be the expected semantics of that flag exactly ? Would you > expect the NetDevice subclasses to honor calling SetIfDown by ignoring > packets being passed down with NetDevice::Send* ? > Yes. I would try to match it to what happens in a real system when "ifconfig eth0 down" is called. Note that this typically will trigger upcalls or netlink notifications, which cause the upper layer to refrain from sending packets down to it when it is in a down state. Tom From tomh at tomh.org Thu Aug 6 16:00:24 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 06 Aug 2009 17:00:24 -0600 Subject: [Ns-developers] ipv6 plans for ns-3 In-Reply-To: <4A71EA53.9020709@clarinet.u-strasbg.fr> References: <36caa09167fd3a8199d20efc14211f2c@tomh.org> <4A5381E1.5090602@clarinet.u-strasbg.fr> <4A65BC4F.6070500@clarinet.u-strasbg.fr> <4A6868B3.6040508@tomh.org> <4A696E6F.8080606@clarinet.u-strasbg.fr> <004b01ca0c5c$c6e966f0$54bc34d0$@ch> <4A6D7E12.8030201@clarinet.u-strasbg.fr> <4A71EA53.9020709@clarinet.u-strasbg.fr> Message-ID: On Thu, 30 Jul 2009 20:45:39 +0200, S?bastien Vincent wrote: > Hi all, > > New features: > - RA handler to autoconfigure address and default route; > - Radvd application made scratch (not reused radvd stuff from ns-3-ipv6 > old repository); > - Two new examples: radvd and radvd-two-prefix. The last ones advertise > two prefixes in RA. > > By the way I added in Ipv6RoutingProtocol, two methods for adding > routes. It is needed for ICMPv6 redirect (which add a host route to > redirected target), and to configure the default route when receive > first RA's prefix: NotifyAddRoute and NotifyRemoveRoute. > I am not sure about the above Ipv6RoutingProtocol changes. It seems like what you want to do is to get a handle on a static routing object and add a host route directly, but you are instead providing a notification to all routing protocols (as in RTM_NEWROUTE). > To summarize what is done now in > https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd: > - IPv6 interface; > - IPv6 layer; > - IPv6 raw socket; > - Static IPv6 routing; > - ICMPv6 layer; > - Some ICMPv6 error messages (destination unreachable, ...); > - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); > - Ping6 application (send Echo request); > - Radvd application (send RA); > - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, > icmpv6-redirect). > > My holidays ends by monday, as I already said I will not have much time > to work on ns-3 after. > > I think that we can first review current work and give feedback. And > maybe try to merge it before continue to work on UDP/TCP. It will be > great to finally enable ns-3 users to begin make IPv6 simulations with > ICMPv6 in next ns-3 release. > I've posted this repository on ns-3-reviews in case people would like to review it there. Please review it by next Wed. or ask for more time; if no major comments, I will try to merge this later next week. http://codereview.appspot.com/105054 Many thanks for this contribution, Tom From mathieu.lacage at sophia.inria.fr Thu Aug 6 23:40:30 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 07 Aug 2009 08:40:30 +0200 Subject: [Ns-developers] NetDevice link change callback In-Reply-To: <87e5008df199e72b24526a238b4e9221@tomh.org> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> Message-ID: <1249627230.3385.11.camel@diese.inria.fr> On Thu, 2009-08-06 at 15:50 -0600, Tom Henderson wrote: > >> 1) use of TracedCallback? > >> Another option is to use a TracedCallback here, which some other > >> developers have recommended in the past to use when there needs to be a > >> list of callbacks. > >> > >> I don't have a strong opinion but this question keeps popping up (also > >> in Qasim's conntrack code) so I think we should clarify whether > >> TracedCallback should also be used in non-tracing scenarios whenever you > > >> want a std::list of callbacks, or whether we want another general > >> CallbackList of some sort that is not used by tracing code. > > > > I think that all you would need to make TracedCallback generic is change > > its name to something which does not include 'Trace'. i.e., its API and > > implementation has no dependency on the tracing code. > > Maybe what would be best is to add something like the CallbackList > suggested but allow user to optionally specify order or priority of > callbacks-- if no priority is specified, they all get priority 0 and it > behaves like TracedCallback. It's not clear to me what this priority would be used for. Do you have a specific usecase in mind ? If not, I would support simply renaming TracedCallback to NotifierCallback or something similar (better suggestions for a name would be welcome) and typedef NotifierCallback to TracedCallback to avoid changing our existing codebase. > >> 2) should we report link change, or link up? > >> The method name is not really suggestive of how the callback works, > >> which does not call when the link changes in all cases but only when the > > >> link goes to up. So, I would suggest either "AddLinkUpCallback" or > >> "SetLinkChangeCallback" with an extra argument such as an enum for Up or > > >> Down. > > > > The current implementation reports link change events, not link up > > events. i.e., see src/devices/wifi/wifi-net-devices.cc. The current API > > documentation in src/node/net-device.h should be improved instead of > > changing the method name I think. > > Only WifiNetDevice reports all link changes, but you can't tell from the > callback what type of event it was. The other devices (PointToPoint, Csma, IsLinkUp is expected to be used from within the notification callback to query the state of the link. That was the original intend of the device API design. > Emu) just call it upon going up, perhaps because they can't go down (it is > really only used at node startup time). Yes, none of them can go down which is why they never report link down events. Anyway, to summarize, I see no real need to change this API since it provides the needed functionality. What is needed is improving the doxygen which does not align with the intend of the original design. > >> I think others have raised the question "can I put a NetDevice into down > > >> state?" and presently the answer is no, but in practice, IFF_UP flag of > >> a netdevice is settable, and it seems like we might want to add the > >> capability to configure an interface to down state, which would trigger > >> upcalls to both Ipv4 and Ipv6 stacks (and to the routing protocols). > > > > What would be the expected semantics of that flag exactly ? Would you > > expect the NetDevice subclasses to honor calling SetIfDown by ignoring > > packets being passed down with NetDevice::Send* ? > > > > Yes. I would try to match it to what happens in a real system when > "ifconfig eth0 down" is called. Note that this typically will trigger > upcalls or netlink notifications, which cause the upper layer to refrain > from sending packets down to it when it is in a down state. I think that it would be nice if adding such a flag would not require adding extra send/receive logic to net device implementations but I could live with it. Mathieu From tomh at tomh.org Fri Aug 7 06:40:27 2009 From: tomh at tomh.org (Tom Henderson) Date: Fri, 07 Aug 2009 06:40:27 -0700 Subject: [Ns-developers] NetDevice link change callback In-Reply-To: <1249627230.3385.11.camel@diese.inria.fr> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> Message-ID: <4A7C2ECB.7090100@tomh.org> Mathieu Lacage wrote: > On Thu, 2009-08-06 at 15:50 -0600, Tom Henderson wrote: > >>>> 1) use of TracedCallback? >>>> Another option is to use a TracedCallback here, which some other >>>> developers have recommended in the past to use when there needs to be a >>>> list of callbacks. >>>> >>>> I don't have a strong opinion but this question keeps popping up (also >>>> in Qasim's conntrack code) so I think we should clarify whether >>>> TracedCallback should also be used in non-tracing scenarios whenever you >>>> want a std::list of callbacks, or whether we want another general >>>> CallbackList of some sort that is not used by tracing code. >>> I think that all you would need to make TracedCallback generic is change >>> its name to something which does not include 'Trace'. i.e., its API and >>> implementation has no dependency on the tracing code. >> Maybe what would be best is to add something like the CallbackList >> suggested but allow user to optionally specify order or priority of >> callbacks-- if no priority is specified, they all get priority 0 and it >> behaves like TracedCallback. > > It's not clear to me what this priority would be used for. Do you have a > specific usecase in mind ? iptables (chains of ordered rules) If not, I would support simply renaming > TracedCallback to NotifierCallback or something similar (better > suggestions for a name would be welcome) and typedef NotifierCallback to > TracedCallback to avoid changing our existing codebase. I don't care strongly; ListCallback conveys the list semantics. > >>>> 2) should we report link change, or link up? >>>> The method name is not really suggestive of how the callback works, >>>> which does not call when the link changes in all cases but only when the >>>> link goes to up. So, I would suggest either "AddLinkUpCallback" or >>>> "SetLinkChangeCallback" with an extra argument such as an enum for Up or >>>> Down. >>> The current implementation reports link change events, not link up >>> events. i.e., see src/devices/wifi/wifi-net-devices.cc. The current API >>> documentation in src/node/net-device.h should be improved instead of >>> changing the method name I think. >> Only WifiNetDevice reports all link changes, but you can't tell from the >> callback what type of event it was. The other devices (PointToPoint, Csma, > > IsLinkUp is expected to be used from within the notification callback to > query the state of the link. That was the original intend of the device > API design. > >> Emu) just call it upon going up, perhaps because they can't go down (it is >> really only used at node startup time). > > Yes, none of them can go down which is why they never report link down > events. > > Anyway, to summarize, I see no real need to change this API since it > provides the needed functionality. What is needed is improving the > doxygen which does not align with the intend of the original design. Can you clarify-- are you objecting to AddLinkChangeCallback as Sebastien suggested, or changing other aspects as I later suggested (such as changing the name or the arguments of the callback)? I am OK with what you suggest about using the API as you originally intended with IsLinkUp(), and fixing the doxygen, but it seems like Sebastien has a valid use case to make this a TracedCallback. > >>>> I think others have raised the question "can I put a NetDevice into down >>>> state?" and presently the answer is no, but in practice, IFF_UP flag of >>>> a netdevice is settable, and it seems like we might want to add the >>>> capability to configure an interface to down state, which would trigger >>>> upcalls to both Ipv4 and Ipv6 stacks (and to the routing protocols). >>> What would be the expected semantics of that flag exactly ? Would you >>> expect the NetDevice subclasses to honor calling SetIfDown by ignoring >>> packets being passed down with NetDevice::Send* ? >>> >> Yes. I would try to match it to what happens in a real system when >> "ifconfig eth0 down" is called. Note that this typically will trigger >> upcalls or netlink notifications, which cause the upper layer to refrain >> from sending packets down to it when it is in a down state. > > I think that it would be nice if adding such a flag would not require > adding extra send/receive logic to net device implementations but I > could live with it. > I think the burden here will be requiring netdevice users to register for the link change callback and process it; I don't think adding the extra NetDevice logic (shunt packets to a drop trace if the device is down) will be too difficult. Tom From oriandmish at gmail.com Sat Aug 8 04:20:40 2009 From: oriandmish at gmail.com (ori and mish bgu) Date: Sat, 8 Aug 2009 14:20:40 +0300 Subject: [Ns-developers] adding annotation box to nam Message-ID: Hi eveybody I want to add another annotation box to nam in order to print statistics information of my simulation. ( I'm already using the current annotation box for other issues and it's a mess to print all the information I want to this box). Anyone knows where should I declare it ? hope it's not too much tweaking for nam .. Thanks Michael From tomh at tomh.org Sat Aug 8 15:22:11 2009 From: tomh at tomh.org (Tom Henderson) Date: Sat, 08 Aug 2009 15:22:11 -0700 Subject: [Ns-developers] adding annotation box to nam In-Reply-To: References: Message-ID: <4A7DFA93.6080806@tomh.org> ori and mish bgu wrote: > Hi eveybody > > I want to add another annotation box to nam in order to print statistics > information of my simulation. > ( I'm already using the current annotation box for other issues and it's a > mess to print all the information I want to this box). > Anyone knows where should I declare it ? hope it's not too much tweaking for > nam .. > > Thanks > Michael Michael, I don't have an answer to your question regarding where to declare it, but I would just like to note that I don't know of anyone else who has been working on nam development for several years now. (if anyone reading on the list is doing nam development, can you let us know?) So, I would suggest that you just make your best guess, and if you think you come up with something interesting, please contribute any patches when you are ready. - Tom From faker.moatamri at sophia.inria.fr Mon Aug 10 02:41:37 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 10 Aug 2009 11:41:37 +0200 Subject: [Ns-developers] Wimax integration with ns-3-dev In-Reply-To: <4A7C2ECB.7090100@tomh.org> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> Message-ID: <4A7FEB51.2050102@sophia.inria.fr> Hi all, In order to add features to NS-3, we would like to merge the wimax module to the next NS-3 release. Wimax module has been under development for over two years now and we think that it is ready to be included in the main tree and in next release. Here is the proposed time schedule: -Monday August 17th: feature/Dev freeze, review and merge patches, testing and debugging -Thursday August 20th: Enhancement of the code to meet NS-3 standard -Wednesday August 26th: Merge with the latest version of ns-3-dev and testing -Tuesday September 1st: Submission of the proposed Wimax patch for review If you are developing some code for wimax and would like it to be merged in the next NS-3 release, please send us a patch as soon as possible and before next monday August 17th (the sooner the better) based on iamine/ns-3-wimax-dev repository. Best regards Faker Moatamri From tomh at tomh.org Mon Aug 10 06:51:29 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 10 Aug 2009 06:51:29 -0700 Subject: [Ns-developers] next ns-3 release In-Reply-To: <4A7FEB51.2050102@sophia.inria.fr> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> <4A7FEB51.2050102@sophia.inria.fr> Message-ID: <4A8025E1.7000303@tomh.org> Faker Moatamri wrote: > Hi all, > In order to add features to NS-3, we would like to merge the wimax > module to the next NS-3 release. We haven't set a date for the next release, although if we keep roughly to our current quarterly schedule, it would be around the beginning of October. I put a release page template at the below page, with a provisional date of October 7. http://www.nsnam.org/wiki/index.php/Ns-3.6 Craig agreed to be release manager again, so here is an initial page and he can start to manage the merge process. Please start to coordinate with Craig if you want to merge new features to ns-3.6. - Tom From mathieu.lacage at sophia.inria.fr Tue Aug 11 08:34:10 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 11 Aug 2009 17:34:10 +0200 Subject: [Ns-developers] GSOC: Minstrel multirate control port update In-Reply-To: <70f6a1ed0907111042s7fa790d2g72c04f5a5342382e@mail.gmail.com> References: <70f6a1ed0907111042s7fa790d2g72c04f5a5342382e@mail.gmail.com> Message-ID: <1250004850.12645.22.camel@diese.inria.fr> hi duy, I looked at your code for merging in ns-3-dev: overall, it looks nice so, thank you for working on this. I am sure we can merge this quickly if you can take some time to address my comments below. 0) copyright: it's not "the ns-3 project" because there is no such thing. It's "Duy Nguyen" according to the EULA of gsoc (http://code.google.com/soc/2008/student_step1.html) 1) coding style: please, do follow the ns-3 coding style (http://www.nsnam.org/codingstyle.html). Specifically, I noticed: - don't use tab characters for indent. Use 2 spaces instead. - use two-level indent for ifs: the following is not proper if () { // do stuff } instead, do this: if () { // do stuff } - always use braces, even for one-line statements. don't do this: if () // do stuff instead, do this: if () { // do stuff } - the same for 'else' statements and 'for' loops - don't use s_ prefix for structure members. Just remove the s_ prefix. - there is no need to repeat the Minstrel keyword in method names because all of these methods are really members of the MinstrelWifiRemoteStation class which already contains the 'Minstrel' keyword. Affected methods: MinstrelGetNextSample, MinstrelFindRate, MinstrelUpdateStats, MinstrelRateInit, PrintMinstrelTable, CheckMinstrelInit. - overall, identation appears to be broken in a lot of places. I see this for example: else if (m_longRetry <= (m_minstrelTable[m_txrate].s_retryCount + m_minstrelTable[m_maxTpRate].s_retryCount)) { which is really hard to read. The following makes the flow more obvious: else if (m_longRetry <= (m_minstrelTable[m_txrate].s_retryCount + m_minstrelTable[m_maxTpRate].s_retryCount)) { 2) remove dead code: - line 158 - line 164 - line 201 - line 269 - line 597: add a TODO of FIXME, file a bug in bugzilla. 3) SAMPLE_COLS: defined at line 35: why do you use a hardcoded constant ? what happens if your array is too small ? Can't you use a dynamic vector and get rid of this hardcoded constant ? 4) Why do you need m_interference ? Can't you do what IdealWifiManager is doing (see SetupPhy called from WifiNetDevice::CompleteConfig). Mathieu On Sat, 2009-07-11 at 10:42 -0700, Duy Nguyen wrote: > Hi everyone, here is my update and current progress on the Minstrel > multirate control port for ns-3 > (http://www.nsnam.org/wiki/index.php/GSOC2009Minstrel): > > 1) All the major coding for Minstrel multirate control is done > 2) Minstrel implementation is up and running (using modified test > cases from ns-3-dev/examples directory) > 3) The behavior of Minstrel is verified according to specification > from madwifi project and > http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/minstrel > (by meticulously going through the debugging log) > > My next step for the project is to continue to verify and validate > minstrel implementation by the following: > > 1) Work on the error/interference model in order to introduce errors > into sending or receiving packets( I am still looking into Tom's > suggestion on http://www.nsnam.org/bugzilla/show_bug.cgi?id=414) > 2) Set up a testbed experiments with simple scenarios: a) two nodes in > concurrent transmission moving away from one another until they are > out of range b) two nodes, out of transmission range, moving into > transmission range. > 3) Test the minstrel port in emulation mode (still need to get an > account from CMU/Orbit emulator). > 4) Write more test cases and scripts. > > I am looking forward to the second half of GSOC. > > Duy From mathieu.lacage at sophia.inria.fr Wed Aug 12 09:11:16 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 12 Aug 2009 18:11:16 +0200 Subject: [Ns-developers] making the vector class more useful Message-ID: <1250093476.18353.2.camel@diese.inria.fr> hi, I needed to do some data manipulation in some local code and I ended up needing a Vector2d and Vector3d classes, both pretty close to the existing Vector class in src/mobility, so, I tried moving it in src/core/ and defining the extra Vector2d class. Thoughts about the attached patch ? Is the class naming appropriate ? Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: vector.patch Type: text/x-patch Size: 14459 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090812/117adb40/vector.bin From gjcarneiro at gmail.com Wed Aug 12 15:37:12 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 12 Aug 2009 23:37:12 +0100 Subject: [Ns-developers] making the vector class more useful In-Reply-To: <1250093476.18353.2.camel@diese.inria.fr> References: <1250093476.18353.2.camel@diese.inria.fr> Message-ID: 2009/8/12 Mathieu Lacage > hi, > > I needed to do some data manipulation in some local code and I ended up > needing a Vector2d and Vector3d classes, both pretty close to the > existing Vector class in src/mobility, so, I tried moving it in > src/core/ and defining the extra Vector2d class. Can you clarify why you need a "2D" vector? Aside from extra computation, what is different between 2D vector operations and 3D vector with the Z coordinate always set to zero and otherwise ignored? 1. We could have a new Vector constructor that takes only X and Y and sets Z to zero; 2. CalculateDistance will just ignore Z if it is zero. I suspect at CPU level there is probably an optimization that speeds up zero-times-zero, so the computational overhead is probably small. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From dnlove at gmail.com Wed Aug 12 23:26:01 2009 From: dnlove at gmail.com (Duy Nguyen) Date: Wed, 12 Aug 2009 23:26:01 -0700 Subject: [Ns-developers] GSOC: Minstrel multirate control port update In-Reply-To: <1250004850.12645.22.camel@diese.inria.fr> References: <70f6a1ed0907111042s7fa790d2g72c04f5a5342382e@mail.gmail.com> <1250004850.12645.22.camel@diese.inria.fr> Message-ID: <70f6a1ed0908122326g68d48e6cpcce4b7d0ff0248ad@mail.gmail.com> Hi Mathieu, thank you for your review. I fixed all the points you mentioned and did a rerun of all my test cases. Could you/ns developers help me check again to see if I am missing anything else? http://code.nsnam.org/duy/ns-3-dev-minstrel/ Hi Ruben and Tom, I am still working on more sophisticated test cases and regression test you talked about. Keep you posted. duy 2009/8/11 Mathieu Lacage > hi duy, > > I looked at your code for merging in ns-3-dev: overall, it looks nice > so, thank you for working on this. I am sure we can merge this quickly > if you can take some time to address my comments below. > > 0) copyright: it's not "the ns-3 project" because there is no such > thing. It's "Duy Nguyen" according to the EULA of gsoc > (http://code.google.com/soc/2008/student_step1.html) > > 1) coding style: please, do follow the ns-3 coding style > (http://www.nsnam.org/codingstyle.html). Specifically, I noticed: > - don't use tab characters for indent. Use 2 spaces instead. > - use two-level indent for ifs: the following is not proper > if () > { > // do stuff > } > instead, do this: > if () > { > // do stuff > } > - always use braces, even for one-line statements. don't do this: > if () > // do stuff > instead, do this: > if () > { > // do stuff > } > - the same for 'else' statements and 'for' loops > - don't use s_ prefix for structure members. Just remove the s_ > prefix. > - there is no need to repeat the Minstrel keyword in method names > because all of these methods are really members of the > MinstrelWifiRemoteStation class which already contains the 'Minstrel' > keyword. Affected methods: MinstrelGetNextSample, MinstrelFindRate, > MinstrelUpdateStats, MinstrelRateInit, PrintMinstrelTable, > CheckMinstrelInit. > - overall, identation appears to be broken in a lot of places. I see > this for example: > > else if (m_longRetry <= (m_minstrelTable[m_txrate].s_retryCount + > m_minstrelTable[m_maxTpRate].s_retryCount)) > { > > which is really hard to read. The following makes the flow more obvious: > > else if (m_longRetry <= (m_minstrelTable[m_txrate].s_retryCount + > m_minstrelTable[m_maxTpRate].s_retryCount)) > { > > 2) remove dead code: > - line 158 > - line 164 > - line 201 > - line 269 > - line 597: add a TODO of FIXME, file a bug in bugzilla. > > 3) SAMPLE_COLS: defined at line 35: why do you use a hardcoded > constant ? what happens if your array is too small ? Can't you use a > dynamic vector and get rid of this hardcoded constant ? > > 4) Why do you need m_interference ? Can't you do what IdealWifiManager > is doing (see SetupPhy called from WifiNetDevice::CompleteConfig). > > > Mathieu > > On Sat, 2009-07-11 at 10:42 -0700, Duy Nguyen wrote: > > Hi everyone, here is my update and current progress on the Minstrel > > multirate control port for ns-3 > > (http://www.nsnam.org/wiki/index.php/GSOC2009Minstrel): > > > > 1) All the major coding for Minstrel multirate control is done > > 2) Minstrel implementation is up and running (using modified test > > cases from ns-3-dev/examples directory) > > 3) The behavior of Minstrel is verified according to specification > > from madwifi project and > > > http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/minstrel > > (by meticulously going through the debugging log) > > > > My next step for the project is to continue to verify and validate > > minstrel implementation by the following: > > > > 1) Work on the error/interference model in order to introduce errors > > into sending or receiving packets( I am still looking into Tom's > > suggestion on http://www.nsnam.org/bugzilla/show_bug.cgi?id=414) > > 2) Set up a testbed experiments with simple scenarios: a) two nodes in > > concurrent transmission moving away from one another until they are > > out of range b) two nodes, out of transmission range, moving into > > transmission range. > > 3) Test the minstrel port in emulation mode (still need to get an > > account from CMU/Orbit emulator). > > 4) Write more test cases and scripts. > > > > I am looking forward to the second half of GSOC. > > > > Duy > > From mathieu.lacage at sophia.inria.fr Wed Aug 12 23:33:17 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 13 Aug 2009 08:33:17 +0200 Subject: [Ns-developers] making the vector class more useful In-Reply-To: References: <1250093476.18353.2.camel@diese.inria.fr> Message-ID: <1250145197.3372.2.camel@diese.inria.fr> On Wed, 2009-08-12 at 23:37 +0100, Gustavo Carneiro wrote: > 2009/8/12 Mathieu Lacage > hi, > > I needed to do some data manipulation in some local code and I > ended up > needing a Vector2d and Vector3d classes, both pretty close to > the > existing Vector class in src/mobility, so, I tried moving it > in > src/core/ and defining the extra Vector2d class. > > Can you clarify why you need a "2D" vector? Aside from extra > computation, what is different between 2D vector operations and 3D > vector with the Z coordinate always set to zero and otherwise ignored? memory usage for large vectors. Mathieu > From mathieu.lacage at sophia.inria.fr Wed Aug 12 23:34:46 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 13 Aug 2009 08:34:46 +0200 Subject: [Ns-developers] making the vector class more useful In-Reply-To: <1250145197.3372.2.camel@diese.inria.fr> References: <1250093476.18353.2.camel@diese.inria.fr> <1250145197.3372.2.camel@diese.inria.fr> Message-ID: <1250145286.3372.4.camel@diese.inria.fr> On Thu, 2009-08-13 at 08:33 +0200, Mathieu Lacage wrote: > On Wed, 2009-08-12 at 23:37 +0100, Gustavo Carneiro wrote: > > 2009/8/12 Mathieu Lacage > > hi, > > > > I needed to do some data manipulation in some local code and I > > ended up > > needing a Vector2d and Vector3d classes, both pretty close to > > the > > existing Vector class in src/mobility, so, I tried moving it > > in > > src/core/ and defining the extra Vector2d class. > > > > Can you clarify why you need a "2D" vector? Aside from extra > > computation, what is different between 2D vector operations and 3D > > vector with the Z coordinate always set to zero and otherwise ignored? > > memory usage for large vectors. It occurs to me that this is not very clear: what I am trying to optimize is the memory usage of this case: std::vector aVeryLargeArray; Mathieu From mathieu.lacage at sophia.inria.fr Thu Aug 13 00:15:51 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 13 Aug 2009 09:15:51 +0200 Subject: [Ns-developers] GSOC: Minstrel multirate control port update In-Reply-To: <70f6a1ed0908122326g68d48e6cpcce4b7d0ff0248ad@mail.gmail.com> References: <70f6a1ed0907111042s7fa790d2g72c04f5a5342382e@mail.gmail.com> <1250004850.12645.22.camel@diese.inria.fr> <70f6a1ed0908122326g68d48e6cpcce4b7d0ff0248ad@mail.gmail.com> Message-ID: <1250147751.3372.41.camel@diese.inria.fr> On Wed, 2009-08-12 at 23:26 -0700, Duy Nguyen wrote: > Hi Mathieu, thank you for your review. I fixed all the points you > mentioned and did a rerun of all my test cases. Could you/ns > developers help me check again to see if I am missing anything else? > http://code.nsnam.org/duy/ns-3-dev-minstrel/ > I have merged your code in ns-3-dev. Thanks for updating your code so quickly. Mathieu From mathieu.lacage at sophia.inria.fr Thu Aug 13 01:33:49 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 13 Aug 2009 10:33:49 +0200 Subject: [Ns-developers] 'meta' attributes Message-ID: <1250152429.3372.48.camel@diese.inria.fr> hi, While reviewing exiting wifi bugs and trying to come up with a solution to the problem of configuration of different 802.11 standard parameters, it occured to me that one of the issues with the existing wifi code is that it uses so-called 'meta' attributes, that is, attributes which, when set, modify the value of other attributes. I would like to point out that this is really a bad idea generally and that we should avoid such attributes as much as possible because they break some of the underlying assumptions from the attribute code: setting an attribute should _never_ have as a side effect changing the value of another attribute. So, the point of this email is mostly to point out that we need to kill these 'meta' attributes, and, really, that we need to avoid creating more of them. Mathieu From gjcarneiro at gmail.com Thu Aug 13 01:39:33 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 13 Aug 2009 09:39:33 +0100 Subject: [Ns-developers] making the vector class more useful In-Reply-To: <1250145286.3372.4.camel@diese.inria.fr> References: <1250093476.18353.2.camel@diese.inria.fr> <1250145197.3372.2.camel@diese.inria.fr> <1250145286.3372.4.camel@diese.inria.fr> Message-ID: 2009/8/13 Mathieu Lacage > On Thu, 2009-08-13 at 08:33 +0200, Mathieu Lacage wrote: > > On Wed, 2009-08-12 at 23:37 +0100, Gustavo Carneiro wrote: > > > 2009/8/12 Mathieu Lacage > > > hi, > > > > > > I needed to do some data manipulation in some local code and I > > > ended up > > > needing a Vector2d and Vector3d classes, both pretty close to > > > the > > > existing Vector class in src/mobility, so, I tried moving it > > > in > > > src/core/ and defining the extra Vector2d class. > > > > > > Can you clarify why you need a "2D" vector? Aside from extra > > > computation, what is different between 2D vector operations and 3D > > > vector with the Z coordinate always set to zero and otherwise ignored? > > > > memory usage for large vectors. > > It occurs to me that this is not very clear: what I am trying to > optimize is the memory usage of this case: > > std::vector aVeryLargeArray; > > Mathieu > > In that case I would rather not rename Vector to Vector3d. Let there be Vector and Vector2d, the name asymmetry to reflect the fact that Vector2d is a special case of Vector, to be seldom used, and that when in doubt the programmer should just use Vector. That it also preserves API compatibility may also be in the back of my mind :-) Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From faker.moatamri at sophia.inria.fr Thu Aug 13 01:42:39 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 13 Aug 2009 10:42:39 +0200 Subject: [Ns-developers] Wimax integration with ns-3-dev In-Reply-To: <4A7FEB51.2050102@sophia.inria.fr> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> <4A7FEB51.2050102@sophia.inria.fr> Message-ID: <4A83D1FF.2080006@sophia.inria.fr> Faker Moatamri wrote: > Hi all, > In order to add features to NS-3, we would like to merge the wimax > module to the next NS-3 release. Wimax module has been under > development for over two years now and we think that it is ready to be > included in the main tree and in next release. > > Here is the proposed time schedule: > > -Monday August 17th: feature/Dev freeze, review and merge patches, > testing and debugging > -Thursday August 20th: Enhancement of the code to meet NS-3 standard > -Wednesday August 26th: Merge with the latest version of ns-3-dev and > testing > -Tuesday September 1st: Submission of the proposed Wimax patch for review > > If you are developing some code for wimax and would like it to be > merged in the next NS-3 release, please send us a patch as soon as > possible and before next monday August 17th (the sooner the better) > based on iamine/ns-3-wimax-dev repository. > Best regards > Faker Moatamri > > Hi, For the future merging of modules with wimax, I have been through Flavio's code available on: http://code.nsnam.org/flaviokubota/ns-3-wimax-dev/ Is that the code you would like it to be merged with wimax? From what I understand from the code, you have made the uplink-scheduler a virtual class with two implementations, one is the default implementation and the second is your new implementation: uplink-schduler-mpqos. I saw also that you include some bandwidth information in the wimaxMac packet headers and that you increased the queue size from 1024 to 10000, to give enough time to the process to change the header of the packets. You changed also the wimax helper to include the scheduler type in order to decide which scheduler will be used (why there is an install function accepting two scheduler types: line 185 of wimax-helper.h?). I saw that you have some example/test scripts in the scratch directory, those should I guess be put into the appropriate directory/files. Did I understand the code well? Other suggestion will be to add as much doxygen as you can and to remove commented code. Overall the code is well done and I think that we can merge the code with wimax and lately with ns-3-dev. This is conditional to the patch that we will have about the scheduler, if we have another scheduler implementation from Giuseppe we will need to see if both or one is safely mergeable with wimax and then with ns-3-dev. I remind you that we need to have your final patches BEFORE Monday august 17th so that we can begin to review and merge on Monday. Best regards Faker Moatamri From mathieu.lacage at sophia.inria.fr Thu Aug 13 02:01:23 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 13 Aug 2009 11:01:23 +0200 Subject: [Ns-developers] making the vector class more useful In-Reply-To: References: <1250093476.18353.2.camel@diese.inria.fr> <1250145197.3372.2.camel@diese.inria.fr> <1250145286.3372.4.camel@diese.inria.fr> Message-ID: <1250154083.3372.51.camel@diese.inria.fr> On Thu, 2009-08-13 at 09:39 +0100, Gustavo Carneiro wrote: > > > I needed to do some data manipulation in some > local code and I > > > ended up > > > needing a Vector2d and Vector3d classes, both > pretty close to > > > the > > > existing Vector class in src/mobility, so, I tried > moving it > > > in > > > src/core/ and defining the extra Vector2d class. > > > > > > Can you clarify why you need a "2D" vector? Aside from > extra > > > computation, what is different between 2D vector > operations and 3D > > > vector with the Z coordinate always set to zero and > otherwise ignored? > > > > memory usage for large vectors. > > > It occurs to me that this is not very clear: what I am trying > to > optimize is the memory usage of this case: > > std::vector aVeryLargeArray; > > In that case I would rather not rename Vector to Vector3d. Let there > be Vector and Vector2d, the name asymmetry to reflect the fact that > Vector2d is a special case of Vector, to be seldom used, and that when > in doubt the programmer should just use Vector. > > That it also preserves API compatibility may also be in the back of my > mind :-) What I did in this patch is rename Vector to Vector3d, introduce Vector2d, and provide compatibility typedefs from Vector3d to Vector to avoid breaking the existing API (they are at the bottom of the vector.h header). It seems to work nicely: I could not picture myself breaking all users of the Vector class... Mathieu From mathieu.lacage at sophia.inria.fr Thu Aug 13 08:34:52 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 13 Aug 2009 17:34:52 +0200 Subject: [Ns-developers] wifi overhaul for simple configuration of different PHY standards Message-ID: <1250177692.3372.78.camel@diese.inria.fr> hi, bug 641 outlines one of the symptoms of the current pain to configure different PHY standards. Here is a patch which attempts to fix that bug and simplify configuration of PHY standard for users. This patch touches a lot of things so, I would really appreciate comments from all concerned parties (802.11b, 10/5mhz modes, qos mac, etc.). API changes: 1) add WifiHelper::SetStandard 2) remove NqosWifiMacHelper::SetDcaParameters 3) remove QosWifiMacHelper::SetEdcaParametersForAc 4) remove 'Standard' attributes from WifiPhy and WifiMac 5) add ConfigureStandard method in WifiPhy and WifiMac So, nicola, mirko, others, it would be really nice to look at this before I attempt to push it to master. Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: standard.patch Type: text/x-patch Size: 62385 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090813/997a0b89/standard-0001.bin From Guangyu.Pei at boeing.com Thu Aug 13 10:22:27 2009 From: Guangyu.Pei at boeing.com (Pei, Guangyu) Date: Thu, 13 Aug 2009 10:22:27 -0700 Subject: [Ns-developers] wifi overhaul for simple configuration of differentPHY standards In-Reply-To: <1250177692.3372.78.camel@diese.inria.fr> References: <1250177692.3372.78.camel@diese.inria.fr> Message-ID: Mathieu, The patch makes sense and looks great to me. Thanks, Gary > -----Original Message----- > From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr] > Sent: Thursday, August 13, 2009 8:35 AM > To: ns-developers at ISI.EDU > Subject: [Ns-developers] wifi overhaul for simple > configuration of differentPHY standards > > hi, > > bug 641 outlines one of the symptoms of the current pain to > configure different PHY standards. Here is a patch which > attempts to fix that bug and simplify configuration of PHY > standard for users. This patch touches a lot of things so, I > would really appreciate comments from all concerned parties > (802.11b, 10/5mhz modes, qos mac, etc.). > > API changes: > > 1) add WifiHelper::SetStandard > 2) remove NqosWifiMacHelper::SetDcaParameters > 3) remove QosWifiMacHelper::SetEdcaParametersForAc > 4) remove 'Standard' attributes from WifiPhy and WifiMac > 5) add ConfigureStandard method in WifiPhy and WifiMac > > So, nicola, mirko, others, it would be really nice to look at > this before I attempt to push it to master. > > > Mathieu > From mk.banchi at gmail.com Thu Aug 13 13:26:07 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 13 Aug 2009 22:26:07 +0200 Subject: [Ns-developers] wifi overhaul for simple configuration of different PHY standards In-Reply-To: <1250177692.3372.78.camel@diese.inria.fr> References: <1250177692.3372.78.camel@diese.inria.fr> Message-ID: Il giorno 13/ago/09, alle ore 17:34, Mathieu Lacage ha scritto: > hi, > > bug 641 outlines one of the symptoms of the current pain to configure > different PHY standards. Here is a patch which attempts to fix that > bug > and simplify configuration of PHY standard for users. This patch > touches > a lot of things so, I would really appreciate comments from all > concerned parties (802.11b, 10/5mhz modes, qos mac, etc.). > > API changes: > > 1) add WifiHelper::SetStandard > 2) remove NqosWifiMacHelper::SetDcaParameters > 3) remove QosWifiMacHelper::SetEdcaParametersForAc > 4) remove 'Standard' attributes from WifiPhy and WifiMac > 5) add ConfigureStandard method in WifiPhy and WifiMac > > So, nicola, mirko, others, it would be really nice to look at this > before I attempt to push it to master. > > > Great work Mathieu! Only a little correction: line 530 in standard.patch - edca->SetTypeOfStation (AP); + edca->SetTypeOfStation (ADHOC_STA); It's important for MSDU aggregation's correct behaviour. All should be ok. Thanks, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090813/bb2bb6cc/smime.bin From tomh at tomh.org Thu Aug 13 22:50:13 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 13 Aug 2009 22:50:13 -0700 Subject: [Ns-developers] making the vector class more useful In-Reply-To: <1250154083.3372.51.camel@diese.inria.fr> References: <1250093476.18353.2.camel@diese.inria.fr> <1250145197.3372.2.camel@diese.inria.fr> <1250145286.3372.4.camel@diese.inria.fr> <1250154083.3372.51.camel@diese.inria.fr> Message-ID: <4A84FB15.10503@tomh.org> Mathieu Lacage wrote: >> In that case I would rather not rename Vector to Vector3d. Let there >> be Vector and Vector2d, the name asymmetry to reflect the fact that >> Vector2d is a special case of Vector, to be seldom used, and that when >> in doubt the programmer should just use Vector. >> >> That it also preserves API compatibility may also be in the back of my >> mind :-) > > What I did in this patch is rename Vector to Vector3d, introduce > Vector2d, and provide compatibility typedefs from Vector3d to Vector to > avoid breaking the existing API (they are at the bottom of the vector.h > header). It seems to work nicely: I could not picture myself breaking > all users of the Vector class... > Mathieu, I had the same reaction as Gustavo initially but I am fine with the changes, with those typedefs for compatibility. Tom From vincent at clarinet.u-strasbg.fr Fri Aug 14 00:17:43 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Fri, 14 Aug 2009 09:17:43 +0200 Subject: [Ns-developers] NetDevice link change callback In-Reply-To: <4A7C2ECB.7090100@tomh.org> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> Message-ID: <4A850F97.5020505@clarinet.u-strasbg.fr> Tom Henderson a ?crit : > Mathieu Lacage wrote: >> On Thu, 2009-08-06 at 15:50 -0600, Tom Henderson wrote: >> >>>>> 1) use of TracedCallback? >>>>> Another option is to use a TracedCallback here, which some other >>>>> developers have recommended in the past to use when there needs to >>>>> be a list of callbacks. >>>>> >>>>> I don't have a strong opinion but this question keeps popping up >>>>> (also in Qasim's conntrack code) so I think we should clarify >>>>> whether TracedCallback should also be used in non-tracing >>>>> scenarios whenever you >>>>> want a std::list of callbacks, or whether we want another general >>>>> CallbackList of some sort that is not used by tracing code. >>>> I think that all you would need to make TracedCallback generic is >>>> change >>>> its name to something which does not include 'Trace'. i.e., its API >>>> and >>>> implementation has no dependency on the tracing code. >>> Maybe what would be best is to add something like the CallbackList >>> suggested but allow user to optionally specify order or priority of >>> callbacks-- if no priority is specified, they all get priority 0 and it >>> behaves like TracedCallback. >> >> It's not clear to me what this priority would be used for. Do you have a >> specific usecase in mind ? > > iptables (chains of ordered rules) > > If not, I would support simply renaming >> TracedCallback to NotifierCallback or something similar (better >> suggestions for a name would be welcome) and typedef NotifierCallback to >> TracedCallback to avoid changing our existing codebase. > > I don't care strongly; ListCallback conveys the list semantics. > >> >>>>> 2) should we report link change, or link up? >>>>> The method name is not really suggestive of how the callback >>>>> works, which does not call when the link changes in all cases but >>>>> only when the >>>>> link goes to up. So, I would suggest either "AddLinkUpCallback" >>>>> or "SetLinkChangeCallback" with an extra argument such as an enum >>>>> for Up or >>>>> Down. >>>> The current implementation reports link change events, not link up >>>> events. i.e., see src/devices/wifi/wifi-net-devices.cc. The current >>>> API >>>> documentation in src/node/net-device.h should be improved instead of >>>> changing the method name I think. >>> Only WifiNetDevice reports all link changes, but you can't tell from >>> the >>> callback what type of event it was. The other devices >>> (PointToPoint, Csma, >> >> IsLinkUp is expected to be used from within the notification callback to >> query the state of the link. That was the original intend of the device >> API design. >> >>> Emu) just call it upon going up, perhaps because they can't go down >>> (it is >>> really only used at node startup time). >> >> Yes, none of them can go down which is why they never report link down >> events. >> >> Anyway, to summarize, I see no real need to change this API since it >> provides the needed functionality. What is needed is improving the >> doxygen which does not align with the intend of the original design. > > Can you clarify-- are you objecting to AddLinkChangeCallback as > Sebastien suggested, or changing other aspects as I later suggested > (such as changing the name or the arguments of the callback)? > > I am OK with what you suggest about using the API as you originally > intended with IsLinkUp(), and fixing the doxygen, but it seems like > Sebastien has a valid use case to make this a TracedCallback. > I made a small update on the patch on bugzilla (http://www.nsnam.org/bugzilla/show_bug.cgi?id=653) to use ListCallback (typedef from TracedCallback) in NetDevice. Regards, -- Sebastien >> >>>>> I think others have raised the question "can I put a NetDevice >>>>> into down >>>>> state?" and presently the answer is no, but in practice, IFF_UP >>>>> flag of a netdevice is settable, and it seems like we might want >>>>> to add the capability to configure an interface to down state, >>>>> which would trigger upcalls to both Ipv4 and Ipv6 stacks (and to >>>>> the routing protocols). >>>> What would be the expected semantics of that flag exactly ? Would you >>>> expect the NetDevice subclasses to honor calling SetIfDown by ignoring >>>> packets being passed down with NetDevice::Send* ? >>>> >>> Yes. I would try to match it to what happens in a real system when >>> "ifconfig eth0 down" is called. Note that this typically will trigger >>> upcalls or netlink notifications, which cause the upper layer to >>> refrain >>> from sending packets down to it when it is in a down state. >> >> I think that it would be nice if adding such a flag would not require >> adding extra send/receive logic to net device implementations but I >> could live with it. >> > I think the burden here will be requiring netdevice users to register > for the link change callback and process it; I don't think adding the > extra NetDevice logic (shunt packets to a drop trace if the device is > down) will be too difficult. > > Tom > From craigdo at ee.washington.edu Fri Aug 14 00:29:24 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 14 Aug 2009 00:29:24 -0700 Subject: [Ns-developers] making the vector class more useful In-Reply-To: <4A84FB15.10503@tomh.org> References: <1250093476.18353.2.camel@diese.inria.fr> <1250145197.3372.2.camel@diese.inria.fr> <1250145286.3372.4.camel@diese.inria.fr> <1250154083.3372.51.camel@diese.inria.fr> <4A84FB15.10503@tomh.org> Message-ID: <39D8150A1D4F46BE97A91AE953D51AB7@CRAIGVAIO> > >> In that case I would rather not rename Vector to Vector3d. > Let there > >> be Vector and Vector2d, the name asymmetry to reflect the fact that > >> Vector2d is a special case of Vector, to be seldom used, > and that when > >> in doubt the programmer should just use Vector. > >> > >> That it also preserves API compatibility may also be in > the back of my > >> mind :-) > > > > What I did in this patch is rename Vector to Vector3d, introduce > > Vector2d, and provide compatibility typedefs from Vector3d > to Vector to > > avoid breaking the existing API (they are at the bottom of > the vector.h > > header). It seems to work nicely: I could not picture > myself breaking > > all users of the Vector class... > > > > Mathieu, I had the same reaction as Gustavo initially but I > am fine with > the changes, with those typedefs for compatibility. I'm with Mathieu on this one, except I would have called them Vector2D and Vector3D irrespective of the coding convention. -- Craig From amine.ismail at sophia.inria.fr Fri Aug 14 00:48:51 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Fri, 14 Aug 2009 09:48:51 +0200 Subject: [Ns-developers] patch for Wimax Scheduler In-Reply-To: <4A842FB0.2090601@gmail.com> References: <4365bdc50908130324t3f1b56baq22de024cc5f1196a@mail.gmail.com> <4A842448.6020603@sophia.inria.fr> <4A842FB0.2090601@gmail.com> Message-ID: <4A8516E3.5090303@sophia.inria.fr> Hi Guys, I would like to thank Giuseppe and Flavio for their great work on uplink and downlink schedulers!! Just one thing, could you put ns-3-developers and ns-3-users mailing lists in cc please? For Giuseppe: Sorry for the delay but I am very busy since I am trying to finish the implementation of loss model before the deadline of 17/08! I will try to work on the BandwidthRequest bug the next week! On an other hand, as we will start the testing and debugging phase next week, it will be nice if we log the bug that we find using http://www.nsnam.org/bugzilla/ (choose ns-3 as product and wimax as component). Giuseppe: could you enter the bug about the BandwidthRequest in the database? Thank you Amine Giuseppe Piro wrote: > Faker Moatamri ha scritto: >> Giuseppe Piro wrote: >>> Hi Amine and Faker! >>> >>> You can find attached my patch based on >>> "http://code.nsnam.org/iamine/ns-3-wimax-dev" code. >>> >>> As I have already written to Amine, I have implemented a simple >>> scheduler for both UL and DL. >>> >>> The goals of my work is to define a simple scheduler (obviously >>> standard-compliant) that is able to serve all rtPS >>> active flows in the wimax scenario. Infact in the actual code not >>> all connection are able to transmit their packets >>> into the UL Sub Frame (and so into the DL). >>> >> The scheduler that you are proposing is the same as the one already >> implemented but with more features or it is a different method?? > The scheduler is the same as the one already implemented but with more > features. >>> The schedulers use the priority approach to serve all type of >>> service flows (as the standard proposes). >>> In DL the available bandwidth is assigned to the service flows in >>> the following order: >>> - IR Connections >>> - Broadcast Connections >>> - Basic and Primary Connections >>> - UGS Connections >>> - rtPS Connections >>> - nrtPS Connections >>> - BE Connections >>> To be more precisely, IR, Broadcast and Basic/Primary Connections >>> must transmit all packet in the queue. UGS Connections can trasmit >>> their requested Grant Size (that is one of service flows QoS >>> parameters) according to their requested MaxLatency (another QoS >>> parameter). >>> ALL rtPS Connections are able to transmit all packet in the queue >>> according to the available bandwidth. The bandwidth saturation >>> control has been implemented to redistribute the effective available >>> bandwidth to ALL rtPS that have at least one packet to transmit. The >>> remaining bandwidth is allocated to rntPS and BE Connections. >>> >>> The UL Scheduler work in this way: >>> At the beginning of the UL sub-frame some simbols are allocated to >>> the rangingInterval Messages, DSA Messages, UGS grant and >>> UGS/rtPS/nrtPS/BE poll. >>> Then, the remaining available symbols are allocated to the ALL rtPS >>> Connection according to their requestedBandwidth. >>> Also in this case, the bandwidth saturation control has been >>> implemented. >>> So, the remaining symbols are allocated to nrtPS and BE Connections. >>> >>> >>> To implement this schedulers, I have done some little changes in >>> bs-scheduler.cc and uplink-scheduler.cc files. >>> I think that this schedulers may be the default implementation for >>> the next release, and so we can compare the effectiveness of all >>> Schedulers (for example the UL scheduler implemented by Flavio or >>> the feedback based schedulers for which I'm working on). >>> >> If your scheduler is different from the implemented one, we'd rather >> have 3 instead of two. >> I think that the my UL/DL schedulers (that may became the default >> implementation) and the Flavio's implementation are safely mergeable >> with wimax and then with ns-3-dev. You can add the switch-case for >> rtPS/nrtPS schedulers considering both of implementations. >> In this way, I can merge the scheduler for wich I'm working on in a >> safely way! >> >> >> It is important to remark anothe little changes that I have done on >> the code: >> >> 1)bandwidth-manager.cc: When the Service Flows send the >> BandwidthRequest, set the bytesToRequest like to the queue length and >> so the BandwidthRequestHeader is equal to HEADER_TYPE_AGGREGATE >> >> 2)ofdm-wimax-phy.cc and ofdm-wimax-phy.h, simpleOfdmWimaxPhy.cc and >> simpleOfdmWimaxPhy.h, wimax-phy.cc and wimax-phy.h, >> simple-wimax-phy.cc and simple-wimax-phy.h: >> I have added the this function: >> "DoGetNrBytes(uint32_t symbols, WimaxPhy::ModulationType >> modulationType) const;" >> that convert the number of symbols in the number of bytes. >> >> 3)service-flow-record.cc: >> I have modified the SetRequestedBandwidth function. >> >> 4)wimax-mac-queue.cc and wimax-mac-queue.h: I have added the function >> "const WimaxMacQueue::PacketQueue & GetPacketQueue(void) const;". >> >> >> >> HAVE YOU ANY QUESTIONS? :-) >> >> See you! >> Peppe >> >> >> for Amine: The bug about the BandwidthRequest value isn't resolved yet! >> >> >> -- >> Giuseppe Piro >> Ph.D. Student >> DEE - Politecnico di Bari >> v. Orabona 4, 70125 - Bari, Italy >> e-mail: g.piro at poliba.it >> peppe.piro at gmail.com >> Phone: +39 0805963301 >> Web: http://telematics.poliba.it/piro >> For the code implementation, I think that ideally we will have a >> completely virtual uplink/downlink scheduler with different >> implementations. That would be easier for everybody. And in that case >> we will be able to add as many schedulers as we want. You can take a >> look at Flavio code on >> http://code.nsnam.org/flaviokubota/ns-3-wimax-dev/, he made some >> functions of uplink-scheduler virtual so that he can reimplement >> them. We'd rather create a completely virtual uplink-scheduler with >> different implementations so that we cannot instantiate anymore the >> uplink-scheduler class and we are obliged to choose one of the >> implementations. >> The best way to go is that you and Flavio (added in cc) synchronize >> your work together and submit one patch, since you're working on the >> same peace of code conflicts are expected if you don't work together >> to get the two implementations for the next release. >> Giuseppe and Flavio, can you please take a look at each other's code >> and manage to merge it together? (for Flavio Giuseppe's patch is >> attached, sorry for others that already have the patch) > Ok, I'll look the Flavio's implementation to try to merge our patches. >> >> I have several other remarks: >> - First of all this email should be sent to ns-developers mailing >> list (ns-developers at ISI.EDU), please send emails to this list, this >> is really VERY important >> For your patch: >> - Avoid having space changes (there is an option to ignore those >> changes) >> - Add doxygen >> - Remove commented code >> - Be careful to respect coding style (space before parentheses, 2 >> spaces indentation, ... http://www.nsnam.org/codingstyle.html) >> >> Thanks >> Faker Moatarmri >> > > > > Giuseppe Piro > > From vincent at clarinet.u-strasbg.fr Fri Aug 14 00:58:36 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Fri, 14 Aug 2009 09:58:36 +0200 Subject: [Ns-developers] ipv6 plans for ns-3 In-Reply-To: References: <36caa09167fd3a8199d20efc14211f2c@tomh.org> <4A5381E1.5090602@clarinet.u-strasbg.fr> <4A65BC4F.6070500@clarinet.u-strasbg.fr> <4A6868B3.6040508@tomh.org> <4A696E6F.8080606@clarinet.u-strasbg.fr> <004b01ca0c5c$c6e966f0$54bc34d0$@ch> <4A6D7E12.8030201@clarinet.u-strasbg.fr> <4A71EA53.9020709@clarinet.u-strasbg.fr> Message-ID: <4A85192C.2030702@clarinet.u-strasbg.fr> Tom Henderson a ?crit : > On Thu, 30 Jul 2009 20:45:39 +0200, S?bastien Vincent > wrote: > >> Hi all, >> >> New features: >> - RA handler to autoconfigure address and default route; >> - Radvd application made scratch (not reused radvd stuff from ns-3-ipv6 >> old repository); >> - Two new examples: radvd and radvd-two-prefix. The last ones advertise >> two prefixes in RA. >> >> By the way I added in Ipv6RoutingProtocol, two methods for adding >> routes. It is needed for ICMPv6 redirect (which add a host route to >> redirected target), and to configure the default route when receive >> first RA's prefix: NotifyAddRoute and NotifyRemoveRoute. >> >> > > I am not sure about the above Ipv6RoutingProtocol changes. It seems like > what you want to do is to get a handle on a static routing object and add a > host route directly, but you are instead providing a notification to all > routing protocols (as in RTM_NEWROUTE). > > >> To summarize what is done now in >> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd: >> - IPv6 interface; >> - IPv6 layer; >> - IPv6 raw socket; >> - Static IPv6 routing; >> - ICMPv6 layer; >> - Some ICMPv6 error messages (destination unreachable, ...); >> - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); >> - Ping6 application (send Echo request); >> - Radvd application (send RA); >> - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, >> icmpv6-redirect). >> >> My holidays ends by monday, as I already said I will not have much time >> to work on ns-3 after. >> >> I think that we can first review current work and give feedback. And >> maybe try to merge it before continue to work on UDP/TCP. It will be >> great to finally enable ns-3 users to begin make IPv6 simulations with >> ICMPv6 in next ns-3 release. >> >> > > I've posted this repository on ns-3-reviews in case people would like to > review it there. Please review it by next Wed. or ask for more time; if no > major comments, I will try to merge this later next week. > http://codereview.appspot.com/105054 > > I have updated repository (fix one bug and recent ns-3-dev changes). Feel free to review it. Tom, I have also added text from RELEASE_NOTES/CHANGES.html you made in http://codereview.appspot.com/105054 Regards, -- Sebastien > Many thanks for this contribution, > Tom > > > From nbaldo at cttc.es Fri Aug 14 02:42:30 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 14 Aug 2009 11:42:30 +0200 Subject: [Ns-developers] wifi overhaul for simple configuration of different PHY standards In-Reply-To: <1250177692.3372.78.camel@diese.inria.fr> References: <1250177692.3372.78.camel@diese.inria.fr> Message-ID: <4A853186.3050604@cttc.es> Hi Mathieu, Mathieu Lacage wrote: > hi, > > bug 641 outlines one of the symptoms of the current pain to configure > different PHY standards. Here is a patch which attempts to fix that bug > and simplify configuration of PHY standard for users. This patch touches > a lot of things so, I would really appreciate comments from all > concerned parties (802.11b, 10/5mhz modes, qos mac, etc.). > > API changes: > > 1) add WifiHelper::SetStandard > 2) remove NqosWifiMacHelper::SetDcaParameters > 3) remove QosWifiMacHelper::SetEdcaParametersForAc > 4) remove 'Standard' attributes from WifiPhy and WifiMac > 5) add ConfigureStandard method in WifiPhy and WifiMac > > So, nicola, mirko, others, it would be really nice to look at this > before I attempt to push it to master. > overall the patch looks very good to me. Some minor comments: a) WifiMac::FinishConfigureStandard() it would be nice to have some doxygen comments for this method. b) WifiMac::ConfigureDca() this template relies on the fact that all dca implementations have the same methods, namely SetMinCw, SetMaxCw and SetAifsn. What about using an abstract base class instead? c) are the changes in interference-helper.cc related to the PHY standard issue? Regards, Nicola From mathieu.lacage at sophia.inria.fr Fri Aug 14 02:54:22 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 14 Aug 2009 11:54:22 +0200 Subject: [Ns-developers] making the vector class more useful In-Reply-To: <39D8150A1D4F46BE97A91AE953D51AB7@CRAIGVAIO> References: <1250093476.18353.2.camel@diese.inria.fr> <1250145197.3372.2.camel@diese.inria.fr> <1250145286.3372.4.camel@diese.inria.fr> <1250154083.3372.51.camel@diese.inria.fr> <4A84FB15.10503@tomh.org> <39D8150A1D4F46BE97A91AE953D51AB7@CRAIGVAIO> Message-ID: <1250243662.11564.1.camel@diese.inria.fr> On Fri, 2009-08-14 at 00:29 -0700, craigdo at ee.washington.edu wrote: > I'm with Mathieu on this one, except I would have called them Vector2D and > Vector3D irrespective of the coding convention. Ok, so be it. Pushed to ns-3-dev since no one appeared to disagree. Mathieu From mathieu.lacage at sophia.inria.fr Fri Aug 14 03:19:21 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 14 Aug 2009 12:19:21 +0200 Subject: [Ns-developers] wifi overhaul for simple configuration of different PHY standards In-Reply-To: References: <1250177692.3372.78.camel@diese.inria.fr> Message-ID: <1250245161.11564.2.camel@diese.inria.fr> On Thu, 2009-08-13 at 22:26 +0200, Mirko Banchi wrote: > > - edca->SetTypeOfStation (AP); > + edca->SetTypeOfStation (ADHOC_STA); ha, good catch. thanks, Mathieu From mathieu.lacage at sophia.inria.fr Fri Aug 14 03:20:47 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 14 Aug 2009 12:20:47 +0200 Subject: [Ns-developers] wifi overhaul for simple configuration of different PHY standards In-Reply-To: <4A853186.3050604@cttc.es> References: <1250177692.3372.78.camel@diese.inria.fr> <4A853186.3050604@cttc.es> Message-ID: <1250245247.11564.4.camel@diese.inria.fr> On Fri, 2009-08-14 at 11:42 +0200, Nicola Baldo wrote: > a) WifiMac::FinishConfigureStandard() > it would be nice to have some doxygen comments for this method. done. > > b) WifiMac::ConfigureDca() > this template relies on the fact that all dca implementations have the > same methods, namely SetMinCw, SetMaxCw and SetAifsn. What about using > an abstract base class instead? done. > > c) are the changes in interference-helper.cc related to the PHY standard > issue? oops, testing for bug 643. Removed. Mathieu From guillaume.seguin at ens.fr Fri Aug 14 06:42:03 2009 From: guillaume.seguin at ens.fr (Guillaume Seguin) Date: Fri, 14 Aug 2009 15:42:03 +0200 Subject: [Ns-developers] Multithreading code status update Message-ID: <20090814134203.GB4581@clipper.ens.fr> During the past few weeks I've been working on a new version of the multithreaded simulator implementation. Summary ======= This new implementation is no more based on Chandy, Misra, Bryant algorithm bus uses synchronization barriers to perform critical operations, which mostly are computing a global maximum date up to which events can be computed. This way no messages are used, so that the algorithm doesn't lose all its time processing messages while doing minimal work. Where ===== I uploaded the new version to http://code.nsnam.org/guillaume/ns-3-multithreading/ and moved the previous version to http://code.nsnam.org/guillaume/ns-3-multithreading-old/ Details ======= The current multithreaded simulator code can currently two implementations of simulation barriers (POSIX (pthread) ones and spinlock ones, implemented by Mathieu Lacage), and splits the partitions into two categories : - dedicated partitions, which are specific to a given thread - shared partitions, which are stored in one or more global list, each list being processed by several threads Dedicated partitions are used to reduce contention, while shared partitions are used to balance threads run time at each iteration : threads which will have processed their dedicated partitions quickly will pick up shared partitions, so that they don't waste too much time waiting for slower threads. Two implementations of the shared partitions lists are available, a lock-based one and a lockless one, though I highly disadvice you from using the lock-based one since it has proved being really slow. Making your script use the multithreaded simulator ================================================== This is actually quite easy. You first have to enable multithreading right after processing command line arguments with : MultiThreadingHelper multiThreadingHelper; multiThreadingHelper.Enable (); Then, right before Simulator::Run (), add : multiThreadingHelper.Install (); And that's it ! For reference, see examples/multithreaded-udp-echo.cc Parameters ========== Four specific runtime parameters are available : - ns3::MultiThreadedSimulatorImpl::ThreadsCount, which specifies the number of computation threads - ns3::MultiThreadedSimulatorImpl::BarrierType, which specifies the type of barriers you want to use : either "posix" (for pthread barriers) or "spin" (for global spinlock based barriers) or the default, "spin-tree" (for tree framed spinlock based barriers) - ns3::MultiThreadedSimulatorImpl::ThreadDedicatedPercent, which specifies the percentage of thread dedicated partitions - ns3::MultiThreadedSimulatorImpl::SharedPartitionsSets, which specifies the number of shared partitions lists, which are equally distributed among threads Example : ./your-script --ns3::MultiThreadedSimulatorImpl::ThreadsCount=8 \ --ns3::MultiThreadedSimulatorImpl::BarrierType=posix \ --ns3::MultiThreadedSimulatorImpl::ThreadDedicatedPercent=60 \ --ns3::MultiThreadedSimulatorImpl::SharedPartitionsSets=4 This makes the simulator use 8 threads, synchronizing using POSIX barriers, with 60% of dedicated partitions and 4 shared partitions sets. If there are 100 partitions, each thread will have : - 7 or 8 dedicated partitions (60% of 100 divided by 8) - access to a shared partitions set which will hold 10 partitions (40% of 100 divided by 4) and which will be shared by 2 threads (8 / 4) In addition, one compile time parameters is available, defined in src/simulator/multithreaded-simulator-impl.h : - LOCKLESS_SHARED_PARTITIONS : 0 means using lock-based shared partitions sets, 1 means using lockless shared partitions sets Notes ===== As a side note, with this new version, if you specify a ThreadsCount value of 8, you'll have exactly 8 threads created, while in the previous version you had 9 ; the thread which used to be waiting for other threads is now doing actual work before waiting others. Please also note that Wifi networks still aren't supported in this version. PowerPC architecture isn't supported yet either, mostly because of thread specific storage and barrier implementations issues. The PowerPC code included for atomic and high precision clock operations hasn't been tested yet (because of the aforementioned issues). Performances ============ We've been benchmarking the multithreaded simulator using the nms-p2p (and its multithreaded clone multithreaded-nms-p2p) example. Running the nms-p2p with an up to date ns-3-dev (as of this morning) we get : Simulator init time: 11.3674 Simulator run time: 11.4909 Total elapsed time: 22.8583 Running nms-p2p on the current multithreading repo (but without multithreading) we get : Simulator init time: 24.9997 Simulator run time: 15.0179 Total elapsed time: 40.0177 Running multithreaded-nms-p2p (default parameters, not optimized yet) we get : Simulator init time: 25.0096 Simulator run time: 14.0174 Total elapsed time: 39.027 So as you can see, there is *some* gain from the multithreaded code compared to the non-multithreaded one. Sadly, the thread-safety bits introduced in the codebase also lead to a huge performance decrease compared to ns-3-dev current state. Better performances were achieved at some point, which were around the non-multithreaded code performances (for run time only) and I'm aiming to reach this point again soon. Sadly, it appears that this example has some bad bottlenecks (specifically some PointToPointNetDevice::Receive events taking a loooooot of time to run because of the shape of the network) and is more a nice routing benchmark than a multithreading one, so that performance gains can't be as awesome as we would want them to be. Call for examples ================= Consequently, if you have any real-world example that you'd like to run using the multithreaded simulator, just send it to me and I'll take care of it (private communications will remain private, though it'd be great to include the examples in the ns-3 distribution for future works). Further work ============ Well, further work includes mostly finding the best parameters and finding new examples, either from the litterature or from YOU *wink* and using them to benchmark the simulator. This will allow me to try more tricky optimizations and heuristics to balance threads or optimize memory details. Doing better memory (and more specifically L1/L2) caches benchmarks and improvements is also a path to follow. Last, a good solution to support Wifi networks has to be found. Feel free to send any question you might have about this implementation :) Best regards, Guillaume Seguin From peppe.piro at gmail.com Fri Aug 14 02:55:25 2009 From: peppe.piro at gmail.com (Giuseppe Piro) Date: Fri, 14 Aug 2009 11:55:25 +0200 Subject: [Ns-developers] patch for Wimax Scheduler In-Reply-To: <4A8516E3.5090303@sophia.inria.fr> References: <4365bdc50908130324t3f1b56baq22de024cc5f1196a@mail.gmail.com> <4A842448.6020603@sophia.inria.fr> <4A842FB0.2090601@gmail.com> <4A8516E3.5090303@sophia.inria.fr> Message-ID: <4365bdc50908140255ofd32ec6rba9dfc88d7d5f6d5@mail.gmail.com> 2009/8/14 Ismail Amine > Hi Guys, > > I would like to thank Giuseppe and Flavio for their great work on uplink > and downlink schedulers!! Just one thing, could you put ns-3-developers and > ns-3-users mailing lists in cc please? > For Giuseppe: Sorry for the delay but I am very busy since I am trying to > finish the implementation of loss model before the deadline of 17/08! I will > try to work on the BandwidthRequest bug the next week! > > On an other hand, as we will start the testing and debugging phase next > week, it will be nice if we log the bug that we find using > http://www.nsnam.org/bugzilla/ (choose ns-3 as product and wimax as > component). Giuseppe: could you enter the bug about the BandwidthRequest in > the database? Sure! > > > > Thank you > Amine > > > > > > > Giuseppe Piro wrote: > >> Faker Moatamri ha scritto: >> >>> Giuseppe Piro wrote: >>> >>>> Hi Amine and Faker! >>>> >>>> You can find attached my patch based on " >>>> http://code.nsnam.org/iamine/ns-3-wimax-dev" code. >>>> >>>> As I have already written to Amine, I have implemented a simple >>>> scheduler for both UL and DL. >>>> >>>> The goals of my work is to define a simple scheduler (obviously >>>> standard-compliant) that is able to serve all rtPS >>>> active flows in the wimax scenario. Infact in the actual code not all >>>> connection are able to transmit their packets >>>> into the UL Sub Frame (and so into the DL). >>>> >>>> The scheduler that you are proposing is the same as the one already >>> implemented but with more features or it is a different method?? >>> >> The scheduler is the same as the one already implemented but with more >> features. >> >>> The schedulers use the priority approach to serve all type of service >>>> flows (as the standard proposes). >>>> In DL the available bandwidth is assigned to the service flows in the >>>> following order: >>>> - IR Connections >>>> - Broadcast Connections >>>> - Basic and Primary Connections >>>> - UGS Connections >>>> - rtPS Connections >>>> - nrtPS Connections >>>> - BE Connections >>>> To be more precisely, IR, Broadcast and Basic/Primary Connections must >>>> transmit all packet in the queue. UGS Connections can trasmit their >>>> requested Grant Size (that is one of service flows QoS parameters) according >>>> to their requested MaxLatency (another QoS parameter). >>>> ALL rtPS Connections are able to transmit all packet in the queue >>>> according to the available bandwidth. The bandwidth saturation control has >>>> been implemented to redistribute the effective available bandwidth to ALL >>>> rtPS that have at least one packet to transmit. The remaining bandwidth is >>>> allocated to rntPS and BE Connections. >>>> >>>> The UL Scheduler work in this way: >>>> At the beginning of the UL sub-frame some simbols are allocated to the >>>> rangingInterval Messages, DSA Messages, UGS grant and UGS/rtPS/nrtPS/BE >>>> poll. >>>> Then, the remaining available symbols are allocated to the ALL rtPS >>>> Connection according to their requestedBandwidth. >>>> Also in this case, the bandwidth saturation control has been >>>> implemented. >>>> So, the remaining symbols are allocated to nrtPS and BE Connections. >>>> >>>> >>>> To implement this schedulers, I have done some little changes in >>>> bs-scheduler.cc and uplink-scheduler.cc files. >>>> I think that this schedulers may be the default implementation for the >>>> next release, and so we can compare the effectiveness of all Schedulers (for >>>> example the UL scheduler implemented by Flavio or the feedback based >>>> schedulers for which I'm working on). >>>> >>>> If your scheduler is different from the implemented one, we'd rather >>> have 3 instead of two. >>> I think that the my UL/DL schedulers (that may became the default >>> implementation) and the Flavio's implementation are safely mergeable with >>> wimax and then with ns-3-dev. You can add the switch-case for rtPS/nrtPS >>> schedulers considering both of implementations. >>> In this way, I can merge the scheduler for wich I'm working on in a >>> safely way! >>> >>> >>> It is important to remark anothe little changes that I have done on the >>> code: >>> >>> 1)bandwidth-manager.cc: When the Service Flows send the >>> BandwidthRequest, set the bytesToRequest like to the queue length and so the >>> BandwidthRequestHeader is equal to HEADER_TYPE_AGGREGATE >>> >>> 2)ofdm-wimax-phy.cc and ofdm-wimax-phy.h, simpleOfdmWimaxPhy.cc and >>> simpleOfdmWimaxPhy.h, wimax-phy.cc and wimax-phy.h, simple-wimax-phy.cc and >>> simple-wimax-phy.h: >>> I have added the this function: >>> "DoGetNrBytes(uint32_t symbols, WimaxPhy::ModulationType >>> modulationType) const;" >>> that convert the number of symbols in the number of bytes. >>> >>> 3)service-flow-record.cc: >>> I have modified the SetRequestedBandwidth function. >>> >>> 4)wimax-mac-queue.cc and wimax-mac-queue.h: I have added the function >>> "const WimaxMacQueue::PacketQueue & GetPacketQueue(void) const;". >>> >>> >>> >>> HAVE YOU ANY QUESTIONS? :-) >>> >>> See you! >>> Peppe >>> >>> >>> for Amine: The bug about the BandwidthRequest value isn't resolved yet! >>> >>> >>> -- >>> Giuseppe Piro >>> Ph.D. Student >>> DEE - Politecnico di Bari >>> v. Orabona 4, 70125 - Bari, Italy >>> e-mail: g.piro at poliba.it >>> peppe.piro at gmail.com >>> Phone: +39 0805963301 >>> Web: http://telematics.poliba.it/piro >>> For the code implementation, I think that ideally we will have a >>> completely virtual uplink/downlink scheduler with different implementations. >>> That would be easier for everybody. And in that case we will be able to add >>> as many schedulers as we want. You can take a look at Flavio code on >>> http://code.nsnam.org/flaviokubota/ns-3-wimax-dev/, he made some >>> functions of uplink-scheduler virtual so that he can reimplement them. We'd >>> rather create a completely virtual uplink-scheduler with different >>> implementations so that we cannot instantiate anymore the uplink-scheduler >>> class and we are obliged to choose one of the implementations. >>> The best way to go is that you and Flavio (added in cc) synchronize your >>> work together and submit one patch, since you're working on the same peace >>> of code conflicts are expected if you don't work together to get the two >>> implementations for the next release. >>> Giuseppe and Flavio, can you please take a look at each other's code and >>> manage to merge it together? (for Flavio Giuseppe's patch is attached, sorry >>> for others that already have the patch) >>> >> Ok, I'll look the Flavio's implementation to try to merge our patches. >> >>> >>> I have several other remarks: >>> - First of all this email should be sent to ns-developers mailing list ( >>> ns-developers at ISI.EDU), please send emails to this list, this is really >>> VERY important >>> For your patch: >>> - Avoid having space changes (there is an option to ignore those changes) >>> - Add doxygen >>> - Remove commented code >>> - Be careful to respect coding style (space before parentheses, 2 spaces >>> indentation, ... http://www.nsnam.org/codingstyle.html) >>> >>> Thanks >>> Faker Moatarmri >>> >>> >> >> >> Giuseppe Piro >> >> >> > > -- Giuseppe Piro Ph.D. Student DEE - Politecnico di Bari v. Orabona 4, 70125 - Bari, Italy e-mail: g.piro at poliba.it peppe.piro at gmail.com Phone: +39 0805963301 Web: http://telematics.poliba.it/piro From tom5760 at gmail.com Fri Aug 14 14:02:14 2009 From: tom5760 at gmail.com (Tom Wambold) Date: Fri, 14 Aug 2009 17:02:14 -0400 Subject: [Ns-developers] Fwd: NS-3 RFC5444 (PacketBB) Implementation In-Reply-To: References: Message-ID: All: I have just recently published a new PacketBB implementation for the NS-3 Network Simulator as part of work at Drexel University and University of Pennsylvania. The implementation can be found in the Mercurial repository at [1]. ?The source files are in src/contrib/packetbb.{cc,h}. ?A thorough test can be found at src/contrib/test-packetbb.cc This library fully conforms to RFC5444 [2], and passes all interoperability tests performed at the 2008 OLSR Interop [3]. ?Since these example packets were based on an earlier PacketBB draft, a minor change was needed to match the latest RFC. ?Otherwise, this implementation passes all of the tests found at [4]. We will be actively using this library to support our implementation of NHDP and SMF. ?These should be ready for release in a few weeks. Hopefully, these could be merged into the main NS-3 distribution. Since NS-3 has a full IP stack, with packets being fully serialized, this implementation could potentially interoperate with other PacketBB implementations when using NS-3 in emulation. ?Also, this implementation is fairly generic, so it could be ported to live systems without much effort. Please feel free to send me any questions/comments/etc. that you may have as we are actively using and maintaining this library. Thanks! -Tom Wambold [1] - http://code.nsnam.org/twambold/ns-3-dev-packetbb [2] - http://tools.ietf.org/html/rfc5444 [3] - http://interop08.thomasclausen.org/packets-and-dumps.txt [4] - http://code.nsnam.org/twambold/ns-3-dev-packetbb/file/tip/src/contrib/test-packetbb.cc From faker.moatamri at sophia.inria.fr Mon Aug 17 01:04:43 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 17 Aug 2009 10:04:43 +0200 Subject: [Ns-developers] Wimax dev freeze Message-ID: <4A890F1B.50709@sophia.inria.fr> Hi all, As of today, we freeze the development for new features in the wimax module. Only bug fixing and added code reviews are allowed from now on. We remind you that the plan is to freeze bug fixing and code reviewing on thursday August 20th. The next milestones will be: -Wednesday August 26th: Merge with the latest version of ns-3-dev and testing -Tuesday September 1st: Submission of the proposed Wimax patch for review Thank you all for your participation Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Mon Aug 17 02:16:29 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 17 Aug 2009 11:16:29 +0200 Subject: [Ns-developers] errors when I try to compile ns-3-wimax-dev-schedulers In-Reply-To: <4A8909BC.1080107@sophia.inria.fr> References: <77f6152c-bed2-45e7-b4a0-f466a706128a@t13g2000yqt.googlegroups.com> <4365bdc50908161007l39209a04yb1cf8889d57f6590@mail.gmail.com> <4365bdc50908161111l3cfd283n3349043c72f63edf@mail.gmail.com> <4A8909BC.1080107@sophia.inria.fr> Message-ID: <4A891FED.7070508@sophia.inria.fr> Ismail Amine wrote: > Hi Giuseppe and Flavio, > > > Giuseppe Piro wrote: > >> 2009/8/16 Flavio Kubota > > >> >> Hi Giuseppe, >> >> Those warnings when compiling with g++-4.2 were already removed. >> >> On Sun, Aug 16, 2009 at 2:07 PM, Giuseppe Piro >> > wrote: >> >> Hi Flavio, >> >> The code compile without any error! >> >> Just one thing: Do you know why the function >> SendBandwidthRequest and ProcessBandwidthRequest are never >> called? Is this another bug? >> >> To find this... you can simulate examples/my-simple-wimax.cc, >> after you have changed the SFID from 100 (UGS) to 101 (rtPS). >> >> I run the original wimax module (without merged schedulers) and >> those methods were never called too. >> I notice that If you remove UGS connection >> ("wimax.SetupConnection(ss[i], bs[0], UGSparameterSet[i], >> QoSParameterSet::SCHEDULING_TYPE_UGS)"), the functions >> SendBandwidthRequest and ProcessBandwidthRequest are called. >> >> >> Are you sure? I remenber that this function are called with >> simple-scheduler (ns-3-dev-wimax without any patch) and ns-3-wimax-dev >> with my patch! >> Have you chanded this line (in example/my-simple-wimax.cc ) >> >> wimax.ClassifierConfig(ss[i + (nbSS / 2)], ss[i], bs[0], >> SSinterfaces.GetAddress(i + (nbSS / 2)), >> SSinterfaces.GetAddress(i), >> 0, 100 + (i * 10), 17, 100); >> >> with >> wimax.ClassifierConfig(ss[i + (nbSS / 2)], ss[i], bs[0], >> SSinterfaces.GetAddress(i + (nbSS / 2)), >> SSinterfaces.GetAddress(i), >> 0, 100 + (i * 10), 17, 101); >> >> ? >> >> >> >> >> I don't know if it is a bug. Maybe you should ask Amine if >> classifiers are working correctly. >> I'm currently not using these classifiers, I setup only one >> connection per SS. >> >> >> I think that the Classifier works also if each SS hosts only one >> transport connection connection. >> Amine, wath do you think about this? >> > I don't have any idea about SendBandwidthRequest and > ProcessBandwidthRequest functions but regarding the Classifier I think > that it is working correctly! > > >> >> >> >> >> >> >> >> 2009/8/16 Flavio Kubota > > >> >> Hi Giuseppe, >> >> >> On Sun, Aug 16, 2009 at 5:11 AM, Giuseppe Piro >> > wrote: >> >> Hi Flavio, >> I'm trying to compile the >> http://code.nsnam.org/flaviokubota/ns-3-wimax-dev-schedulers/ >> code ... >> but I find these errors: >> >> with g++-4.2: >> >> [637/748] cxx: >> src/devices/wimax/uplink-scheduler-mbqos.cc -> build/ >> debug/src/devices/wimax/uplink-scheduler-mbqos_1.o >> cc1plus: warnings being treated as errors >> ../src/devices/wimax/uplink-scheduler-mbqos.cc: In >> member function >> ?virtual bool >> ns3::UplinkSchedulerMBQoS::ServiceBandwidthRequests >> (ns3::ServiceFlow*, ns3::QoSParameterSet::SchedulingType, >> ns3::OfdmUlMapIe&, ns3::WimaxPhy::ModulationType, >> uint32_t&, >> uint32_t&)?: >> ../src/devices/wimax/uplink-scheduler-mbqos.cc:860: >> warning: >> comparison between signed and unsigned integer expressions >> Waf: Leaving directory >> `/home/peppe/ns-3-wimax-dev-schedulers/build' >> Build failed >> -> task failed (err #1): >> {task: cxx uplink-scheduler-mbqos.cc -> >> uplink-scheduler- >> mbqos_1.o} >> >> This warning will be removed. Try to compile without >> -werror flag. To configure, I'm using: >> CXXFLAGS="-Wall -g" ./waf configure >> >> >> >> >> >> with g++-4.3.2 >> >> [599/748] cxx: src/helper/udpHelper.cc -> >> build/debug/src/helper/ >> udpHelper_1.o >> In file included from >> debug/ns3/IPCS_SS_Packet_classifier.h:26, >> from debug/ns3/wimax-ss-net-device.h:29, >> from debug/ns3/wimax-bs-net-device.h:29, >> from ../src/helper/wimax-helper.h:29, >> from ../src/helper/wimax-helper.cc:22: >> debug/ns3/IPCS_Bind_parameter_manager.h:40: error: >> multiple parameters >> named ?src_ip_adr? >> [600/748] cxx: >> src/helper/trace-based-streamer-helper.cc -> build/ >> debug/src/helper/trace-based-streamer-helper_1.o >> In file included from ../src/helper/wimax-helper.cc:22: >> ../src/helper/wimax-helper.h:194: error: multiple >> parameters named >> ?schedulerType? >> Waf: Leaving directory >> `/home/peppe/ns-3-wimax-dev-schedulers/build' >> Build failed >> -> task failed (err #1): >> {task: cxx wimax-helper.cc -> wimax-helper_1.o} >> >> Thanks for report this. I'll check this error. >> >> >> >> >> >> >> Plese, could you show me what g++ compiler you are using? >> >> >> Thanks, >> >> Peppe >> >> >> >> >> -- >> Giuseppe Piro >> Ph.D. Student >> DEE - Politecnico di Bari >> v. Orabona 4, 70125 - Bari, Italy >> e-mail: g.piro at poliba.it >> peppe.piro at gmail.com >> Phone: +39 0805963301 >> Web: http://telematics.poliba.it/piro >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ > 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 > -~----------~----~----~----~------~----~------~--~--- > > Hi all, Those warnings should be fixed, using -wall will treat warnings as warnings just displaying them without interrupting the compilation. This is a turn around and I think that you should fix this warning and make the comparison between compatible types or make an explicit cast. Is there any patch ready for reviewing? Best regards Faker Moatamri From flaviokubota at gmail.com Mon Aug 17 05:18:06 2009 From: flaviokubota at gmail.com (Flavio Kubota) Date: Mon, 17 Aug 2009 09:18:06 -0300 Subject: [Ns-developers] GSoC: Scheduler for WiMAX module Message-ID: Hi, Me and Giuseppe Piro had implemented schedulers for WiMAX module. We merged our work and, at this code implementation, we have a completely virtual uplink/downlink scheduler with different implementations. The code is based on http://code.nsnam.org/iamine/ns-3-wimax-dev/ and a patch is attached. The code is also available on http://code.nsnam.org/flaviokubota/ns-3-wimax-dev-schedulers/ . Today we freeze the development for new features but I'll keep removing bugs and testing on others compilers. -- Flavio Kubota MSc Computer Science Student IC / UNICAMP -------------- next part -------------- A non-text attachment was scrubbed... Name: GSoC_WiMAX_Schedulers.patch Type: text/x-patch Size: 228576 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090817/668487df/GSoC_WiMAX_Schedulers-0001.bin From amine.ismail at sophia.inria.fr Mon Aug 17 05:51:30 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Mon, 17 Aug 2009 14:51:30 +0200 Subject: [Ns-developers] Wimax dev freeze In-Reply-To: <4A890F1B.50709@sophia.inria.fr> References: <4A890F1B.50709@sophia.inria.fr> Message-ID: <4A895252.50505@sophia.inria.fr> Hi all, I have created a new mercurial repository on code.nsnam.org : http://code.nsnam.org/iamine/ns-3-wimax-to_be_released/ This repository contains the wimax module that we propose to be merged with the ns-3 main development tree. I have applied my patch that provides an enhanced physical layer, and I will also apply the patch provided by Flavio Kubota and Giuseppe Piro. Best regards Amine Faker Moatamri wrote: > Hi all, > As of today, we freeze the development for new features in the wimax > module. Only bug fixing and added code reviews are allowed from now on. > We remind you that the plan is to freeze bug fixing and code reviewing > on thursday August 20th. > The next milestones will be: > -Wednesday August 26th: Merge with the latest version of ns-3-dev and > testing > -Tuesday September 1st: Submission of the proposed Wimax patch for review > Thank you all for your participation > Best regards > Faker Moatamri From faker.moatamri at sophia.inria.fr Mon Aug 17 06:58:01 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 17 Aug 2009 15:58:01 +0200 Subject: [Ns-developers] Wimax patch reviews Message-ID: <4A8961E9.2030505@sophia.inria.fr> Hi all, I uploaded the patches submitted by Amine and by Flavio/Giuseppe to be reviewed. We need to have a review of the code done as fast as possible to have enough time to correct the code before submitting final patches. Any review from the community will be welcome but it has to be done before Tuesday evening. Here is the code review for Upload/Download Scheduler for Wimax: http://codereview.appspot.com/107047 Here is the code review for Propagation and loss model enhanced http://codereview.appspot.com/108047 I propose that we distribute our review energy on those: -Flavio and Giovanni can review Amine's code -I and Amine can review Flavio/Giuseppe's code. To review the code you need only to have a gmail account and to add comments in the web page. Please try to do it by Tuesday evening and if you can't just tell me. I will try to do my best to review both codes. Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Tue Aug 18 01:00:46 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 18 Aug 2009 10:00:46 +0200 Subject: [Ns-developers] Review of your patch Message-ID: <4A8A5FAE.6040400@sophia.inria.fr> Hi Giuseppe and Flavio, Please find in this web page a review of your code, can you please take a look at it and correct the patch if needed? http://codereview.appspot.com/107047 Thanks Faker Moatamri From faker.moatamri at sophia.inria.fr Tue Aug 18 01:56:10 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 18 Aug 2009 10:56:10 +0200 Subject: [Ns-developers] review of your patch Message-ID: <4A8A6CAA.3070805@sophia.inria.fr> Hi Amine, Here is a review of your code. Can you please correct what needs to be corrected and update the created repository accordingly? http://codereview.appspot.com/108047 Thank you Best regards Faker Moatamri From amine.ismail at sophia.inria.fr Tue Aug 18 07:13:31 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Tue, 18 Aug 2009 16:13:31 +0200 Subject: [Ns-developers] [Fwd: Re: review of your patch] Message-ID: <4A8AB70B.7060002@sophia.inria.fr> -------------- next part -------------- An embedded message was scrubbed... From: Ismail Amine Subject: Re: [Ns-developers] review of your patch Date: Tue, 18 Aug 2009 16:04:51 +0200 Size: 2165 Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20090818/e8b99e5c/Ns-developersreviewofyourpatch.eml From faker.moatamri at sophia.inria.fr Tue Aug 18 09:00:07 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 18 Aug 2009 18:00:07 +0200 Subject: [Ns-developers] Repository http://code.nsnam.org/iamine/ns-3-wimax-to_be_released Message-ID: <4A8AD007.9050406@sophia.inria.fr> Hi all, The repository http://code.nsnam.org/iamine/ns-3-wimax-to_be_released doesn't include some of the changes that I applied to ns-3-wimax-dev and thus it doesn't compile with g++-3.4.6 , g++-4.0.4 , g++-4.3.3 and g++-4.4.0. Here is a patch to make it compile under those platforms, Amine can you apply it as soon as possible to make the repository more platform compatible. Flavio, Giuseppe, now that your patches are included you can make the fixes suggested in the review directly in the new repository. Thanks Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: compiling.patch Type: text/x-patch Size: 11703 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090818/0a037d00/compiling.bin From faker.moatamri at sophia.inria.fr Tue Aug 18 09:05:08 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 18 Aug 2009 18:05:08 +0200 Subject: [Ns-developers] Repository http://code.nsnam.org/iamine/ns-3-wimax-to_be_released Message-ID: <4A8AD134.4080802@sophia.inria.fr> Hi all, Sorry for previous mail with useless links, here is the good one The repository http://code.nsnam.org/iamine/ns-3-wimax-to_be_released doesn't include some of the changes that I applied to ns-3-wimax-dev and thus it doesn't compile with g++-3.4.6, g++-4.0.4, g++-4.3.3 and g++-4.4.0. Here is a patch to make it compile under those platforms, Amine can you apply it as soon as possible to make the repository more platform compatible. Flavio, Giuseppe, now that your patches are included you can make the fixes suggested in the review directly in the new repository. Best regards Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: compiling.patch Type: text/x-patch Size: 11703 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090818/85790044/compiling-0001.bin From amine.ismail at sophia.inria.fr Tue Aug 18 10:00:33 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Tue, 18 Aug 2009 19:00:33 +0200 Subject: [Ns-developers] Repository http://code.nsnam.org/iamine/ns-3-wimax-to_be_released In-Reply-To: <4A8AD134.4080802@sophia.inria.fr> References: <4A8AD134.4080802@sophia.inria.fr> Message-ID: <4A8ADE31.5020901@sophia.inria.fr> > Here is a patch to make it compile under those platforms, Amine can you apply it as soon as possible to make the repository > more platform compatible. Done! Faker Moatamri wrote: > Hi all, > Sorry for previous mail with useless links, here is the good one > The repository http://code.nsnam.org/iamine/ns-3-wimax-to_be_released > doesn't include some of the changes that I applied to ns-3-wimax-dev > and thus it doesn't compile with g++-3.4.6, g++-4.0.4, g++-4.3.3 and > g++-4.4.0. > Here is a patch to make it compile under those platforms, Amine can > you apply it as soon as possible to make the repository more platform > compatible. > Flavio, Giuseppe, now that your patches are included you can make the > fixes suggested in the review directly in the new repository. > Best regards > Faker Moatamri From guillaume.seguin at ens.fr Wed Aug 19 05:20:00 2009 From: guillaume.seguin at ens.fr (Guillaume Seguin) Date: Wed, 19 Aug 2009 14:20:00 +0200 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl Message-ID: <20090819122000.GC15935@clipper.ens.fr> Some benchmarks I made showed a 15% speedup of the global routing table initialization by not recomputing the NodeList::End () at every iteration in the GlobalRouteManagerImpl code. May I push this patch to ns-3-dev ? Thanks ! Guillaume diff -r bf61a97f667b src/routing/global-routing/global-route-manager-impl.cc --- a/src/routing/global-routing/global-route-manager-impl.cc Tue Aug 18 18:13:16 2009 +0200 +++ b/src/routing/global-routing/global-route-manager-impl.cc Wed Aug 19 13:22:44 2009 +0200 @@ -371,7 +371,8 @@ GlobalRouteManagerImpl::DeleteGlobalRoutes () { NS_LOG_FUNCTION_NOARGS (); - for (NodeList::Iterator i = NodeList::Begin (); i != NodeList::End (); i++) + NodeList::Iterator listEnd = NodeList::End (); + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) { Ptr node = *i; Ptr router = node->GetObject (); @@ -418,7 +419,8 @@ // Walk the list of nodes looking for the GlobalRouter Interface. Nodes with // global router interfaces are, not too surprisingly, our routers. // - for (NodeList::Iterator i = NodeList::Begin (); i != NodeList::End (); i++) + NodeList::Iterator listEnd = NodeList::End (); + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) { Ptr node = *i; @@ -498,7 +500,8 @@ // // Walk the list of nodes in the system. // - for (NodeList::Iterator i = NodeList::Begin (); i != NodeList::End (); i++) + NodeList::Iterator listEnd = NodeList::End (); + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) { Ptr node = *i; // @@ -1318,7 +1321,8 @@ // the routing information to. // NodeList::Iterator i = NodeList::Begin (); - for (; i != NodeList::End (); i++) + NodeList::Iterator listEnd = NodeList::End (); + for (; i != listEnd; i++) { Ptr node = *i; // @@ -1439,7 +1443,8 @@ // building the routing table. // NodeList::Iterator i = NodeList::Begin (); - for (; i != NodeList::End (); i++) + NodeList::Iterator listEnd = NodeList::End (); + for (; i != listEnd; i++) { Ptr node = *i; @@ -1529,7 +1534,8 @@ // the routing information to. // NodeList::Iterator i = NodeList::Begin (); - for (; i != NodeList::End (); i++) + NodeList::Iterator listEnd = NodeList::End (); + for (; i != listEnd; i++) { Ptr node = *i; // @@ -1669,7 +1675,8 @@ // the routing information to. // NodeList::Iterator i = NodeList::Begin (); - for (; i != NodeList::End (); i++) + NodeList::Iterator listEnd = NodeList::End (); + for (; i != listEnd; i++) { Ptr node = *i; // From gjcarneiro at gmail.com Wed Aug 19 06:38:47 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 19 Aug 2009 14:38:47 +0100 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: <20090819122000.GC15935@clipper.ens.fr> References: <20090819122000.GC15935@clipper.ens.fr> Message-ID: So you speed up 15% of global routing, which is, what, 1% of the simulation time? Hardly seems worth it, IMHO (unless global routing is called repeatedly during a simulation). And have you compared with the far cleaner solution of making NodeList::Begin() and NodeList::End() inline functions (unless with the NodeList/NodeListPriv split it may not have the desired speedup)? Just my 2 cents. 2009/8/19 Guillaume Seguin > Some benchmarks I made showed a 15% speedup of the global routing table > initialization by not recomputing the NodeList::End () at every iteration > in the > GlobalRouteManagerImpl code. May I push this patch to ns-3-dev ? > > Thanks ! > Guillaume > > diff -r bf61a97f667b > src/routing/global-routing/global-route-manager-impl.cc > --- a/src/routing/global-routing/global-route-manager-impl.cc Tue Aug 18 > 18:13:16 2009 +0200 > +++ b/src/routing/global-routing/global-route-manager-impl.cc Wed Aug 19 > 13:22:44 2009 +0200 > @@ -371,7 +371,8 @@ > GlobalRouteManagerImpl::DeleteGlobalRoutes () > { > NS_LOG_FUNCTION_NOARGS (); > - for (NodeList::Iterator i = NodeList::Begin (); i != NodeList::End (); > i++) > + NodeList::Iterator listEnd = NodeList::End (); > + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) > { > Ptr node = *i; > Ptr router = node->GetObject (); > @@ -418,7 +419,8 @@ > // Walk the list of nodes looking for the GlobalRouter Interface. Nodes > with > // global router interfaces are, not too surprisingly, our routers. > // > - for (NodeList::Iterator i = NodeList::Begin (); i != NodeList::End (); > i++) > + NodeList::Iterator listEnd = NodeList::End (); > + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) > { > Ptr node = *i; > > @@ -498,7 +500,8 @@ > // > // Walk the list of nodes in the system. > // > - for (NodeList::Iterator i = NodeList::Begin (); i != NodeList::End (); > i++) > + NodeList::Iterator listEnd = NodeList::End (); > + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) > { > Ptr node = *i; > // > @@ -1318,7 +1321,8 @@ > // the routing information to. > // > NodeList::Iterator i = NodeList::Begin (); > - for (; i != NodeList::End (); i++) > + NodeList::Iterator listEnd = NodeList::End (); > + for (; i != listEnd; i++) > { > Ptr node = *i; > // > @@ -1439,7 +1443,8 @@ > // building the routing table. > // > NodeList::Iterator i = NodeList::Begin (); > - for (; i != NodeList::End (); i++) > + NodeList::Iterator listEnd = NodeList::End (); > + for (; i != listEnd; i++) > { > Ptr node = *i; > > @@ -1529,7 +1534,8 @@ > // the routing information to. > // > NodeList::Iterator i = NodeList::Begin (); > - for (; i != NodeList::End (); i++) > + NodeList::Iterator listEnd = NodeList::End (); > + for (; i != listEnd; i++) > { > Ptr node = *i; > // > @@ -1669,7 +1675,8 @@ > // the routing information to. > // > NodeList::Iterator i = NodeList::Begin (); > - for (; i != NodeList::End (); i++) > + NodeList::Iterator listEnd = NodeList::End (); > + for (; i != listEnd; i++) > { > Ptr node = *i; > // > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From guillaume.seguin at ens.fr Wed Aug 19 06:55:09 2009 From: guillaume.seguin at ens.fr (Guillaume Seguin) Date: Wed, 19 Aug 2009 15:55:09 +0200 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: References: <20090819122000.GC15935@clipper.ens.fr> Message-ID: <20090819135509.GD15935@clipper.ens.fr> On 19 ao?t 2009 ? 14:38:47 (+0100), Gustavo Carneiro wrote : > So you speed up 15% of global routing, which is, what, 1% of the simulation > time? Hardly seems worth it, IMHO (unless global routing is called > repeatedly during a simulation). > It all depends on the length of the subsequent simulation. On the example I'm working on, on current ns-3-dev, the routing table init phase takes 11 seconds and the simulation phase takes 11 seconds. So I'm speeding up 15% of 50% of the script runtime. Seems worth it, IMHO. > And have you compared with the far cleaner solution of making > NodeList::Begin() and NodeList::End() inline functions (unless with the > NodeList/NodeListPriv split it may not have the desired speedup)? > As far as I understand the gain, it was because the end node kept getting it's reference count to 0, thus running a MaybeDelete (even though the node wasn't getting freed in the end). Storing the end node outside of the loop has the nice effect of keeping the reference count at least at 1 during the whole iteration, avoiding the collection attempt. So this is *not* about avoiding a bunch of function calls. Guillaume From riley at ece.gatech.edu Wed Aug 19 06:59:33 2009 From: riley at ece.gatech.edu (George Riley) Date: Wed, 19 Aug 2009 09:59:33 -0400 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: References: <20090819122000.GC15935@clipper.ens.fr> Message-ID: <9FF4F2F3-18FF-43BB-8F82-F2DBB4F90B3F@ece.gatech.edu> Gustavo, Where did you get the statistic about global routing being 1% of the total sim time? Routing computations can be quite time consuming for large topologies. Secondly, I am in favor of almost any efficiency improvement, as long as it does not decrease code readability or understandability. I vote for this to be merged. Geroge -------------------------------------------------- George Riley Associate Professor Georgia Tech Electrical and Computer Engineering riley at ece.gatech.edu 404-894-4767 Klaus Advanced Computing Building Room 3360 266 Ferst Drive Atlanta, Georgia 30332-0765 ECE6110 Web page: http://users.ece.gatech.edu/~riley/ece6110/ ECE3090 Web page: http://users.ece.gatech.edu/~riley/ece3090/ On Aug 19, 2009, at 9:38 AM, Gustavo Carneiro wrote: > So you speed up 15% of global routing, which is, what, 1% of the > simulation > time? Hardly seems worth it, IMHO (unless global routing is called > repeatedly during a simulation). > > And have you compared with the far cleaner solution of making > NodeList::Begin() and NodeList::End() inline functions (unless with > the > NodeList/NodeListPriv split it may not have the desired speedup)? > > Just my 2 cents. > > 2009/8/19 Guillaume Seguin > >> Some benchmarks I made showed a 15% speedup of the global routing >> table >> initialization by not recomputing the NodeList::End () at every >> iteration >> in the >> GlobalRouteManagerImpl code. May I push this patch to ns-3-dev ? >> >> Thanks ! >> Guillaume >> >> diff -r bf61a97f667b >> src/routing/global-routing/global-route-manager-impl.cc >> --- a/src/routing/global-routing/global-route-manager-impl.cc Tue >> Aug 18 >> 18:13:16 2009 +0200 >> +++ b/src/routing/global-routing/global-route-manager-impl.cc Wed >> Aug 19 >> 13:22:44 2009 +0200 >> @@ -371,7 +371,8 @@ >> GlobalRouteManagerImpl::DeleteGlobalRoutes () >> { >> NS_LOG_FUNCTION_NOARGS (); >> - for (NodeList::Iterator i = NodeList::Begin (); i != >> NodeList::End (); >> i++) >> + NodeList::Iterator listEnd = NodeList::End (); >> + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) >> { >> Ptr node = *i; >> Ptr router = node->GetObject (); >> @@ -418,7 +419,8 @@ >> // Walk the list of nodes looking for the GlobalRouter Interface. >> Nodes >> with >> // global router interfaces are, not too surprisingly, our routers. >> // >> - for (NodeList::Iterator i = NodeList::Begin (); i != >> NodeList::End (); >> i++) >> + NodeList::Iterator listEnd = NodeList::End (); >> + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) >> { >> Ptr node = *i; >> >> @@ -498,7 +500,8 @@ >> // >> // Walk the list of nodes in the system. >> // >> - for (NodeList::Iterator i = NodeList::Begin (); i != >> NodeList::End (); >> i++) >> + NodeList::Iterator listEnd = NodeList::End (); >> + for (NodeList::Iterator i = NodeList::Begin (); i != listEnd; i++) >> { >> Ptr node = *i; >> // >> @@ -1318,7 +1321,8 @@ >> // the routing information to. >> // >> NodeList::Iterator i = NodeList::Begin (); >> - for (; i != NodeList::End (); i++) >> + NodeList::Iterator listEnd = NodeList::End (); >> + for (; i != listEnd; i++) >> { >> Ptr node = *i; >> // >> @@ -1439,7 +1443,8 @@ >> // building the routing table. >> // >> NodeList::Iterator i = NodeList::Begin (); >> - for (; i != NodeList::End (); i++) >> + NodeList::Iterator listEnd = NodeList::End (); >> + for (; i != listEnd; i++) >> { >> Ptr node = *i; >> >> @@ -1529,7 +1534,8 @@ >> // the routing information to. >> // >> NodeList::Iterator i = NodeList::Begin (); >> - for (; i != NodeList::End (); i++) >> + NodeList::Iterator listEnd = NodeList::End (); >> + for (; i != listEnd; i++) >> { >> Ptr node = *i; >> // >> @@ -1669,7 +1675,8 @@ >> // the routing information to. >> // >> NodeList::Iterator i = NodeList::Begin (); >> - for (; i != NodeList::End (); i++) >> + NodeList::Iterator listEnd = NodeList::End (); >> + for (; i != listEnd; i++) >> { >> Ptr node = *i; >> // >> > > > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert From gjcarneiro at gmail.com Wed Aug 19 07:13:52 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 19 Aug 2009 15:13:52 +0100 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: <20090819135509.GD15935@clipper.ens.fr> References: <20090819122000.GC15935@clipper.ens.fr> <20090819135509.GD15935@clipper.ens.fr> Message-ID: 2009/8/19 Guillaume Seguin > On 19 ao?t 2009 ? 14:38:47 (+0100), Gustavo Carneiro wrote : > > So you speed up 15% of global routing, which is, what, 1% of the > simulation > > time? Hardly seems worth it, IMHO (unless global routing is called > > repeatedly during a simulation). > > > > It all depends on the length of the subsequent simulation. On the example > I'm > working on, on current ns-3-dev, the routing table init phase takes 11 > seconds > and the simulation phase takes 11 seconds. So I'm speeding up 15% of 50% of > the > script runtime. Seems worth it, IMHO. OK, I guess. I have been running simulations that take over an hour each to complete, so 11 seconds is not noticeable in my case, but I now understand better your concern. > > > > And have you compared with the far cleaner solution of making > > NodeList::Begin() and NodeList::End() inline functions (unless with the > > NodeList/NodeListPriv split it may not have the desired speedup)? > > > > As far as I understand the gain, it was because the end node kept getting > it's > reference count to 0, thus running a MaybeDelete (even though the node > wasn't > getting freed in the end). Storing the end node outside of the loop has the > nice > effect of keeping the reference count at least at 1 during the whole > iteration, > avoiding the collection attempt. So this is *not* about avoiding a bunch of > function calls. What do you mean by "end node"? NodeList::End() should return an std::vector >::iterator which points beyond the end of the vector. You cannot dereference this iterator or the pointer contained inside or else you read garbage. I don't think the listEnd variable in your patch causes any Node reference count to increase, unless I miss something. I still wish NodeList::End could be effectively inlined so that we would be speeding up not only global routing but other code using NodeList as well. Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From guillaume.seguin at ens.fr Wed Aug 19 07:23:41 2009 From: guillaume.seguin at ens.fr (Guillaume Seguin) Date: Wed, 19 Aug 2009 16:23:41 +0200 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: References: <20090819122000.GC15935@clipper.ens.fr> <20090819135509.GD15935@clipper.ens.fr> Message-ID: <20090819142341.GE15935@clipper.ens.fr> On 19 ao?t 2009 ? 15:13:52 (+0100), Gustavo Carneiro wrote : > 2009/8/19 Guillaume Seguin > > > On 19 ao?t 2009 ? 14:38:47 (+0100), Gustavo Carneiro wrote : > > > So you speed up 15% of global routing, which is, what, 1% of the > > simulation > > > time? Hardly seems worth it, IMHO (unless global routing is called > > > repeatedly during a simulation). > > > > > > > It all depends on the length of the subsequent simulation. On the example > > I'm > > working on, on current ns-3-dev, the routing table init phase takes 11 > > seconds > > and the simulation phase takes 11 seconds. So I'm speeding up 15% of 50% of > > the > > script runtime. Seems worth it, IMHO. > > > OK, I guess. > > I have been running simulations that take over an hour each to complete, so > 11 seconds is not noticeable in my case, but I now understand better your > concern. > Yeah I definitely understand, it's just a matter of scale. > > > > > > > > And have you compared with the far cleaner solution of making > > > NodeList::Begin() and NodeList::End() inline functions (unless with the > > > NodeList/NodeListPriv split it may not have the desired speedup)? > > > > > > > As far as I understand the gain, it was because the end node kept getting > > it's > > reference count to 0, thus running a MaybeDelete (even though the node > > wasn't > > getting freed in the end). Storing the end node outside of the loop has the > > nice > > effect of keeping the reference count at least at 1 during the whole > > iteration, > > avoiding the collection attempt. So this is *not* about avoiding a bunch of > > function calls. > > > What do you mean by "end node"? NodeList::End() should return an > std::vector >::iterator which points beyond the end of the > vector. You cannot dereference this iterator or the pointer contained > inside or else you read garbage. > > I don't think the listEnd variable in your patch causes any Node reference > count to increase, unless I miss something. > Hmm yeah this sounds right. After checking the code again, most likely those Unrefs were coming from the NodeListPriv object, which is ref'd and unref'd in NodeList::End () I believe. > I still wish NodeList::End could be effectively inlined so that we would be > speeding up not only global routing but other code using NodeList as well. > Yeah, this might be a worthy gain, though the trip through the singleton getter might be expensive part. Regards, Guillaume From mathieu.lacage at sophia.inria.fr Wed Aug 19 11:20:23 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 19 Aug 2009 20:20:23 +0200 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: <20090819142341.GE15935@clipper.ens.fr> References: <20090819122000.GC15935@clipper.ens.fr> <20090819135509.GD15935@clipper.ens.fr> <20090819142341.GE15935@clipper.ens.fr> Message-ID: <1250706023.2635.5.camel@localhost.localdomain> On Wed, 2009-08-19 at 16:23 +0200, Guillaume Seguin wrote: > > I don't think the listEnd variable in your patch causes any Node reference > > count to increase, unless I miss something. > > > > > Hmm yeah this sounds right. After checking the code again, most likely those > Unrefs were coming from the NodeListPriv object, which is ref'd and unref'd in > NodeList::End () I believe. ha, good catch: that is the root of the problem most likely. > > I still wish NodeList::End could be effectively inlined so that we would be > > speeding up not only global routing but other code using NodeList as well. > > > > Yeah, this might be a worthy gain, though the trip through the singleton getter > might be expensive part. I guess you could do something along the lines of: - make End inline - mark singleton get functions inline - make get function return a const & Ptr or a raw pointer (I did not look at the code to check if this makes sense at all) Mathieu From flaviokubota at gmail.com Wed Aug 19 12:13:24 2009 From: flaviokubota at gmail.com (Flavio Kubota) Date: Wed, 19 Aug 2009 16:13:24 -0300 Subject: [Ns-developers] WiMAX takes too long to run Message-ID: Hi all, After include virtual functions for schedulers, I notice my simulations is taking too long to finish. Is this happening to someone else? -- Flavio Kubota MSc Computer Science Student IC / UNICAMP From faker.moatamri at sophia.inria.fr Thu Aug 20 00:11:08 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 20 Aug 2009 09:11:08 +0200 Subject: [Ns-developers] Bug fixes freeze Message-ID: <4A8CF70C.9000407@sophia.inria.fr> Hi all, As of today, Thursday August 20th, we will freeze the bug fixing and feature merging. We were able to merge two new additions to the wimax module in the last few days which are available in http://code.nsnam.org/iamine/ns-3-wimax-to_be_released/: - Uplink/Downlink scheduler - Enhanced propagation model For the bugs, we used to have those bugs: - 577 : Simulation stops with assert failed. file=../src/devices/wimax/simpleOfdmWimaxPhy.cc, line=436, cond="bufferCopy == buffer" - 576 : A core dump happens when the simulation is about to finish - 575 : some of the TLVs carrying wimax PDUs are not correctly decoded by wireshark - 662 : the GetRequestedBandwidth() function doesn't return the correct value of BandwidthRequested Bugs 577 and 576 which are considered to be critical are solved. The other two bugs are not critical and we think that we can merge the code despite these bugs. In the next few days all the development and debugging will be frozen and we will enhance the Wimax code to meet ns-3-dev standard based on the following code review. http://codereview.appspot.com/75057/show. We remind you that the time schedule for wimax integration is the following: -Wednesday August 26th: Merge with the latest version of ns-3-dev and testing -Tuesday September 1st: Submission of the proposed Wimax patch for review Best regards Faker Moatamri From nbaldo at cttc.es Thu Aug 20 03:36:53 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 20 Aug 2009 12:36:53 +0200 Subject: [Ns-developers] path names to be used for Config::Connect [was: athstats in ns3] In-Reply-To: <1247465013.3324.7.camel@diese.inria.fr> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> Message-ID: <4A8D2745.5050007@cttc.es> Hi, Mathieu Lacage wrote: > > On Fri, 2009-07-10 at 16:56 +0200, Nicola Baldo wrote: >> >> 1) a new set of traces that I added to WifiMac in order to notify when a >> RTS or DATA frames is to be retransmitted as well as when a frame is >> dropped due to exceeded retry limit: >> http://codereview.appspot.com/91098> > > All the information you need is already present in the > WifiRemoteStationManager so, there should be no need to duplicate this > information at the MAC layer itself. To minimize impact in the MAC layer > itself, all you have to do is to: > > a) make all the WifiRemoteStation::Report* methods call corresponding > notify methods in the WifiRemoteStationManager before calling the > DoReport* methods. > > b) implement the Notify methods in WifiRemoteStationManager like you did > in wifi-mac.cc > > c) profit ! > > > The API below looks good to me. > >> 2) the implementation of AthstatsWifiTraceSink and its associated helper: >> http://codereview.appspot.com/88151 > I did point a) and b) above, so that now it is WifiRemoteStationManager who exports the new trace sources. However, I am stuck with the problem of how to connect AthstatsWifiTraceSink to the new trace sources. I tried the following paths: /NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager/MacTxDataFailed /NodeList/0/DeviceList/0/ns3::WifiRemoteStationManager/MacTxDataFailed /NodeList/2/DeviceList/0/MacTxDataFailed /NodeList/2/DeviceList/0/Mac/MacTxDataFailed /NodeList/0/DeviceList/0/Mac/$ns3::WifiRemoteStationManager/ but none of them worked in the end (some gave an explicit error when using NS_LOG="Config=level_all", and some not, but still without making the trace connection work). Then I have been looking for the exact specification of the path to be used with Config::Connect, but I couldn't find it in the documentation. The list of trace sources here http://www.nsnam.org/doxygen/group___trace_source_list.html only mentions the object they belong to, but there is no hint on the actual path to be used. Looking for emails on the topic, the most valuable information I found is this email by Craig on ns3-users: http://groups.google.com/group/ns-3-users/browse_thread/thread/c162f5a8d13fe9d1/67b21278f7abf925?lnk=gst&q=config#67b21278f7abf925 but still even with this information I was not able to find a solution to my problem. Then I was also wondering whether this is an object aggregation issue, but I found rather scarce documentation on how aggregation is done and what exactly is aggregated to what. Then I have also been wondering whether the reason that the callback doesn't work is that I am trying to define a callback without parameters: TracedCallback< > m_macTxDataFailed; but I really have no idea if this can work (I am not very confident with templates, and from the ns3 documentation I could not tell whether this usage is supported or not). Given these many questions with poor answer from the documetation, I thought the best thing was to ask the list first... any help would be very much appreciated! Regards, Nicola From mathieu.lacage at sophia.inria.fr Thu Aug 20 06:11:14 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 20 Aug 2009 15:11:14 +0200 Subject: [Ns-developers] path names to be used for Config::Connect [was: athstats in ns3] In-Reply-To: <4A8D2745.5050007@cttc.es> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> Message-ID: <1250773874.4616.11.camel@localhost.localdomain> On Thu, 2009-08-20 at 12:36 +0200, Nicola Baldo wrote: [snip] > > a) make all the WifiRemoteStation::Report* methods call corresponding > > notify methods in the WifiRemoteStationManager before calling the > > DoReport* methods. > > > > b) implement the Notify methods in WifiRemoteStationManager like you did > > in wifi-mac.cc [snip] > I did point a) and b) above, so that now it is WifiRemoteStationManager > who exports the new trace sources. > > However, I am stuck with the problem of how to connect > AthstatsWifiTraceSink to the new trace sources. I tried the following paths: > > /NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager/MacTxDataFailed > /NodeList/0/DeviceList/0/ns3::WifiRemoteStationManager/MacTxDataFailed > /NodeList/2/DeviceList/0/MacTxDataFailed > /NodeList/2/DeviceList/0/Mac/MacTxDataFailed > /NodeList/0/DeviceList/0/Mac/$ns3::WifiRemoteStationManager/ > > but none of them worked in the end (some gave an explicit error when > using NS_LOG="Config=level_all", and some not, but still without making > the trace connection work). [snip] I can hear you screaming :) I believe that the right path will be: /NodeList/0/DeviceList/0/RemoteStationManager/MacTxDataFailed Why is that ? Because: 1) $-prefixed items in a path are used to perform an aggregation lookup: /NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager is getting device 0 in node 0, and, then, doing GetObject on it but it gets null because the remote station manager is not aggregated to the device. 2) non-$ prefixed non-terminating items in a path are used to perform an attribute lookup on an attribute of type Pointer: /NodeList/0/DeviceList/0/RemoteStationManager is is getting device 0 in node 0, and, then, doing: PointerValue ptr; dev->GetAttribute ("RemoteStationManager", ptr); A nice way to figure out a path is to use the ConfigStore: if you use it to dump all attributes in a text file, you can see a valid path for each attribute (this, arguably, does not work for trace sources). Mathieu From amine.ismail at sophia.inria.fr Thu Aug 20 06:52:38 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Thu, 20 Aug 2009 15:52:38 +0200 Subject: [Ns-developers] Review In-Reply-To: <49479.217.128.71.243.1250730073.squirrel@imap-sop.inria.fr> References: <4A8BC0D4.7080005@sophia.inria.fr> <4365bdc50908190217x3b957adfm47a4a6fcac88496d@mail.gmail.com> <4A8BD4A6.1090609@sophia.inria.fr> <49479.217.128.71.243.1250730073.squirrel@imap-sop.inria.fr> Message-ID: <4A8D5526.8070704@sophia.inria.fr> > Amine, can you please apply the patch and run tests if needed? Done, Tests are OK Amine Faker.Moatamri at sophia.inria.fr wrote: >> Hi all, >> >> I'm sorry for delay. I've found a bug and it takes some time to fix it. I >> didn't refactor some functions as Faker asked. I'm already late, so I >> decide >> to send what I have already done. After refactor I'll need to run some >> test >> to check if everything is working fine and I'll do it later. >> Giuseppe also sent me a patch and it is already included on my patch. >> This patch is based on >> http://code.nsnam.org/iamine/ns-3-wimax-to_be_released/. >> >> -- >> Flavio >> > ok I think that's the way to go, we can refactor the code after the merge, > for now we don't have enough time. > Amine, can you please apply the patch and run tests if needed? > Thanks > Best regards > Faker Moatamri > From faker.moatamri at sophia.inria.fr Thu Aug 20 08:55:47 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 20 Aug 2009 17:55:47 +0200 Subject: [Ns-developers] Review In-Reply-To: <4A8D5526.8070704@sophia.inria.fr> References: <4A8BC0D4.7080005@sophia.inria.fr> <4365bdc50908190217x3b957adfm47a4a6fcac88496d@mail.gmail.com> <4A8BD4A6.1090609@sophia.inria.fr> <49479.217.128.71.243.1250730073.squirrel@imap-sop.inria.fr> <4A8D5526.8070704@sophia.inria.fr> Message-ID: <4A8D7203.80408@sophia.inria.fr> Hello Amine, I merged my patch to rename the files of wimax with the changes added by Flavio and Giuseppe to produce an up todate patch. Please apply/test this patch and if everything is ok push it to repository. Thanks Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: renameFiles.patch Type: text/x-patch Size: 526344 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090820/f5749fae/renameFiles-0001.bin From nbaldo at cttc.es Thu Aug 20 10:44:53 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 20 Aug 2009 19:44:53 +0200 Subject: [Ns-developers] path names to be used for Config::Connect In-Reply-To: <1250773874.4616.11.camel@localhost.localdomain> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> Message-ID: <4A8D8B95.1040705@cttc.es> Hi, Mathieu Lacage wrote: > > I can hear you screaming :) > > I believe that the right path will be: > > /NodeList/0/DeviceList/0/RemoteStationManager/MacTxDataFailed > > Why is that ? > > Because: > > 1) $-prefixed items in a path are used to perform an aggregation lookup: > /NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager is getting > device 0 in node 0, and, then, doing GetObject > on it but it gets null because the remote station manager is not > aggregated to the device. > > 2) non-$ prefixed non-terminating items in a path are used to perform an > attribute lookup on an attribute of type Pointer: > /NodeList/0/DeviceList/0/RemoteStationManager is is getting device 0 > in node 0, and, then, doing: > PointerValue ptr; > dev->GetAttribute ("RemoteStationManager", ptr); > > A nice way to figure out a path is to use the ConfigStore: if you use it > to dump all attributes in a text file, you can see a valid path for each > attribute (this, arguably, does not work for trace sources). > Thank you very much for your help, now I finally understood the thing and made it work. In the hope of reducing the number of people that will stumble on this issue in the future, I've come up with this wiki page: http://www.nsnam.org/wiki/index.php/HOWTO_determine_the_path_of_an_attribute_or_trace_source Finally, I wonder whether there is any special reason for maintaining these two different methods for accessing objects through a path, i.e., object aggregation and pointer-to-object attributes. The fact that some objects need to be accessed with one method and some other objects with the other method is rather confusing, IMHO. Nicola From nbaldo at cttc.es Thu Aug 20 10:54:19 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 20 Aug 2009 19:54:19 +0200 Subject: [Ns-developers] added AthstatsWifiTraceSink and associated helper In-Reply-To: <0016368e1c2fc21d70046ed28ba5@google.com> References: <0016368e1c2fc21d70046ed28ba5@google.com> Message-ID: <4A8D8DCB.8080806@cttc.es> tomh.org at gmail.com wrote: > I reviewed this today and think it will be a nice addition. +1 for > merging this > feature after Mathieu's implementation comments and Pavel's doxygen > comments are > resolved. Revised version of athstats here: http://codereview.appspot.com/110054 Both Mathieu's and Pavel's comments have been addressed. Awaiting for feedback... Regards, Nicola From craigdo at ee.washington.edu Thu Aug 20 10:54:09 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 20 Aug 2009 10:54:09 -0700 Subject: [Ns-developers] path names to be used for Config::Connect [was: athstats in ns3] In-Reply-To: <1250773874.4616.11.camel@localhost.localdomain> References: <4A575697.7000306@cttc.es><1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> Message-ID: <2CE2FF65B8C64EC28770D878952F2C5F@CRAIGVAIO> [ ... ] > > [snip] > > I can hear you screaming :) In config space, nobody can hear you scream :-) I think we might be able to help people figure out what is going on if we introduce some log messages designed for that purpose. Right now, the log messages are nice for people who already know what is happening and where the messages are generated, but they are pretty cryptic. Perhaps if we added LOG_LEVEL_INFO messages that printed (only) "/NodeList" okay "/NodeList/0" okay "/NodeList/0/DeviceList" okay "/NodeList/0/DeviceList/0" okay "/NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager/MacTxDataFailed": the "ns3::WifiNetDevice" at "/NodeList/0/DeviceList/0" does not have an object of type "$ns3::WifiRemoteStationManager" aggregated. Or, "/NodeList" okay "/NodeList/0" okay "/NodeList/0/DeviceList" okay "/NodeList/0/DeviceList/0" okay "/NodeList/0/DeviceList/0/ns3::WifiRemoteStationManager/MacTxDataFailed": the "ns3::WifiNetDevice" at "/NodeList/0/DeviceList/0" does not have an Attribute of name "ns3::WifiRemoteStationManager" defined. Or, "/NodeList" okay "/NodeList/2" okay "/NodeList/2/DeviceList" okay "/NodeList/2/DeviceList/0" okay "/NodeList/2/DeviceList/0/MacTxDataFailed": the "ns3::WifiNetDevice" at "/NodeList/2/DeviceList/0" does not have an Attribute of name "MacTxDataFailed" defined. Or, "/NodeList" okay "/NodeList/2" okay "/NodeList/2/DeviceList" okay "/NodeList/2/DeviceList/0" okay "/NodeList/2/DeviceList/0/Mac/MacTxDataFailed": the "ns3::WifiMac" at "/NodeList/2/DeviceList/0/Mac" does not have an Attribute of name "MacTxDataFailed" defined. Or, "/NodeList" okay "/NodeList/2" okay "/NodeList/2/DeviceList" okay "/NodeList/2/DeviceList/0" okay "/NodeList/0/DeviceList/0/Mac/$ns3::WifiRemoteStationManager/MacTxDataFailed ": the "ns3::WifiMac" at "/NodeList/0/DeviceList/0/Mac" does not have an object of type "$ns3::WifiRemoteStationManager" aggregated. None of this will tell someone what path they need to use, but will at least much more clearly where their path went wrong, and hopefully make it easier to get it right. From mathieu.lacage at sophia.inria.fr Thu Aug 20 11:57:09 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 20 Aug 2009 20:57:09 +0200 Subject: [Ns-developers] path names to be used for Config::Connect In-Reply-To: <4A8D8B95.1040705@cttc.es> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> <4A8D8B95.1040705@cttc.es> Message-ID: <1250794629.2869.185.camel@localhost.localdomain> On Thu, 2009-08-20 at 19:44 +0200, Nicola Baldo wrote: [snip] > Finally, I wonder whether there is any special reason for maintaining > these two different methods for accessing objects through a path, i.e., > object aggregation and pointer-to-object attributes. The fact that > some objects need to be accessed with one method and some other objects > with the other method is rather confusing, IMHO. Hrm, I am not sure I understand what the question is. What different methods are you talking about ? Mathieu From mathieu.lacage at sophia.inria.fr Thu Aug 20 12:30:46 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 20 Aug 2009 21:30:46 +0200 Subject: [Ns-developers] added AthstatsWifiTraceSink and associated helper In-Reply-To: <4A8D8DCB.8080806@cttc.es> References: <0016368e1c2fc21d70046ed28ba5@google.com> <4A8D8DCB.8080806@cttc.es> Message-ID: <1250796646.2869.224.camel@localhost.localdomain> 1) I would tend to move the code of athstats-wifi-trace-sink.cc in athstats-helper.cc 2) can't you report in the trace sources something to indicate which remote station is triggering the event ? i.e., some kind of mac address ? On Thu, 2009-08-20 at 19:54 +0200, Nicola Baldo wrote: > tomh.org at gmail.com wrote: > > I reviewed this today and think it will be a nice addition. +1 for > > merging this > > feature after Mathieu's implementation comments and Pavel's doxygen > > comments are > > resolved. > > Revised version of athstats here: > http://codereview.appspot.com/110054 > > Both Mathieu's and Pavel's comments have been > addressed. Awaiting for feedback... > > Regards, > > Nicola From nbaldo at cttc.es Fri Aug 21 01:41:12 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 21 Aug 2009 10:41:12 +0200 Subject: [Ns-developers] path names to be used for Config::Connect [was: athstats in ns3] In-Reply-To: <2CE2FF65B8C64EC28770D878952F2C5F@CRAIGVAIO> References: <4A575697.7000306@cttc.es><1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> <2CE2FF65B8C64EC28770D878952F2C5F@CRAIGVAIO> Message-ID: <4A8E5DA8.8000509@cttc.es> Hi, craigdo at ee.washington.edu wrote: > I think we might be able to help people figure out what is going on if we > introduce some log messages designed for that purpose. Right now, the log > messages are nice for people who already know what is happening and where > the messages are generated, but they are pretty cryptic. > > Perhaps if we added LOG_LEVEL_INFO messages that printed (only) > > "/NodeList" okay > "/NodeList/0" okay > "/NodeList/0/DeviceList" okay > "/NodeList/0/DeviceList/0" okay > "/NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager/MacTxDataFailed": > the "ns3::WifiNetDevice" at "/NodeList/0/DeviceList/0" does not have an > object of type "$ns3::WifiRemoteStationManager" aggregated. > > Or, [similar cases snipped] > > None of this will tell someone what path they need to use, but will at least > much more clearly where their path went wrong, and hopefully make it easier > to get it right. > I definitely agree. Maybe using LOG_LEVEL_WARNING or LOG_LEVEL_ERROR to report the failure. Also it would be nice if Config::Connect() could report failure when no matching traces are found, e.g., by using a bool return value. Nicola From mathieu.lacage at sophia.inria.fr Fri Aug 21 01:50:05 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 21 Aug 2009 10:50:05 +0200 Subject: [Ns-developers] path names to be used for Config::Connect [was: athstats in ns3] In-Reply-To: <4A8E5DA8.8000509@cttc.es> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> <2CE2FF65B8C64EC28770D878952F2C5F@CRAIGVAIO> <4A8E5DA8.8000509@cttc.es> Message-ID: <1250844605.2925.101.camel@localhost.localdomain> On Fri, 2009-08-21 at 10:41 +0200, Nicola Baldo wrote: > > I think we might be able to help people figure out what is going on if we > > introduce some log messages designed for that purpose. Right now, the log > > messages are nice for people who already know what is happening and where > > the messages are generated, but they are pretty cryptic. > > > > Perhaps if we added LOG_LEVEL_INFO messages that printed (only) > > > > "/NodeList" okay > > "/NodeList/0" okay > > "/NodeList/0/DeviceList" okay > > "/NodeList/0/DeviceList/0" okay > > "/NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager/MacTxDataFailed": > > the "ns3::WifiNetDevice" at "/NodeList/0/DeviceList/0" does not have an > > object of type "$ns3::WifiRemoteStationManager" aggregated. > > > > Or, > [similar cases snipped] > > > > None of this will tell someone what path they need to use, but will at least > > much more clearly where their path went wrong, and hopefully make it easier > > to get it right. > > > > I definitely agree. Maybe using LOG_LEVEL_WARNING or LOG_LEVEL_ERROR to > report the failure. Also it would be nice if Config::Connect() could > report failure when no matching traces are found, e.g., by using a bool > return value. 1) You already have the equivalent of this bool return value in the MatchContainer class: I think that Config::Connect could be safely deprecated in favor of the MatchContainer object. 2) Then, you could extend the MatchContainer class to keep track of this failed-match information and provide a ::Print (std::ostream) method so that users can optionally dump the match information. Using the LOG mechanism to extract the information from the underlying code feels a bit kludgy. Mathieu From nbaldo at cttc.es Fri Aug 21 01:58:09 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 21 Aug 2009 10:58:09 +0200 Subject: [Ns-developers] path names to be used for Config::Connect In-Reply-To: <1250794629.2869.185.camel@localhost.localdomain> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> <4A8D8B95.1040705@cttc.es> <1250794629.2869.185.camel@localhost.localdomain> Message-ID: <4A8E61A1.5080103@cttc.es> Mathieu Lacage wrote: >> Finally, I wonder whether there is any special reason for maintaining >> these two different methods for accessing objects through a path, i.e., >> object aggregation and pointer-to-object attributes. The fact that >> some objects need to be accessed with one method and some other objects >> with the other method is rather confusing, IMHO. > > Hrm, I am not sure I understand what the question is. What different > methods are you talking about ? > The case being considered is when we have two objects A and B, we know that B has a 1-to-1 relationship with A, we have a path to A, and we want to retrieve B. What happens is that one of these methods might be supported, depending on which particular objects are involved: 1) A has an attribute which is a pointer to B 2) B is aggregated to A My considerations: a) for what I have seen, either 1) or 2) is supported, depending on the case, but never both; b) it is confusing that you cannot guess beforehand whether method 1) or 2) is to be used without examining the source code, or looking into ConfigStore output. Example: why isn't WifiRemoteStationManager aggregated with WifiNetDevice? why don't we always use object aggregation? Dual example: why don't we get rid of object aggregation, since every object can have attributes which point to all related objects? c) the way method 2) is currently used is that attributes have slightly different names than the object types they point to. This is not intuitive and always requires a lookup in the code/documentation/ConfigStore output. Example: WifiNetDevice is related to WifiRemoteStationManager. Say I know this relationship is implemented using a pointer-to-object attribute (e.g. because I tried method 1) and it failed). I would guess that the attribute name is WifiRemoteStationManager, but instead the attribute name is RemoteStationManager. Similar cases: WifiNetDevice's attributes Phy and Mac, which point to a WifiPhy and a WifiMac object, respectively. Just my two eurocents, Nicola From mathieu.lacage at sophia.inria.fr Fri Aug 21 02:44:11 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 21 Aug 2009 11:44:11 +0200 Subject: [Ns-developers] path names to be used for Config::Connect In-Reply-To: <4A8E61A1.5080103@cttc.es> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> <4A8D8B95.1040705@cttc.es> <1250794629.2869.185.camel@localhost.localdomain> <4A8E61A1.5080103@cttc.es> Message-ID: <1250847851.2925.148.camel@localhost.localdomain> On Fri, 2009-08-21 at 10:58 +0200, Nicola Baldo wrote: > The case being considered is when we have two objects A and B, we know > that B has a 1-to-1 relationship with A, we have a path to A, and we > want to retrieve B. > > What happens is that one of these methods might be supported, depending > on which particular objects are involved: > > 1) A has an attribute which is a pointer to B > 2) B is aggregated to A > > > My considerations: > > > a) for what I have seen, either 1) or 2) is supported, depending on the > case, but never both; Actually, sometimes, we do support both [reasons elided]. > b) it is confusing that you cannot guess beforehand whether method 1) or > 2) is to be used without examining the source code, or looking into > ConfigStore output. Ok, so, the problem is not the configuration path format. You are complaining about the way we use aggregation and attributes :) > Example: why isn't WifiRemoteStationManager aggregated with > WifiNetDevice? why don't we always use object aggregation? Object aggregation was designed with a specific goal in mind: avoid the need for a MobileNode class. i.e., We have a MobilityModel, we have a Node, none of them know about each other but we construct the equivalent of a MobileNode by aggregating them. This allows us to make the MobilityModel independent from a Node and to reuse that code independently. In that case, it is not possible to have a StationManager without a WifiNetDevice, and vice-versa. So, aggregation is not needed because both objects need each other: we can use a simpler attribute. > Dual example: why don't we get rid of object aggregation, since every > object can have attributes which point to all related objects? Aggregation allows only one instance of a type to be aggregated to another object. What if you want two instances of the same type to be aggregated together ? It can't work. > c) the way method 2) is currently used is that attributes have slightly > different names than the object types they point to. This is not > intuitive and always requires a lookup in the > code/documentation/ConfigStore output. I guess that we could try to name attributes according to the name of their underlying type but what happens when you have two attributes of the same type in the same object ? I don't see any good solution beyond asking you to lookup the doxygen or the code. > Example: WifiNetDevice is related to WifiRemoteStationManager. Say I > know this relationship is implemented using a pointer-to-object > attribute (e.g. because I tried method 1) and it failed). I would guess > that the attribute name is WifiRemoteStationManager, but instead the > attribute name is RemoteStationManager. Similar cases: WifiNetDevice's > attributes Phy and Mac, which point to a WifiPhy and a WifiMac object, > respectively. See above for why this would not work in general. To summarize, I understand your concerns but it's not clear to me that we can really do much better: using aggregation all the time is neither desirable (calling GetObject<> is costly) not feasible. Using attributes all the time is not desirable (Node would need an explicit pointer to MobilityModel). There is quite a bit of complexity and pain there but it's not obvious to me how this can be made much simpler and keep the features we need. Mathieu From mathieu.lacage at sophia.inria.fr Fri Aug 21 02:52:03 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 21 Aug 2009 11:52:03 +0200 Subject: [Ns-developers] exporting more headers from src/internet-stack Message-ID: <1250848323.2925.158.camel@localhost.localdomain> hi, I needed to get the protocol headers from src/internet-stack but I did not want to export all headers, so, I ended-up doing some more serious cleaning-up. Comments about this ? Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: ip.patch Type: text/x-patch Size: 12820 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090821/14bdd34d/ip-0001.bin From boyko at iitp.ru Fri Aug 21 03:37:38 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Fri, 21 Aug 2009 14:37:38 +0400 Subject: [Ns-developers] exporting more headers from src/internet-stack In-Reply-To: <1250848323.2925.158.camel@localhost.localdomain> References: <1250848323.2925.158.camel@localhost.localdomain> Message-ID: <200908211437.39008.boyko@iitp.ru> On Friday 21 August 2009 01:52:03 pm Mathieu Lacage wrote: > hi, > > I needed to get the protocol headers from src/internet-stack but I did > not want to export all headers, so, I ended-up doing some more serious > cleaning-up. Comments about this ? I also need arp-cache.h to be exported for AODV layer 2 feedback and sgi- hashmap.h follows (m.b. it should be moved to common?). Pavel From nbaldo at cttc.es Fri Aug 21 03:32:22 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 21 Aug 2009 12:32:22 +0200 Subject: [Ns-developers] added AthstatsWifiTraceSink and associated helper In-Reply-To: <1250796646.2869.224.camel@localhost.localdomain> References: <0016368e1c2fc21d70046ed28ba5@google.com> <4A8D8DCB.8080806@cttc.es> <1250796646.2869.224.camel@localhost.localdomain> Message-ID: <4A8E77B6.9060800@cttc.es> Hi, Mathieu Lacage wrote: > 1) I would tend to move the code of athstats-wifi-trace-sink.cc in > athstats-helper.cc So what should I do? 1) dump athstats-wifi-trace-sink.* into athstats-helper.*, and so remove athstats-wifi-trace-sink.* 2) move athstats-wifi-trace-sink.* from src/devices/wifi to somewhere else (where?) 3) leave athstats-wifi-trace-sink.* where it is, but move some of the functionality (what exactly?) from AthstatsWifiTraceSink to AthstatsHelper > > 2) can't you report in the trace sources something to indicate which > remote station is triggering the event ? i.e., some kind of mac > address ? > Good point. The only issue is that currently this information is not available, since all the methods WifiRemoteStation::ReportXxxFailed() have no parameters, and WifiRemoteStation has no knowledge of the remote STA address. What if I add a Mac48Address member variable to WifiRemoteStation, which is set to the right value within WifiRemoteStationManager::Lookup() right after the call to CreateStation() ? Nicola From mathieu.lacage at sophia.inria.fr Fri Aug 21 03:34:28 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 21 Aug 2009 12:34:28 +0200 Subject: [Ns-developers] exporting more headers from src/internet-stack In-Reply-To: <200908211437.39008.boyko@iitp.ru> References: <1250848323.2925.158.camel@localhost.localdomain> <200908211437.39008.boyko@iitp.ru> Message-ID: <1250850868.2925.172.camel@localhost.localdomain> On Fri, 2009-08-21 at 14:37 +0400, Pavel Boyko wrote: > > I needed to get the protocol headers from src/internet-stack but I did > > not want to export all headers, so, I ended-up doing some more serious > > cleaning-up. Comments about this ? > > I also need arp-cache.h to be exported for AODV layer 2 feedback and sgi- I see that the only header it requires is sgi-hashmap.h so, it should be trivial to add to wscript. > hashmap.h follows (m.b. it should be moved to common?). Yes, we can do this: anyone against this ? Mathieu From mathieu.lacage at sophia.inria.fr Fri Aug 21 03:38:05 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 21 Aug 2009 12:38:05 +0200 Subject: [Ns-developers] added AthstatsWifiTraceSink and associated helper In-Reply-To: <4A8E77B6.9060800@cttc.es> References: <0016368e1c2fc21d70046ed28ba5@google.com> <4A8D8DCB.8080806@cttc.es> <1250796646.2869.224.camel@localhost.localdomain> <4A8E77B6.9060800@cttc.es> Message-ID: <1250851085.2925.176.camel@localhost.localdomain> On Fri, 2009-08-21 at 12:32 +0200, Nicola Baldo wrote: > > 1) I would tend to move the code of athstats-wifi-trace-sink.cc in > > athstats-helper.cc > > So what should I do? > > 1) dump athstats-wifi-trace-sink.* into athstats-helper.*, and so remove > athstats-wifi-trace-sink.* I would go for 1). > > > > 2) can't you report in the trace sources something to indicate which > > remote station is triggering the event ? i.e., some kind of mac > > address ? > > > > Good point. The only issue is that currently this information is not > available, since all the methods WifiRemoteStation::ReportXxxFailed() > have no parameters, and WifiRemoteStation has no knowledge of the remote > STA address. > > What if I add a Mac48Address member variable to WifiRemoteStation, which > is set to the right value within WifiRemoteStationManager::Lookup() > right after the call to CreateStation() ? yes, and you can remove the address in the manager in std::vector > so you get a vector of pointers instead of a vector of pairs. Mathieu From amine.ismail at sophia.inria.fr Fri Aug 21 07:07:31 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Fri, 21 Aug 2009 16:07:31 +0200 Subject: [Ns-developers] Wimax bugs update? In-Reply-To: <4365bdc50908190648v588954cdh66d7a81f55753820@mail.gmail.com> References: <4A8BF711.50701@sophia.inria.fr> <4A8BF90A.2030803@sophia.inria.fr> <4365bdc50908190648v588954cdh66d7a81f55753820@mail.gmail.com> Message-ID: <4A8EAA23.5070600@sophia.inria.fr> Hi Flavio and Giuseppe, To merge the code with the main version of ns-3 we should provide a test plan including at least some regression tests. These regression tests will be used to check that the module works as expected after performing some changes or adding some features. So can you write some procedures (text or code) explaining how to test your schedulers? The best way is to develop an example which outputs "TEST OK" or "TEST FAILED" for each feature you have developed and you think it is interesting to test it. Have a nice WE Best regards Amine Giuseppe Piro wrote: > Dear all, > > I would to remark the presence of another bug: > http://www.nsnam.org/bugzilla/show_bug.cgi?id=662 > > Regards, > Giuseppe > > > 2009/8/19 Ismail Amine > > > Hi Faker, > > Bug 577 and 576 have been fixed, I will update bugzilla and close > these PRs. > > > > Faker Moatamri wrote: > > Hi all, > In the bug tracker, we have three bugs in wimax: > - 577 : > Simulation stops with assert failed. > file=../src/devices/wimax/simpleOfdmWimaxPhy.cc, line=436, > cond="bufferCopy == buffer" > - 576 : A > core dump happens when the simulation is about to finish > - 575 : > some of the TLVs carrying wimax PDUs are not correctly decoded > by wireshark > Bug 577 and 576 are critical in the sense that the examples > my-wimax-example and wimax-example doesn't finish their jobs. > Is there any updates on these bugs? > The third bug doesn't seem te me so critical. At the end the > most important is to have working examples. > Thanks > Best regards > Faker Moatamri > > > > > > > -- > Giuseppe Piro > Ph.D. Student > DEE - Politecnico di Bari > v. Orabona 4, 70125 - Bari, Italy > e-mail: g.piro at poliba.it > peppe.piro at gmail.com > Phone: +39 0805963301 > Web: http://telematics.poliba.it/piro From craigdo at ee.washington.edu Fri Aug 21 11:06:01 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 21 Aug 2009 11:06:01 -0700 Subject: [Ns-developers] path names to be used for Config::Connect [was: athstats in ns3] In-Reply-To: <1250844605.2925.101.camel@localhost.localdomain> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> <2CE2FF65B8C64EC28770D878952F2C5F@CRAIGVAIO> <4A8E5DA8.8000509@cttc.es> <1250844605.2925.101.camel@localhost.localdomain> Message-ID: <48C0704D5A5D49BC9433A2EA49BD0DBF@CRAIGVAIO> > > I definitely agree. Maybe using LOG_LEVEL_WARNING or > LOG_LEVEL_ERROR to > > report the failure. Also it would be nice if > Config::Connect() could > > report failure when no matching traces are found, e.g., by > using a bool > > return value. > > 1) You already have the equivalent of this bool return value in the > MatchContainer class: I think that Config::Connect could be safely > deprecated in favor of the MatchContainer object. > > 2) Then, you could extend the MatchContainer class to keep > track of this > failed-match information and provide a ::Print (std::ostream) > method so > that users can optionally dump the match information. It's a very common request to return some kind of result. Part of the problem is that when one does a Config::Connect no indication is given as to what actually happened. I think it would be useful to return the number of matches found in a Config::Connect. It's another data point in the battle to write correct code. Why not return it? You want to put what are essentially debug log messages in a match container? Wouldn't that require turning a match container into a search tree container with possibly error messages at each leaf? Print would then have to walk the tree and re-print what the resolver already did? Wouldn't this mean having to walk the tree somehow to find good matches and differentiate them from the "errors"? I like the option of returning a match container that is basically a set of matching paths. This is easy to understand and use. Making it more complicated seems counter-productive here. > Using the LOG mechanism to extract the information from the underlying > code feels a bit kludgy. I'm not sure what you mean by "extract the information from the underlying code"; but the whole purpose of NS_LOG is to easily display what is happening when the underlying code executes. It easy to turn on a log component and read a message describing how your path went wrong. This is one of the first things new ns-3 users learn how to do. It is obviously not easy for many/most new users to understand how this path matching process works. It is obviously not easy for most users to step through Config, ArrayMatcher, Resolver, and MatchContainer to find out where a config path went wrong. I am suggesting that we change NS_LOG messages to make it easier to relate the messages printed to the higher level process. I'm at a loss to understand how you could think that making log messages clearer and arguably much more useful feels "kludgy." I think the combination of returning a count of matched paths or a match container, plus more directed log messages could go a long way toward making it easier to figure out why config paths aren't working. I think we still have a documentation hurdle we need to get over to explain to people how to figure out what text to type into a path. I think we need an entire tutorial section dedicated to this subject. Once you grok what is happening, it is easy; but getting to the point where you can just type in a working config path is obviously a bigger step than we thought -- Craig From mathieu.lacage at sophia.inria.fr Fri Aug 21 12:00:47 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 21 Aug 2009 21:00:47 +0200 Subject: [Ns-developers] path names to be used for Config::Connect [was: athstats in ns3] In-Reply-To: <48C0704D5A5D49BC9433A2EA49BD0DBF@CRAIGVAIO> References: <4A575697.7000306@cttc.es> <1247465013.3324.7.camel@diese.inria.fr> <4A8D2745.5050007@cttc.es> <1250773874.4616.11.camel@localhost.localdomain> <2CE2FF65B8C64EC28770D878952F2C5F@CRAIGVAIO> <4A8E5DA8.8000509@cttc.es> <1250844605.2925.101.camel@localhost.localdomain> <48C0704D5A5D49BC9433A2EA49BD0DBF@CRAIGVAIO> Message-ID: <1250881247.2544.18.camel@localhost.localdomain> On Fri, 2009-08-21 at 11:06 -0700, craigdo at ee.washington.edu wrote: > > 1) You already have the equivalent of this bool return value in the > > MatchContainer class: I think that Config::Connect could be safely > > deprecated in favor of the MatchContainer object. > > > > 2) Then, you could extend the MatchContainer class to keep > > track of this > > failed-match information and provide a ::Print (std::ostream) > > method so > > that users can optionally dump the match information. > > It's a very common request to return some kind of result. Part of the > problem is that when one does a Config::Connect no indication is given as to > what actually happened. I think it would be useful to return the number of > matches found in a Config::Connect. It's another data point in the battle > to write correct code. Why not return it? I am not arguing against returning more information: if you really want more information, you could make it return the MatchContainer it uses internally. But I think that these functions should be deprecated in favor of using the MatchContainer itself because they just duplicate the functionality and they do so badly. So, really, I would rather kill them. > You want to put what are essentially debug log messages in a match > container? Wouldn't that require turning a match container into a search > tree container with possibly error messages at each leaf? Print would then > have to walk the tree and re-print what the resolver already did? Wouldn't > this mean having to walk the tree somehow to find good matches and > differentiate them from the "errors"? Yes, maybe the memory cost would be unacceptable. Maybe the LookupMatches function should be extended to take an extra argument (or overloaded): MatchContainer LookupMatches (std::string path, MatchLogger &logger); class MatchLogger { private: class friend MatchContainer; virtual void ReportPathMatch (std::string path); virtual void ReportPathFail (...); ... other }; with a: class StreamMatchLogger : public MatchLogger { public: StreamMatchLogger (std::ostream &os); private ... }; and that would allow us to provide more structured reports about a match lookup. > I like the option of returning a match container that is basically a set of > matching paths. This is easy to understand and use. Making it more > complicated seems counter-productive here. > > > Using the LOG mechanism to extract the information from the underlying > > code feels a bit kludgy. > > I'm not sure what you mean by "extract the information from the underlying > code"; but the whole purpose of NS_LOG is to easily display what is > happening when the underlying code executes. It easy to turn on a log > component and read a message describing how your path went wrong. This is > one of the first things new ns-3 users learn how to do. > > It is obviously not easy for many/most new users to understand how this path > matching process works. It is obviously not easy for most users to step > through Config, ArrayMatcher, Resolver, and MatchContainer to find out where > a config path went wrong. I am suggesting that we change NS_LOG messages to > make it easier to relate the messages printed to the higher level process. > I'm at a loss to understand how you could think that making log messages > clearer and arguably much more useful feels "kludgy." Making log messages clearer and more useful is good but exporting the matching information in a way which does not require logging would be even better. Mathieu From craigdo at ee.washington.edu Fri Aug 21 17:23:42 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 21 Aug 2009 17:23:42 -0700 Subject: [Ns-developers] Testing Framework -- Status and Sneak Peek [long] Message-ID: I've put together a repository with the current testing framework and demo code in it. To try it out: hg clone http://code.nsnam.org/ns-3-allinone ns-3-allinone-testing cd ns-3-allinone-testing ./download.py --ns3-branch=craigdo/ns-3-testing ./build.py cd ns-3-testing ./waf --check ./waf --regression ./test.py The existing tests are all still there unchanged -- i.e., "./waf check" still works as does "./waf --regression". The new tests are run from "./test.py" in the top level directory. Test.py produces output similar to the current unit test run out of waf (./waf check) but does not live inside waf. As previously discussed, there are reasons to run the tests out of waf, but also reasons to avoid waf. In my opinion, the waf negatives outweigh the positives. In addition to just printing PASS/FAIL/SKIP status messages, test.py also produces a test-results.xml file that is translated to a test-results.txt file which provides more details about what has happened and will provide much more information in the presence of an error. It also produces a test-results.html file that formats that information for a web page. The translations are just a simple demo showing what can be done and how easy it is. As mentioned before, we want there to be one framework suitable for all of the tests we do. As previously discussed, the new tests will eventually replace the functionality of "./waf check" but equivalent tests will be runnable using ./waf check. This means translating the old-style test cases to the new TestSuite/TestCase structure. This is easy to do, but I haven't spent the time to go through all dozen or so unit tests. There are no trace-based regression tests in the new test framework. All of the examples which used to be run and their pcap output checked are now just run to make sure they execute without error. This is a primary goal of the project. We will need to change all of the regression tests to work in the new environment without the megabytes of trace files required now. There are still several major issues to consider and deal with, but I wanted to create some more real examples of what tests look like and preview them. I would also like to open up some of the big issues for discussion before going any further. Test.py has started to get ugly over time and needs some love, but I've fleshed it all out quite a bit since it was last looked at. There are some known and lingering issues that still need resolving, but I think it's time for another public look-see. There are four broad kinds of tests we are considering: -- Build Verification Tests -- Unit Tests -- System Tests -- Examples Build Verification Tests These are relatively simple tests that are built along with the distribution and are used to make sure that the build is pretty much working. Our current unit tests live in the source files of the code they test and are built into the ns-3 modules; and so fit the description of BVTs. BVTs live in the same source code that is built into the ns-3 code. Our current tests are examples of this kind of test. Unit Tests Unit tests are more involved tests that go into detail to make sure that a piece of code works as advertized in isolation. There is really no reason for this kind of test to be built into an ns-3 module. It turns out, for example, that the unit tests for the object name service are about the same size as the object name service code itself. Unit tests are tests that check a single bit of functionality that are not built into the ns-3 code, but live in the same directory as the code it tests. It is possible that these tests check integration of multiple implementation files in a module as well. The file src/core/names-test-suite.cc is an example of this kind of test. The file src/common/pcap-file-test-suite.cc is another example that uses a known good pcap file as a test vector file. This file is stored locally in the src/common directory. System Tests System tests are those that involve more than one module in the system. We have lots of this kind of test running in our current regression framework, but they are overloaded examples. We provide a new place for this kind of test in the directory "src/tests". The file src/test/ns3tcp/ns3-interop-test-suite.cc is an example of this kind of test. It uses NSC TCP to test the ns-3 TCP implementation. Often there will be test vectors required for this kind of test, and they are stored in the directory where the test lives. For example, ns3tcp-interop-response-vectors.pcap is a file consisting of a number of TCP headers that are used as the expected responses of the ns-3 TCP under test to a stimulus generated by the NSC TCP which is used as a "known good" implementation. Examples The examples are tested by the framework to make sure they built and will run. Nothing is checked, and currently the pcap files are just written off into /tmp to be discarded. If the examples run (don't crash) they pass this smoke test. This brings up an important unresolved issue. Currently all tests are built into the ns-3 distribution. As we get more and more tests up, and especially as new system tests are written, the ns-3 code is going to balloon. We need to be able to split up the build process to build ns-3 module code in each src directory, ns-3 test code in each src directory. We need to be able to separately link ns-3 module and script code without including the test stuff. We also need to be able to link a test runner with the module code and the test code. I don't see how to do this right now without major waf surgery. The concepts of source directory name, module name, library name, number of header files and final executable content seem to be very entangled. I made a half-hearted attempt to try and figure this out, but got tired of waf fairly quickly. This isn't a huge problem yet, but will be as more tests are introduced. Tom had a number of "lingering issues" in an email from last month. I suppose I should address them here: 1) what is the overall plan for where this test code lives, and how does it relate to existing test.h and test.cc? Should existing src/test be moved to src/core? Answer: Current unit tests will turn into BVTs and still live in the module directories. Unit tests will live in the module directories. System tests will live in src/test and Examples will remain in examples. Src/core/test/{h,cc} will remain and have additional stuff added for the new test framework. It is expected that eventually all of the current unit tests will be moved into the BVT class of tests in the new framework. 2) Why not just borrow one of the existing GPLed testing frameworks and reuse it here? Which ones have we looked at for comparison? Answer: The most commonly used functionality for test frameworks is quite simple. There are dozens of different frameworks around, all of which implement basically the same core functionality. The basics are quite simple to implement. There are frameworks that go beyond this basic set -- the biggest and most ambitious I found is Google Test. The issue I have with Google Test is that it is very ... computer sciency. There are quite complicated ways to do things like use abstract test patterns (cf design patterns) which you instantiate and type to generate concrete test cases. This is simply not the kind of testing we need to do. We do electrical engineering kinds of things, not computer sciency things. My take is that existing frameworks provide the basics that we need, but also provide lots of stuff we will probably never use. They introduce their own conceptual models for how tests will be run and have their own coding standards, etc. It seemed to me to be much more desirable to keep the test framework looking and feeling like ns-3 and just implement the small set of functionality that I think we will use. 3) How are non-trivial output test vectors (they could be trace files, long sequences of numbers or timestamps, etc.) going to be stored? Answer: I've built a class to store test vectors which can be used as stimulus or response collections. These are collections of objects that are stored in the same directory as the test that uses them. There is a header associated with the vectors that identifies the endian-ness of the saved data, a version of the file format, time zone of the time stamps, number of significant figures of the time stamps, the maximum length of the saved object data, and a type that identifies what kind of data is saved. The saved objects have a timestamp associated with them to tell when they should be played back (as stimulus vectors) or when they should have been generated (as response vectors). If this sounds a lot like a pcap file, I came to the same conclusion. I generalized pcap files to allow for types outside the normal range and used them as test vector containers. This means that we suddenly have the ability to play back pcap files. This is implemented in src/common/pcap-file.{h,cc} as a low level service. It doesn't use Packets or Times since it is expected to be used to test things in core, but a separate more ns-3-ized thing could easily be built that returns Ptr instead of arrays of octets. 4) What is the story for waf integration, if test.py is retained? In particular, what kind of front end could waf provide for test.py script? In a previous post, I suggested that basic modes of test.py could still be invoked by ./waf --check, ./waf --test, ./waf --regression (etc.). Are the issues of accessing the configuration cache and of running programs through waf (or not) settled? Answer: Waf integration will be minimal. We will still be able to type waf check since people seem to like that. This will, however eventually call out to test.py and run all of the tests identified as Build Verification Tests (BVT). I don't have this in yet since there are no converted BVTs, but I expect to use something like "./test.py --class=BVT" to describe a set of tests to run. The issues of accessing the configuration cache are not completely settled. Right now test.py still looks directly at the waf configuration cache. This should probably be changed such that waf can output a list of the needed configuration items. I don't think this is a big deal, and haven't addressed it yet. Right now, test.py does not use waf at all to run its tests. I think eventually we will have enough test programs that it makes sense not to run through waf so this should remain. The change needed is to teach waf to dump "interesting information." 5) Related to this, what is the expected API and granularity for running these tests? Do we have different levels of testing that have simple APIs (such as the above sequence of waf commands)? Answer: ./test.py will run all of the tests ./test.py --class=BVT will run all of the build verification tests as defined above ./test.py --class=Unit will run all of the unit tests as defined above ./test.py --class=System will run all of the system tests as defined above ./test.py --class=Example will run all of the example smoke tests as defined above If desired, these options could be ORed together If desired, this functionality could be echoed in waf ./waf test could run all of the tests ./waf BVT could run all of the build verification tests as defined above ./waf Unit could run all of the unit tests as defined above ./waf System could run all of the system tests as defined above ./waf Example could run all of the example smoke tests as defined above OR is harder. 6) Can we review some really simple examples (e.g. in samples/ directory) showing different examples of what different types of tests would look like? What about a TCP model verification example? Answer: There are several different examples of different complexity provided in the repo. The essential concepts are that there are a number of TestCase classes that are used to compose a TestSuite. There is very little required to construct a simple test. class MyTestCase : public TestCase { virtual bool DoRun (void); }; bool MyTestCase::DoRun (void) { NS_TEST_ASSERT_MSG_EQ (true, true, "Some message"); return GetErrorStatus (); } class MySuite : public TestSuite { public: MyTestSuite (); }; MyTestSuite::MyTestSuite () : TestSuite ("my-test-suite-name") { AddTestCase (new MyTestCase); } MyTestSuite myTestSuite; That's it. It's roughly the same amount of effort required for a current unit test, and the same as for pretty much all of the available test packages. Some of them use macros to avoid a tiny bit of typing, but I think this approach is much clearer. Take a look in src/core/names-test-suite.cc for an example test suite for the object name service. This fits the description of a Unit Test since it is longer than the object name service implementation file. Like pretty much all unit tests, it is a collection of test cases that exercise the underlying code. It does things and then asserts that the correct things happened. It's just long and detailed. There is a smaller version of an object name service test that lives in names.cc (still in the old framework). That one demonstrates what might be done in a BVT. Look in src/common/pcap-file-test-suite.cc for an example test suite for the pcap file object. This uses a known good pcap file saved in the src/common directory as part of the test. It shows how unit tests can have test-vector files in the module directory. See src/core/rng-test-suite.cc for an example of how to do stochastic tests. These are the original random number generator tests I showed that use GSL to do chi-squared testing of random number generator histograms. Take a look at src/test/ns3wifi/propagation-loss-models-test-suite.cc to see an implementation of Michael Rush's Friis and LogDistance propagation loss model validation tests. This shows how one could move nodes around and take a look at how SNR changes with distance and compare that against a precalculated value. Also shows how measurement tolerances would work. Look at src/test/ns3tcp/ns3tcp-interop-test-suite.cc for an example that replaces the kind of pcap-file-based regression tests that we use now. This suite uses NSC TCP to start a connection with ns-3 TCP and then compares the ns3 TCP responses to a set of saved TCP headers. The responses are snagged out of the Ipv4L3Protocol Tx trace hook and the IP header is stripped leaving only the TCP header. The saved headers (response vectors) are stored in one of the generalized pcap files described above which are stored in the same directory as the test itself. Also see src/test/ns3tcp/ns3tcp-cwnd-test-suite.cc for an example that shows how to use a generic TestVector collection to capture congestion window trace events and compare them against values calculated dynamically. 7) Where do more complicated test and validation programs (i.e. the actual tests) reside? src/test? Answer: Yes. 8) What about Mathieu's comment recently about having a mode that dumps a lot of trace locally (without downloading saved regression traces) for more extensive regression testing before a checkin? Answer: There aren't any saved regression traces in the sense that we use that term now. Here's a comment from ns3tcp-interop-test-suite.cc that might address this: // // The idea here is that someone will look very closely at the all of the // communications between the reference TCP and the TCP under test in this // simulation and determine that all of the responses are correct. We expect // that this means generating a pcap trace file from the point-to-point link // and examining the packets closely using tcpdump, wireshark or some such // program. So we provide the ability to generate a pcap trace of the // test execution for your perusal. // // Once the validation test is determined to be running exactly as expected, // we allow you to generate a file that contains the response vectors that // will be checked during the actual execution of the test. // if (m_writeVectors) { PointToPointHelper::EnablePcapAll ("tcp-interop"); } Right now this is done by setting m_writeVectors to true, but eventually I would think it would be good to add a flag that is passed down to the test suite via test.py 9) What output do people want to see, typically (Gustavo had made a comment about minimal output for successful tests and verbose outputs for failed tests)? Answer: As it stands now, if you run test.py you get see something that looks like this: FAIL: TestSuite ns3-wifi-propagation-loss-models PASS: TestSuite object-name-service PASS: TestSuite ns3-tcp-cwnd PASS: TestSuite ns3-tcp-interoperability PASS: TestSuite pcap-file-object PASS: Example csma-broadcast ... PASS: Example csma-multicast PASS: Example csma-star PASS: Example tcp-large-transfer PASS: Example realtime-udp-echo This is the "minimal output case". If you look in the file, "test-results.txt" you'll see more information PASS: Test Suite "ns3-wifi-propagation-loss-models" PASS: Test Case "Check to see that the ns-3 Friis propagation loss model provides correct SNR values" FAIL: Test Case "Check to see that the ns-3 Log Distance propagation loss model provides correct SNR values" Details: Message: Got unexpected SNR value Condition: snr (actual) LT testVector.m_snr (limit) + testVector.m_tolerance (tol) AND snr (actual) GT testVector.m_snr (l imit) - testVector.m_tolerance (tol) Actual: 176.395 Limit: 176.407 +- 0.0005 File: ../src/test/ns3wifi/propagation-loss-models-test-suite.cc Line: 360 PASS: Test Suite "object-name-service" PASS: Test Case "Check low level Names::Add and Names::FindName functionality" PASS: Test Case "Check string context Names::Add and Names::FindName functionality" PASS: Test Case "Check fully qualified path Names::Add and Names::FindName functionality" PASS: Test Case "Check relative path Names::Add and Names::FindName functionality" PASS: Test Case "Check low level Names::Rename functionality" PASS: Test Case "Check string context-based Names::Rename functionality" PASS: Test Case "Check fully qualified path Names::Rename functionality" PASS: Test Case "Check relative path Names::Rename functionality" PASS: Test Case "Check Names::FindPath functionality" PASS: Test Case "Check low level Names::Find functionality" PASS: Test Case "Check string context-based Names::Find functionality" PASS: Test Case "Check fully qualified path Names::Find functionality" PASS: Test Case "Check relative path Names::Find functionality" PASS: Test Case "Check GetObject operation in Names::Find" PASS: Test Suite "ns3-tcp-cwnd" PASS: Test Case "Check to see that the ns-3 TCP congestion window works as expected against liblinux2.6.26.so" PASS: Test Suite "ns3-tcp-interoperability" PASS: Test Case "Check to see that the ns-3 TCP can work with liblinux2.6.26.so" PASS: Test Suite "pcap-file-object" PASS: Test Case "Check to see that PcapFile::Open with mode "w" works" PASS: Test Case "Check to see that PcapFile::Open with mode "r" works" PASS: Test Case "Check to see that PcapFile::Open with mode "a" works" PASS: Test Case "Check to see that PcapFileHeader is managed correctly" PASS: Test Case "Check to see that PcapRecordHeader is managed correctly" PASS: Test Case "Check to see that PcapFile can read out a known good pcap file" PASS: Test Suite "random-number-generators" PASS: Test Case "Uniform Random Number Generator" PASS: Test Case "Normal Random Number Generator" PASS: Test Case "Exponential Random Number Generator" PASS: Test Case "Pareto Random Number Generator" PASS: Example "csma-broadcast" PASS: Example "csma-multicast" PASS: Example "csma-bridge" ... PASS: Example "udp-echo" PASS: Example "wifi-wired-bridging" PASS: Example "csma-star" PASS: Example "tcp-large-transfer" PASS: Example "realtime-udp-echo" You see a more verbose description of what was executed and a rather detailed description of what went wrong. There is also an HTML file generated with the same level of detail as the text file for incorporation into a nightly build results web page. 10) Can we avoid baking in a GSL dependency in case we want to rewrite histogram or chi-squared routines ourselves in the future? Answer: Yes. I don't really relish the idea of writing cumulative distribution functions for various distributions, though. GSL makes statistical tests so much easier to deal with that I think we should really begin to use it more. We could try and write a porting layer in between ns-3 and GSL to make it easier to swap in other libraries, but I'm not sure we could get it even close to right unless we knew what those libraries were. 11) Mathieu remarked early on that it would be nice to factor out the chi-squared testing tools from within the random number tests, so they could be used elsewhere. Answer: The interesting thing about the chi-squared tests is that they are trivial to implement, but difficult to really understand. If you look in src/core/rng-test-suite.cc, you will find that the complete chi-squared test including creating the histos, filling them and doing the test is only about 20 lines of code. The hard thing to understand is why the numbers are what they are and those numbers would have to be provided to a chi-square function. I think a well-documented example with lots of words about choosing the magic numbers might be just as good. Perhaps this starts getting more into developing a statistics toolkit more than a testing toolkit. 12) How would lcov, nightly builds (buildbots, others) etc. be plumbed in? Answer: The same way that it is done now? From mathieu.lacage at sophia.inria.fr Sun Aug 23 17:09:20 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Sun, 23 Aug 2009 17:09:20 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-3.4.6 Message-ID: <200908240009.n7O09KmM022514@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/135 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 shell_16 shell_17 shell_18 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Sun Aug 23 17:18:29 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Sun, 23 Aug 2009 17:18:29 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.0.4 Message-ID: <200908240018.n7O0ITBR022522@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/123 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 shell_16 shell_17 shell_18 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Sun Aug 23 17:27:49 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Sun, 23 Aug 2009 17:27:49 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.1.2 Message-ID: <200908240027.n7O0RnQL022540@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/129 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_8 shell_9 shell_10 shell_12 shell_13 shell_14 shell_16 shell_17 shell_18 sincerely, -The Buildbot From tomh at tomh.org Sun Aug 23 21:09:08 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 23 Aug 2009 21:09:08 -0700 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: <1250706023.2635.5.camel@localhost.localdomain> References: <20090819122000.GC15935@clipper.ens.fr> <20090819135509.GD15935@clipper.ens.fr> <20090819142341.GE15935@clipper.ens.fr> <1250706023.2635.5.camel@localhost.localdomain> Message-ID: <4A921264.4020507@tomh.org> Mathieu Lacage wrote: > On Wed, 2009-08-19 at 16:23 +0200, Guillaume Seguin wrote: > >>> I don't think the listEnd variable in your patch causes any Node reference >>> count to increase, unless I miss something. >>> >> >> Hmm yeah this sounds right. After checking the code again, most likely those >> Unrefs were coming from the NodeListPriv object, which is ref'd and unref'd in >> NodeList::End () I believe. > > ha, good catch: that is the root of the problem most likely. > >>> I still wish NodeList::End could be effectively inlined so that we would be >>> speeding up not only global routing but other code using NodeList as well. >>> >> Yeah, this might be a worthy gain, though the trip through the singleton getter >> might be expensive part. > > I guess you could do something along the lines of: > - make End inline > - mark singleton get functions inline > - make get function return a const & Ptr or a raw pointer > > (I did not look at the code to check if this makes sense at all) > Guillaume, I would be fine with either solution you choose (your original patch, or inlining End if the above were to work out). - Tom From tomh at tomh.org Sun Aug 23 21:28:26 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 23 Aug 2009 21:28:26 -0700 Subject: [Ns-developers] exporting more headers from src/internet-stack In-Reply-To: <1250850868.2925.172.camel@localhost.localdomain> References: <1250848323.2925.158.camel@localhost.localdomain> <200908211437.39008.boyko@iitp.ru> <1250850868.2925.172.camel@localhost.localdomain> Message-ID: <4A9216EA.4040509@tomh.org> Mathieu Lacage wrote: > On Fri, 2009-08-21 at 14:37 +0400, Pavel Boyko wrote: > >>> I needed to get the protocol headers from src/internet-stack but I did >>> not want to export all headers, so, I ended-up doing some more serious >>> cleaning-up. Comments about this ? >> I also need arp-cache.h to be exported for AODV layer 2 feedback and sgi- > > I see that the only header it requires is sgi-hashmap.h so, it should be > trivial to add to wscript. > >> hashmap.h follows (m.b. it should be moved to common?). > > Yes, we can do this: anyone against this ? > No objections here. - Tom From tomh at tomh.org Sun Aug 23 21:48:45 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 23 Aug 2009 21:48:45 -0700 Subject: [Ns-developers] merge plan for ns-3-netfilter work Message-ID: <4A921BAD.20407@tomh.org> Qasim, I spent some time reviewing your repository: http://code.nsnam.org/qasimj/ns-3-dev-netfilter/ and it's great to see that NAT is working, but we need to do some more work to get it to mergeable state. I am going to repeat something I sent to you recently but on the developers list this time so that others may track this. It seems that we could work towards a two-step merge. The first would be to merge only the netfilter framework, with no NAT or conntracking code. This would involve the following: 1) definition of Netfilter hook and callback chain 2) Ipv4Netfilter object 3) insertion at the five hook points in Ipv4L3Protocol The above would be exercisable by a test program that injected test packets, and inserted hooks at various points and checked to see if the right behavior occurred. For instance, do packets successfully go through all registered hooks? Does the framework respect the callbacks setting the return values of NF_ACCEPT, NF_DROP, etc? The second merge chunk would be the rest of the code, including helper code that allows user to easily turn an IPv4 node into a NAT and to obtain statistics or other debugging information regarding what is going on in the NAT state, as well as a second test program or set of test programs. If you agree with this overall approach, then I think the next thing to do is to settle on final header files for the objects to be included in the first merge chunk, and agree on a test program that needs to pass before declaring success. - Tom From tomh at tomh.org Sun Aug 23 22:05:35 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 23 Aug 2009 22:05:35 -0700 Subject: [Ns-developers] ipv6 plans for ns-3 In-Reply-To: <4A85192C.2030702@clarinet.u-strasbg.fr> References: <36caa09167fd3a8199d20efc14211f2c@tomh.org> <4A5381E1.5090602@clarinet.u-strasbg.fr> <4A65BC4F.6070500@clarinet.u-strasbg.fr> <4A6868B3.6040508@tomh.org> <4A696E6F.8080606@clarinet.u-strasbg.fr> <004b01ca0c5c$c6e966f0$54bc34d0$@ch> <4A6D7E12.8030201@clarinet.u-strasbg.fr> <4A71EA53.9020709@clarinet.u-strasbg.fr> <4A85192C.2030702@clarinet.u-strasbg.fr> Message-ID: <4A921F9F.5040204@tomh.org> Sebastien Vincent wrote: > Tom Henderson a ?crit : >> On Thu, 30 Jul 2009 20:45:39 +0200, S?bastien Vincent >> wrote: >> >>> Hi all, >>> >>> New features: >>> - RA handler to autoconfigure address and default route; >>> - Radvd application made scratch (not reused radvd stuff from >>> ns-3-ipv6 old repository); >>> - Two new examples: radvd and radvd-two-prefix. The last ones >>> advertise two prefixes in RA. >>> >>> By the way I added in Ipv6RoutingProtocol, two methods for adding >>> routes. It is needed for ICMPv6 redirect (which add a host route to >>> redirected target), and to configure the default route when receive >>> first RA's prefix: NotifyAddRoute and NotifyRemoveRoute. >>> >>> >> >> I am not sure about the above Ipv6RoutingProtocol changes. It seems like >> what you want to do is to get a handle on a static routing object and >> add a >> host route directly, but you are instead providing a notification to all >> routing protocols (as in RTM_NEWROUTE). >> >>> To summarize what is done now in >>> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd: >>> - IPv6 interface; >>> - IPv6 layer; >>> - IPv6 raw socket; >>> - Static IPv6 routing; >>> - ICMPv6 layer; >>> - Some ICMPv6 error messages (destination unreachable, ...); >>> - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); >>> - Ping6 application (send Echo request); >>> - Radvd application (send RA); >>> - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, >>> icmpv6-redirect). >>> >>> My holidays ends by monday, as I already said I will not have much >>> time to work on ns-3 after. >>> >>> I think that we can first review current work and give feedback. And >>> maybe try to merge it before continue to work on UDP/TCP. It will be >>> great to finally enable ns-3 users to begin make IPv6 simulations >>> with ICMPv6 in next ns-3 release. >>> >>> >> >> I've posted this repository on ns-3-reviews in case people would like to >> review it there. Please review it by next Wed. or ask for more time; >> if no >> major comments, I will try to merge this later next week. >> http://codereview.appspot.com/105054 >> >> > > I have updated repository (fix one bug and recent ns-3-dev changes). > Feel free to review it. > > Tom, I have also added text from RELEASE_NOTES/CHANGES.html you made in > http://codereview.appspot.com/105054 Sebastien, I checked in the new code earlier today. Thanks again for this contribution. Here is a brief list of the open issues that we need to tackle: - need to find clean way to reuse transport layer implementations across address families - link change callback issue (bug 560-- I just left a fresh comment) - improve static routing implementation along the lines of what Antti has done in bug 659 - possibly a better solution for handling the static routes generated by ICMPv6 redirects (than the current NotifyAddRoute). - handle link-local multicast in static routing - handle Router Advertisement (receive, parse, extract prefix and autoconfigured global address with it + timer) Then, more features - TCP/UDP - IPv6 global routing Plus, we should start a manual chapter on IPv6 stack, add some regression tests, and add something to the tutorial. Others I'm forgetting? Tom From vincent at clarinet.u-strasbg.fr Mon Aug 24 00:10:27 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Mon, 24 Aug 2009 09:10:27 +0200 Subject: [Ns-developers] ipv6 plans for ns-3 In-Reply-To: <4A921F9F.5040204@tomh.org> References: <36caa09167fd3a8199d20efc14211f2c@tomh.org> <4A5381E1.5090602@clarinet.u-strasbg.fr> <4A65BC4F.6070500@clarinet.u-strasbg.fr> <4A6868B3.6040508@tomh.org> <4A696E6F.8080606@clarinet.u-strasbg.fr> <004b01ca0c5c$c6e966f0$54bc34d0$@ch> <4A6D7E12.8030201@clarinet.u-strasbg.fr> <4A71EA53.9020709@clarinet.u-strasbg.fr> <4A85192C.2030702@clarinet.u-strasbg.fr> <4A921F9F.5040204@tomh.org> Message-ID: <4A923CE3.8020900@clarinet.u-strasbg.fr> Hi, Tom Henderson a ?crit : > Sebastien Vincent wrote: >> Tom Henderson a ?crit : >>> On Thu, 30 Jul 2009 20:45:39 +0200, S?bastien Vincent >>> wrote: >>> >>>> Hi all, >>>> >>>> New features: >>>> - RA handler to autoconfigure address and default route; >>>> - Radvd application made scratch (not reused radvd stuff from >>>> ns-3-ipv6 old repository); >>>> - Two new examples: radvd and radvd-two-prefix. The last ones >>>> advertise two prefixes in RA. >>>> >>>> By the way I added in Ipv6RoutingProtocol, two methods for adding >>>> routes. It is needed for ICMPv6 redirect (which add a host route to >>>> redirected target), and to configure the default route when receive >>>> first RA's prefix: NotifyAddRoute and NotifyRemoveRoute. >>>> >>>> >>> >>> I am not sure about the above Ipv6RoutingProtocol changes. It seems >>> like >>> what you want to do is to get a handle on a static routing object >>> and add a >>> host route directly, but you are instead providing a notification to >>> all >>> routing protocols (as in RTM_NEWROUTE). >>>> To summarize what is done now in >>>> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd: >>>> - IPv6 interface; >>>> - IPv6 layer; >>>> - IPv6 raw socket; >>>> - Static IPv6 routing; >>>> - ICMPv6 layer; >>>> - Some ICMPv6 error messages (destination unreachable, ...); >>>> - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); >>>> - Ping6 application (send Echo request); >>>> - Radvd application (send RA); >>>> - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, >>>> icmpv6-redirect). >>>> >>>> My holidays ends by monday, as I already said I will not have much >>>> time to work on ns-3 after. >>>> >>>> I think that we can first review current work and give feedback. >>>> And maybe try to merge it before continue to work on UDP/TCP. It >>>> will be great to finally enable ns-3 users to begin make IPv6 >>>> simulations with ICMPv6 in next ns-3 release. >>>> >>>> >>> >>> I've posted this repository on ns-3-reviews in case people would >>> like to >>> review it there. Please review it by next Wed. or ask for more >>> time; if no >>> major comments, I will try to merge this later next week. >>> http://codereview.appspot.com/105054 >>> >>> >> >> I have updated repository (fix one bug and recent ns-3-dev changes). >> Feel free to review it. >> >> Tom, I have also added text from RELEASE_NOTES/CHANGES.html you made >> in http://codereview.appspot.com/105054 > > Sebastien, I checked in the new code earlier today. Thanks again for > this contribution. Here is a brief list of the open issues that we > need to tackle: > > - need to find clean way to reuse transport layer implementations > across address families > - link change callback issue (bug 560-- I just left a fresh comment) You mean bug 653 I think. I will update patch latter today and by the way set the link change callback for NdiscCache (in icmpv6-l4-protocl.cc). > - improve static routing implementation along the lines of what Antti > has done in bug 659 > - possibly a better solution for handling the static routes generated > by ICMPv6 redirects (than the current NotifyAddRoute). > - handle link-local multicast in static routing OK > - handle Router Advertisement (receive, parse, extract prefix and > autoconfigured global address with it + timer) > This one is already in this chunk and works (see Icmpv6L4Protocol::ReceiveRA (), Ipv6L3Protocol::AddAutoconfiguredAddress () and Ipv6AutoconfiguredAddress class for timer stuff). > Then, more features > - TCP/UDP > - IPv6 global routing > > Plus, we should start a manual chapter on IPv6 stack, add some > regression tests, and add something to the tutorial. OK. > > Others I'm forgetting? > IPv6 extensions support: - headers (hop-by-hop, destination, fragment, routing (type 0, type 2), AH (authentication) and ESP (confidentiality); - parsing; - processing (routing, fragmentation, ...). You can see at old repository (https://svnet.u-strasbg.fr/hg/ns-3-ipv6) what it looks like (files src/internet-stack/ipv6-extension* and src/internet-stack/ipv6-l3-protocol.cc). Best regards, -- Sebastien > Tom > From nbaldo at cttc.es Mon Aug 24 03:23:25 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Mon, 24 Aug 2009 12:23:25 +0200 Subject: [Ns-developers] added AthstatsWifiTraceSink and associated helper In-Reply-To: <1250851085.2925.176.camel@localhost.localdomain> References: <0016368e1c2fc21d70046ed28ba5@google.com> <4A8D8DCB.8080806@cttc.es> <1250796646.2869.224.camel@localhost.localdomain> <4A8E77B6.9060800@cttc.es> <1250851085.2925.176.camel@localhost.localdomain> Message-ID: <4A926A1D.4050205@cttc.es> Hi all, please find attached the release candidate version for the patch introducing the new trace sources for WifiRemoteStationManager + the athstats sink and its associated helper. Awaiting for feedback... Nicola -------------- next part -------------- A non-text attachment was scrubbed... Name: new-mac-traces-plus-athstats-rc2.patch Type: text/x-patch Size: 24799 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090824/d854fa66/new-mac-traces-plus-athstats-rc2.bin From mathieu.lacage at sophia.inria.fr Mon Aug 24 03:51:36 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 24 Aug 2009 12:51:36 +0200 Subject: [Ns-developers] added AthstatsWifiTraceSink and associated helper In-Reply-To: <4A926A1D.4050205@cttc.es> References: <0016368e1c2fc21d70046ed28ba5@google.com> <4A8D8DCB.8080806@cttc.es> <1250796646.2869.224.camel@localhost.localdomain> <4A8E77B6.9060800@cttc.es> <1250851085.2925.176.camel@localhost.localdomain> <4A926A1D.4050205@cttc.es> Message-ID: <1251111096.3335.7.camel@diese.inria.fr> ok for commit. On Mon, 2009-08-24 at 12:23 +0200, Nicola Baldo wrote: > Hi all, > > please find attached the release candidate version for the patch > introducing the new trace sources for WifiRemoteStationManager + the > athstats sink and its associated helper. > Awaiting for feedback... > > Nicola > > From guillaume.seguin at ens.fr Mon Aug 24 04:02:19 2009 From: guillaume.seguin at ens.fr (Guillaume Seguin) Date: Mon, 24 Aug 2009 13:02:19 +0200 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: <4A921264.4020507@tomh.org> References: <20090819122000.GC15935@clipper.ens.fr> <20090819135509.GD15935@clipper.ens.fr> <20090819142341.GE15935@clipper.ens.fr> <1250706023.2635.5.camel@localhost.localdomain> <4A921264.4020507@tomh.org> Message-ID: <20090824110219.GF15935@clipper.ens.fr> On 23 ao?t 2009 ? 21:09:08 (-0700), Tom Henderson wrote : > Mathieu Lacage wrote: >> On Wed, 2009-08-19 at 16:23 +0200, Guillaume Seguin wrote: >> >>>> I don't think the listEnd variable in your patch causes any Node reference >>>> count to increase, unless I miss something. >>>> >>> >>> Hmm yeah this sounds right. After checking the code again, most likely those >>> Unrefs were coming from the NodeListPriv object, which is ref'd and unref'd in >>> NodeList::End () I believe. >> >> ha, good catch: that is the root of the problem most likely. >> >>>> I still wish NodeList::End could be effectively inlined so that we would be >>>> speeding up not only global routing but other code using NodeList as well. >>>> >>> Yeah, this might be a worthy gain, though the trip through the singleton getter >>> might be expensive part. >> >> I guess you could do something along the lines of: >> - make End inline >> - mark singleton get functions inline >> - make get function return a const & Ptr or a raw pointer >> >> (I did not look at the code to check if this makes sense at all) >> > > Guillaume, I would be fine with either solution you choose (your > original patch, or inlining End if the above were to work out). > Well, I think that the two solutions are distinct, one being micro-optimization and the other one being some more general optimization (the inlining). Guillaume From faker.moatamri at sophia.inria.fr Mon Aug 24 06:45:27 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 24 Aug 2009 15:45:27 +0200 Subject: [Ns-developers] Wimax status Message-ID: <4A929977.1090604@sophia.inria.fr> Hi all, I've been through big modifications for coding and naming style, I did commit the changes to http://code.nsnam.org/iamine/ns-3-wimax-to_be_released/, the changes are basically: - Coding style changes including indentation, spacing and return to the line, etc - Naming style changes including class names, methods names variable and member variable names - File naming changes - Replacing NS_ASSERT (false) by NS_FATAL_ERROR ("message") - Remove commented code from all the wimax code If I missed something please don't hesitate to tell me about it so we can fix it. Now that the most conflicting changes are done, we can keep on enhancing the code for the future merge with ns-3-dev. The steps that we need to go through are: - Moving files from scratch folder to appropriate folders -> amine - Removing #include "../../...." from files -> amine - Adding validation tests-> Amine can you manage that with Flavio and Giuseppe? - We need documentation for advanced features, Amine again can you help managing that? - We need to apply the review comments from http://codereview.appspot.com/75057/show which is a big task: Since there are about 160 files to review, we can divide the work between us, I need your help, please tell me if you are available to help. I will start now to go through the above review. I remind you that we need to *freeze refactoring on wednesday* *August 26th* to begin merging with ns-3-dev on thursday August 27th. Thanks Best regards Faker Moatamri From tomh at tomh.org Mon Aug 24 07:12:14 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 24 Aug 2009 07:12:14 -0700 Subject: [Ns-developers] Don't recompute NodeList::End () at every loop in GlobalRouteManagerImpl In-Reply-To: <20090824110219.GF15935@clipper.ens.fr> References: <20090819122000.GC15935@clipper.ens.fr> <20090819135509.GD15935@clipper.ens.fr> <20090819142341.GE15935@clipper.ens.fr> <1250706023.2635.5.camel@localhost.localdomain> <4A921264.4020507@tomh.org> <20090824110219.GF15935@clipper.ens.fr> Message-ID: <4A929FBE.1080004@tomh.org> >>> >> Guillaume, I would be fine with either solution you choose (your >> original patch, or inlining End if the above were to work out). >> > > Well, I think that the two solutions are distinct, one being micro-optimization > and the other one being some more general optimization (the inlining). > Yes, I agree; I'm basically saying that unless you or someone else produces the more general optimization, I'd be in favor of your original patch. From flaviokubota at gmail.com Mon Aug 24 08:14:06 2009 From: flaviokubota at gmail.com (Flavio Kubota) Date: Mon, 24 Aug 2009 12:14:06 -0300 Subject: [Ns-developers] Wimax status In-Reply-To: <4A929977.1090604@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> Message-ID: Hi Faker, I'll have some time only tomorrow afternoon (August 25th). You can give me some tasks to do. Regards, -- Flavio Kubota MSc Computer Science Student IC / UNICAMP On Mon, Aug 24, 2009 at 10:45 AM, Faker Moatamri < faker.moatamri at sophia.inria.fr> wrote: > Hi all, > > I've been through big modifications for coding and naming style, I did > commit the changes to > http://code.nsnam.org/iamine/ns-3-wimax-to_be_released/, the changes are > basically: > - Coding style changes including indentation, spacing and return to the > line, etc > - Naming style changes including class names, methods names variable and > member variable names > - File naming changes > - Replacing NS_ASSERT (false) by NS_FATAL_ERROR ("message") > - Remove commented code from all the wimax code > If I missed something please don't hesitate to tell me about it so we can > fix it. > > Now that the most conflicting changes are done, we can keep on enhancing > the code for the future merge with ns-3-dev. > > The steps that we need to go through are: > - Moving files from scratch folder to appropriate folders -> amine > - Removing #include "../../...." from files -> amine > - Adding validation tests-> Amine can you manage that with Flavio and > Giuseppe? > - We need documentation for advanced features, Amine again can you help > managing that? > - We need to apply the review comments from > http://codereview.appspot.com/75057/show which is a big task: Since there > are about 160 files to review, we can divide the work between us, I need > your help, please tell me if you are available to help. > I will start now to go through the above review. > > I remind you that we need to *freeze refactoring on wednesday* *August > 26th* to begin merging with ns-3-dev on thursday August 27th. > > Thanks > Best regards > Faker Moatamri > > From qasimj at gmail.com Mon Aug 24 13:44:15 2009 From: qasimj at gmail.com (Qasim Javed) Date: Mon, 24 Aug 2009 14:44:15 -0600 Subject: [Ns-developers] merge plan for ns-3-netfilter work In-Reply-To: <4A921BAD.20407@tomh.org> References: <4A921BAD.20407@tomh.org> Message-ID: <8e718ab40908241344o785a2358o4cd317edb1a4be2@mail.gmail.com> I agree with the two-step merge approach. I can start working on the test program which will exercise the basic functionality of the framework. I have tested the packet traversal through the hook points for UDP/TCP packets. However, I will test the same for ICMP, ARP etc. so that we can proceed with a certain degree of confidence. These tests will go into the test program as suggested by you. Also, I need to verify that the framework respects NF_DROP and NF_ACCEPT verdicts. I had not done that earlier as this functionality was not required for implementing NAT. Regarding the API, there are two options for Ipv4Netfilter object. Ptr ipv4 = ... Ptr ipv4nf = ipv4->GetNetfilter(); vs. Ptr ipv4 = ... Ptr ipv4nf = ipv4->GetObject (); That is, we can either make Ipv4Netfilter object a member of Ipv4 class (accessible by GetNetfilter () method) or aggregate it to Ipv4 class. We need to discuss this so that the flexible of the two can be implemented. Considering that Netfilter framework is optional, the idea of aggregating the object to Ipv4 class sounds more logical. However, I would like people to chip in here and give suggestions regarding the matter. As soon as we can finish deciding upon the API, I can work towards merging the first part, which is the netfilter framework. After that, we can have similar dicussions on the second part of the merge which would include connection tracking code and NAT helpers. Thanks, -Qasim On Sun, Aug 23, 2009 at 10:48 PM, Tom Henderson wrote: > Qasim, > I spent some time reviewing your repository: > http://code.nsnam.org/qasimj/ns-3-dev-netfilter/ > and it's great to see that NAT is working, but we need to do some more work > to get it to mergeable state. I am going to repeat something I sent to you > recently but on the developers list this time so that others may track this. > > It seems that we could work towards a two-step merge. The first > would be to merge only the netfilter framework, with no NAT or > conntracking code. This would involve the following: > > 1) definition of Netfilter hook and callback chain > 2) Ipv4Netfilter object > 3) insertion at the five hook points in Ipv4L3Protocol > > The above would be exercisable by a test program that injected test > packets, and inserted hooks at various points and checked to see if the > right behavior occurred. For instance, do packets successfully go > through all registered hooks? Does the framework respect the callbacks > setting the return values of NF_ACCEPT, NF_DROP, etc? > > The second merge chunk would be the rest of the code, including helper > code that allows user to easily turn an IPv4 node into a NAT and to > obtain statistics or other debugging information regarding what is going > on in the NAT state, as well as a second test program or set of test > programs. > > If you agree with this overall approach, then I think the next thing to > do is to settle on final header files for the objects to be included in > the first merge chunk, and agree on a test program that needs to pass > before declaring success. > > - Tom > > From mathieu.lacage at sophia.inria.fr Tue Aug 25 00:01:56 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 25 Aug 2009 09:01:56 +0200 Subject: [Ns-developers] exporting more headers from src/internet-stack In-Reply-To: <4A9216EA.4040509@tomh.org> References: <1250848323.2925.158.camel@localhost.localdomain> <200908211437.39008.boyko@iitp.ru> <1250850868.2925.172.camel@localhost.localdomain> <4A9216EA.4040509@tomh.org> Message-ID: <1251183716.5692.9.camel@diese.inria.fr> On Sun, 2009-08-23 at 21:28 -0700, Tom Henderson wrote: > No objections here. I took this as an ack to the whole patchset and pushed my original patch as well as pavel's requested additions. Mathieu From faker.moatamri at sophia.inria.fr Tue Aug 25 00:58:17 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 25 Aug 2009 09:58:17 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: References: <4A929977.1090604@sophia.inria.fr> Message-ID: <4A939999.80807@sophia.inria.fr> Flavio Kubota wrote: > Hi Faker, > > I'll have some time only tomorrow afternoon (August 25th). You can > give me some tasks to do. > > > Regards, > -- > Flavio Kubota > MSc Computer Science Student > IC / UNICAMP > > > On Mon, Aug 24, 2009 at 10:45 AM, Faker Moatamri > > wrote: > > Hi all, > > I've been through big modifications for coding and naming style, I > did commit the changes to > http://code.nsnam.org/iamine/ns-3-wimax-to_be_released/, the > changes are basically: > - Coding style changes including indentation, spacing and return > to the line, etc > - Naming style changes including class names, methods names > variable and member variable names > - File naming changes > - Replacing NS_ASSERT (false) by NS_FATAL_ERROR ("message") > - Remove commented code from all the wimax code > If I missed something please don't hesitate to tell me about it so > we can fix it. > > Now that the most conflicting changes are done, we can keep on > enhancing the code for the future merge with ns-3-dev. > > The steps that we need to go through are: > - Moving files from scratch folder to appropriate folders -> amine > - Removing #include "../../...." from files -> amine > - Adding validation tests-> Amine can you manage that with Flavio > and Giuseppe? > - We need documentation for advanced features, Amine again can you > help managing that? > - We need to apply the review comments from > http://codereview.appspot.com/75057/show which is a big task: > Since there are about 160 files to review, we can divide the work > between us, I need your help, please tell me if you are available > to help. > I will start now to go through the above review. > > I remind you that we need to *freeze refactoring on wednesday* > *August 26th* to begin merging with ns-3-dev on thursday August 27th. > > Thanks > Best regards > Faker Moatamri > > Hi, Ok Giuseppe, it's fine with me if you'd like to work on regression test. Flavio, can you please go through your code and correct all that needs to be corrected: http://codereview.appspot.com/107047/show . Also we need as much doxygen as you can, so can you please document your modules and all the related modules you know how they work and that needs documentation. If you finish those tasks I can give you more work. Thanks Best regards Faker Moatamri From amine.ismail at sophia.inria.fr Tue Aug 25 03:25:54 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Tue, 25 Aug 2009 12:25:54 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: <4A929977.1090604@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> Message-ID: <4A93BC32.2060102@sophia.inria.fr> Hi all, >- Moving files from scratch folder to appropriate folders -> amine Done! >- Removing #include "../../...." from files -> amine Done! >- Adding validation tests-> Amine can you manage that with Flavio and Giuseppe? I have added 2 regression tests based on example scenarios. To execute these tests we should compile the module with "WIMAX_TEST" flag: CXXFLAGS="-DWIMAX_TEST" ./waf configure; ./waf The first test is wimax-ipv4 and the second one is wimax-simple under example repository. the 2 scripts output a test report reporting if the test was ok or failed. We can select the scheduling type using command line thanks to -s option: wimax-simple [-s scheduling_type] the scheduling type can be: 0 for SCHED_TYPE_SIMPLE 1 for SCHED_TYPE_MBQOS 2 for SCHED_TYPE_RTPS The default scheduler is SCHED_TYPE_SIMPLE (0) Wimax-ipv4 simulates a network of 3 couples of SSs exchanging ipv4 datagrams over a single BS while wimax-multicast simulates a network with 10 SSs receiving multicast ipv4 datagrams from a streamer connected to the BS with CSMA. The output of wimax-ipv4 is as follows: TEST SS0 SS3.....OK TEST SS1 SS4.....OK TEST SS2 SS5.....OK TEST.....OK The output of wimax-multicast is as follows: TEST SS0.....OK TEST SS1.....OK TEST SS2.....OK TEST SS3.....OK TEST SS4.....OK TEST SS5.....OK TEST SS6.....OK TEST SS7.....OK TEST SS8.....OK TEST SS9.....OK TEST.....OK > - We need documentation for advanced features, Amine again can you help managing that? There si a README file under src/devices/wimax which describes the main features of the module. We can extend this by describing the new features we have developed. I will add a paragraph for the new physical layer. Giusseppe and Flavio could you please provide a little description of the schedulers you have developed? Best regards Amine Faker Moatamri wrote: > Hi all, > > I've been through big modifications for coding and naming style, I did > commit the changes to > http://code.nsnam.org/iamine/ns-3-wimax-to_be_released/, the changes > are basically: > - Coding style changes including indentation, spacing and return to > the line, etc > - Naming style changes including class names, methods names variable > and member variable names > - File naming changes > - Replacing NS_ASSERT (false) by NS_FATAL_ERROR ("message") > - Remove commented code from all the wimax code > If I missed something please don't hesitate to tell me about it so we > can fix it. > > Now that the most conflicting changes are done, we can keep on > enhancing the code for the future merge with ns-3-dev. > > The steps that we need to go through are: > - Moving files from scratch folder to appropriate folders -> amine > - Removing #include "../../...." from files -> amine > - Adding validation tests-> Amine can you manage that with Flavio and > Giuseppe? > - We need documentation for advanced features, Amine again can you > help managing that? > - We need to apply the review comments from > http://codereview.appspot.com/75057/show which is a big task: Since > there are about 160 files to review, we can divide the work between > us, I need your help, please tell me if you are available to help. > I will start now to go through the above review. > > I remind you that we need to *freeze refactoring on wednesday* *August > 26th* to begin merging with ns-3-dev on thursday August 27th. > > Thanks > Best regards > Faker Moatamri > From faker.moatamri at sophia.inria.fr Tue Aug 25 04:40:17 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 25 Aug 2009 13:40:17 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: <4A93BC32.2060102@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> Message-ID: <4A93CDA1.70308@sophia.inria.fr> Ismail Amine wrote: > Hi all, > > >- Moving files from scratch folder to appropriate folders -> amine > Done! Cool, thanks, though you need to be carefull because the version in the repository doesn't compile due to the following error: [749/817] cxx: examples/wimax.cc -> build/debug/examples/wimax_39.o cc1plus: warnings being treated as errors ../examples/wimax-ipv4.cc: In function 'int main(int, char**)': ../examples/wimax-ipv4.cc:115: warning: unused variable 'schedType' [751/817] cxx: scratch/multiple-sources/simple-simulation.cc -> build/debug/scratch/multiple-sources/simple-simulation_1.o cc1plus: warnings being treated as errors ../examples/wimax-multicast.cc: In function 'int main(int, char**)': ../examples/wimax-multicast.cc:151: warning: unused variable 'schedType' ../examples/wimax-multicast.cc:261: warning: unused variable 'baseAddress' Waf: Leaving directory `/home/buildslave/slave/full-mimas-g++-4.2.4/build/build' Build failed -> task failed (err #1): {task: cxx wimax-ipv4.cc -> wimax-ipv4_37.o} -> task failed (err #1): {task: cxx wimax-multicast.cc -> wimax-multicast_38.o} > >- Removing #include "../../...." from files -> amine > Done! > >- Adding validation tests-> Amine can you manage that with Flavio and > Giuseppe? > I have added 2 regression tests based on example scenarios. To execute > these tests we should compile the module with "WIMAX_TEST" flag: > CXXFLAGS="-DWIMAX_TEST" ./waf configure; ./waf > > The first test is wimax-ipv4 and the second one is wimax-simple under > example repository. the 2 scripts output a test report reporting if > the test was ok or failed. We can select the scheduling type using > command line thanks to -s option: > > wimax-simple [-s scheduling_type] > the scheduling type can be: > 0 for SCHED_TYPE_SIMPLE > 1 for SCHED_TYPE_MBQOS > 2 for SCHED_TYPE_RTPS > > The default scheduler is SCHED_TYPE_SIMPLE (0) > > Wimax-ipv4 simulates a network of 3 couples of SSs exchanging ipv4 > datagrams over a single BS while wimax-multicast simulates a network > with 10 SSs receiving multicast ipv4 datagrams from a streamer > connected to the BS with CSMA. > > The output of wimax-ipv4 is as follows: > > TEST SS0 SS3.....OK > TEST SS1 SS4.....OK > TEST SS2 SS5.....OK > TEST.....OK > > > The output of wimax-multicast is as follows: > > TEST SS0.....OK > TEST SS1.....OK > TEST SS2.....OK > TEST SS3.....OK > TEST SS4.....OK > TEST SS5.....OK > TEST SS6.....OK > TEST SS7.....OK > TEST SS8.....OK > TEST SS9.....OK > TEST.....OK > > > - We need documentation for advanced features, Amine again can you > help managing that? > > There si a README file under src/devices/wimax which describes the > main features of the module. We can extend this by describing the new > features we have developed. I will add a paragraph for the new > physical layer. Giusseppe and Flavio could you please provide a > little description of the schedulers you have developed? > > > Best regards > Amine From amine.ismail at sophia.inria.fr Tue Aug 25 05:34:52 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Tue, 25 Aug 2009 14:34:52 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: <4A93CDA1.70308@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <4A93CDA1.70308@sophia.inria.fr> Message-ID: <4A93DA6C.3050804@sophia.inria.fr> Faker Moatamri wrote: > Ismail Amine wrote: >> Hi all, >> >> >- Moving files from scratch folder to appropriate folders -> amine >> Done! > Cool, thanks, though you need to be carefull because the version in > the repository doesn't compile due to the following error: Fixed! > > > [749/817] cxx: examples/wimax.cc -> build/debug/examples/wimax_39.o > cc1plus: warnings being treated as errors > ../examples/wimax-ipv4.cc: In function 'int main(int, char**)': > ../examples/wimax-ipv4.cc:115: warning: unused variable 'schedType' > [751/817] cxx: scratch/multiple-sources/simple-simulation.cc -> > build/debug/scratch/multiple-sources/simple-simulation_1.o > cc1plus: warnings being treated as errors > ../examples/wimax-multicast.cc: In function 'int main(int, char**)': > ../examples/wimax-multicast.cc:151: warning: unused variable 'schedType' > ../examples/wimax-multicast.cc:261: warning: unused variable > 'baseAddress' > Waf: Leaving directory > `/home/buildslave/slave/full-mimas-g++-4.2.4/build/build' > Build failed > -> task failed (err #1): {task: cxx wimax-ipv4.cc -> wimax-ipv4_37.o} > -> task failed (err #1): {task: cxx wimax-multicast.cc -> > wimax-multicast_38.o} > > >> >- Removing #include "../../...." from files -> amine >> Done! >> >- Adding validation tests-> Amine can you manage that with Flavio >> and Giuseppe? >> I have added 2 regression tests based on example scenarios. To >> execute these tests we should compile the module with "WIMAX_TEST" flag: >> CXXFLAGS="-DWIMAX_TEST" ./waf configure; ./waf >> >> The first test is wimax-ipv4 and the second one is wimax-simple under >> example repository. the 2 scripts output a test report reporting if >> the test was ok or failed. We can select the scheduling type using >> command line thanks to -s option: >> >> wimax-simple [-s scheduling_type] >> the scheduling type can be: >> 0 for SCHED_TYPE_SIMPLE >> 1 for SCHED_TYPE_MBQOS >> 2 for SCHED_TYPE_RTPS >> >> The default scheduler is SCHED_TYPE_SIMPLE (0) >> >> Wimax-ipv4 simulates a network of 3 couples of SSs exchanging ipv4 >> datagrams over a single BS while wimax-multicast simulates a network >> with 10 SSs receiving multicast ipv4 datagrams from a streamer >> connected to the BS with CSMA. >> >> The output of wimax-ipv4 is as follows: >> >> TEST SS0 SS3.....OK >> TEST SS1 SS4.....OK >> TEST SS2 SS5.....OK >> TEST.....OK >> >> >> The output of wimax-multicast is as follows: >> >> TEST SS0.....OK >> TEST SS1.....OK >> TEST SS2.....OK >> TEST SS3.....OK >> TEST SS4.....OK >> TEST SS5.....OK >> TEST SS6.....OK >> TEST SS7.....OK >> TEST SS8.....OK >> TEST SS9.....OK >> TEST.....OK >> >> > - We need documentation for advanced features, Amine again can you >> help managing that? >> >> There si a README file under src/devices/wimax which describes the >> main features of the module. We can extend this by describing the >> new features we have developed. I will add a paragraph for the new >> physical layer. Giusseppe and Flavio could you please provide a >> little description of the schedulers you have developed? >> >> >> Best regards >> Amine > From faker.moatamri at sophia.inria.fr Tue Aug 25 07:07:03 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 25 Aug 2009 16:07:03 +0200 Subject: [Ns-developers] Review application Message-ID: <4A93F007.3070106@sophia.inria.fr> Hi all, While applying the review comments on the code (http://codereview.appspot.com/75057/show), some comments I can't apply them and I need help specially for comments and I have some questions: Some comments will be welcome in those files (please refer to the review above): examples/my-simple-wimax.cc examples/simple-wimax.cc src/device/wimax/ipcs-bs-bind-parameter-record.h/cc src/device/wimax/ipcs-bs-packet-classifier.h/cc src/device/wimax/mac-2-mac.h/cc src/devices/wimax/crc8.cc We should also restructure the file README and update it accordingly, same thing for RELEASE_NOTES and src/devices/wimax/wimax-ofdm-phy/readme Those documentation issues can be done only by someone knowing the code very well, can you do it Amine? I have also some questions regarding the code: -file bandwidth manager.cc line 238, the variables rtpsAllocationPerFrame = 0, nrtpsAllocationPerFrame = 0, beAllocationPerFrame = 0; are set to 0 and never updated, so basically they don't add anything to the return value: uint32_t allocatedSymbols = ugsAllocationPerFrame + rtpsAllocationPerFrame + nrtpsAllocationPerFrame + beAllocationPerFrame; return allocatedSymbols; Only the value of ugsAllocationPerFrame is updated, the other values remain 0, can I remove those useless variables? -In connection identifier line 73, should we not compare the m_identifier like the above function? -simple-ofdm-wimax-phy.cc line 796 -> pages are indicated in the comments but it refers to what document? -ss-link-manager.cc lines 340 and 357: should there be some code? line 405 in AdjustRangingParameters: Temp is overwritten 3 times and the successful boolean never updated, I'm wondering if this function is useful/used? -wimax-bs-net-device.cc at EndFrame () you call StartFrame, is this normal? -In wimax-ss-net-device.cc there is a lot of new statements, are they deleted somewhere? Thanks Best regards Faker Moatamri From amine.ismail at sophia.inria.fr Tue Aug 25 07:57:02 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Tue, 25 Aug 2009 16:57:02 +0200 Subject: [Ns-developers] Review application In-Reply-To: <4A93F007.3070106@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> Message-ID: <4A93FBBE.10700@sophia.inria.fr> Faker Moatamri wrote: > Hi all, > While applying the review comments on the code > (http://codereview.appspot.com/75057/show), some comments I can't > apply them and I need help specially for comments and I have some > questions: > > Some comments will be welcome in those files (please refer to the > review above): > examples/my-simple-wimax.cc > examples/simple-wimax.cc > src/device/wimax/ipcs-bs-bind-parameter-record.h/cc > src/device/wimax/ipcs-bs-packet-classifier.h/cc > > src/device/wimax/mac-2-mac.h/cc > src/devices/wimax/crc8.cc > > > We should also restructure the file README and update it accordingly, > same thing for RELEASE_NOTES and src/devices/wimax/wimax-ofdm-phy/readme. > Those documentation issues can be done only by someone knowing the > code very well, can you do it Amine? OK > I have also some questions regarding the code: > > -file bandwidth manager.cc line 238, the variables > rtpsAllocationPerFrame = 0, nrtpsAllocationPerFrame = 0, > beAllocationPerFrame = 0; are set to 0 and never updated, so basically > they don't add anything to the return value: > uint32_t allocatedSymbols = ugsAllocationPerFrame + > rtpsAllocationPerFrame > + nrtpsAllocationPerFrame + beAllocationPerFrame; > return allocatedSymbols; > Only the value of ugsAllocationPerFrame is updated, the other values > remain 0, can I remove those useless variables? Faker, these files have been written by Tippu. I didn't go into implementation details but I think it's wiser not to change any thing we don't know how to test...unless you're sure > > -In connection identifier line 73, should we not compare the > m_identifier like the above function? It is the same thing since != operator will call == operator (return !(lhs == rhs)); > -simple-ofdm-wimax-phy.cc line 796 -> pages are indicated in the > comments but it refers to what document? IEEE standard for local and metropolitan area networks Part16: Air Interface for Fixed Broadband Wireless Access System (802.16-2004.pdf) > -ss-link-manager.cc lines 340 and 357: should there be some code? > line 405 in AdjustRangingParameters: > Temp is overwritten 3 times and the successful boolean never updated, > I'm wondering if this function is useful/used? Yes the code is incomplete! We have just the skeleton of the functions it 'is very important to keep it as it is > -wimax-bs-net-device.cc at EndFrame () you call StartFrame, is this > normal? Yes it is normal! when a frame ends a new one starts > -In wimax-ss-net-device.cc there is a lot of new statements, are they > deleted somewhere? Can you be more precise? > Thanks > Best regards > Faker Moatamri > > > From mathieu.lacage at sophia.inria.fr Tue Aug 25 11:53:14 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 25 Aug 2009 20:53:14 +0200 Subject: [Ns-developers] Review application In-Reply-To: <4A93FBBE.10700@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> Message-ID: <1251226394.2559.11.camel@localhost.localdomain> [trimming CC list] On Tue, 2009-08-25 at 16:57 +0200, Ismail Amine wrote: > > I have also some questions regarding the code: > > > > -file bandwidth manager.cc line 238, the variables > > rtpsAllocationPerFrame = 0, nrtpsAllocationPerFrame = 0, > > beAllocationPerFrame = 0; are set to 0 and never updated, so basically > > they don't add anything to the return value: > > uint32_t allocatedSymbols = ugsAllocationPerFrame + > > rtpsAllocationPerFrame > > + nrtpsAllocationPerFrame + beAllocationPerFrame; > > return allocatedSymbols; > > Only the value of ugsAllocationPerFrame is updated, the other values > > remain 0, can I remove those useless variables? > Faker, these files have been written by Tippu. I didn't go into > implementation details but I think it's wiser not to change any thing we > don't know how to test...unless you're sure If we have code without any tests, no maintainer, and it looks buggy, it should be killed (err, not merged so that we don't have to kill it later :). But maybe someone could try to track down tippu and ask him the question ? > > -In connection identifier line 73, should we not compare the > > m_identifier like the above function? > It is the same thing since != operator will call == operator (return > !(lhs == rhs)); > > -simple-ofdm-wimax-phy.cc line 796 -> pages are indicated in the > > comments but it refers to what document? > IEEE standard for local and metropolitan area networks Part16: Air > Interface for Fixed Broadband Wireless Access System (802.16-2004.pdf) That should be somewhat documented somewhere. Either in a global 'wimax documentation' or whenever a page number is referenced. > > -ss-link-manager.cc lines 340 and 357: should there be some code? > > line 405 in AdjustRangingParameters: > > Temp is overwritten 3 times and the successful boolean never updated, > > I'm wondering if this function is useful/used? > Yes the code is incomplete! We have just the skeleton of the functions > it 'is very important to keep it as it is That should be documented somewhere. > > -wimax-bs-net-device.cc at EndFrame () you call StartFrame, is this > > normal? > Yes it is normal! when a frame ends a new one starts > > -In wimax-ss-net-device.cc there is a lot of new statements, are they > > deleted somewhere? > Can you be more precise? Where are the delete statements which correspond to the new statements found in that function ? Are we leaking objects ? Mathieu From mathieu.lacage at sophia.inria.fr Tue Aug 25 11:54:45 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 25 Aug 2009 20:54:45 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: <4A93BC32.2060102@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> Message-ID: <1251226485.2559.16.camel@localhost.localdomain> On Tue, 2009-08-25 at 12:25 +0200, Ismail Amine wrote: > > - We need documentation for advanced features, Amine again can you > help managing that? > > There si a README file under src/devices/wimax which describes the main > features of the module. We can extend this by describing the new > features we have developed. I will add a paragraph for the new physical > layer. Giusseppe and Flavio could you please provide a little > description of the schedulers you have developed? That documentation should be doxygened. See src/devices/wifi/wifi.h or src/devices/csma/csma.h for an example of introduction documentation for a device. Mathieu From flaviokubota at gmail.com Tue Aug 25 12:06:37 2009 From: flaviokubota at gmail.com (Flavio Kubota) Date: Tue, 25 Aug 2009 16:06:37 -0300 Subject: [Ns-developers] Wimax status In-Reply-To: <1251226485.2559.16.camel@localhost.localdomain> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <1251226485.2559.16.camel@localhost.localdomain> Message-ID: Hi Mathieu, On Tue, Aug 25, 2009 at 3:54 PM, Mathieu Lacage < mathieu.lacage at sophia.inria.fr> wrote: > On Tue, 2009-08-25 at 12:25 +0200, Ismail Amine wrote: > > > > - We need documentation for advanced features, Amine again can you > > help managing that? > > > > There si a README file under src/devices/wimax which describes the main > > features of the module. We can extend this by describing the new > > features we have developed. I will add a paragraph for the new physical > > layer. Giusseppe and Flavio could you please provide a little > > description of the schedulers you have developed? > > That documentation should be doxygened. See src/devices/wifi/wifi.h or > src/devices/csma/csma.h for an example of introduction documentation for > a device. > I've started to add some doxygen comments at code. I started with wimax-helper.h and I intend to document the parts of code that I know. I can take a look at wifi.h, and if it is simple to convert README to a device documentation, it will be included in my patch. -- Flavio Kubota MSc Computer Science Student IC / UNICAMP From flaviokubota at gmail.com Tue Aug 25 17:45:33 2009 From: flaviokubota at gmail.com (Flavio Kubota) Date: Tue, 25 Aug 2009 21:45:33 -0300 Subject: [Ns-developers] Wimax status In-Reply-To: References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <1251226485.2559.16.camel@localhost.localdomain> Message-ID: Hi all, I've added some doxygen comments to wimax-helper, uplink-scheduler, uplink-scheduler-mbqos and I converted README file to doxygen format. The patch is attached. On Tue, Aug 25, 2009 at 4:06 PM, Flavio Kubota wrote: > Hi Mathieu, > > On Tue, Aug 25, 2009 at 3:54 PM, Mathieu Lacage < > mathieu.lacage at sophia.inria.fr> wrote: > >> On Tue, 2009-08-25 at 12:25 +0200, Ismail Amine wrote: >> >> > > - We need documentation for advanced features, Amine again can you >> > help managing that? >> > >> > There si a README file under src/devices/wimax which describes the main >> > features of the module. We can extend this by describing the new >> > features we have developed. I will add a paragraph for the new physical >> > layer. Giusseppe and Flavio could you please provide a little >> > description of the schedulers you have developed? >> >> That documentation should be doxygened. See src/devices/wifi/wifi.h or >> src/devices/csma/csma.h for an example of introduction documentation for >> a device. >> > I've started to add some doxygen comments at code. I started with > wimax-helper.h and I intend to document the parts of code that I know. > I can take a look at wifi.h, and if it is simple to convert README to a > device documentation, it will be included in my patch. > > -- > Flavio Kubota > MSc Computer Science Student > IC / UNICAMP > > -- Flavio Kubota MSc Computer Science Student IC / UNICAMP -------------- next part -------------- A non-text attachment was scrubbed... Name: WiMAX_comments.patch Type: text/x-patch Size: 32899 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090825/a7dde607/WiMAX_comments-0001.bin From faker.moatamri at sophia.inria.fr Wed Aug 26 01:05:36 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 26 Aug 2009 10:05:36 +0200 Subject: [Ns-developers] Review application In-Reply-To: <1251226394.2559.11.camel@localhost.localdomain> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> Message-ID: <4A94ECD0.5010402@sophia.inria.fr> Mathieu Lacage wrote: > [trimming CC list] > > On Tue, 2009-08-25 at 16:57 +0200, Ismail Amine wrote: > > >>> I have also some questions regarding the code: >>> >>> -file bandwidth manager.cc line 238, the variables >>> rtpsAllocationPerFrame = 0, nrtpsAllocationPerFrame = 0, >>> beAllocationPerFrame = 0; are set to 0 and never updated, so basically >>> they don't add anything to the return value: >>> uint32_t allocatedSymbols = ugsAllocationPerFrame + >>> rtpsAllocationPerFrame >>> + nrtpsAllocationPerFrame + beAllocationPerFrame; >>> return allocatedSymbols; >>> Only the value of ugsAllocationPerFrame is updated, the other values >>> remain 0, can I remove those useless variables? >>> >> Faker, these files have been written by Tippu. I didn't go into >> implementation details but I think it's wiser not to change any thing we >> don't know how to test...unless you're sure >> > > If we have code without any tests, no maintainer, and it looks buggy, it > should be killed (err, not merged so that we don't have to kill it > later :). But maybe someone could try to track down tippu and ask him > the question ? > > Actually this is not a bug but rather an non useful variables that have significant names for wimax people I guess, their only matter is that they are not updated, having an answer or a document about it would be cool. Does rtpsAllocationPerFrame, nrtpsAllocationPerFrame, beAllocationPerFrame mean something for Wimax experts? If they mean nothing then we will remove them but I think they should mean something. >>> -simple-ofdm-wimax-phy.cc line 796 -> pages are indicated in the >>> comments but it refers to what document? >>> >> IEEE standard for local and metropolitan area networks Part16: Air >> Interface for Fixed Broadband Wireless Access System (802.16-2004.pdf) >> > > That should be somewhat documented somewhere. Either in a global 'wimax > documentation' or whenever a page number is referenced. > > I agree, in some places in the code, there are reference to page numbers, without a reference to a document name or something like that. I would vote for a global address that will be referenced in whenever a page number is referenced. I would see it like this: // taken from pages 25 and 78 ([1] in README). >>> -ss-link-manager.cc lines 340 and 357: should there be some code? >>> line 405 in AdjustRangingParameters: >>> Temp is overwritten 3 times and the successful boolean never updated, >>> I'm wondering if this function is useful/used? >>> >> Yes the code is incomplete! We have just the skeleton of the functions >> it 'is very important to keep it as it is >> > > That should be documented somewhere. > > I definitely agree... >>> -wimax-bs-net-device.cc at EndFrame () you call StartFrame, is this >>> normal? >>> >> Yes it is normal! when a frame ends a new one starts >> Perfect, just checking :-) >>> -In wimax-ss-net-device.cc there is a lot of new statements, are they >>> deleted somewhere? >>> >> Can you be more precise? >> > > Where are the delete statements which correspond to the new statements > found in that function ? Are we leaking objects ? > > in the constructor: WimaxSubscriberStationNetDevice::WimaxSubscriberStationNetDevice (void) : ......., m_dlBurstProfile ( new OfdmDlBurstProfile ()), m_ulBurstProfile ( new OfdmUlBurstProfile ()), ..... { ..... m_classifier = new IpcsSSPacketclassifier (m_serviceFlowManager); m_linkManager = new SSLinkManager (this); m_scheduler = new SSScheduler (this); } The destructor is empty: WimaxSubscriberStationNetDevice::~WimaxSubscriberStationNetDevice (void) { } and we have the DoDispose function: void WimaxSubscriberStationNetDevice::DoDispose (void) { ... delete m_dlBurstProfile; delete m_ulBurstProfile; delete m_scheduler; delete m_linkManager; m_dlBurstProfile = 0; m_ulBurstProfile = 0; m_scheduler = 0; m_linkManager = 0; WimaxNetDevice::DoDispose (); } From what I see here we have the /m_classifier/ object that is never emptied unless it is deleted somewhere else. I know it's easy to fix if it is a bug but please verify that all the new statements are followed somewhere by a delete statement and that the objects created using is unreferenced somewhere after. > Mathieu > > Best regards Faker Moatamri From amine.ismail at sophia.inria.fr Wed Aug 26 02:06:22 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Wed, 26 Aug 2009 11:06:22 +0200 Subject: [Ns-developers] Review application In-Reply-To: <4A94ECD0.5010402@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> Message-ID: <4A94FB0E.9020500@sophia.inria.fr> Faker Moatamri wrote: > Mathieu Lacage wrote: >> [trimming CC list] >> >> On Tue, 2009-08-25 at 16:57 +0200, Ismail Amine wrote: >> >> >>>> I have also some questions regarding the code: >>>> >>>> -file bandwidth manager.cc line 238, the variables >>>> rtpsAllocationPerFrame = 0, nrtpsAllocationPerFrame = 0, >>>> beAllocationPerFrame = 0; are set to 0 and never updated, so >>>> basically they don't add anything to the return value: >>>> uint32_t allocatedSymbols = ugsAllocationPerFrame + >>>> rtpsAllocationPerFrame >>>> + nrtpsAllocationPerFrame + beAllocationPerFrame; >>>> return allocatedSymbols; >>>> Only the value of ugsAllocationPerFrame is updated, the other >>>> values remain 0, can I remove those useless variables? >>>> >>> Faker, these files have been written by Tippu. I didn't go into >>> implementation details but I think it's wiser not to change any >>> thing we don't know how to test...unless you're sure >>> >> >> If we have code without any tests, no maintainer, and it looks buggy, it >> should be killed (err, not merged so that we don't have to kill it Faker >> later :). But maybe someone could try to track down tippu and ask him >> the question ? >> >> > Actually this is not a bug but rather an non useful variables that > have significant names for wimax people I guess, their only matter is > that they are not updated, having an answer or a document about it > would be cool. Does rtpsAllocationPerFrame, nrtpsAllocationPerFrame, > beAllocationPerFrame mean something for Wimax experts? If they mean > nothing then we will remove them but I think they should mean something. > I had a look on the function BandwidthManager::GetSymbolsPerFrameAllocated (void), and I confirm that the variables rtpsAllocationPerFrame, nrtpsAllocationPerFrame, beAllocationPerFrame should be removed and the variable ugsAllocationPerFrame should be renamed allocationPerFrame. I will modify and include it in my next patch! >>>> -simple-ofdm-wimax-phy.cc line 796 -> pages are indicated in the >>>> comments but it refers to what document? >>>> >>> IEEE standard for local and metropolitan area networks Part16: Air >>> Interface for Fixed Broadband Wireless Access System (802.16-2004.pdf) >>> >> >> That should be somewhat documented somewhere. Either in a global 'wimax >> documentation' or whenever a page number is referenced. >> >> > I agree, in some places in the code, there are reference to page > numbers, without a reference to a document name or something like > that. I would vote for a global address that will be referenced in > whenever a page number is referenced. I would see it like this: // > taken from pages 25 and 78 ([1] in README). Faker, ok I definitely agree. can you manage that? >>>> -ss-link-manager.cc lines 340 and 357: should there be some code? >>>> line 405 in AdjustRangingParameters: >>>> Temp is overwritten 3 times and the successful boolean never >>>> updated, I'm wondering if this function is useful/used? >>>> >>> Yes the code is incomplete! We have just the skeleton of the >>> functions it 'is very important to keep it as it is >>> >> >> That should be documented somewhere. >> >> > I definitely agree... >>>> -wimax-bs-net-device.cc at EndFrame () you call StartFrame, is this >>>> normal? >>>> >>> Yes it is normal! when a frame ends a new one starts >>> > Perfect, just checking :-) >>>> -In wimax-ss-net-device.cc there is a lot of new statements, are >>>> they deleted somewhere? >>>> >>> Can you be more precise? >>> >> >> Where are the delete statements which correspond to the new statements >> found in that function ? Are we leaking objects ? >> >> > in the constructor: > WimaxSubscriberStationNetDevice::WimaxSubscriberStationNetDevice (void) : > ......., m_dlBurstProfile ( > new OfdmDlBurstProfile ()), m_ulBurstProfile ( > new OfdmUlBurstProfile ()), ..... > > { > ..... > m_classifier = new IpcsSSPacketclassifier (m_serviceFlowManager); > m_linkManager = new SSLinkManager (this); > m_scheduler = new SSScheduler (this); > } > The destructor is empty: > WimaxSubscriberStationNetDevice::~WimaxSubscriberStationNetDevice (void) > { > } > and we have the DoDispose function: > void > WimaxSubscriberStationNetDevice::DoDispose (void) > { > ... > delete m_dlBurstProfile; > delete m_ulBurstProfile; > delete m_scheduler; > delete m_linkManager; > m_dlBurstProfile = 0; > m_ulBurstProfile = 0; > m_scheduler = 0; > m_linkManager = 0; > > WimaxNetDevice::DoDispose (); > } > From what I see here we have the /m_classifier/ object that is never > emptied unless it is deleted somewhere else. I know it's easy to fix > if it is a bug but please verify that all the new statements are > followed somewhere by a delete statement and that the objects created > using is unreferenced somewhere after. I confirm that it is a bug, I will fix it for the next patch >> Mathieu >> >> > Best regards > Faker Moatamri Amine From faker.moatamri at sophia.inria.fr Wed Aug 26 02:08:50 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 26 Aug 2009 11:08:50 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <1251226485.2559.16.camel@localhost.localdomain> Message-ID: <4A94FBA2.1000207@sophia.inria.fr> Flavio Kubota wrote: > Hi all, > > I've added some doxygen comments to wimax-helper, uplink-scheduler, > uplink-scheduler-mbqos and I converted README file to doxygen format. > The patch is attached. > Thanks Flavio, you changes are uploaded to the server with a minor change, Amine, Flavio and Giuseppe, please update your local repository accordingly so that I don't have to reapply changes already applied. Best regards Faker Moatamri From amine.ismail at sophia.inria.fr Wed Aug 26 03:16:47 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Wed, 26 Aug 2009 12:16:47 +0200 Subject: [Ns-developers] WiMAX BUG 662 In-Reply-To: <4A94FBA2.1000207@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <1251226485.2559.16.camel@localhost.localdomain> <4A94FBA2.1000207@sophia.inria.fr> Message-ID: <4A950B8F.9000006@sophia.inria.fr> Hi Giuseppe, I'm not able to reproduce the bug 662! Can you provide more information? Which example have you executed and with which parameters ? Thank you Amine From faker.moatamri at sophia.inria.fr Wed Aug 26 04:24:11 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 26 Aug 2009 13:24:11 +0200 Subject: [Ns-developers] Review application In-Reply-To: <4A94FB0E.9020500@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> <4A94FB0E.9020500@sophia.inria.fr> Message-ID: <4A951B5B.6070505@sophia.inria.fr> Ismail Amine wrote: > Faker Moatamri wrote: >> Mathieu Lacage wrote: >>> [trimming CC list] >>> >>> On Tue, 2009-08-25 at 16:57 +0200, Ismail Amine wrote: >>> >>> >>>>> I have also some questions regarding the code: >>>>> >>>>> -file bandwidth manager.cc line 238, the variables >>>>> rtpsAllocationPerFrame = 0, nrtpsAllocationPerFrame = 0, >>>>> beAllocationPerFrame = 0; are set to 0 and never updated, so >>>>> basically they don't add anything to the return value: >>>>> uint32_t allocatedSymbols = ugsAllocationPerFrame + >>>>> rtpsAllocationPerFrame >>>>> + nrtpsAllocationPerFrame + beAllocationPerFrame; >>>>> return allocatedSymbols; >>>>> Only the value of ugsAllocationPerFrame is updated, the other >>>>> values remain 0, can I remove those useless variables? >>>>> >>>> Faker, these files have been written by Tippu. I didn't go into >>>> implementation details but I think it's wiser not to change any >>>> thing we don't know how to test...unless you're sure >>>> >>> >>> If we have code without any tests, no maintainer, and it looks >>> buggy, it >>> should be killed (err, not merged so that we don't have to kill it >>> Faker >>> later :). But maybe someone could try to track down tippu and ask him >>> the question ? >>> >>> >> Actually this is not a bug but rather an non useful variables that >> have significant names for wimax people I guess, their only matter is >> that they are not updated, having an answer or a document about it >> would be cool. Does rtpsAllocationPerFrame, nrtpsAllocationPerFrame, >> beAllocationPerFrame mean something for Wimax experts? If they mean >> nothing then we will remove them but I think they should mean something. >> > > I had a look on the function > BandwidthManager::GetSymbolsPerFrameAllocated (void), and I confirm > that the variables rtpsAllocationPerFrame, nrtpsAllocationPerFrame, > beAllocationPerFrame should be removed and the variable > ugsAllocationPerFrame should be renamed allocationPerFrame. I will > modify and include it in my next patch! Ok >>>>> -simple-ofdm-wimax-phy.cc line 796 -> pages are indicated in the >>>>> comments but it refers to what document? >>>>> >>>> IEEE standard for local and metropolitan area networks Part16: Air >>>> Interface for Fixed Broadband Wireless Access System (802.16-2004.pdf) >>>> >>> >>> That should be somewhat documented somewhere. Either in a global 'wimax >>> documentation' or whenever a page number is referenced. >>> >>> >> I agree, in some places in the code, there are reference to page >> numbers, without a reference to a document name or something like >> that. I would vote for a global address that will be referenced in >> whenever a page number is referenced. I would see it like this: // >> taken from pages 25 and 78 ([1] in README). > Faker, ok I definitely agree. can you manage that? I can't manage that, since you guys are adding the documentation and updating files. >>>>> -ss-link-manager.cc lines 340 and 357: should there be some code? >>>>> line 405 in AdjustRangingParameters: >>>>> Temp is overwritten 3 times and the successful boolean never >>>>> updated, I'm wondering if this function is useful/used? >>>>> >>>> Yes the code is incomplete! We have just the skeleton of the >>>> functions it 'is very important to keep it as it is >>>> >>> >>> That should be documented somewhere. >>> >>> >> I definitely agree... >> >>>>> -In wimax-ss-net-device.cc there is a lot of new statements, are >>>>> they deleted somewhere? >>>>> >>>> Can you be more precise? >>>> >>> >>> Where are the delete statements which correspond to the new statements >>> found in that function ? Are we leaking objects ? >>> >>> >> in the constructor: >> WimaxSubscriberStationNetDevice::WimaxSubscriberStationNetDevice >> (void) : >> ......., m_dlBurstProfile ( >> new OfdmDlBurstProfile ()), m_ulBurstProfile ( >> new OfdmUlBurstProfile ()), ..... >> >> { >> ..... >> m_classifier = new IpcsSSPacketclassifier (m_serviceFlowManager); >> m_linkManager = new SSLinkManager (this); >> m_scheduler = new SSScheduler (this); >> } >> The destructor is empty: >> WimaxSubscriberStationNetDevice::~WimaxSubscriberStationNetDevice (void) >> { >> } >> and we have the DoDispose function: >> void >> WimaxSubscriberStationNetDevice::DoDispose (void) >> { >> ... >> delete m_dlBurstProfile; >> delete m_ulBurstProfile; >> delete m_scheduler; >> delete m_linkManager; >> m_dlBurstProfile = 0; >> m_ulBurstProfile = 0; >> m_scheduler = 0; >> m_linkManager = 0; >> >> WimaxNetDevice::DoDispose (); >> } >> From what I see here we have the /m_classifier/ object that is never >> emptied unless it is deleted somewhere else. I know it's easy to fix >> if it is a bug but please verify that all the new statements are >> followed somewhere by a delete statement and that the objects created >> using is unreferenced somewhere after. > > I confirm that it is a bug, I will fix it for the next patch > Ok cool >>> Mathieu >>> >>> >> Best regards >> Faker Moatamri > > Amine > > Please remember that your patches should be atomic and based on http://code.nsnam.org/fmoatamr/ns-3-wimax-release/ Giuseppe, Amine, any new documentation/addition/patch? Flavio thanks again for the doxygen, have you been through the code review : http://codereview.appspot.com/107047/show? Thanks Best regards Faker Moatamri From peppe.piro at gmail.com Wed Aug 26 04:18:03 2009 From: peppe.piro at gmail.com (Giuseppe Piro) Date: Wed, 26 Aug 2009 13:18:03 +0200 Subject: [Ns-developers] WiMAX BUG 662 In-Reply-To: <4A950B8F.9000006@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <1251226485.2559.16.camel@localhost.localdomain> <4A94FBA2.1000207@sophia.inria.fr> <4A950B8F.9000006@sophia.inria.fr> Message-ID: <4365bdc50908260418n2c929d23yff556058959ec2ed@mail.gmail.com> Hi Amine, you can reproduce the bug 662 applying the patch (attached on this mail) to http://code.nsnam.org/fmoatamr/ns-3-wimax-release/ . ./wa 2009/8/26 Ismail Amine > Hi Giuseppe, > > I'm not able to reproduce the bug 662! Can you provide more information? > Which example have you executed and with which parameters ? > > Thank you > Amine > > > -- Giuseppe Piro Ph.D. Student DEE - Politecnico di Bari v. Orabona 4, 70125 - Bari, Italy e-mail: g.piro at poliba.it peppe.piro at gmail.com Phone: +39 0805963301 Web: http://telematics.poliba.it/piro From peppe.piro at gmail.com Wed Aug 26 04:22:26 2009 From: peppe.piro at gmail.com (Giuseppe Piro) Date: Wed, 26 Aug 2009 13:22:26 +0200 Subject: [Ns-developers] WiMAX BUG 662 In-Reply-To: <4365bdc50908260418o5a8d137dtbb8eda277cfc47f3@mail.gmail.com> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <1251226485.2559.16.camel@localhost.localdomain> <4A94FBA2.1000207@sophia.inria.fr> <4A950B8F.9000006@sophia.inria.fr> <4365bdc50908260418n2c929d23yff556058959ec2ed@mail.gmail.com> <4365bdc50908260418o5a8d137dtbb8eda277cfc47f3@mail.gmail.com> Message-ID: <4365bdc50908260422n6c7b97afu731ed87fa6a1cd25@mail.gmail.com> Hi guys, sorry for this mails.... I have some problems with my keyboard. Hi Amine, you can reproduce the bug 662 applying the patch (attached on this mail) to http://code.nsnam.org/fmoatamr/ns-3-wimax-release/ please, run ./waf --run scratch/wimax-ipv4 Giuseppe 2009/8/26 Ismail Amine >> >> Hi Giuseppe, >>> >>> I'm not able to reproduce the bug 662! Can you provide more information? >>> Which example have you executed and with which parameters ? >>> >>> Thank you >>> Amine >>> >>> >>> >> >> >> -- >> Giuseppe Piro >> Ph.D. Student >> DEE - Politecnico di Bari >> v. Orabona 4, 70125 - Bari, Italy >> e-mail: g.piro at poliba.it >> peppe.piro at gmail.com >> Phone: +39 0805963301 >> Web: http://telematics.poliba.it/piro >> > > > > -- > Giuseppe Piro > Ph.D. Student > DEE - Politecnico di Bari > v. Orabona 4, 70125 - Bari, Italy > e-mail: g.piro at poliba.it > peppe.piro at gmail.com > Phone: +39 0805963301 > Web: http://telematics.poliba.it/piro > -- Giuseppe Piro Ph.D. Student DEE - Politecnico di Bari v. Orabona 4, 70125 - Bari, Italy e-mail: g.piro at poliba.it peppe.piro at gmail.com Phone: +39 0805963301 Web: http://telematics.poliba.it/piro -------------- next part -------------- A non-text attachment was scrubbed... Name: debug-662.patch Type: text/x-patch Size: 8766 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090826/d2dafc87/debug-662.bin From vincent at clarinet.u-strasbg.fr Thu Aug 27 00:47:03 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Thu, 27 Aug 2009 09:47:03 +0200 Subject: [Ns-developers] NetDevice link change callback In-Reply-To: <4A850F97.5020505@clarinet.u-strasbg.fr> References: <4A6DC6FA.2040602@clarinet.u-strasbg.fr> <4A6E2033.6060700@tomh.org> <1248773029.8162.8.camel@localhost.localdomain> <87e5008df199e72b24526a238b4e9221@tomh.org> <1249627230.3385.11.camel@diese.inria.fr> <4A7C2ECB.7090100@tomh.org> <4A850F97.5020505@clarinet.u-strasbg.fr> Message-ID: <4A9639F7.8060805@clarinet.u-strasbg.fr> Hi, I modified patch (http://www.nsnam.org/bugzilla/attachment.cgi?id=570) to just use TracedCallback (no typedef to ListCallback) in *-net-device files. Comments about this ? Is it OK to apply ? Regards, -- Sebastien Sebastien Vincent a ?crit : > Tom Henderson a ?crit : >> Mathieu Lacage wrote: >>> On Thu, 2009-08-06 at 15:50 -0600, Tom Henderson wrote: >>> >>>>>> 1) use of TracedCallback? >>>>>> Another option is to use a TracedCallback here, which some other >>>>>> developers have recommended in the past to use when there needs >>>>>> to be a list of callbacks. >>>>>> >>>>>> I don't have a strong opinion but this question keeps popping up >>>>>> (also in Qasim's conntrack code) so I think we should clarify >>>>>> whether TracedCallback should also be used in non-tracing >>>>>> scenarios whenever you >>>>>> want a std::list of callbacks, or whether we want another general >>>>>> CallbackList of some sort that is not used by tracing code. >>>>> I think that all you would need to make TracedCallback generic is >>>>> change >>>>> its name to something which does not include 'Trace'. i.e., its >>>>> API and >>>>> implementation has no dependency on the tracing code. >>>> Maybe what would be best is to add something like the CallbackList >>>> suggested but allow user to optionally specify order or priority of >>>> callbacks-- if no priority is specified, they all get priority 0 >>>> and it >>>> behaves like TracedCallback. >>> >>> It's not clear to me what this priority would be used for. Do you >>> have a >>> specific usecase in mind ? >> >> iptables (chains of ordered rules) >> >> If not, I would support simply renaming >>> TracedCallback to NotifierCallback or something similar (better >>> suggestions for a name would be welcome) and typedef >>> NotifierCallback to >>> TracedCallback to avoid changing our existing codebase. >> >> I don't care strongly; ListCallback conveys the list semantics. >> >>> >>>>>> 2) should we report link change, or link up? >>>>>> The method name is not really suggestive of how the callback >>>>>> works, which does not call when the link changes in all cases but >>>>>> only when the >>>>>> link goes to up. So, I would suggest either "AddLinkUpCallback" >>>>>> or "SetLinkChangeCallback" with an extra argument such as an enum >>>>>> for Up or >>>>>> Down. >>>>> The current implementation reports link change events, not link up >>>>> events. i.e., see src/devices/wifi/wifi-net-devices.cc. The >>>>> current API >>>>> documentation in src/node/net-device.h should be improved instead of >>>>> changing the method name I think. >>>> Only WifiNetDevice reports all link changes, but you can't tell >>>> from the >>>> callback what type of event it was. The other devices >>>> (PointToPoint, Csma, >>> >>> IsLinkUp is expected to be used from within the notification >>> callback to >>> query the state of the link. That was the original intend of the device >>> API design. >>> >>>> Emu) just call it upon going up, perhaps because they can't go down >>>> (it is >>>> really only used at node startup time). >>> >>> Yes, none of them can go down which is why they never report link down >>> events. >>> >>> Anyway, to summarize, I see no real need to change this API since it >>> provides the needed functionality. What is needed is improving the >>> doxygen which does not align with the intend of the original design. >> >> Can you clarify-- are you objecting to AddLinkChangeCallback as >> Sebastien suggested, or changing other aspects as I later suggested >> (such as changing the name or the arguments of the callback)? >> >> I am OK with what you suggest about using the API as you originally >> intended with IsLinkUp(), and fixing the doxygen, but it seems like >> Sebastien has a valid use case to make this a TracedCallback. >> > > > I made a small update on the patch on bugzilla > (http://www.nsnam.org/bugzilla/show_bug.cgi?id=653) to use > ListCallback (typedef from TracedCallback) in NetDevice. > > Regards, > -- > Sebastien > > >>> >>>>>> I think others have raised the question "can I put a NetDevice >>>>>> into down >>>>>> state?" and presently the answer is no, but in practice, IFF_UP >>>>>> flag of a netdevice is settable, and it seems like we might want >>>>>> to add the capability to configure an interface to down state, >>>>>> which would trigger upcalls to both Ipv4 and Ipv6 stacks (and to >>>>>> the routing protocols). >>>>> What would be the expected semantics of that flag exactly ? Would you >>>>> expect the NetDevice subclasses to honor calling SetIfDown by >>>>> ignoring >>>>> packets being passed down with NetDevice::Send* ? >>>>> >>>> Yes. I would try to match it to what happens in a real system when >>>> "ifconfig eth0 down" is called. Note that this typically will trigger >>>> upcalls or netlink notifications, which cause the upper layer to >>>> refrain >>>> from sending packets down to it when it is in a down state. >>> >>> I think that it would be nice if adding such a flag would not require >>> adding extra send/receive logic to net device implementations but I >>> could live with it. >>> >> I think the burden here will be requiring netdevice users to register >> for the link change callback and process it; I don't think adding the >> extra NetDevice logic (shunt packets to a drop trace if the device is >> down) will be too difficult. >> >> Tom >> > > From faker.moatamri at sophia.inria.fr Thu Aug 27 02:57:01 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 27 Aug 2009 11:57:01 +0200 Subject: [Ns-developers] Wimax status update Message-ID: <4A96586D.8060903@sophia.inria.fr> Hi all, As of today we will begin the integration of the wimax module with the latest version of ns-3-dev. We aim to merge Wimax module with ns-3-dev and to provide a patch based on ns-3-dev on tuesday september 1st. If you have any patch for WiMax module please make sure that it is compatible with the latest version of http://code.nsnam.org/fmoatamr/ns-3-wimax-release/ Thanks Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Thu Aug 27 02:59:33 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 27 Aug 2009 11:59:33 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: <4A93BC32.2060102@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> Message-ID: <4A965905.30706@sophia.inria.fr> Ismail Amine wrote: > Hi all, > > >- Moving files from scratch folder to appropriate folders -> amine > Done! > >- Removing #include "../../...." from files -> amine > Done! > >- Adding validation tests-> Amine can you manage that with Flavio and > Giuseppe? > I have added 2 regression tests based on example scenarios. To execute > these tests we should compile the module with "WIMAX_TEST" flag: > CXXFLAGS="-DWIMAX_TEST" ./waf configure; ./waf > > The first test is wimax-ipv4 and the second one is wimax-simple under > example repository. the 2 scripts output a test report reporting if > the test was ok or failed. We can select the scheduling type using > command line thanks to -s option: > > wimax-simple [-s scheduling_type] > the scheduling type can be: > 0 for SCHED_TYPE_SIMPLE > 1 for SCHED_TYPE_MBQOS > 2 for SCHED_TYPE_RTPS > > The default scheduler is SCHED_TYPE_SIMPLE (0) > > Wimax-ipv4 simulates a network of 3 couples of SSs exchanging ipv4 > datagrams over a single BS while wimax-multicast simulates a network > with 10 SSs receiving multicast ipv4 datagrams from a streamer > connected to the BS with CSMA. > what are the inputs of these programs to get the following output? > The output of wimax-ipv4 is as follows: > > TEST SS0 SS3.....OK > TEST SS1 SS4.....OK > TEST SS2 SS5.....OK > TEST.....OK > > > The output of wimax-multicast is as follows: > > TEST SS0.....OK > TEST SS1.....OK > TEST SS2.....OK > TEST SS3.....OK > TEST SS4.....OK > TEST SS5.....OK > TEST SS6.....OK > TEST SS7.....OK > TEST SS8.....OK > TEST SS9.....OK > TEST.....OK > > > - We need documentation for advanced features, Amine again can you > help managing that? > > There si a README file under src/devices/wimax which describes the > main features of the module. We can extend this by describing the new > features we have developed. I will add a paragraph for the new > physical layer. Giusseppe and Flavio could you please provide a > little description of the schedulers you have developed? > > > Best regards > Amine Thanks Best regards Faker Moatamri From amine.ismail at sophia.inria.fr Fri Aug 28 00:41:47 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Fri, 28 Aug 2009 09:41:47 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: <4A965905.30706@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <4A965905.30706@sophia.inria.fr> Message-ID: <4A978A3B.2000701@sophia.inria.fr> Faker Moatamri wrote: > Ismail Amine wrote: >> > what are the inputs of these programs to get the following output? Just compile ns-3 module using WIMAX_TEST flag, run the example without any arguments...and wait >> The output of wimax-ipv4 is as follows: >> >> TEST SS0 SS3.....OK >> TEST SS1 SS4.....OK >> TEST SS2 SS5.....OK >> TEST.....OK >> >> >> The output of wimax-multicast is as follows: >> >> TEST SS0.....OK >> TEST SS1.....OK >> TEST SS2.....OK >> TEST SS3.....OK >> TEST SS4.....OK >> TEST SS5.....OK >> TEST SS6.....OK >> TEST SS7.....OK >> TEST SS8.....OK >> TEST SS9.....OK >> TEST.....OK >> >> > - We need documentation for advanced features, Amine again can you >> help managing that? >> >> There si a README file under src/devices/wimax which describes the >> main features of the module. We can extend this by describing the >> new features we have developed. I will add a paragraph for the new >> physical layer. Giusseppe and Flavio could you please provide a >> little description of the schedulers you have developed? >> >> >> Best regards >> Amine > Thanks > Best regards > Faker Moatamri > From faker.moatamri at sophia.inria.fr Fri Aug 28 02:40:49 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 28 Aug 2009 11:40:49 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: <4A978A3B.2000701@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <4A965905.30706@sophia.inria.fr> <4A978A3B.2000701@sophia.inria.fr> Message-ID: <4A97A621.8050902@sophia.inria.fr> Ismail Amine wrote: > Faker Moatamri wrote: >> Ismail Amine wrote: >>> >> what are the inputs of these programs to get the following output? > Just compile ns-3 module using WIMAX_TEST flag, run the example > without any arguments...and wait > I downloaded from your repository and the result is attached in this file and it finishes by a segmentation fault. Please note that hardcoding paths like in simple-ofdm-wimax-phy.cc (/m_snrToBlockErrorRateManager->SetTraceFilePath ( (char*) "/home/iamine/Desktop/PHD/workspace/ns-3-wimax-dev/build/debug/examples/SNRtoErrorTraces");/) is not portable and will lead to: Unable to load /home/iamine/Desktop/PHD/workspace/ns-3-wimax-dev/build/debug/examples/SNRtoErrorTraces/Modulation0.txt same thing in trace-based-streamer.cc: /strcpy (m_traceFile, "/home/iamine/Desktop/Terse_Jurassic_MPEG4_HD.dat"); /Same problem in wimax-multicast.cc, path is hardcoded. Those files must be changed, you can use relative paths instead. Please note also that when merged with ns-3-dev, wimax-simple and wimax-ipv4 just output the unable to load ... (after I changed to a local path) and then outputs segmentation fault without outputting anything else. The merged code is uploaded to my repository http://code.nsnam.org/fmoatamr/ns-3-wimax-release. This repository contains wimax merged with revision 4740:34acfd7ad508 of ns-3-dev. Thanks Best regards Faker Moatamri -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wimax-simple.output Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20090828/9a83febc/wimax-simple-0001.ksh From amine.ismail at sophia.inria.fr Fri Aug 28 02:59:46 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Fri, 28 Aug 2009 11:59:46 +0200 Subject: [Ns-developers] Wimax status In-Reply-To: <4A97A621.8050902@sophia.inria.fr> References: <4A929977.1090604@sophia.inria.fr> <4A93BC32.2060102@sophia.inria.fr> <4A965905.30706@sophia.inria.fr> <4A978A3B.2000701@sophia.inria.fr> <4A97A621.8050902@sophia.inria.fr> Message-ID: <4A97AA92.30006@sophia.inria.fr> Faker, Please find attached a patch adding doxygene code to several files Faker Moatamri wrote: > Ismail Amine wrote: >> Faker Moatamri wrote: >>> Ismail Amine wrote: >>>> >>> what are the inputs of these programs to get the following output? >> Just compile ns-3 module using WIMAX_TEST flag, run the example >> without any arguments...and wait >> > I downloaded from your repository and the result is attached in this > file and it finishes by a segmentation fault. Please note that > hardcoding paths like in simple-ofdm-wimax-phy.cc > (/m_snrToBlockErrorRateManager->SetTraceFilePath ( (char*) > "/home/iamine/Desktop/PHD/workspace/ns-3-wimax-dev/build/debug/examples/SNRtoErrorTraces");/) > is not portable and will lead to: > Unable to load > /home/iamine/Desktop/PHD/workspace/ns-3-wimax-dev/build/debug/examples/SNRtoErrorTraces/Modulation0.txt > > same thing in trace-based-streamer.cc: > /strcpy (m_traceFile, > "/home/iamine/Desktop/Terse_Jurassic_MPEG4_HD.dat"); > /Same problem in wimax-multicast.cc, path is hardcoded. > Those files must be changed, you can use relative paths instead. > Please note also that when merged with ns-3-dev, wimax-simple and > wimax-ipv4 just output the unable to load ... (after I changed to a > local path) and then outputs segmentation fault without outputting > anything else. > The merged code is uploaded to my repository > http://code.nsnam.org/fmoatamr/ns-3-wimax-release. This repository > contains wimax merged with revision 4740:34acfd7ad508 of ns-3-dev. > Thanks > Best regards > Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: doxygen.patch Type: text/x-patch Size: 7749 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090828/6b0614b7/doxygen.bin From faker.moatamri at sophia.inria.fr Fri Aug 28 03:17:31 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 28 Aug 2009 12:17:31 +0200 Subject: [Ns-developers] Review application In-Reply-To: <4A94FB0E.9020500@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> <4A94FB0E.9020500@sophia.inria.fr> Message-ID: <4A97AEBB.8080807@sophia.inria.fr> Ismail Amine wrote: > Faker Moatamri wrote: >> Mathieu Lacage wrote: >>> [trimming CC list] >>> >>> On Tue, 2009-08-25 at 16:57 +0200, Ismail Amine wrote: >>> >>> >>>>> I have also some questions regarding the code: >>>>> >>>>> -file bandwidth manager.cc line 238, the variables >>>>> rtpsAllocationPerFrame = 0, nrtpsAllocationPerFrame = 0, >>>>> beAllocationPerFrame = 0; are set to 0 and never updated, so >>>>> basically they don't add anything to the return value: >>>>> uint32_t allocatedSymbols = ugsAllocationPerFrame + >>>>> rtpsAllocationPerFrame >>>>> + nrtpsAllocationPerFrame + beAllocationPerFrame; >>>>> return allocatedSymbols; >>>>> Only the value of ugsAllocationPerFrame is updated, the other >>>>> values remain 0, can I remove those useless variables? >>>>> >>>> Faker, these files have been written by Tippu. I didn't go into >>>> implementation details but I think it's wiser not to change any >>>> thing we don't know how to test...unless you're sure >>>> >>> >>> If we have code without any tests, no maintainer, and it looks >>> buggy, it >>> should be killed (err, not merged so that we don't have to kill it >>> Faker >>> later :). But maybe someone could try to track down tippu and ask him >>> the question ? >>> >>> >> Actually this is not a bug but rather an non useful variables that >> have significant names for wimax people I guess, their only matter is >> that they are not updated, having an answer or a document about it >> would be cool. Does rtpsAllocationPerFrame, nrtpsAllocationPerFrame, >> beAllocationPerFrame mean something for Wimax experts? If they mean >> nothing then we will remove them but I think they should mean something. >> > > I had a look on the function > BandwidthManager::GetSymbolsPerFrameAllocated (void), and I confirm > that the variables rtpsAllocationPerFrame, nrtpsAllocationPerFrame, > beAllocationPerFrame should be removed and the variable > ugsAllocationPerFrame should be renamed allocationPerFrame. I will > modify and include it in my next patch! Done >> -In wimax-ss-net-device.cc there is a lot of new statements, are they >> deleted somewhere? >>>>> >>>> Can you be more precise? >>>> >>> >>> Where are the delete statements which correspond to the new statements >>> found in that function ? Are we leaking objects ? >>> >>> >> in the constructor: >> WimaxSubscriberStationNetDevice::WimaxSubscriberStationNetDevice >> (void) : >> ......., m_dlBurstProfile ( >> new OfdmDlBurstProfile ()), m_ulBurstProfile ( >> new OfdmUlBurstProfile ()), ..... >> >> { >> ..... >> m_classifier = new IpcsSSPacketclassifier (m_serviceFlowManager); >> m_linkManager = new SSLinkManager (this); >> m_scheduler = new SSScheduler (this); >> } >> The destructor is empty: >> WimaxSubscriberStationNetDevice::~WimaxSubscriberStationNetDevice (void) >> { >> } >> and we have the DoDispose function: >> void >> WimaxSubscriberStationNetDevice::DoDispose (void) >> { >> ... >> delete m_dlBurstProfile; >> delete m_ulBurstProfile; >> delete m_scheduler; >> delete m_linkManager; >> m_dlBurstProfile = 0; >> m_ulBurstProfile = 0; >> m_scheduler = 0; >> m_linkManager = 0; >> >> WimaxNetDevice::DoDispose (); >> } >> From what I see here we have the /m_classifier/ object that is never >> emptied unless it is deleted somewhere else. I know it's easy to fix >> if it is a bug but please verify that all the new statements are >> followed somewhere by a delete statement and that the objects created >> using is unreferenced somewhere after. > > I confirm that it is a bug, I will fix it for the next patch done From gjcarneiro at gmail.com Fri Aug 28 04:30:48 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 28 Aug 2009 12:30:48 +0100 Subject: [Ns-developers] Updating Python bindings in ns-3-dev Message-ID: While trying to update Python bindings to use newer PyBindGen and rescan API definitions, I noticed they didn't compile. Besides the usual couple of methods declared but not implemented, some now private header files need to be made public. Public classes' destructors will try to invoke destructor of contained objects and compilation fails if those objects have incomplete types. Any objections to this patch? -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- A non-text attachment was scrubbed... Name: ns3.diff Type: text/x-diff Size: 2192 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090828/97c2396d/ns3.bin From mathieu.lacage at sophia.inria.fr Fri Aug 28 05:46:49 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 28 Aug 2009 05:46:49 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200908281246.n7SCknti032631@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/134 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_4 shell_5 shell_7 shell_8 shell_9 shell_11 shell_12 shell_13 sincerely, -The Buildbot From Faker.Moatamri at sophia.inria.fr Fri Aug 28 06:01:02 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Fri, 28 Aug 2009 15:01:02 +0200 (CEST) Subject: [Ns-developers] Buildbot Message-ID: <49867.217.128.71.243.1251464462.squirrel@imap-sop.inria.fr> Hi all, I put buildbot up on ns-regression, the address to view the building status is: http://ns-regression.ee.washington.edu:8010/ It reports an error when compiling with cygwin: [576/727] cxx: src/helper/athstats-helper.cc -> build/debug/src/helper/athstats-helper_1.o cc1plus: warnings being treated as errors ../src/helper/athstats-helper.cc: In member function 'void ns3::AthstatsWifiTraceSink::WriteStats()': ../src/helper/athstats-helper.cc:292: error: format '%8u' expects type 'unsigned int', but argument 4 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%8u' expects type 'unsigned int', but argument 5 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%7u' expects type 'unsigned int', but argument 7 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%7u' expects type 'unsigned int', but argument 8 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%6u' expects type 'unsigned int', but argument 9 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%6u' expects type 'unsigned int', but argument 10 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%8u' expects type 'unsigned int', but argument 4 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%8u' expects type 'unsigned int', but argument 5 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%7u' expects type 'unsigned int', but argument 7 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%7u' expects type 'unsigned int', but argument 8 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%6u' expects type 'unsigned int', but argument 9 has type 'uint32_t' ../src/helper/athstats-helper.cc:292: error: format '%6u' expects type 'unsigned int', but argument 10 has type 'uint32_t' Waf: Leaving directory `/home/mathieu/buildslave/full-cygwin-g++/build/build' Build failed -> task failed (err #1): {task: cxx athstats-helper.cc -> athstats-helper_1.o} program finished with exit code 1 Best regards Faker Moatamri From tomh at tomh.org Fri Aug 28 06:54:58 2009 From: tomh at tomh.org (Tom Henderson) Date: Fri, 28 Aug 2009 06:54:58 -0700 Subject: [Ns-developers] Updating Python bindings in ns-3-dev In-Reply-To: References: Message-ID: <4A97E1B2.3060308@tomh.org> Gustavo Carneiro wrote: > While trying to update Python bindings to use newer PyBindGen and rescan API > definitions, I noticed they didn't compile. Besides the usual couple of > methods declared but not implemented, some now private header files need to > be made public. Public classes' destructors will try to invoke destructor > of contained objects and compilation fails if those objects have incomplete > types. > > Any objections to this patch? > > This patch and Mathieu's previous one is inconsistent about which impl classes need to be exported and which ones can stay private, which makes me wonder whether there is further cleanup or alignment needed. For instance, tcp-socket-impl.h and nsc-tcp-socket-impl.h but not udp-socket-impl.h. Also, the IPv4 implementation headers are largely exported but the IPv6 headers are not. Mathieu didn't comment on why he needed these extra v4 headers exposed. Do you have an idea, however, why tcp-socket-impl.h needs to be public now but udp-socket-impl.h doesn't? - Tom From gjcarneiro at gmail.com Fri Aug 28 07:47:10 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 28 Aug 2009 15:47:10 +0100 Subject: [Ns-developers] Updating Python bindings in ns-3-dev In-Reply-To: <4A97E1B2.3060308@tomh.org> References: <4A97E1B2.3060308@tomh.org> Message-ID: 2009/8/28 Tom Henderson > Gustavo Carneiro wrote: > >> While trying to update Python bindings to use newer PyBindGen and rescan >> API >> definitions, I noticed they didn't compile. Besides the usual couple of >> methods declared but not implemented, some now private header files need >> to >> be made public. Public classes' destructors will try to invoke destructor >> of contained objects and compilation fails if those objects have >> incomplete >> types. >> >> Any objections to this patch? >> >> >> > This patch and Mathieu's previous one is inconsistent about which impl > classes need to be exported and which ones can stay private, which makes me > wonder whether there is further cleanup or alignment needed. For instance, > tcp-socket-impl.h and nsc-tcp-socket-impl.h but not udp-socket-impl.h. > Also, the IPv4 implementation headers are largely exported but the IPv6 > headers are not. > > Mathieu didn't comment on why he needed these extra v4 headers exposed. Do > you have an idea, however, why tcp-socket-impl.h needs to be public now but > udp-socket-impl.h doesn't? tcp-socket-impl.h needs to be public because class TcpL4Protocol contains a member: std::vector > m_sockets; I am not sure yet exactly what, but something in the pybindgen-generated code triggers an "incomplete type" error (see attached log file), which goes away when the bindings are allowed to include the -impl header. My best guess is just that when a class has a member attribute with pointer to an incomplete type, the error will occur under certain situations. I do not fully understand why code manipulating incomplete types work sometimes and sometimes not. But neither do I have any other proposed solution. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 8461 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090828/adb4e9a6/log.obj From amine.ismail at sophia.inria.fr Fri Aug 28 07:49:52 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Fri, 28 Aug 2009 16:49:52 +0200 Subject: [Ns-developers] Review application In-Reply-To: <4A97AEBB.8080807@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> <4A94FB0E.9020500@sophia.inria.fr> <4A97AEBB.8080807@sophia.inria.fr> Message-ID: <4A97EE90.7010500@sophia.inria.fr> Faker, A regression was introduced in the code, I'm no longer able to execute the wimax-ipv4 example,,,it exits with a core dump!! the same thing happens also for wimax-multicast. We sould execute at least the 2 tests I described in a previous mail and check that they output OK before uploading a new version in the mercurial repository. Thank you Best regards Amine Faker Moatamri wrote: > Ismail Amine wrote: >> Faker Moatamri wrote: >>> Mathieu Lacage wrote: >>>> [trimming CC list] >>>> >>>> On Tue, 2009-08-25 at 16:57 +0200, Ismail Amine wrote: >>>> >>>> >>>>>> I have also some questions regarding the code: >>>>>> >>>>>> -file bandwidth manager.cc line 238, the variables >>>>>> rtpsAllocationPerFrame = 0, nrtpsAllocationPerFrame = 0, >>>>>> beAllocationPerFrame = 0; are set to 0 and never updated, so >>>>>> basically they don't add anything to the return value: >>>>>> uint32_t allocatedSymbols = ugsAllocationPerFrame + >>>>>> rtpsAllocationPerFrame >>>>>> + nrtpsAllocationPerFrame + beAllocationPerFrame; >>>>>> return allocatedSymbols; >>>>>> Only the value of ugsAllocationPerFrame is updated, the other >>>>>> values remain 0, can I remove those useless variables? >>>>>> >>>>> Faker, these files have been written by Tippu. I didn't go into >>>>> implementation details but I think it's wiser not to change any >>>>> thing we don't know how to test...unless you're sure >>>>> >>>> >>>> If we have code without any tests, no maintainer, and it looks >>>> buggy, it >>>> should be killed (err, not merged so that we don't have to kill it >>>> Faker >>>> later :). But maybe someone could try to track down tippu and ask him >>>> the question ? >>>> >>>> >>> Actually this is not a bug but rather an non useful variables that >>> have significant names for wimax people I guess, their only matter >>> is that they are not updated, having an answer or a document about >>> it would be cool. Does rtpsAllocationPerFrame, >>> nrtpsAllocationPerFrame, beAllocationPerFrame mean something for >>> Wimax experts? If they mean nothing then we will remove them but I >>> think they should mean something. >>> >> >> I had a look on the function >> BandwidthManager::GetSymbolsPerFrameAllocated (void), and I confirm >> that the variables rtpsAllocationPerFrame, nrtpsAllocationPerFrame, >> beAllocationPerFrame should be removed and the variable >> ugsAllocationPerFrame should be renamed allocationPerFrame. I will >> modify and include it in my next patch! > Done >>> -In wimax-ss-net-device.cc there is a lot of new statements, are >>> they deleted somewhere? >>>>>> >>>>> Can you be more precise? >>>>> >>>> >>>> Where are the delete statements which correspond to the new statements >>>> found in that function ? Are we leaking objects ? >>>> >>>> >>> in the constructor: >>> WimaxSubscriberStationNetDevice::WimaxSubscriberStationNetDevice >>> (void) : >>> ......., m_dlBurstProfile ( >>> new OfdmDlBurstProfile ()), m_ulBurstProfile ( >>> new OfdmUlBurstProfile ()), ..... >>> >>> { >>> ..... >>> m_classifier = new IpcsSSPacketclassifier (m_serviceFlowManager); >>> m_linkManager = new SSLinkManager (this); >>> m_scheduler = new SSScheduler (this); >>> } >>> The destructor is empty: >>> WimaxSubscriberStationNetDevice::~WimaxSubscriberStationNetDevice >>> (void) >>> { >>> } >>> and we have the DoDispose function: >>> void >>> WimaxSubscriberStationNetDevice::DoDispose (void) >>> { >>> ... >>> delete m_dlBurstProfile; >>> delete m_ulBurstProfile; >>> delete m_scheduler; >>> delete m_linkManager; >>> m_dlBurstProfile = 0; >>> m_ulBurstProfile = 0; >>> m_scheduler = 0; >>> m_linkManager = 0; >>> >>> WimaxNetDevice::DoDispose (); >>> } >>> From what I see here we have the /m_classifier/ object that is never >>> emptied unless it is deleted somewhere else. I know it's easy to fix >>> if it is a bug but please verify that all the new statements are >>> followed somewhere by a delete statement and that the objects >>> created using is unreferenced somewhere after. >> >> I confirm that it is a bug, I will fix it for the next patch > done > From vinutheraj at gmail.com Thu Aug 27 16:09:41 2009 From: vinutheraj at gmail.com (Vinu Rajashekhar) Date: Fri, 28 Aug 2009 04:39:41 +0530 Subject: [Ns-developers] Interested to do Realtime Distributed Simulation Message-ID: Hi, My name is Vinu Rajashekhar. I am a final year student of IIT Kharagpur, India. I was going through some implementation work I would like to do as my master's project, when I chanced upon the ns-3 GSOC 2009 projects page. One project that interested me was this - *Realtime Distributed Simulation.* This project would add support to ns-3 for running multiple instances distributed over several physical machines connected by and exchanging packet events over an IP network. I think I have sufficient proficiency in C/C++ coding. I have no knowledge of Python and Distributed Computing. So I am unsure of starting this project, but I feel the uncomfortable feeling is good since it means I will be able to learn new stuff during the work on this project. And I am willing to work hard and earnestly. I have some done some work in ns-2, basically integrating ns-2 and VanetMobiSim to make an integrated simulation framework for VANETs. Can somebody tell me about the issues related to this project please ? -- Vinu Rajashekhar, 5th Year Dual Degree Student, Deptt of Computer Science & Engg, IIT Kharagpur, India. From riley at ece.gatech.edu Fri Aug 28 09:20:00 2009 From: riley at ece.gatech.edu (George Riley) Date: Fri, 28 Aug 2009 12:20:00 -0400 Subject: [Ns-developers] Interested to do Realtime Distributed Simulation In-Reply-To: References: Message-ID: Hi Vinu, We have an implementation of "distributed" ns3 using MPI that is posted and hopefully will be included in the next release. THis one focuses strictly on wired point-to-point networks, although is should not be hard to do it for CSMA networks as well. Wireless networks are the tricky part, and are not included at the moment. People have looked at efficient ways to get good performance on distributed wireless simulations for decades, with little or no good solutions. That might be worth thinking about. Josh Pelkey, my PhD student here at GT, is thinking about distributed wireless as well. George -------------------------------------------------- George Riley Associate Professor Georgia Tech Electrical and Computer Engineering riley at ece.gatech.edu 404-894-4767 Klaus Advanced Computing Building Room 3360 266 Ferst Drive Atlanta, Georgia 30332-0765 ECE6110 Web page: http://users.ece.gatech.edu/~riley/ece6110/ ECE3090 Web page: http://users.ece.gatech.edu/~riley/ece3090/ On Aug 27, 2009, at 7:09 PM, Vinu Rajashekhar wrote: > Hi, > My name is Vinu Rajashekhar. I am a final year student of IIT > Kharagpur, > India. I was going > through some implementation work I would like to do as my master's > project, > when I chanced > upon the ns-3 GSOC 2009 projects page. One project that interested > me was > this - > > *Realtime Distributed Simulation.* This project would add support to > ns-3 > for running multiple > instances distributed over several physical machines connected by and > exchanging packet events > over an IP network. > > I think I have sufficient proficiency in C/C++ coding. I have no > knowledge > of Python and Distributed > Computing. So I am unsure of starting this project, but I feel the > uncomfortable feeling is good since > it means I will be able to learn new stuff during the work on this > project. > And I am willing to work hard > and earnestly. > > I have some done some work in ns-2, basically integrating ns-2 and > VanetMobiSim to make an integrated > simulation framework for VANETs. > > Can somebody tell me about the issues related to this project please ? > > -- > Vinu Rajashekhar, > 5th Year Dual Degree Student, > Deptt of Computer Science & Engg, > IIT Kharagpur, > India. From Faker.Moatamri at sophia.inria.fr Fri Aug 28 09:42:39 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Fri, 28 Aug 2009 18:42:39 +0200 (CEST) Subject: [Ns-developers] Review application In-Reply-To: <4A97EE90.7010500@sophia.inria.fr> References: <4A93F007.3070106@sophia.inria.fr> <4A93FBBE.10700@sophia.inria.fr> <1251226394.2559.11.camel@localhost.localdomain> <4A94ECD0.5010402@sophia.inria.fr> <4A94FB0E.9020500@sophia.inria.fr> <4A97AEBB.8080807@sophia.inria.fr> <4A97EE90.7010500@sophia.inria.fr> Message-ID: <49997.217.128.71.243.1251477759.squirrel@imap-sop.inria.fr> > Faker, > > A regression was introduced in the code, I'm no longer able to execute > the wimax-ipv4 example,,,it exits with a core dump!! > the same thing happens also for wimax-multicast. This is added to wimax-simple, which exits with core dump from your repository but after executing for a brief while. We need to fix or to remove the static paths so that this error won't be there. For the core dump problem we need to debug that as soon as possible. > We sould execute at least the 2 tests I described in a previous mail and > check that they output OK before uploading a new version in the > mercurial repository. The version we have in mercurial needs to be fixed, if we did not integrate wimax with ns-3-dev we wouldn't have seen this problem. I think that it is good that we integrated wimax with ns-3-dev now since we found this core dump error few days before the september 1st deadline. We should see what changed in the ns-3 API that caused this core dump error. This is a critical error and if the examples doesn't work, we won't be able to integrate with ns-3-dev successfully. > > Thank you > > Best regards > Amine > Best regards Faker Moatamri From mathieu.lacage at sophia.inria.fr Fri Aug 28 11:50:55 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 28 Aug 2009 20:50:55 +0200 Subject: [Ns-developers] Updating Python bindings in ns-3-dev In-Reply-To: References: <4A97E1B2.3060308@tomh.org> Message-ID: <1251485455.2639.19.camel@localhost.localdomain> On Fri, 2009-08-28 at 15:47 +0100, Gustavo Carneiro wrote: > >> Any objections to this patch? Yes, I do object :) I have tried to minimize the number of headers exported so, I would like to see another solution to avoid these extra exports. If there is no other solution, so be it, but, really, I think we should be able to avoid most exports. > > This patch and Mathieu's previous one is inconsistent about which impl > > classes need to be exported and which ones can stay private, which makes me > > wonder whether there is further cleanup or alignment needed. For instance, > > tcp-socket-impl.h and nsc-tcp-socket-impl.h but not udp-socket-impl.h. > > Also, the IPv4 implementation headers are largely exported but the IPv6 > > headers are not. ArpCache needs ipv4-interface.h because the python bindings attempt to wrap the GetInterface method which, really, we should not be exporting. We should ask pavel what he needs ArpCache for exactly to see if we can deal with this. > > > > Mathieu didn't comment on why he needed these extra v4 headers exposed. Do For consistency with every other module in ns-3, we need to export the objects we create from outside. i.e., WifiNetDevice is exported as well as every other object we create from src/helper. The 5 implementation objects I exported were just the same. Otherwise, we force every user to use the helper objects which is not really consistent with the stated goal of the helpers. i.e., I have seen people reproducing the InternetStackHelper object factory code which I found a bit horrid. > > you have an idea, however, why tcp-socket-impl.h needs to be public now but > > udp-socket-impl.h doesn't? > > > tcp-socket-impl.h needs to be public because class TcpL4Protocol contains a > member: > > std::vector > m_sockets; > > I am not sure yet exactly what, but something in the pybindgen-generated > code triggers an "incomplete type" error (see attached log file), which goes > away when the bindings are allowed to include the -impl header. > > My best guess is just that when a class has a member attribute with pointer > to an incomplete type, the error will occur under certain situations. I do > not fully understand why code manipulating incomplete types work sometimes > and sometimes not. But neither do I have any other proposed solution. I would guess that a couple of objects also need private copy constructors and assignment operators to make sure that the compiler does not attempt to generate implicit versions of these. i.e., the untested attached patch shows what could be done for a couple of these objects to avoid problems. I can't test this right now but I will try it on monday if you don't beat me to it. Mathieu From tomh at tomh.org Fri Aug 28 14:55:45 2009 From: tomh at tomh.org (Tom Henderson) Date: Fri, 28 Aug 2009 14:55:45 -0700 Subject: [Ns-developers] Fwd: NS-3 RFC5444 (PacketBB) Implementation In-Reply-To: References: Message-ID: <4A985261.4040304@tomh.org> Tom Wambold wrote: > All: > > I have just recently published a new PacketBB implementation for the > NS-3 Network Simulator as part of work at Drexel University and > University of Pennsylvania. > > The implementation can be found in the Mercurial repository at [1]. The > source files are in src/contrib/packetbb.{cc,h}. A thorough test can be > found at src/contrib/test-packetbb.cc > > This library fully conforms to RFC5444 [2], and passes all > interoperability tests performed at the 2008 OLSR Interop [3]. Since > these example packets were based on an earlier PacketBB draft, a minor > change was needed to match the latest RFC. Otherwise, this > implementation passes all of the tests found at [4]. > > We will be actively using this library to support our implementation of > NHDP and SMF. These should be ready for release in a few weeks. > Hopefully, these could be merged into the main NS-3 distribution. > > Since NS-3 has a full IP stack, with packets being fully serialized, > this implementation could potentially interoperate with other PacketBB > implementations when using NS-3 in emulation. Also, this implementation > is fairly generic, so it could be ported to live systems without much > effort. > > Please feel free to send me any questions/comments/etc. that you may > have as we are actively using and maintaining this library. Tom, I reviewed this and it looks great to me. I especially appreciate the 3500 lines of code for 37 test cases. Coding style conformance seems very good. Here are a few issues for merging this in the main tree: 1) we could add it to src/contrib but it seems to me that this will be generally useful for many protocols (a packet TLV facility), and since your group plans to maintain it, I think we should just find a home for it in the regular src/ tree. I originally thought perhaps src/common, but there are some IPv4 and IPv6 address dependencies for some of it, so maybe src/node would be better 2) I'd like people to comment on whether they like the idea of wrapping this in a new pbb namespace within ns-3 namespace. In general, we have not been nesting namespaces; OLSR was an exception and I think it was done for OLSR since it was ported in from ns-2 3) Doxygen for packetbb.h would need to be completed 4) We should try to port the tests into the new test framework [1] if that is completed soon; I would suggest we try to see if we can merge the test framework first and then port the tests over to test cases there. - Tom [1] http://mailman.isi.edu/pipermail/ns-developers/2009-August/006370.html From mk.banchi at gmail.com Sun Aug 30 09:42:19 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sun, 30 Aug 2009 18:42:19 +0200 Subject: [Ns-developers] Incremental review for Block Ack Message-ID: Hi all, in the past month i saw that a lot of changes have been made for NS-3 wifi module. About block ack, i work with a lot of patches with mercurial queues in order to keep clean repository's history but i figured out that keeping aligned all my patches with ns-3-dev is a very tedious work :(. So i suggest to start an incremental review in order to merge all "isolated" parts of code (for example block ack headers, Management headers, block ack support in mac low, etc...) so i have less patches to mantain. Thank you all, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090830/8eb72dde/smime.bin From mathieu.lacage at sophia.inria.fr Sun Aug 30 23:55:23 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 31 Aug 2009 08:55:23 +0200 Subject: [Ns-developers] Incremental review for Block Ack In-Reply-To: References: Message-ID: <1251701723.3340.6.camel@diese.inria.fr> On Sun, 2009-08-30 at 18:42 +0200, Mirko Banchi wrote: > Hi all, > > in the past month i saw that a lot of changes have been made for NS-3 > wifi module. About block ack, i work with a lot of patches with > mercurial queues in order to keep clean repository's history but i > figured out that keeping aligned all my patches with ns-3-dev is a > very tedious work :(. So i suggest to start an incremental review in > order to merge all "isolated" parts of code (for example block ack > headers, Management headers, block ack support in mac low, etc...) so > i have less patches to mantain. I wholeheartedly support the idea of incremental merges ! The best way to go for this would be to have something which describes the big-picture (i.e., what the complete support will look like in the end) as well as pointers to the patches which implement the start of the work. Mathieu From mathieu.lacage at sophia.inria.fr Mon Aug 31 01:08:24 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 31 Aug 2009 10:08:24 +0200 Subject: [Ns-developers] trilogy summer school tutorial Message-ID: <1251706104.3340.18.camel@diese.inria.fr> hi, I did a presentation last week in belgium about ns-3: some users might find the following slides interesting. If you wish to do an ns-3 presentation yourself, please, do not hesitate to steal these slides, tweak them, and reuse them in any way you see fit: the source is in the public domain. presentation pdf: http://www.nsnam.org/tutorials/trilogy-summer-school.pdf handouts pdf: http://www.nsnam.org/tutorials/trilogy-summer-school-handouts.pdf latex source: http://code.nsnam.org/mathieu/tutorial-trilogy I have added a link to these slides there: http://www.nsnam.org/tutorials.html regards, Mathieu From gjcarneiro at gmail.com Mon Aug 31 03:27:54 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 31 Aug 2009 11:27:54 +0100 Subject: [Ns-developers] Updating Python bindings in ns-3-dev In-Reply-To: <1251485455.2639.19.camel@localhost.localdomain> References: <4A97E1B2.3060308@tomh.org> <1251485455.2639.19.camel@localhost.localdomain> Message-ID: 2009/8/28 Mathieu Lacage > On Fri, 2009-08-28 at 15:47 +0100, Gustavo Carneiro wrote: > > > >> Any objections to this patch? > > Yes, I do object :) I have tried to minimize the number of headers > exported so, I would like to see another solution to avoid these extra > exports. If there is no other solution, so be it, but, really, I think > we should be able to avoid most exports. > > > > This patch and Mathieu's previous one is inconsistent about which impl > > > classes need to be exported and which ones can stay private, which > makes me > > > wonder whether there is further cleanup or alignment needed. For > instance, > > > tcp-socket-impl.h and nsc-tcp-socket-impl.h but not udp-socket-impl.h. > > > Also, the IPv4 implementation headers are largely exported but the > IPv6 > > > headers are not. > > ArpCache needs ipv4-interface.h because the python bindings attempt to > wrap the GetInterface method which, really, we should not be exporting. > We should ask pavel what he needs ArpCache for exactly to see if we can > deal with this. > > > > > > > Mathieu didn't comment on why he needed these extra v4 headers exposed. > Do > > For consistency with every other module in ns-3, we need to export the > objects we create from outside. i.e., WifiNetDevice is exported as well > as every other object we create from src/helper. The 5 implementation > objects I exported were just the same. Otherwise, we force every user to > use the helper objects which is not really consistent with the stated > goal of the helpers. > > i.e., I have seen people reproducing the InternetStackHelper object > factory code which I found a bit horrid. > > > > you have an idea, however, why tcp-socket-impl.h needs to be public now > but > > > udp-socket-impl.h doesn't? > > > > > > tcp-socket-impl.h needs to be public because class TcpL4Protocol contains > a > > member: > > > > std::vector > m_sockets; > > > > I am not sure yet exactly what, but something in the pybindgen-generated > > code triggers an "incomplete type" error (see attached log file), which > goes > > away when the bindings are allowed to include the -impl header. > > > > My best guess is just that when a class has a member attribute with > pointer > > to an incomplete type, the error will occur under certain situations. I > do > > not fully understand why code manipulating incomplete types work > sometimes > > and sometimes not. But neither do I have any other proposed solution. > > > I would guess that a couple of objects also need private copy > constructors and assignment operators to make sure that the compiler > does not attempt to generate implicit versions of these. i.e., the > untested attached patch shows what could be done for a couple of these > objects to avoid problems. I can't test this right now but I will try it > on monday if you don't beat me to it. > You are right. Making the copy constructors private takes care of the problem. We already had a similar problem before, and arrived to the same conclusion, but I have too short memory and forgot :P I added this information to the wiki: http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings#Pitfalls Thanks! -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From faker.moatamri at sophia.inria.fr Mon Aug 31 03:30:48 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 31 Aug 2009 12:30:48 +0200 Subject: [Ns-developers] Debugging wimax-simple Message-ID: <4A9BA658.7070102@sophia.inria.fr> Hi, I'm currently debugging wimax-simple program, I found the following: -in wimax-helper.cc, device->Start () at line 261 is causing the crash (coming from wimax-simple.cc line 143 and 144, the call to wimax.Install) -in connection-identifier-factory.cc line 52, this call is causing a crash (high level call: wimax.SetupConnection at lines 184 and 202 of wimax-simple.cc) Any idea Amine of what is happening? Thanks Faker Moatamri From ian.thomson at gmail.com Sun Aug 30 10:22:21 2009 From: ian.thomson at gmail.com (Ian Thomson) Date: Sun, 30 Aug 2009 18:22:21 +0100 Subject: [Ns-developers] AODV Implementation in NS-3 Message-ID: <20a651590908301022h1acb41a1keed75e3ad3f051bc@mail.gmail.com> >On Monday 22 June 2009 11:17:22 am Mathieu Lacage wrote: >> hi, >> >> On Fri, 2009-06-19 at 11:19 -0400, David Liu wrote: >> > When will AODV be supported in NS-3? >> >> When you send us a patch :) >> >> More seriously, I am not aware of anyone working on aodv support for >> ns-3. > > We plan (though I can't really promise this) to port ns-2 aodv model till > September. Stay tuned. > > Best reards, > Pavel Boyko, IITP Hello Is anyone aware of any progress being made with the task of implementing AODV routing in NS3? I ask because I am interested in adopting this problem as part of my project. It is still listed in the project ideas wiki page for the gsoc2009 students, and i don't believe any of the 3 gsoc students took this project. I suppose the main question is whether Pavel Boyko has ported the model like he said he may. Regards Ian From amine.ismail at sophia.inria.fr Mon Aug 31 08:20:22 2009 From: amine.ismail at sophia.inria.fr (Ismail Amine) Date: Mon, 31 Aug 2009 17:20:22 +0200 Subject: [Ns-developers] Debugging wimax-simple In-Reply-To: <4A9BA658.7070102@sophia.inria.fr> References: <4A9BA658.7070102@sophia.inria.fr> Message-ID: <4A9BEA36.5050201@sophia.inria.fr> Hi Faker, These two bugs was introduced when you have ported the wimax module to the latest version of ns-3 Faker Moatamri wrote: > Hi, > I'm currently debugging wimax-simple program, I found the following: > -in wimax-helper.cc, device->Start () at line 261 is causing the crash > (coming from wimax-simple.cc line 143 and 144, the call to wimax.Install) More precisely, the crash happens at the following line *|393 GetClassifier()->SetDevice(this); |*and we can see using gdb that GetClassifier() returns a null pointer! This happens since you have added a new constructor calling the default one * | WimaxBaseStationNetDevice::WimaxBaseStationNetDevice(Ptr node, Ptr< WimaxPhy> phy) { WimaxBaseStationNetDevice(); this->SetNode(node); this->SetPhy(phy); }|* And this don't work in C++ (However I think it works in C#) To fix this I have added a new function named *|InitWimaxBaseStationNetDevice()|* performing what the default constructor performs and I call it in the new constructor. the code becomes: * | WimaxBaseStationNetDevice::WimaxBaseStationNetDevice(Ptr node, Ptr< WimaxPhy> phy) { InitWimaxBaseStationNetDevice(); this->SetNode(node); this->SetPhy(phy); }|* *| |* > -in connection-identifier-factory.cc line 52, this call is causing a > crash (high level call: wimax.SetupConnection at lines 184 and 202 of > wimax-simple.cc) Same reason (a new constructor calling the default one)! > Any idea Amine of what is happening? > Thanks > Faker Moatamri From tom5760 at gmail.com Mon Aug 31 08:30:28 2009 From: tom5760 at gmail.com (Tom Wambold) Date: Mon, 31 Aug 2009 11:30:28 -0400 Subject: [Ns-developers] Fwd: NS-3 RFC5444 (PacketBB) Implementation In-Reply-To: <4A985261.4040304@tomh.org> References: <4A985261.4040304@tomh.org> Message-ID: On Fri, Aug 28, 2009 at 5:55 PM, Tom Henderson wrote: > the 3500 lines of code for 37 test cases. ?Coding style conformance > seems very good. Thanks! > Here are a few issues for merging this in the main tree: > > 1) we could add it to src/contrib but it seems to me that this will be > generally useful for many protocols (a packet TLV facility), and since > your group plans to maintain it, I think we should just find a home for > it in the regular src/ tree. ?I originally thought perhaps src/common, > but there are some IPv4 and IPv6 address dependencies for some of it, so > maybe src/node would be better I wasn't sure where to add it at first, so src/contrib seemed to make sense, but src/node would be fine too. > 2) I'd like people to comment on whether they like the idea of wrapping > this in a new pbb namespace within ns-3 namespace. ?In general, we have > not been nesting namespaces; OLSR was an exception and I think it was > done for OLSR since it was ported in from ns-2 The classes have fairly generic names right now (Message, AddressBlock), such that I was concerned about grouping them together in one logical entity. If you would rather do without the nested namespace, maybe these should be renamed to reflect their relation to PacketBB. > 3) Doxygen for packetbb.h would need to be completed This is on my to-do list. > 4) We should try to port the tests into the new test framework [1] if > that is completed soon; I would suggest we try to see if we can merge > the test framework first and then port the tests over to test cases there. Yes, this sounds like a great idea. I'll look into the framework, and once it gets merged, I'll port my tests. Thanks for your comments! -Tom Wambold From mathieu.lacage at sophia.inria.fr Mon Aug 31 08:36:13 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 31 Aug 2009 17:36:13 +0200 Subject: [Ns-developers] Fwd: NS-3 RFC5444 (PacketBB) Implementation In-Reply-To: References: <4A985261.4040304@tomh.org> Message-ID: <1251732973.3340.45.camel@diese.inria.fr> On Mon, 2009-08-31 at 11:30 -0400, Tom Wambold wrote: > The classes have fairly generic names right now (Message, AddressBlock), > such that I was concerned about grouping them together in one logical > entity. If you would rather do without the nested namespace, maybe > these should be renamed to reflect their relation to PacketBB. Yes, if you don't use the pbb namespace, you should probably use the Pbb prefix for every class name. Mathieu From mathieu.lacage at sophia.inria.fr Mon Aug 31 18:01:47 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 31 Aug 2009 18:01:47 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.0 Message-ID: <200909010101.n8111lbC014664@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/88 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Aug 31 18:05:40 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 31 Aug 2009 18:05:40 -0700 Subject: [Ns-developers] buildbot failure in NsNam on mingw-g++ Message-ID: <200909010105.n8115eD6014668@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of mingw-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/mingw-g%2B%2B/builds/137 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: mingw Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Aug 31 19:37:29 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 31 Aug 2009 19:37:29 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.2 Message-ID: <200909010237.n812bTxV014750@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.2/builds/85 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From tomh at tomh.org Mon Aug 31 22:34:50 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 31 Aug 2009 22:34:50 -0700 Subject: [Ns-developers] [Fwd: buildbot failure in NsNam on osx-ppc-g++-4.0] Message-ID: <4A9CB27A.60706@tomh.org> this error seems to be because NSC is being added to the bindings on platforms for which it is disabled. - Tom -------- Original Message -------- Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.0 Date: Mon, 31 Aug 2009 18:01:47 -0700 From: mathieu.lacage at sophia.inria.fr To: ns-developers at ISI.EDU The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/88 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From martin.ferrari at gmail.com Mon Aug 31 10:41:02 2009 From: martin.ferrari at gmail.com (=?ISO-8859-1?Q?Mart=EDn_Ferrari?=) Date: Mon, 31 Aug 2009 19:41:02 +0200 Subject: [Ns-developers] Fwd: [patch] Helper methods for pcap tracing with explicit filenames In-Reply-To: References: Message-ID: Resending with my other address, mailman doesn't like me :) ---------- Forwarded message ---------- From: Mart?n Ferrari Date: Mon, Aug 31, 2009 at 18:11 Subject: [patch] Helper methods for pcap tracing with explicit filenames To: craigdo at ee.washington.edu Cc: ns-developers at isi.edu Hi Craig, For a project I'm working on, I need to set up pcap tracing while being able to define exactly which filename the traces will have. Now, the helper methods unconditionally append the node and device ids and the ".pcap" suffix. I've created a patch that defines a new method EnablePcapExplicit with exactly the same arguments as EnablePcap, but doesn't append anything to the filename argument. ATM, I'd just implemented overloaded methods for the nodeid+deviceid and device ptr versions, but if you think it's worthwhile, I can add equivalent methods for the other signatures of EnablePcap. I've also included the updated bindings for this. I'd like to ask you to consider merging this functionality. Maybe you'd prefer a different method name, or some different organisation. What I'd like to avoid is any diversion from the ns-3-dev main tree. Thanks, Mart?n. PS: please note that the current revision of ns-3-dev has some of the bindings out of sync. When I run --python-scan, these files are modified: M bindings/python/ns3_module_core.py M bindings/python/ns3_module_internet_stack.py M bindings/python/ns3_module_wifi.py -- Mart?n Ferrari -- Mart?n Ferrari -------------- next part -------------- A non-text attachment was scrubbed... Name: add_explicit_pcaphelpers.patch Type: text/x-patch Size: 12086 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090831/cfd7fa86/add_explicit_pcaphelpers-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: bindings_explicit_pcaphelpers.patch Type: text/x-patch Size: 4679 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090831/cfd7fa86/bindings_explicit_pcaphelpers-0001.bin From oriandmish at gmail.com Mon Aug 31 09:57:12 2009 From: oriandmish at gmail.com (ori and mish bgu) Date: Mon, 31 Aug 2009 19:57:12 +0300 Subject: [Ns-developers] Timers bug in ns2 ? In-Reply-To: References: Message-ID: Dear ns developers We wrote our own mac layer that works similar to TDMA. In our mac layer we generate ticks with timers of 1micro sec, means that every 1micro sec the program goes into the tickHandler function. The basic idea: mhTick_.tick_start(0.0); ... void MacMt::tickHandler(Event *e) { .. our code .. printf("%.15f\n",NOW); mhTick_.tick_start(0.000001); } But from some odd reason we found that it is not accurate ... ?! the printed log shows that there is a drift of 1*10^(-15) every few hundreds of ticks .. part of the prints : 0.000001000000000 0.000002000000000 0.000003000000000 0.000004000000000 ... 0.006358000000001 0.006359000000001 0.006360000000001 .. 0.032848000000012 0.032849000000012 0.032850000000012 .. 0.073830000000053 0.073831000000053 0.073832000000053 0.073833000000053 ... and it gets worse with time .. 0.250990000000203 0.250991000000203 0.250992000000203 0.250993000000203 .. ?? and drifts downwards too 0.259740999999969 0.259741999999969 0.259742999999969 Is it normal ? Or is it an ns2 bug ? Any help would be much appreciated Thanks in advance Ori and Michael