From f1mauchl at hsr.ch Mon Nov 2 01:24:24 2009 From: f1mauchl at hsr.ch (Fabian Mauchle) Date: Mon, 2 Nov 2009 10:24:24 +0100 Subject: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) In-Reply-To: <4AEAD0B8.8070202@sophia.inria.fr> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <000301ca57ef$46c5d150$d45173f0$@ch> <4AE91BE8.9090900@tomh.org> <4AE93B92.6000809@clarinet.u-strasbg.fr> <4AE97000.1090900@sophia.inria.fr> <001b01ca5938$16e382d0$44aa8870$@ch> <4AEAD0B8.8070202@sophia.inria.fr> Message-ID: <004301ca5b9e$4488b210$cd9a1630$@ch> Hi All, I looked over it again, and I'm not sure if removing the OptionDemux could limit the flexibility it currently provides. So I've put together my old Extension-Option link. You can find the code at http://sinv-56031.edu.hsr.ch/hg/ns-3-ipv6-option. The modification mainly simplifies the Assembly of Extension- and Option Headers. It leaves the OptionDemux as is, and only extends the Ipv6ExtensionHeader and Ipv6OptionHeader. It also includes a small refactoring to remove duplicate code in the Ipv6Extension* subclasses. So for now, I would propose to us this as a merge candidate. What do you think? Sebastien? Regards, Fabian -----Urspr?ngliche Nachricht----- Von: Faker Moatamri [mailto:faker.moatamri at sophia.inria.fr] Gesendet: Freitag, 30. Oktober 2009 12:41 An: Mauchle Fabian (f1mauchl at hsr.ch) Cc: vincent at clarinet.u-strasbg.fr; ns-developers at ISI.EDU; ns-3-reviews at googlegroups.com Betreff: Re: AW: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) ... Thanks for the explanation. It is clear that we can't merge both codes in the main tree, so which version should be taken as a merge candidate? ... Best regards Faker Moatamri From mk.banchi at gmail.com Mon Nov 2 05:35:14 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Mon, 2 Nov 2009 14:35:14 +0100 Subject: [Ns-developers] Block ack review request Message-ID: Hi Nicola, Pavel and all, is it possible to start review for block ack implementation?The complete patch set is available on http://codereview.appspot.com/144050/show . Thank you very much, 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 From tomh at tomh.org Mon Nov 2 22:17:29 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 02 Nov 2009 22:17:29 -0800 Subject: [Ns-developers] IPv6 extension support In-Reply-To: <4AE57F14.4020205@clarinet.u-strasbg.fr> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <4AE57F14.4020205@clarinet.u-strasbg.fr> Message-ID: <4AEFCAF9.5030307@tomh.org> Sebastien Vincent wrote: > Hi, > > Here is the repository for IPv6 extension support: > http://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext/ > > It contains two new examples: > - fragmentation-ipv6, a node sends packets > MTU, packets are fragmented > in IPv6 stack; > - loose-routing-ipv6, a node sends special ICMPv6 which have IPv6 > routing header type 0 (it choose the router path). > > There are some stuff that could/have to be enhanced: > - In ipv6-static-routing.cc, class Ipv6LooseRoutingExtension send > directly the packets instead of passing up to Ipv6L3Protocol and it need > Ipv6StaticRouting object to have a lookup (StaticLookup) in routing > table (I don't need LocalDeliver/IpForward, ... callbacks). To do this I > copy code from Ipv6RoutingHelper to get Ipv6StaticRouting object from > Ipv6L3Protocol::GetRoutingProtocol. So we have the following choices: > - include an helper class in stack (not sure it is good); > - refactor to pass processed packets with routing header in IPv6 stack > (tag, ...); Can the RouteInput method demux the routing headers (without tag) and forward on the routing header instead of the IPv6 header, since it gets the packet? I am suspicious of putting in these static routing methods because it may not be static routing that is operating on the packet. It seems to me that routing headers can be processed from within RouteInput, and destination headers can be processed in LocalDeliver. > - add a virtual method in Ipv6RoutingProtocol that just look in routing > table for a destination (stuff like RouteInput() with no callback) and > returns a route. Can RouteOutput() be used for these use cases? - Tom From vincent at clarinet.u-strasbg.fr Mon Nov 2 22:39:54 2009 From: vincent at clarinet.u-strasbg.fr (=?windows-1252?Q?S=E9bastien_Vincent?=) Date: Tue, 03 Nov 2009 07:39:54 +0100 Subject: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) In-Reply-To: <4AEAD0B8.8070202@sophia.inria.fr> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <000301ca57ef$46c5d150$d45173f0$@ch> <4AE91BE8.9090900@tomh.org> <4AE93B92.6000809@clarinet.u-strasbg.fr> <4AE97000.1090900@sophia.inria.fr> <001b01ca5938$16e382d0$44aa8870$@ch> <4AEAD0B8.8070202@sophia.inria.fr> Message-ID: <4AEFD03A.5030104@clarinet.u-strasbg.fr> Hi, Repository and codereview has been updated. It remains doxygen to do and remove duplicate code in Ipv6Extension (Fabian has already done this part so I will take it). Regards, -- Sebastien Faker Moatamri a ?crit : > Fabian Mauchle wrote: >> Hi, >> >> I did that because Ipv6Extensios and Ipv6Options are currently treated >> independently, which they aren?t. >> So my changes are: >> - Add a relationship between Ipv6ExtensionHeader and >> Ipv6OptionHeader, with >> the possibility to add Option headers to Extension Headers. This also >> automates the Header alignment required by IPv6. (I implemented this >> some >> time ago, based on the old IPv6 repo from Sebastien) >> >> - Because options are often used to store additional information for >> processing extensions, the independent processing of options does not >> suit >> this very well. So I replaced the Ipv6OptionDemux by a list of >> Callbacks, >> registered by the Ipv6Extension and called for each Ipv6OptionHeader >> present >> (identified by the type field). >> > Thanks for the explanation. It is clear that we can't merge both codes > in the main tree, so which version should be taken as a merge candidate? > > Sebastian, I reviewed your code in > https://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext : > you will find all my comment in http://codereview.appspot.com/144048 > The code is overall good, here is my most important remarks: > - Some code should contain more doxygen > - When you use new, be sure that somewhere you delete > - Coding style specially in indentation of header files > Best regards > Faker Moatamri > > From vincent at clarinet.u-strasbg.fr Mon Nov 2 22:50:57 2009 From: vincent at clarinet.u-strasbg.fr (=?ISO-8859-1?Q?S=E9bastien_Vincent?=) Date: Tue, 03 Nov 2009 07:50:57 +0100 Subject: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) In-Reply-To: <004301ca5b9e$4488b210$cd9a1630$@ch> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <000301ca57ef$46c5d150$d45173f0$@ch> <4AE91BE8.9090900@tomh.org> <4AE93B92.6000809@clarinet.u-strasbg.fr> <4AE97000.1090900@sophia.inria.fr> <001b01ca5938$16e382d0$44aa8870$@ch> <4AEAD0B8.8070202@sophia.inria.fr> <004301ca5b9e$4488b210$cd9a1630$@ch> Message-ID: <4AEFD2D1.4020309@clarinet.u-strasbg.fr> Hi Fabian, Fabian Mauchle a ?crit : > Hi All, > > I looked over it again, and I'm not sure if removing the OptionDemux could > limit the flexibility it currently provides. So I've put together my old > Extension-Option link. You can find the code at > http://sinv-56031.edu.hsr.ch/hg/ns-3-ipv6-option. > > The modification mainly simplifies the Assembly of Extension- and Option > Headers. It leaves the OptionDemux as is, and only extends the > Ipv6ExtensionHeader and Ipv6OptionHeader. It also includes a small > refactoring to remove duplicate code in the Ipv6Extension* subclasses. > > So for now, I would propose to us this as a merge candidate. > > What do you think? > Sebastien? > > I am very busy this week so I will try to review it by the end of week. And I will apply today the "code duplication fix" part of your patch. Regards, -- Sebastien > Regards, > > Fabian > > > -----Urspr?ngliche Nachricht----- > Von: Faker Moatamri [mailto:faker.moatamri at sophia.inria.fr] > Gesendet: Freitag, 30. Oktober 2009 12:41 > An: Mauchle Fabian (f1mauchl at hsr.ch) > Cc: vincent at clarinet.u-strasbg.fr; ns-developers at ISI.EDU; > ns-3-reviews at googlegroups.com > Betreff: Re: AW: [Ns-developers] Ipv6Extension (was UDPv6, missleading > subject) > ... > Thanks for the explanation. It is clear that we can't merge both codes > in the main tree, so which version should be taken as a merge candidate? > ... > > Best regards > Faker Moatamri > > > > From andreev at iitp.ru Tue Nov 3 03:03:12 2009 From: andreev at iitp.ru (Kirill Andreev) Date: Tue, 03 Nov 2009 14:03:12 +0300 Subject: [Ns-developers] Mesh 802.11s and FLAME regressions Message-ID: Hi! I have written some regression tests for HWMP and PeerManagementProtocol. All test-cases are described in the attachment. There are the following regression tests: 1. Simple Peer management protocol regression: 2 stations establish a peer link 2. HWMP regression with 2 stations 3. HWMP regression with 6 stations placed in the line and one of stations changes its position -- tested PERR propagation 4. Proactive HWMP regression test with 5 stations 5. HWMP target flags regression test -- intermediate reply and PREQ/PREP exchanges in this case 6. FLAME test with 3 stations. All reference *.pcap files are stored at directories src/devices/mesh/{dot11s,flame}/test (the same place of sources of tests). Any comments and review remarks are welcome. If there are no objections till Thursday, I will push this changes and reference traces. Regards, Kirill Andreev, IITP RAS -------------- next part -------------- A non-text attachment was scrubbed... Name: regression.patch Type: application/octet-stream Size: 69249 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091103/e04bc88e/regression-0001.obj From faker.moatamri at sophia.inria.fr Tue Nov 3 08:37:00 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 03 Nov 2009 17:37:00 +0100 Subject: [Ns-developers] MingWin compiling bug 705 Message-ID: <4AF05C2C.1010607@sophia.inria.fr> Hi Gustavo & George, Yes again Mingwin, it is still an issue and buildbot doesn't build with Mingwin. The issue is reported in bug 705. Thanks Gustavo for the patch but it needs more work right? As far as I understand, we need to disable code using socket in net-anim which requires to add some #ifdef to the code right? Gustavo, George, can you please make the patch in bug 705 work so that we can keep on supporting Mingwin, hoping that other problems won't arise? Thanks Faker Moatamri From riley at ece.gatech.edu Tue Nov 3 08:42:04 2009 From: riley at ece.gatech.edu (George Riley) Date: Tue, 3 Nov 2009 11:42:04 -0500 Subject: [Ns-developers] MingWin compiling bug 705 In-Reply-To: <4AF05C2C.1010607@sophia.inria.fr> References: <4AF05C2C.1010607@sophia.inria.fr> Message-ID: <1DB473D7-ED00-4C84-892F-E845AB25BCF0@ece.gatech.edu> Yes, we can put needed ifdef's in to get Mingwin to compile. Of course the animation will not be supported there. Am cc'ing Josh for information. 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 Nov 3, 2009, at 11:37 AM, Faker Moatamri wrote: > Hi Gustavo & George, > > Yes again Mingwin, it is still an issue and buildbot doesn't build > with Mingwin. The issue is reported in bug 705. Thanks Gustavo for > the patch but it needs more work right? As far as I understand, we > need to disable code using socket in net-anim which requires to add > some #ifdef to the code right? > > Gustavo, George, can you please make the patch in bug 705 work so > that we can keep on supporting Mingwin, hoping that other problems > won't arise? > > Thanks > Faker Moatamri From faker.moatamri at sophia.inria.fr Tue Nov 3 09:36:27 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 03 Nov 2009 18:36:27 +0100 Subject: [Ns-developers] 802.11n Block ack review In-Reply-To: <12BAD9BC-9D70-4B62-A3F3-44C89527504C@gmail.com> References: <12BAD9BC-9D70-4B62-A3F3-44C89527504C@gmail.com> Message-ID: <4AF06A1B.9080305@sophia.inria.fr> Mirko Banchi wrote: > Hi all, > > i've created a new issue http://codereview.appspot.com/144050 for > review. For now only compressed variant is supported but i'm working > on little changes in order to also add support for basic variant. > Hi Mirko, I reviewed your code and my comments can be found in http://codereview.appspot.com/144050/show Overall the code is good but some points need to be revisited: -Doxygen -Some setters are redundant, you can use only one setter with an input variable and get the expected behavior -Two or three similar functions did the same thing using copy and paste, you should find a better solution > I'd like to start a first review to know if changes to existing code > could be ok. However, don't worry, i have separate patches, one for > each added feature in order to keep history clean. I hope that all > could be merged in next realese. Two weeks left for that, any other reviews? Nicolas, Pavel? any review? Best regards Faker Moatamri > > Best regards, > > 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 > > > > From tbns at idlebox.net Tue Nov 3 07:48:56 2009 From: tbns at idlebox.net (Timo Bingmann) Date: Tue, 3 Nov 2009 16:48:56 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <200910301204.47152.boyko@iitp.ru> References: <594D5AD5-660E-44D5-A00D-F8A7A784F08F@gmail.com> <200910301204.47152.boyko@iitp.ru> Message-ID: <200911031648.56644.tbns@idlebox.net> Hello guys, thanks for "waking me up" :). No really, I was absent from this whole world, including reality, for the last few months due to an exam, which I finally finished just last week. I am going to work on merging some of my code into the mainstream. However, I'm definitely desynched from current development, as is my repo. I believe the feature most people are interested in is the frame capture. This, I believe, I have no not integrated into the YansWifiPhy yet, because it is conceptually incompatible. Nevertheless, I believe we can still combine the models by adding a capture threshold separate from the PER calculations. Practical simulations will benefit from this approach. What to do with the Ns2ExtWifiPhy I don't quite know. There is much duplicate code from YansWifiPhy, which makes maintenance difficult. What do the wifi- maintainers think? I also remember the TrafficApplication, which is very simple but very useful. But its a separate topic. There is also an approach to adding TXOP limits and burst in that wifiex (or in my unpublished repo?), that I will review later on. Greetings, Timo On Friday 30 October 2009 10:04:47 Pavel Boyko wrote: > Hi, Trevor, > > I'm happy to hear that you plan to merge yans & wifiex PHY models, thank > you! > > But apart of capture effect and explicit preamble modeling (by the way -- > do you plan to add explicit preamble to yans?) wifiex includes simple > threshold- based interference model. Since YANS interference calculations > are performance bottleneck in large networks, I propose to keep > interference model from wifiex as an option. It would be great if you can > do this too. > > Good luck, > Pavel > > On Friday 30 October 2009 07:24:17 am Trevor Bosaw wrote: > > Hey, > > > > I've sent an email off to Timo to see if he is still working on this > > or not. The last change was done four months ago. > > > > > > Also, as for the error in compiling the code, the ncs-tcp-socket- > > impl.cc file, which is where the error is generated, is not part of my > > planned patch. Essentially I plan to move over solely the capture > > effect code for now, that way I'll be able to make the three week > > deadline. > > > > -Trevor From bosawt at gmail.com Tue Nov 3 10:26:58 2009 From: bosawt at gmail.com (Trevor Bosaw) Date: Tue, 3 Nov 2009 10:26:58 -0800 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo Message-ID: So I've talked with Timo, and he apparently just finished up with his exams, and is now willing to resume work on wifiex. It seems that any attempts to merge wifiex and ns-3 will come from him, so I would expect he'll have a patch sometime soon. From craigdo at ee.washington.edu Tue Nov 3 10:36:14 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 3 Nov 2009 10:36:14 -0800 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <4AF05C2C.1010607@sophia.inria.fr> References: <4AF05C2C.1010607@sophia.inria.fr> Message-ID: <001201ca5cb4$86930090$93b901b0$@washington.edu> > Gustavo, George, can you please make the patch in bug 705 work so that > we can keep on supporting Mingwin, hoping that other problems won't > arise? Keep on supporting Mingwin? I'll say it again. MinGW is not a supported platform for ns-3. I have seen no indication that this has been discussed anywhere and I've seen no decision made by the project. As far as I can make out, our "official" windows story consists entirely of Cygwin. If we are going to make MinGW a supported platform, we (as a group) should make a positive decision and actually consistently add it to the list of supported platforms and have someone actually test it before each release. We need to let people know that they have got to find a MinGW installation and test their code under MinGW before committing it. I don't know what the issue is, but MinGW support keeps trying to sneak in the back door instead of politely knocking on the front. In different documents, MinGW will sometimes just appear out of nowhere. I noticed that it has been added as a supported platform in the RELEASE_NOTES on ns-3-dev. This seems to have happened for ns-3.5.1-RC2. (Huh? We silently added a new supported platform in a second release candidate?) It is not, however, added to the list of supported platforms on the main web site, nor the wiki. There was no discussion nor notification to developers to start testing things under MinGW, no indication that someone had actually verified that everything was working -- it just silently appeared in the RELEASE_NOTES. That is completely bogus. Either it *is* a supported platform or it *is not*. Either we (as a project) decide it is worthwhile to support it or not. It is ridiculous to find no mention of MinGW on the project web site, but find it listed as supported in the RELEASE_NOTES. It is ridiculous to find no mention of MinGW in one paragraph of the wiki as a supported platform only to find it in a product matrix in the very next section. See: http://www.nsnam.org/getting_started.html#os and http://www.nsnam.org/wiki/index.php/Installation#Supported_platforms Can we, as a project, get our act together on this and make a positive (or negative) decision and consistently document this decision? Can we let developers actually know that their code needs to deal with the possibility that it may be run in some MSVCRT-like environment or write itself out of the build? I doubt most of our developers are actually seriously considering that sockets may actually turn out to be Winsock, for example. If we decide positively, will someone pick up the ball and make sure all of the documentation agrees with our decision and run all of the samples/examples that are built to make sure they work? So, now for the real question: Does ns-3 view MinGW as a supported platform? -0 I am neutral, tending slightly negative. If there is a significant demand for running ns-3 on MinGW, sure -- let's officially support it; but let's document and advertize that fact. If nobody is going to use it, and all it does is get in the way while pretending to be some kind of alternate platform to enforce arbitrary portability guidelines, then no -- let's not bother. It's just a pain. What I am not neutral about is the half-in, half-out, partially-tested, snuck-in nature of current MinGW "support." Regards, -- Craig From Faker.Moatamri at sophia.inria.fr Tue Nov 3 12:32:58 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Tue, 3 Nov 2009 21:32:58 +0100 (CET) Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <001201ca5cb4$86930090$93b901b0$@washington.edu> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> Message-ID: <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> > So, now for the real question: Does ns-3 view MinGW as a supported > platform? > > -0 > You're right, we should have only one word about mingwin. Either it is or it is not supported. If it is not supported, no bug should be filed for it and buildbot should not compile Mingwin. I would also give -0 or even -1 for Mingwin support as it lacks a lot of libraries and it will be only a pain for maintainers. Moreover, Cygwin is doing the work under windows, so there is no point of going in the hassle of supporting Mingwin while Cygwin is there. Tom, Mathieu, others, what do you think? From craigdo at ee.washington.edu Tue Nov 3 12:44:09 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 3 Nov 2009 12:44:09 -0800 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> Message-ID: <003b01ca5cc6$655eebc0$301cc340$@washington.edu> > > So, now for the real question: Does ns-3 view MinGW as a supported > > platform? > > > > -0 > > > You're right, we should have only one word about mingwin. Either it is > or > it is not supported. If it is not supported, no bug should be filed for > it > and buildbot should not compile Mingwin. > I would also give -0 or even -1 for Mingwin support as it lacks a lot > of > libraries and it will be only a pain for maintainers. Moreover, Cygwin > is > doing the work under windows, so there is no point of going in the > hassle > of supporting Mingwin while Cygwin is there. > Tom, Mathieu, others, what do you think? In defense of the MinGW platform, Python bindings work there but do not work under Cygwin. From tomh at tomh.org Tue Nov 3 13:21:10 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 03 Nov 2009 14:21:10 -0700 Subject: [Ns-developers] =?utf-8?q?Is_MinGW_Supported_or_Not=3F_=28was_RE?= =?utf-8?q?=3A_MingWin_compiling_bug_705=29?= In-Reply-To: <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> Message-ID: On Tue, 3 Nov 2009 21:32:58 +0100 (CET), Faker.Moatamri at sophia.inria.fr wrote: >> So, now for the real question: Does ns-3 view MinGW as a supported >> platform? >> >> -0 >> > You're right, we should have only one word about mingwin. Either it is or > it is not supported. If it is not supported, no bug should be filed for it > and buildbot should not compile Mingwin. > I would also give -0 or even -1 for Mingwin support as it lacks a lot of > libraries and it will be only a pain for maintainers. Moreover, Cygwin is > doing the work under windows, so there is no point of going in the hassle > of supporting Mingwin while Cygwin is there. > Tom, Mathieu, others, what do you think? Two weeks ago, I asked on both the users and developers list whether there are any users who would like MinGW to be supported, and there were no responses. Without user demand, and given that we have two existing solutions for Windows (Cygwin and virtualization), I have a hard time prioritizing the addition of MinGW support as officially supported platform. Another option we have used for ns-2 in the past is to have volunteer maintainers for non-supported platforms of interest. Cygwin, Solaris, and icc were maintained like this, with the maintainers of those platforms sending in patches around release-candidate time to get the release back into shape. We could also try to take some data on this by preparing an ns-allinone-3.6-mingw release and posting it/announcing it as a MinGW variant and see whether it gets used. Tom From Faker.Moatamri at sophia.inria.fr Tue Nov 3 13:48:14 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Tue, 3 Nov 2009 22:48:14 +0100 (CET) Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> Message-ID: <51995.193.251.48.82.1257284894.squirrel@imap-sop.inria.fr> > > Two weeks ago, I asked on both the users and developers list whether there > are any users who would like MinGW to be supported, and there were no > responses. Without user demand, and given that we have two existing > solutions for Windows (Cygwin and virtualization), I have a hard time > prioritizing the addition of MinGW support as officially supported > platform. > I noticed that also, it is part of why I voted -1. > Another option we have used for ns-2 in the past is to have volunteer > maintainers for non-supported platforms of interest. Cygwin, Solaris, and > icc were maintained like this, with the maintainers of those platforms > sending in patches around release-candidate time to get the release back > into shape. > > We could also try to take some data on this by preparing an > ns-allinone-3.6-mingw release and posting it/announcing it as a MinGW > variant and see whether it gets used. This is kind of last chance for Mingwin surviving, afterwards, we can decide afterwards if we keep it or not. I agree with this idea. > > Tom > From mathieu.lacage at sophia.inria.fr Wed Nov 4 02:27:22 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 04 Nov 2009 11:27:22 +0100 Subject: [Ns-developers] Mesh 802.11s and FLAME regressions In-Reply-To: References: Message-ID: <1257330442.2541.2.camel@localhost.localdomain> more tests being always good, I am all for this to be merged. I think that you should try to get craig to ack it to make sure that the way you have structured the new test data files matches what he designed the new test framework for. Mathieu On Tue, 2009-11-03 at 14:03 +0300, Kirill Andreev wrote: > Hi! > > I have written some regression tests for HWMP and > PeerManagementProtocol. All test-cases are described in > the attachment. There are the following regression tests: > 1. Simple Peer management protocol regression: 2 stations > establish a peer link > 2. HWMP regression with 2 stations > 3. HWMP regression with 6 stations placed in the line and > one of stations changes its position -- tested PERR > propagation > 4. Proactive HWMP regression test with 5 stations > 5. HWMP target flags regression test -- intermediate reply > and PREQ/PREP exchanges in this case > > 6. FLAME test with 3 stations. > > All reference *.pcap files are stored at directories > src/devices/mesh/{dot11s,flame}/test (the same place of > sources of tests). > > Any comments and review remarks are welcome. If there are > no objections till Thursday, I will push this changes and > reference traces. > > Regards, > Kirill Andreev, > IITP RAS From mathieu.lacage at sophia.inria.fr Wed Nov 4 02:33:30 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 04 Nov 2009 11:33:30 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <200911031648.56644.tbns@idlebox.net> References: <594D5AD5-660E-44D5-A00D-F8A7A784F08F@gmail.com> <200910301204.47152.boyko@iitp.ru> <200911031648.56644.tbns@idlebox.net> Message-ID: <1257330810.2541.9.camel@localhost.localdomain> On Tue, 2009-11-03 at 16:48 +0100, Timo Bingmann wrote: > I believe the feature most people are interested in is the frame capture. > This, I believe, I have no not integrated into the YansWifiPhy yet, because it > is conceptually incompatible. > > Nevertheless, I believe we can still combine the models by adding a capture > threshold separate from the PER calculations. Practical simulations will > benefit from this approach. > > What to do with the Ns2ExtWifiPhy I don't quite know. There is much duplicate > code from YansWifiPhy, which makes maintenance difficult. What do the wifi- > maintainers think? I have a dim memory of what your code is doing: it's pretty clear that maintainance is important so, if it's an issue, we need to deal with it. I am also concerned about not making the default wifi PHY model too complex so, I would like to make the default model not create more events than it already is creating. Could you refresh my memory about what you are doing ? Maybe you could also repost here a link to your master thesis which, I presume, talks about your work at length. > There is also an approach to adding TXOP limits and burst in that wifiex (or in > my unpublished repo?), that I will review later on. I have never seen that code so, I can't comment on it. Mathieu From mathieu.lacage at sophia.inria.fr Wed Nov 4 02:42:01 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 04 Nov 2009 11:42:01 +0100 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> Message-ID: <1257331321.2541.17.camel@localhost.localdomain> On Tue, 2009-11-03 at 14:21 -0700, Tom Henderson wrote: > > You're right, we should have only one word about mingwin. Either it is or > > it is not supported. If it is not supported, no bug should be filed for > it > > and buildbot should not compile Mingwin. This is clearly wrong: not being officially supported merely means that no paid developer will invest explicit resources in mingw. However, it is the duty of paid developers to invest cycles to help mingw contributors to fix mingw. i.e., bugs filed against mingw should not be summarily closed as WONTFIX. They should be at least left open with a way for others to keep track of them. > > I would also give -0 or even -1 for Mingwin support as it lacks a lot of > > libraries and it will be only a pain for maintainers. Moreover, Cygwin is > > doing the work under windows, so there is no point of going in the hassle > > of supporting Mingwin while Cygwin is there. > > Tom, Mathieu, others, what do you think? > > Two weeks ago, I asked on both the users and developers list whether there > are any users who would like MinGW to be supported, and there were no > responses. Without user demand, and given that we have two existing I did not notice that email. > solutions for Windows (Cygwin and virtualization), I have a hard time > prioritizing the addition of MinGW support as officially supported > platform. I don't think that anyone is seriously suggesting to make MingW an officially supported platform but I personally strongly believe that not refusing patches to fix mingw and actually working with the mingw contributors (gustavo) to produce correct and useful patches is important, not because mingw is important per se, but because supporting more platforms generally increases test coverage and improves the quality of our codebase. I think that shipping a release which is known to not even compile on mingw is generally not a good idea. Again, not because I care about mingw but because not even compiling or passing basic sanity checks on mingw is a sign of low code quality. Mathieu From gjcarneiro at gmail.com Wed Nov 4 02:41:59 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 4 Nov 2009 10:41:59 +0000 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <001201ca5cb4$86930090$93b901b0$@washington.edu> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> Message-ID: I vote +0 for supporting MinGW: I can promise to try to make the code I maintain work on MinGW (already does, I think), but I do not care enough to spend a lot of time fixing other code I did not write. I personally do not use MinGW, but I do not want to be accused of writing non-portable code, and MinGW is a good way to test the limits of portability of the code. The longer we keep writing non-portable code the harder it will be to come back if in the future we decide to support native win32. 2009/11/3 > > Gustavo, George, can you please make the patch in bug 705 work so that > > we can keep on supporting Mingwin, hoping that other problems won't > > arise? > > Keep on supporting Mingwin? > > I'll say it again. MinGW is not a supported platform for ns-3. I have > seen > no indication that this has been discussed anywhere and I've seen no > decision made by the project. As far as I can make out, our "official" > windows story consists entirely of Cygwin. > > If we are going to make MinGW a supported platform, we (as a group) should > make a positive decision and actually consistently add it to the list of > supported platforms and have someone actually test it before each release. > We need to let people know that they have got to find a MinGW installation > and test their code under MinGW before committing it. > > I don't know what the issue is, but MinGW support keeps trying to sneak in > the back door instead of politely knocking on the front. In different > documents, MinGW will sometimes just appear out of nowhere. I noticed that > it has been added as a supported platform in the RELEASE_NOTES on ns-3-dev. > This seems to have happened for ns-3.5.1-RC2. (Huh? We silently added a > new supported platform in a second release candidate?) It is not, however, > added to the list of supported platforms on the main web site, nor the > wiki. > There was no discussion nor notification to developers to start testing > things under MinGW, no indication that someone had actually verified that > everything was working -- it just silently appeared in the RELEASE_NOTES. > > That is completely bogus. Either it *is* a supported platform or it *is > not*. Either we (as a project) decide it is worthwhile to support it or > not. It is ridiculous to find no mention of MinGW on the project web site, > but find it listed as supported in the RELEASE_NOTES. It is ridiculous to > find no mention of MinGW in one paragraph of the wiki as a supported > platform only to find it in a product matrix in the very next section. > See: > > http://www.nsnam.org/getting_started.html#os > > and > > http://www.nsnam.org/wiki/index.php/Installation#Supported_platforms > > Can we, as a project, get our act together on this and make a positive (or > negative) decision and consistently document this decision? Can we let > developers actually know that their code needs to deal with the possibility > that it may be run in some MSVCRT-like environment or write itself out of > the build? I doubt most of our developers are actually seriously > considering that sockets may actually turn out to be Winsock, for example. > > If we decide positively, will someone pick up the ball and make sure all of > the documentation agrees with our decision and run all of the > samples/examples that are built to make sure they work? > > So, now for the real question: Does ns-3 view MinGW as a supported > platform? > > -0 > > I am neutral, tending slightly negative. If there is a significant demand > for running ns-3 on MinGW, sure -- let's officially support it; but let's > document and advertize that fact. If nobody is going to use it, and all it > does is get in the way while pretending to be some kind of alternate > platform to enforce arbitrary portability guidelines, then no -- let's not > bother. It's just a pain. > > What I am not neutral about is the half-in, half-out, partially-tested, > snuck-in nature of current MinGW "support." > > Regards, > > -- Craig > > > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From nbaldo at cttc.es Wed Nov 4 04:51:15 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Wed, 04 Nov 2009 13:51:15 +0100 Subject: [Ns-developers] Block ack review request In-Reply-To: References: Message-ID: <4AF178C3.2090902@cttc.es> Hi Mirko, Mirko Banchi wrote: > Hi Nicola, Pavel and all, > > is it possible to start review for block ack implementation?The complete > patch set is available on http://codereview.appspot.com/144050/show. > I was trying to review your code but I noticed that there are some features (compressed block ack, multi-tid block ack) that I could not find in IEEE Std. 802.11-2007... could you please tell me where these features are defined? Nicola From vincent at clarinet.u-strasbg.fr Wed Nov 4 05:10:45 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Wed, 04 Nov 2009 14:10:45 +0100 Subject: [Ns-developers] IPv6 extension support In-Reply-To: <4AEFCAF9.5030307@tomh.org> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <4AE57F14.4020205@clarinet.u-strasbg.fr> <4AEFCAF9.5030307@tomh.org> Message-ID: <4AF17D55.6040303@clarinet.u-strasbg.fr> Hi Tom, Tom Henderson a ?crit : > Sebastien Vincent wrote: >> Hi, >> >> Here is the repository for IPv6 extension support: >> http://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext/ >> >> It contains two new examples: >> - fragmentation-ipv6, a node sends packets > MTU, packets are >> fragmented in IPv6 stack; >> - loose-routing-ipv6, a node sends special ICMPv6 which have IPv6 >> routing header type 0 (it choose the router path). >> >> There are some stuff that could/have to be enhanced: >> - In ipv6-static-routing.cc, class Ipv6LooseRoutingExtension send >> directly the packets instead of passing up to Ipv6L3Protocol and it >> need Ipv6StaticRouting object to have a lookup (StaticLookup) in >> routing table (I don't need LocalDeliver/IpForward, ... callbacks). >> To do this I copy code from Ipv6RoutingHelper to get >> Ipv6StaticRouting object from Ipv6L3Protocol::GetRoutingProtocol. So >> we have the following choices: >> - include an helper class in stack (not sure it is good); >> - refactor to pass processed packets with routing header in IPv6 >> stack (tag, ...); > Can the RouteInput method demux the routing headers (without tag) and > forward on the routing header instead of the IPv6 header, since it > gets the packet? I am suspicious of putting in these static routing > methods because it may not be static routing that is operating on the > packet. It seems to me that routing headers can be processed from > within RouteInput, and destination headers can be processed in > LocalDeliver. The routing extension are processed in a local delivered packet, see RFC2460 section 4.4 : A Routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. > >> - add a virtual method in Ipv6RoutingProtocol that just look in >> routing table for a destination (stuff like RouteInput() with no >> callback) and returns a route. > Can RouteOutput() be used for these use cases? Oh I forget this method... yes it could work, I will test it. Regards, -- Sebastien > > - Tom > > From jpelkey at gatech.edu Wed Nov 4 07:48:19 2009 From: jpelkey at gatech.edu (jpelkey@gatech.edu) Date: Wed, 4 Nov 2009 10:48:19 -0500 (EST) Subject: [Ns-developers] MPI for ns-3 In-Reply-To: <909776950.303191257349681246.JavaMail.root@mail8.gatech.edu> Message-ID: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> Hi all, We have the distributed MPI code ready for review. Below is an overview of the code and the changes made. http://codereview.appspot.com/109068/show === Overview [updated 2 Nov 2009]. The distributed simulation code is designed to allow a single topology to be split into "n" sub-topologies and executed on "n" linux boxes in a distributed memory environment. The current implementation only allows packets sent across point-to-point links to be sent across simulator boundaries; the next release will support wireless we hope. We tried to change as little as possible of the existing code base and isolate our changes in separate modules where possible. Details. point-to-point-channel.[h,cc] - Made TransmitStart virtual so the new subclass (see below) can override. point-to-point-remote-channel.[h,cc] - new subclass of p2p channel; used to connect simulated nodes on one simulator to nodes on a separate simulator. Overrides the TransmitStart function and uses MPI to send the packet across simulator processes. point-to-point-helper.[h,cc]. Checks the system id on the two nodes being connected, and uses a p2p-remote-channel rather than a p2p-channel if the system id's do not match. node.[h,cc] - Added a "SetSystemId" function, to allow the system id to be set after the node is constructed, rather than passing parameter to constructor; this exists because there was no way to use non-default constructors on object creation. I believe this might have been fixed since then, so perhaps this might not be neded. global-route-manager.cc - Do not compute routes for any node whose system-id does not match the simulator's system id. Clearly, we don't need to compute routes in simulator A for nodes modeled in simulator B. default-simulator-impl.[h.cc] = Added virtual "GetSystemId" method, which returns the system id (MPI rank) of this process. For the default-simulator object it always returns zero. distributed-simulator-impl.[h.cc] - new subclass of default-simulator-impl. THe meat of this is the overridden "run" method that handles all of the time management needed, using MPI. mpi-interface.[h,cc] - All MPI related processing is here in a single spot, rather than across several modules. buffer.[h,cc] - Added a "CreateLimitedCopy" function which is used when serializing packets for MPI. CreateLimitedCopy does not copy into the buffer the zero byte data of a packet; it only includes the number of bytes of zero byte data. packet.[h,cc] - Added new constructor for rebuilding packets that cross simulator boundaries. Also added serialization/deserialization for MPI. The formato for this is shown in the function comments. packet-metadata.[h,cc] - Added a rank id to the packet-metadata which corresponds to the LP that the packet belongs. A new constructor is also available which creates packet-metadata with a specific rank. This is necessary for when packets cross simulator boundaries, and the packet (and metadata) must be rebuilt. === I also have two issues I'd like to discuss here about the MPI code. 1) Enabling mpi using --with-mpi switch I have modified the wscript to accept a --with-mpi switch to compile with NS3_MPI included in CXXDEFINES. In order to compile correctly, the CXX environment variable must also be set to the path of mpic++. Right now I force the user to do this manually. For example, if they choose the --with-mpi switch, but don't have CXX set appropriately, WAF will exit and alert the user of the issue. Is there a way to set this environment variable automatically if --with-mpi is chosen and the mpic++ program is found? 2) MPI examples in examples/mpi/ These examples are not built automatically through WAF, as using MPI requires some additional setup. The examples must also be run with mpirun, rather than WAF. A README file exists in this directory which explains what must be done in order to run the MPI examples. I couldn't think of a good way to do this automatically, so that's why the examples are not built with WAF but a Makefile in their directory. Thanks, George Riley and Josh Pelkey From faker.moatamri at sophia.inria.fr Wed Nov 4 09:53:15 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 04 Nov 2009 18:53:15 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: <7B6315AD-7D0C-4AA8-A4C3-251A8579D03D@ece.gatech.edu> References: <4AE0601D.4050206@sophia.inria.fr> <4AE53860.2020909@tomh.org> <4AE5621A.8040001@sophia.inria.fr> <4AE8143E.2090104@sophia.inria.fr> <1256807972.13830.3.camel@localhost.localdomain> <4AE9601C.108@sophia.inria.fr> <4AE9B2D9.9030806@sophia.inria.fr> <4AE9BBC2.5050302@sophia.inria.fr> <4AEAADF1.5040508@sophia.inria.fr> <7B6315AD-7D0C-4AA8-A4C3-251A8579D03D@ece.gatech.edu> Message-ID: <4AF1BF8B.1050000@sophia.inria.fr> George Riley wrote: > I would say that anything belonging to "raj" can be removed, assuming > we do > have a backup somewhere. > Thanks george, I will remove them on friday 10 am GMT+1, if no one has objection on that. Mathieu, Guillaume what about the repositories under guillaume? What is to keep/archive/delete? Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Wed Nov 4 09:53:27 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 04 Nov 2009 18:53:27 +0100 Subject: [Ns-developers] MingWin compiling bug 705 In-Reply-To: <1DB473D7-ED00-4C84-892F-E845AB25BCF0@ece.gatech.edu> References: <4AF05C2C.1010607@sophia.inria.fr> <1DB473D7-ED00-4C84-892F-E845AB25BCF0@ece.gatech.edu> Message-ID: <4AF1BF97.9060908@sophia.inria.fr> Hi all, Please find attached a patch to make Mingw compile/Build. It contains already the changes done by Gustavo. Please review it and if no one disagrees, I will upload it to the server by friday. Best regards Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: mingw.patch Type: text/x-patch Size: 2874 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091104/7d0cf850/mingw.bin From guillaume.seguin at ens.fr Wed Nov 4 10:04:28 2009 From: guillaume.seguin at ens.fr (Guillaume Seguin) Date: Wed, 4 Nov 2009 19:04:28 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AF1BF8B.1050000@sophia.inria.fr> References: <1256807972.13830.3.camel@localhost.localdomain> <4AE9601C.108@sophia.inria.fr> <4AE9B2D9.9030806@sophia.inria.fr> <4AE9BBC2.5050302@sophia.inria.fr> <4AEAADF1.5040508@sophia.inria.fr> <7B6315AD-7D0C-4AA8-A4C3-251A8579D03D@ece.gatech.edu> <4AF1BF8B.1050000@sophia.inria.fr> Message-ID: <20091104180428.GB2588@clipper.ens.fr> On 04 nov. 2009 ? 18:53:15 (+0100), Faker Moatamri wrote : > Mathieu, Guillaume what about the repositories under guillaume? What is > to keep/archive/delete? I think you can archive ns-3-multithreading-old and delete ns-3-multithreading-new. I also think that ns-3-multithreading is not up to date, I'll check asap. Guillaume -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091104/86d0e363/attachment.bin From craigdo at ee.washington.edu Wed Nov 4 11:46:47 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 4 Nov 2009 11:46:47 -0800 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <1257331321.2541.17.camel@localhost.localdomain> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> <1257331321.2541.17.camel@localhost.localdomain> Message-ID: <001e01ca5d87$8bcfa5d0$a36ef170$@washington.edu> [ ... ] > supporting more platforms generally increases test coverage and improves the > quality of our codebase. I disagree. Supporting more Unix-like platforms *may* increase the quality of our codebase. It also may introduce hacks and special cases to compensate for bugs or different capabilities in the various platforms and compilers. Supporting something like MinGW will simply introduce complexity for no good reason as far as I can tell (if there is no great user demand for it). We'll have to make porting classes or special case code which increases the amount of code in the product and provides more paths that must be tested, not fewer. We'll need to introduce more special cases in wscripts (on "win32", for example to compensate for features not available in win32) which introduces more complexity that also must be tested. We'll introduce differences in the product that must be documented and tested for graceful degradation (see the product matrix I mentioned earlier). I think that having to factor the codebase more, and introducing special-case code that is rarely if ever run in the real world actually degrades the quality of our codebase. Why in the world would we want to do all of this to not officially support a platform virtually nobody uses? > I think that shipping a release which is known to not even compile on > mingw is generally not a good idea. Again, not because I care about > mingw but because not even compiling or passing basic sanity checks on > mingw is a sign of low code quality. I disagree. That is like saying that an application that is designed to run on, say KDE has low code quality because it does not run on Windows 7. That does not follow. It says that the application writers do not consider portability between Unix and Windows 7 important enough to write a portability layer or jump through the required hoops. There are things that are missing on MinGW and will never be there. If we want to write something that is really portable to MinGW/win32, we need to do a lot more than just accommodate '/' versus '\'. If we want a product that is portable to win32, then emulation code should be able to use Winsock, and the real-time scheduler should have a component that uses Windows CreateThread and WaitForSingleObject. I think it is an illusion to think that having some of our product compile on MinGW makes our code somehow better. What we end up with is a crippled win32 product and a bunch of special case code in the build. I could say the same thing about Cygwin, too; but it is at least pretending to be Unix-like and provides a modicum of Unix-ness so we don't have to deal with as many OS portability issues. It seems to me that we are really building a Linux product. If someone wants to do serious work, then that is really the only option since that is where you get real-time, emu, tap, NSC, simu, mysql, etc., etc. We are constantly asking, "What Would Linux Do" when thinking about how features should be implemented. There was talk some time ago about producing a general purpose simulator core product. Now, I think if we want to do that, or make a portable simulator subset, then it would be a good idea to define it and then build and test on wildly different OSes and run-times to ensure that we have something that really is OS *independent*. That seems to me to be a very different goal than simply making part of ns-3 work on MinGW, though. Anyway, my point is that I think we need to tighten up this story and clearly understand and state what the MinGW and portability story actually is. If MinGW is not supported, we need to stop saying so and acting as if it was. We need to state a real distinction between "supported" and "tested on" if we are going to imply a difference. If we are going to build and test it every night, we need to clearly state what we are implying by doing so. If someone checks in code that breaks on MinGW, we need to clearly state that either this is okay or not; and how bugs will be dealt with and with what priority. Having a buildbot report failure every night to ns-commits seems like a bad plan since it openly communicates poor quality of the entire project. -- Craig From mathieu.lacage at sophia.inria.fr Wed Nov 4 12:04:29 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 04 Nov 2009 21:04:29 +0100 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <001e01ca5d87$8bcfa5d0$a36ef170$@washington.edu> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> <1257331321.2541.17.camel@localhost.localdomain> <001e01ca5d87$8bcfa5d0$a36ef170$@washington.edu> Message-ID: <1257365069.3776.23.camel@localhost.localdomain> On Wed, 2009-11-04 at 11:46 -0800, craigdo at ee.washington.edu wrote: > I disagree. Supporting more Unix-like platforms *may* increase the quality > of our codebase. It also may introduce hacks and special cases to > compensate for bugs or different capabilities in the various platforms and > compilers. Supporting something like MinGW will simply introduce complexity > for no good reason as far as I can tell (if there is no great user demand > for it). Yes, mingw is not a unix platform but it's a gcc platform and that makes it orders of magnitude easier to support than a plain win32 system. i.e., it's not so far removed from a unix system. > Anyway, my point is that I think we need to tighten up this story and > clearly understand and state what the MinGW and portability story actually > is. If MinGW is not supported, we need to stop saying so and acting as if I do not think anyone said mingw is supported. > it was. We need to state a real distinction between "supported" and "tested > on" if we are going to imply a difference. If we are going to build and > test it every night, we need to clearly state what we are implying by doing > so. If someone checks in code that breaks on MinGW, we need to clearly > state that either this is okay or not; and how bugs will be dealt with and It is clearly ok to check in code which breaks mingw because it's not an officially supported platform _but_, as I said previously, it's not ok to summarily dismiss patches to fix mingw support on the grounds that it's not a supported platform and, just like every patch submitted by anyone, it is the duty of every maintainer to help contributors to put together a correct patch. I don't care about mingw personally, but I don't care about wifi block ack support either. However, in both cases, I will work with the relevant contributors to help them merge their code. i.e., I believe that when gustavo submits a patch to fix mingw support, the relevant maintainers should work with him just like they should work with every contributor to merge their patches in a timely manner. With that being said, I will stop sending emails about this: I think that I made my point pretty clearly. Whoever decides on the fate of mingw support will do so on their own. Mathieu From craigdo at ee.washington.edu Wed Nov 4 12:35:46 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 4 Nov 2009 12:35:46 -0800 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <1257365069.3776.23.camel@localhost.localdomain> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> <1257331321.2541.17.camel@localhost.localdomain> <001e01ca5d87$8bcfa5d0$a36ef170$@washington.edu> <1257365069.3776.23.camel@localhost.localdomain> Message-ID: <009a01ca5d8e$63f6d360$2be47a20$@washington.edu> > I do not think anyone said mingw is supported. This is from our current RELEASE_NOTES in ns-3-dev: Supported platforms ------------------- ns-3.4 has been tested on the following platforms: - linux x86 gcc 4.2, 4.1, and, 3.4.6. - linux x86_64 gcc 4.4.0, 4.3.2, 4.2.3, 4.2.1, 4.1.3, 3.4.6 - MacOS X ppc and x86 (gcc 4.0.x and 4.2.x) - cygwin gcc 3.4.4 (debug only), gcc 4.3.2 (debug and optimized) - mingw gcc 3.4.5 (debug only) And what triggered my email the other day was: > Gustavo, George, can you please make the patch in bug 705 work so that > we can keep on supporting Mingwin, hoping that other problems won't > arise? So, if it's not supported, we shouldn't say so; and we shouldn't build and test it every night, sending email to ns-commits saying it's broken. -- Craig From nbaldo at cttc.es Thu Nov 5 02:13:09 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 05 Nov 2009 11:13:09 +0100 Subject: [Ns-developers] Bug 602 status In-Reply-To: <1256917766.21755.13.camel@localhost.localdomain> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> <1256889694.17577.16.camel@localhost.localdomain> <4AEAB54E.8000708@cttc.es> <1256917766.21755.13.camel@localhost.localdomain> Message-ID: <4AF2A535.7040300@cttc.es> I'm summarizing my points on Bug 602 in the hope that we can agree on a solution within reasonable time... 1) I agree with Mirko that the idea of changing the implementation of WifiRemoteStationManager::Lookup() in wifi-remote-station-manager.cc (so that it checks for the tid in addition to the remote station address) does not work, since for example when you just received a RTS you don't know the TID, and hence you cannot pass it to Lookup (); 2) I understand that Mirko's patch is a working solution and that we currently don't have alternative proposals. However, I do not think it can go in as-is. My arguments are: 2a) I agree with Kirill's comment that just replicating variables (like m_voSsrc, m_viSsrc, m_beSsrc...) is not a very clean solution, I would prefer to see some data structure (map, vector...) indexed by AC instead of that. I understand that the number of AC in the standard is fixed, but I am supporting this solution for cleanness and readability of the code, not for flexibility. 2b) I like the new methods MacLow::ReportDataOk() and MacLow::ReportDataFailed(), however for homogeneity I would also like to see new methods MacLow::ReportRtsOk() and MacLow::ReportRtsFailed() Similarly, it would be nice to have EdcaTxOp::ReportFinalRtsFailed() and EdcaTxOp::ReportFinalDataFailed() 2c) There are several method declarations like this: void ReportRtsFailed (enum AccessClass ac = AC_BE_NQOS); quoting Mathieu: "gaaaah. No default values for method arguments. ever. Use overloading if you must." ;-) 2d) I do not know why, but in the patch I see that in wifi-remote-station-manager.h that a new copy of the content of the whole file is pasted at the end of the file itself... Regards, Nicola From nbaldo at cttc.es Thu Nov 5 02:21:04 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 05 Nov 2009 11:21:04 +0100 Subject: [Ns-developers] UniformDiscPositionAllocator Message-ID: <4AF2A710.8010606@cttc.es> Using RandomDiscPositionAllocator it is not straightforward to achieve a uniform distribution of nodes within the disc, basically because using a uniformly distributed rho doesn't do the job. Some time ago I posted a patch addressing this issue: http://www.nsnam.org/bugzilla/show_bug.cgi?id=672 I think it would be nice and easy to have it in ns-3.7, so I am asking for it to be reviewed. Nicola From nbaldo at cttc.es Thu Nov 5 02:29:48 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 05 Nov 2009 11:29:48 +0100 Subject: [Ns-developers] bug 668 Message-ID: <4AF2A91C.60902@cttc.es> Hi all, some time ago I posted a patch for bug 668: http://www.nsnam.org/bugzilla/show_bug.cgi?id=668 Mirko had a look at it and we had some discussion, but we did not reach any conclusion. Can we resume this discussion and see if the patch can go into ns-3.7? Regards From boyko at iitp.ru Thu Nov 5 02:54:41 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Thu, 5 Nov 2009 13:54:41 +0300 Subject: [Ns-developers] bug 668 In-Reply-To: <4AF2A91C.60902@cttc.es> References: <4AF2A91C.60902@cttc.es> Message-ID: <200911051354.41487.boyko@iitp.ru> On Thursday 05 November 2009 01:29:48 pm Nicola Baldo wrote: > Hi all, > > some time ago I posted a patch for bug 668: > > http://www.nsnam.org/bugzilla/show_bug.cgi?id=668 > > Mirko had a look at it and we had some discussion, but we did not reach > any conclusion. Can we resume this discussion and see if the patch can > go into ns-3.7? I vote for: 1) apply your patch 2) write comment to QosTag class, it can quote bug 668 discussion starting from "The exact translation between the UP and the TID being used ..." 3) move qos-tag.{h,cc} out of wifi (m.b. to src/node?) and 4) close bug 668 Pavel From faker.moatamri at sophia.inria.fr Thu Nov 5 02:57:01 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 05 Nov 2009 11:57:01 +0100 Subject: [Ns-developers] UniformDiscPositionAllocator In-Reply-To: <4AF2A710.8010606@cttc.es> References: <4AF2A710.8010606@cttc.es> Message-ID: <4AF2AF7D.6030902@sophia.inria.fr> Nicola Baldo wrote: > Using RandomDiscPositionAllocator it is not straightforward to achieve > a uniform distribution of nodes within the disc, basically because > using a uniformly distributed rho doesn't do the job. > First of all thanks for the patch. The patch looks good but needs some small and very fast clarifications: + +/** + * \brief allocate positions which are uniformly distributed within a + * disc of a given radius. Note that this is NOT equivalent to using + * a RandomDiscPositionAllocator with a uniformly-distributed rho. + */ Please tell the differences between them, what your new position allocator is adding. +class UniformDiscPositionAllocator : public PositionAllocator +{ +public: + static TypeId GetTypeId (void); + UniformDiscPositionAllocator (); + virtual ~UniformDiscPositionAllocator (); + please add some comments to explain that rho is the radius of the disc, and x and y are the coordinates of the center of the circle. + void SetRho (double rho); + void SetX (double x); + void SetY (double y); + + virtual Vector GetNext (void) const; +private: + double m_rho; + double m_x; + double m_y; +}; + > I think it would be nice and easy to have it in ns-3.7, so I am asking > for it to be reviewed. Yes sure, after those small changes you'll get +1 from me, Mathieu, what do you think? > > Nicola > > > From mathieu.lacage at sophia.inria.fr Thu Nov 5 03:30:09 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 05 Nov 2009 12:30:09 +0100 Subject: [Ns-developers] UniformDiscPositionAllocator In-Reply-To: <4AF2AF7D.6030902@sophia.inria.fr> References: <4AF2A710.8010606@cttc.es> <4AF2AF7D.6030902@sophia.inria.fr> Message-ID: <1257420609.4287.0.camel@localhost.localdomain> On Thu, 2009-11-05 at 11:57 +0100, Faker Moatamri wrote: > > I think it would be nice and easy to have it in ns-3.7, so I am asking > > for it to be reviewed. > Yes sure, after those small changes you'll get +1 from me, Mathieu, what > do you think? +1 Mathieu From mathieu.lacage at sophia.inria.fr Thu Nov 5 03:34:52 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 05 Nov 2009 12:34:52 +0100 Subject: [Ns-developers] bug 668 In-Reply-To: <4AF2A91C.60902@cttc.es> References: <4AF2A91C.60902@cttc.es> Message-ID: <1257420892.4287.4.camel@localhost.localdomain> The QosTag class was designed with the expectation that the user would know what he is doing and that he would be giving a tid directly there, not a UP. i.e., when we support TSPEC setup, the user could call directly the MAC to establish the TSPEC with required parameters, get the corresponding tid and set it in the qos tag of his application-level packets (This is how I implemented it in the old ns-2 wifi code I wrote originally). As far as I can tell, this is the only way to allow user applications control over the qos characteristics of an HCCA channel since there is no standardized way to convey the application requirements from the application down to the MAC layer. Mathieu On Thu, 2009-11-05 at 11:29 +0100, Nicola Baldo wrote: > Hi all, > > some time ago I posted a patch for bug 668: > > http://www.nsnam.org/bugzilla/show_bug.cgi?id=668 > > Mirko had a look at it and we had some discussion, but we did not reach > any conclusion. Can we resume this discussion and see if the patch can > go into ns-3.7? > > Regards From mathieu.lacage at sophia.inria.fr Thu Nov 5 03:47:50 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 05 Nov 2009 12:47:50 +0100 Subject: [Ns-developers] Bug 602 status In-Reply-To: <4AF2A535.7040300@cttc.es> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> <1256889694.17577.16.camel@localhost.localdomain> <4AEAB54E.8000708@cttc.es> <1256917766.21755.13.camel@localhost.localdomain> <4AF2A535.7040300@cttc.es> Message-ID: <1257421670.4287.13.camel@localhost.localdomain> On Thu, 2009-11-05 at 11:13 +0100, Nicola Baldo wrote: > I'm summarizing my points on Bug 602 in the hope that we can agree on a > solution within reasonable time... > > 1) I agree with Mirko that the idea of changing the implementation of > WifiRemoteStationManager::Lookup() in wifi-remote-station-manager.cc (so > that it checks for the tid in addition to the remote station address) > does not work, since for example when you just received a RTS you don't > know the TID, and hence you cannot pass it to Lookup (); I believe that you do know the tid: m_currentHdr.GetQosTid () is precisely what you need in that case. The main reason I dislike the approach currently implemented by mirko is that it makes it very hard to do the right thing in non-trivial rate control algorithms which override the NeedRtsRetransmission family of methods. i.e., implementing the approach nicola and myself suggested first is much more friendly to rate control algorithm implementors which is why I am so reluctant to go towards the solution proposed by mirko. Another reason I am still reluctant with mirko's original proposal is that I don't see what is the implementation problem of implementing the solution I proposed. Mathieu From mk.banchi at gmail.com Thu Nov 5 04:11:27 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 5 Nov 2009 13:11:27 +0100 Subject: [Ns-developers] Bug 602 status In-Reply-To: <1257421670.4287.13.camel@localhost.localdomain> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> <1256889694.17577.16.camel@localhost.localdomain> <4AEAB54E.8000708@cttc.es> <1256917766.21755.13.camel@localhost.localdomain> <4AF2A535.7040300@cttc.es> <1257421670.4287.13.camel@localhost.localdomain> Message-ID: <71E1F3CA-DB00-4A0A-BA1A-082645E7A5A2@gmail.com> Il giorno 05/nov/09, alle ore 12:47, Mathieu Lacage ha scritto: > On Thu, 2009-11-05 at 11:13 +0100, Nicola Baldo wrote: >> I'm summarizing my points on Bug 602 in the hope that we can agree >> on a >> solution within reasonable time... >> >> 1) I agree with Mirko that the idea of changing the implementation of >> WifiRemoteStationManager::Lookup() in wifi-remote-station- >> manager.cc (so >> that it checks for the tid in addition to the remote station address) >> does not work, since for example when you just received a RTS you >> don't >> know the TID, and hence you cannot pass it to Lookup (); > > I believe that you do know the tid: m_currentHdr.GetQosTid () is > precisely what you need in that case. > > The main reason I dislike the approach currently implemented by > mirko is > that it makes it very hard to do the right thing in non-trivial rate > control algorithms which override the NeedRtsRetransmission family of > methods. i.e., implementing the approach nicola and myself suggested > first is much more friendly to rate control algorithm implementors > which > is why I am so reluctant to go towards the solution proposed by mirko. > Another reason I am still reluctant with mirko's original proposal is > that I don't see what is the implementation problem of implementing > the > solution I proposed. > Hi Mathieu, as Nicola suggested, when we receive an RTS we don't know for wich tid it was received. So, for example, how would you call WifiRemoteStationManager::Lookup method in MacLow::GetCtsTxModeForRts function? I think that there are a lot of problems like this. If you have ideas or proposal in order to resolve these problems they are welcome. 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/20091105/f5281e76/smime-0001.bin From nbaldo at cttc.es Thu Nov 5 05:04:41 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 05 Nov 2009 14:04:41 +0100 Subject: [Ns-developers] Bug 602 status In-Reply-To: <1257421670.4287.13.camel@localhost.localdomain> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> <1256889694.17577.16.camel@localhost.localdomain> <4AEAB54E.8000708@cttc.es> <1256917766.21755.13.camel@localhost.localdomain> <4AF2A535.7040300@cttc.es> <1257421670.4287.13.camel@localhost.localdomain> Message-ID: <4AF2CD69.3070209@cttc.es> Hi Mathieu, Mathieu Lacage wrote: > On Thu, 2009-11-05 at 11:13 +0100, Nicola Baldo wrote: >> I'm summarizing my points on Bug 602 in the hope that we can agree on a >> solution within reasonable time... >> >> 1) I agree with Mirko that the idea of changing the implementation of >> WifiRemoteStationManager::Lookup() in wifi-remote-station-manager.cc (so >> that it checks for the tid in addition to the remote station address) >> does not work, since for example when you just received a RTS you don't >> know the TID, and hence you cannot pass it to Lookup (); > > I believe that you do know the tid: m_currentHdr.GetQosTid () is > precisely what you need in that case. Just have a look at what happens when we receive an RTS: MacLow::ReceiveOk (...) { WifiMacHeader hdr; packet->RemoveHeader (hdr); bool isPrevNavZero = IsNavZero (); NS_LOG_DEBUG ("duration/id=" << hdr.GetDuration ()); NotifyNav (hdr, txMode, preamble); if (hdr.IsRts ()) { if (isPrevNavZero && hdr.GetAddr1 () == m_self) { // the current code does this: // WifiRemoteStation *station = GetStation (hdr.GetAddr2 ()); // the proposed code would do this: WifiRemoteStation *station = GetStation (hdr.GetAddr2 (), hdr.GetQosTid ()); *BANG!* an assertion fails. Why? uint8_t WifiMacHeader::GetQosTid (void) const { NS_ASSERT (IsQosData ()); return m_qosTid; } the QosTid field is not present in RTS frames. > > The main reason I dislike the approach currently implemented by mirko is > that it makes it very hard to do the right thing in non-trivial rate > control algorithms which override the NeedRtsRetransmission family of > methods. i.e., implementing the approach nicola and myself suggested > first is much more friendly to rate control algorithm implementors which > is why I am so reluctant to go towards the solution proposed by mirko. So if I understand correctly you are talking about the fact that, with Mirko's patch, Ssrc counters are per AC, but there would be only one WifiRemoteStationManager for all ACs, which would then receive all notifications (such as ReportRtsFailed) for all ACs jointly. This breaks how some rate adaptation algorithms work, unless we make all managers AC-aware, which I agree is not a good idea. Mmmmmmhhhhhh. After these considerations, neither of the proposed solutions for bug 602 appears to be acceptable :-( any ideas? Regards, Nicola From mk.banchi at gmail.com Thu Nov 5 07:54:55 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 5 Nov 2009 16:54:55 +0100 Subject: [Ns-developers] Bug 602 status In-Reply-To: <4AF2CD69.3070209@cttc.es> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> <1256889694.17577.16.camel@localhost.localdomain> <4AEAB54E.8000708@cttc.es> <1256917766.21755.13.camel@localhost.localdomain> <4AF2A535.7040300@cttc.es> <1257421670.4287.13.camel@localhost.localdomain> <4AF2CD69.3070209@cttc.es> Message-ID: <7F9AC4CB-7091-4250-ADC8-28635B173DC2@gmail.com> Il giorno 05/nov/09, alle ore 14:04, Nicola Baldo ha scritto: > Hi Mathieu, > > Mathieu Lacage wrote: >> On Thu, 2009-11-05 at 11:13 +0100, Nicola Baldo wrote: >>> I'm summarizing my points on Bug 602 in the hope that we can agree >>> on a solution within reasonable time... >>> >>> 1) I agree with Mirko that the idea of changing the implementation >>> of WifiRemoteStationManager::Lookup() in wifi-remote-station- >>> manager.cc (so that it checks for the tid in addition to the >>> remote station address) does not work, since for example when you >>> just received a RTS you don't know the TID, and hence you cannot >>> pass it to Lookup (); >> I believe that you do know the tid: m_currentHdr.GetQosTid () is >> precisely what you need in that case. > > Just have a look at what happens when we receive an RTS: > > MacLow::ReceiveOk (...) > { > WifiMacHeader hdr; > packet->RemoveHeader (hdr); > > bool isPrevNavZero = IsNavZero (); > NS_LOG_DEBUG ("duration/id=" << hdr.GetDuration ()); > NotifyNav (hdr, txMode, preamble); > if (hdr.IsRts ()) > { > if (isPrevNavZero && > hdr.GetAddr1 () == m_self) > { > // the current code does this: > // WifiRemoteStation *station = GetStation (hdr.GetAddr2 ()); > > // the proposed code would do this: > WifiRemoteStation *station = GetStation (hdr.GetAddr2 (), > hdr.GetQosTid ()); > > > *BANG!* an assertion fails. Why? > > > uint8_t > WifiMacHeader::GetQosTid (void) const > { > NS_ASSERT (IsQosData ()); > return m_qosTid; > } > > > the QosTid field is not present in RTS frames. > > > >> The main reason I dislike the approach currently implemented by >> mirko is >> that it makes it very hard to do the right thing in non-trivial rate >> control algorithms which override the NeedRtsRetransmission family of >> methods. i.e., implementing the approach nicola and myself suggested >> first is much more friendly to rate control algorithm implementors >> which >> is why I am so reluctant to go towards the solution proposed by >> mirko. > > So if I understand correctly you are talking about the fact that, > with Mirko's patch, Ssrc counters are per AC, but there would be > only one WifiRemoteStationManager for all ACs, which would then > receive all notifications (such as ReportRtsFailed) for all ACs > jointly. This breaks how some rate adaptation algorithms work, > unless we make all managers AC-aware, which I agree is not a good > idea. Mmmmmmhhhhhh. > > > After these considerations, neither of the proposed solutions for > bug 602 appears to be acceptable :-( any ideas? > I really think that there is a problem to find a solution only changing WifiRemoteStationManager::Lookup method. Regards, 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/20091105/20c2daef/smime.bin From jpelkey at gatech.edu Thu Nov 5 08:37:38 2009 From: jpelkey at gatech.edu (jpelkey@gatech.edu) Date: Thu, 5 Nov 2009 11:37:38 -0500 (EST) Subject: [Ns-developers] Net-anim for ns-3.7 In-Reply-To: <697199909.562991257438954300.JavaMail.root@mail8.gatech.edu> Message-ID: <1663555460.563421257439058155.JavaMail.root@mail8.gatech.edu> Hi all, Last release, Net-anim was merged under src/contrib. One of the main reasons this occurred was because we released the patch so close to the merge deadline. Since then, we have made a few minor updates, and we would like it to be considered for merge under the main folders. I have created a patch for this on appspot: http://codereview.appspot.com/117051 Note, after applying the patch, the empty src/contrib/net-anim directory should be removed. Also, since the discussion on MinGW, I have included the #ifdefs that Faker merged recently. I am not 100% confident that I modified the wscripts correctly. I modified the src/helper and src/ wscripts. Summary of changes: - Added an animation folder under examples with test-dumbbell and test-grid animation scripts - Moved files from src/contrib/net-anim to src/helper (excluding the examples) - Modified the src/helper wscript and src/ wscript to allow the ifdefs in animation-interface.cc (for MinGW) Thanks, George Riley and Josh Pelkey From mathieu.lacage at sophia.inria.fr Thu Nov 5 12:11:17 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 05 Nov 2009 21:11:17 +0100 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <009a01ca5d8e$63f6d360$2be47a20$@washington.edu> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> <1257331321.2541.17.camel@localhost.localdomain> <001e01ca5d87$8bcfa5d0$a36ef170$@washington.edu> <1257365069.3776.23.camel@localhost.localdomain> <009a01ca5d8e$63f6d360$2be47a20$@washington.edu> Message-ID: <1257451877.3658.3.camel@localhost.localdomain> On Wed, 2009-11-04 at 12:35 -0800, craigdo at ee.washington.edu wrote: > So, if it's not supported, we shouldn't say so; and we shouldn't build and > test it every night, sending email to ns-commits saying it's broken. I am perfectly fine with making RELEASE_NOTES reflect more accurately the current status of testing of ns-3, but I don't really see the point of disabling actually useful automated testing. Who other than a handful of developers actually read the buildbot emails ? Mathieu From mathieu.lacage at sophia.inria.fr Thu Nov 5 12:14:55 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 05 Nov 2009 21:14:55 +0100 Subject: [Ns-developers] Bug 602 status In-Reply-To: <71E1F3CA-DB00-4A0A-BA1A-082645E7A5A2@gmail.com> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> <1256889694.17577.16.camel@localhost.localdomain> <4AEAB54E.8000708@cttc.es> <1256917766.21755.13.camel@localhost.localdomain> <4AF2A535.7040300@cttc.es> <1257421670.4287.13.camel@localhost.localdomain> <71E1F3CA-DB00-4A0A-BA1A-082645E7A5A2@gmail.com> Message-ID: <1257452095.3658.7.camel@localhost.localdomain> On Thu, 2009-11-05 at 13:11 +0100, Mirko Banchi wrote: > as Nicola suggested, when we receive an RTS we don't know for wich tid > it was received. So, for example, how would you call > WifiRemoteStationManager::Lookup method in MacLow::GetCtsTxModeForRts Ok, I see: thanks for the clarification. > function? I think that there are a lot of problems like this. If you What is the exact list of problems beyond this one ? Could you be more specific ? > have ideas or proposal in order to resolve these problems they are > welcome. I will think about this some more. Thanks for reminding us all of this issue and for pushing for a solution. Mathieu From craigdo at ee.washington.edu Thu Nov 5 15:12:23 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 5 Nov 2009 15:12:23 -0800 Subject: [Ns-developers] Is MinGW Supported or Not? (was RE: MingWin compiling bug 705) In-Reply-To: <1257451877.3658.3.camel@localhost.localdomain> References: <4AF05C2C.1010607@sophia.inria.fr> <001201ca5cb4$86930090$93b901b0$@washington.edu> <51643.193.251.48.82.1257280378.squirrel@imap-sop.inria.fr> <1257331321.2541.17.camel@localhost.localdomain> <001e01ca5d87$8bcfa5d0$a36ef170$@washington.edu> <1257365069.3776.23.camel@localhost.localdomain> <009a01ca5d8e$63f6d360$2be47a20$@washington.edu> <1257451877.3658.3.camel@localhost.localdomain> Message-ID: <00ef01ca5e6d$6eda0ab0$a3d75f80@ee.washington.edu> [ ... ] > I am perfectly fine with making RELEASE_NOTES reflect more accurately > the current status of testing of ns-3, but I don't really see > the point > of disabling actually useful automated testing. Who other > than a handful > of developers actually read the buildbot emails ? It's a question of "false positive" reports on ns-commits and access to the false positive reports on the web through the waterfall report. MinGW is a bright red light on the waterfall report saying that the build is broken. It stands out starkly. The link is to the waterfall is at the top of: http://www.nsnam.org/wiki/index.php/Main_Page You can also get to the test.py-generated HTML from there. I talked to Faker about moving to positive acknowledgements from the buildbots -- that is, they send out success of failure messages whenever they run. This avoids situations where a buildbot has simply not been working for days or weeks and nobody notices since its failed state doesn't change. If I see a bunch of emails from the various buildbots saying "success" I get warm fuzzy feelings. Whenever I see "failed" I basically stop what I'm doing and investigate to see if there's something I need to do. If I'm looking in from the outside, I might wonder why this particular build is failing every time I look at the status. I think it is fine to run the tests, but I'm not sure about sending out email all the time saying it's broken, or adding a red light to the waterfall display saying it's broken. -- Craig From faker.moatamri at sophia.inria.fr Fri Nov 6 01:06:01 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 06 Nov 2009 10:06:01 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: <20091104180428.GB2588@clipper.ens.fr> References: <1256807972.13830.3.camel@localhost.localdomain> <4AE9601C.108@sophia.inria.fr> <4AE9B2D9.9030806@sophia.inria.fr> <4AE9BBC2.5050302@sophia.inria.fr> <4AEAADF1.5040508@sophia.inria.fr> <7B6315AD-7D0C-4AA8-A4C3-251A8579D03D@ece.gatech.edu> <4AF1BF8B.1050000@sophia.inria.fr> <20091104180428.GB2588@clipper.ens.fr> Message-ID: <4AF3E6F9.5050904@sophia.inria.fr> Guillaume Seguin wrote: > > I think you can archive ns-3-multithreading-old and delete > ns-3-multithreading-new. I also think that ns-3-multithreading is not up to > date, I'll check asap. > > Guillaume > Hi all, Hi Guillaume, As promised, I removed raj/ repositories Removed ns-3-multithreading-new I will leave ns-3-multithreading-old in the repositories until it got old enough to be moved to archive, unless you are sure that no one will use it. For ns-3-multithreading I will wait until you tell me if it is out of date or not. Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Fri Nov 6 06:43:27 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 06 Nov 2009 15:43:27 +0100 Subject: [Ns-developers] MPI for ns-3 In-Reply-To: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> References: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> Message-ID: <4AF4360F.9080002@sophia.inria.fr> jpelkey at gatech.edu wrote: > Hi all, > > We have the distributed MPI code ready for review. Below is an > overview of the code and the changes made. > > http://codereview.appspot.com/109068/show > > I did a review to your code, please find my messages in http://codereview.appspot.com/109068/show > I also have two issues I'd like to discuss here about the MPI code. > > 1) Enabling mpi using --with-mpi switch > I have modified the wscript to accept a --with-mpi switch to compile > with NS3_MPI included in CXXDEFINES. In order to compile correctly, > the CXX environment variable must also be set to the path of mpic++. > Right now I force the user to do this manually. For example, if they > choose the --with-mpi switch, but don't have CXX set appropriately, > WAF will exit and alert the user of the issue. Is there a way to set > this environment variable automatically if --with-mpi is chosen and the > mpic++ program is found? > 2) MPI examples in examples/mpi/ > These examples are not built automatically through WAF, as using MPI > requires some additional setup. The examples must also be run with > mpirun, rather than WAF. A README file exists in this directory > which explains what must be done in order to run the MPI examples. > I couldn't think of a good way to do this automatically, so that's > why the examples are not built with WAF but a Makefile in their > directory. > Gustavo, can you please give him an answer (if possible) for those two questions? > Thanks, > George Riley and Josh Pelkey > From gjcarneiro at gmail.com Fri Nov 6 07:12:36 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 6 Nov 2009 15:12:36 +0000 Subject: [Ns-developers] MPI for ns-3 In-Reply-To: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> References: <909776950.303191257349681246.JavaMail.root@mail8.gatech.edu> <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> Message-ID: 2009/11/4 > Hi all, > > We have the distributed MPI code ready for review. Below is an > overview of the code and the changes made. > > http://codereview.appspot.com/109068/show > > === > Overview [updated 2 Nov 2009]. The distributed simulation code is > designed to allow a single topology to be split into "n" > sub-topologies and executed on "n" linux boxes in a distributed > memory environment. The current implementation only allows packets > sent across point-to-point links to be sent across simulator > boundaries; the next release will support wireless we hope. > We tried to change as little as possible of the existing code base > and isolate our changes in separate modules where possible. > > Details. > point-to-point-channel.[h,cc] - Made TransmitStart virtual so the > new subclass (see below) can override. > > point-to-point-remote-channel.[h,cc] - new subclass of p2p channel; > used to connect simulated nodes on one simulator to nodes on a > separate simulator. Overrides the TransmitStart function and > uses MPI to send the packet across simulator processes. > > point-to-point-helper.[h,cc]. Checks the system id on the two nodes > being connected, and uses a p2p-remote-channel rather than a p2p-channel > if the system id's do not match. > > node.[h,cc] - Added a "SetSystemId" function, to allow the system id to > be set after the node is constructed, rather than passing parameter > to constructor; this exists because there was no way to use > non-default constructors on object creation. I believe this might have > been fixed since then, so perhaps this might not be neded. > > global-route-manager.cc - Do not compute routes for any node whose > system-id > does not match the simulator's system id. Clearly, we don't need to > compute routes in simulator A for nodes modeled in simulator B. > > default-simulator-impl.[h.cc] = Added virtual "GetSystemId" method, > which returns the system id (MPI rank) of this process. For > the default-simulator object it always returns zero. > > distributed-simulator-impl.[h.cc] - new subclass of default-simulator-impl. > THe meat of this is the overridden "run" method that handles all of > the time management needed, using MPI. > > mpi-interface.[h,cc] - All MPI related processing is here in a single > spot, rather than across several modules. > > buffer.[h,cc] - Added a "CreateLimitedCopy" function which is used when > serializing packets for MPI. CreateLimitedCopy does not copy into the > buffer > the zero byte data of a packet; it only includes the number of bytes of > zero > byte data. > > packet.[h,cc] - Added new constructor for rebuilding packets that cross > simulator boundaries. Also added serialization/deserialization for MPI. > The formato for this is shown in the function comments. > > packet-metadata.[h,cc] - Added a rank id to the packet-metadata which > corresponds to > the LP that the packet belongs. A new constructor is also available which > creates > packet-metadata with a specific rank. This is necessary for when packets > cross simulator > boundaries, and the packet (and metadata) must be rebuilt. > === > > I also have two issues I'd like to discuss here about the MPI code. > > 1) Enabling mpi using --with-mpi switch > I have modified the wscript to accept a --with-mpi switch to compile > with NS3_MPI included in CXXDEFINES. In order to compile correctly, > the CXX environment variable must also be set to the path of mpic++. > Right now I force the user to do this manually. For example, if they > choose the --with-mpi switch, but don't have CXX set appropriately, > WAF will exit and alert the user of the issue. Is there a way to set > this environment variable automatically if --with-mpi is chosen and the > mpic++ program is found? > What does this mpic++ do? Do you have to compile every source file with it, or just selected source files? You can modify CXX on a per "taskgen" basis, for example: obj = bld.create_ns3_program('csma-bridge', ['bridge', 'csma', 'internet-stack']) obj.source = 'csma-bridge.cc' obj.env['CXX'] = '/usr/bin/mpic++' # <<< added To make this conditional, run a configure check: def configure(conf): conf.find_program('mpic++', var='MPICXX') def build(bld): obj = bld.create_task_gen(...) if obj.env['MIPCXX']: obj.env['CXX'] = 'MPICXX' Or something like this... > > 2) MPI examples in examples/mpi/ > These examples are not built automatically through WAF, as using MPI > requires some additional setup. The examples must also be run with > mpirun, rather than WAF. A README file exists in this directory > which explains what must be done in order to run the MPI examples. > I couldn't think of a good way to do this automatically, so that's > why the examples are not built with WAF but a Makefile in their > directory. > I can't imagine why building with WAF is harder than with Makefile. Surely we have example code already using external libraries, such as gtk+2 or sqlite. Can you be more specific on what you don't know how to do? As for running with mpirun, I suppose we could modify waf --run to call mpirun when mpi is enabled. If you are unable to do it, give me a mercurial branch URL (I need code that I can build and extend, none of this review stuff) and I'll post a patch. Anyway, the modifications should be similar to what is already done with the --valgrind option, which modifies --run to run via valgrind. Hope this helps. Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mathieu.lacage at sophia.inria.fr Fri Nov 6 07:46:20 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 06 Nov 2009 16:46:20 +0100 Subject: [Ns-developers] Pybindgen error ==> Buildbot errors In-Reply-To: References: <4AE569D7.5070309@sophia.inria.fr> <4AE5D155.9070805@sophia.inria.fr> Message-ID: <1257522380.6775.9.camel@localhost.localdomain> On Mon, 2009-10-26 at 18:02 +0000, Gustavo Carneiro wrote: > >> I'm sorry, pybindgen simply was not designed to be used like this. It > >> does not come with a waf script because it assumes developers can manage to > >> get waf (which is not the upstream waf, it's a mini-fork), and in the > >> distribution tarballs waf is included for end users. > >> > >> You could try to copy the whole folder, waf-tools, into pybindgen. Or you > >> could just grab waf from a pybindgen 0.12 release and copy/use that one. > >> > >> This didn't work :-( > > > I'm pretty sure that at least dropping waf copied from pybindgen 0.12 _has_ > to work, otherwise how would pybindgen releases be able to work at all for > end users? You must be doing something wrong. Please keep in mind there > are many binaries out there called 'waf' and containing very different waf > versions, even incompatible ones. pybindgen bazaar branches will work with > waf from pybindgen 0.12 or from ns-3.6, but not any other waf. To make that less painful for users (including me: I just got bitten by the fact that the waf required by pybindgen is incompatible with the waf required by ns-3-dev), please, could you store in your bazaar repo a copy of the _right_ waf binary just like we do in ns-3 ? Please ? Mathieu From mathieu.lacage at sophia.inria.fr Fri Nov 6 08:13:54 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 06 Nov 2009 17:13:54 +0100 Subject: [Ns-developers] Pybindgen error ==> Buildbot errors In-Reply-To: <1257522380.6775.9.camel@localhost.localdomain> References: <4AE569D7.5070309@sophia.inria.fr> <4AE5D155.9070805@sophia.inria.fr> <1257522380.6775.9.camel@localhost.localdomain> Message-ID: <1257524034.6775.40.camel@localhost.localdomain> On Fri, 2009-11-06 at 16:46 +0100, Mathieu Lacage wrote: > On Mon, 2009-10-26 at 18:02 +0000, Gustavo Carneiro wrote: > > > >> I'm sorry, pybindgen simply was not designed to be used like this. It > > >> does not come with a waf script because it assumes developers can manage to > > >> get waf (which is not the upstream waf, it's a mini-fork), and in the > > >> distribution tarballs waf is included for end users. > > >> > > >> You could try to copy the whole folder, waf-tools, into pybindgen. Or you > > >> could just grab waf from a pybindgen 0.12 release and copy/use that one. > > >> > > >> This didn't work :-( > > > > > > I'm pretty sure that at least dropping waf copied from pybindgen 0.12 _has_ > > to work, otherwise how would pybindgen releases be able to work at all for > > end users? You must be doing something wrong. Please keep in mind there > > are many binaries out there called 'waf' and containing very different waf > > versions, even incompatible ones. pybindgen bazaar branches will work with > > waf from pybindgen 0.12 or from ns-3.6, but not any other waf. > > To make that less painful for users (including me: I just got bitten by > the fact that the waf required by pybindgen is incompatible with the waf > required by ns-3-dev), please, could you store in your bazaar repo a > copy of the _right_ waf binary just like we do in ns-3 ? Please ? I should have pointed out that I did try your suggestion of taking waf from pybindgen 0.12 or ns-3.6: none of them worked and ns-3-dev appears unable to work with pybindgen 0.12 (--with-pybindgen=../pybindgen-0.12 seems to have no effect on pybindgen detection). How are we supposed to use pybindgen with ns-3-dev ? Mathieu From mathieu.lacage at sophia.inria.fr Fri Nov 6 08:36:35 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 06 Nov 2009 17:36:35 +0100 Subject: [Ns-developers] pybindgen buildbot silently failing Message-ID: <1257525395.6775.77.camel@localhost.localdomain> hi, I noticed the following while trying to do this by hand but "bzr up" no longer works: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B% 2B-4.2.4/builds/217/steps/shell_2/logs/stdio it looks like the canonical guys did upgrade some kind of server-side config which is incompatible with a old bazaar repos. I managed a rm -rf pybindgen && bzr clone to work around this. This is especially annoying because that stupid bzr is not returning an error code: it's just printing a warning even though the requested operation failed. I guess that someone needs to go to each buildbot slave and rm -rf their pybindgen repo. Mathieu From c.facchini at gmail.com Thu Nov 5 09:06:44 2009 From: c.facchini at gmail.com (Christian Facchini) Date: Thu, 5 Nov 2009 15:06:44 -0200 Subject: [Ns-developers] Cross-layer entity development Message-ID: <152433f30911050906jea5501dv26adf835a7aedcb0@mail.gmail.com> Dear list, I am trying to develop a 'cross-layer entity' for ns-3. Such entity does not really belong to any layer of a node's communication stack. Instead, it is a separate entity, "parallel" to the communication stack, receiving inputs from and providing feedback to the various layers (much like the architecture of fig. 2b in V. Srivastava and M. Motani, ?Cross-Layer Design: A Survey and the Road Ahead,? IEEE Comm. Mag., vol. 43, 2005, pp. 112-119). Some key features I would like to implement are: - the capability of being triggered by some events (a variation in some traced variable, a variation in some attribute set via Config::Set during the simulation, etc.) - the capability of setting some simulation parameters (the best way I think is to use Config::Set) as the simulation goes What would be the best way to do it? I have read chapter 15 of the manual, explaining how to create new ns-3 modules, still I am unsure about how to proceed. In particular, I do not think it makes sense to build such an entity by inheriting from the class Object. Or am I wrong? As far as I can tell, it would only need to be inside the ns3 namespace. Any hint on the subject is highly appreciated. Best regards, Christian From gjcarneiro at gmail.com Fri Nov 6 09:10:13 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 6 Nov 2009 17:10:13 +0000 Subject: [Ns-developers] Cross-layer entity development In-Reply-To: <152433f30911050906jea5501dv26adf835a7aedcb0@mail.gmail.com> References: <152433f30911050906jea5501dv26adf835a7aedcb0@mail.gmail.com> Message-ID: 2009/11/5 Christian Facchini > Dear list, > > I am trying to develop a 'cross-layer entity' for ns-3. > Such entity does not really belong to any layer of a node's > communication stack. Instead, it is a separate entity, "parallel" to > the communication stack, receiving inputs from and providing feedback > to the various layers (much like the architecture of fig. 2b in V. > Srivastava and M. Motani, ?Cross-Layer Design: A Survey and the Road > Ahead,? IEEE Comm. Mag., vol. 43, 2005, pp. 112-119). > > Some key features I would like to implement are: > - the capability of being triggered by some events (a variation in > some traced variable, a variation in some attribute set via > Config::Set during the simulation, etc.) > See Config::Connect and ObjectBase::TraceConnect. > - the capability of setting some simulation parameters (the best > way I think is to use Config::Set) as the simulation goes > Yes, see Config::Set and ObjectBase::SetAttribute. > > What would be the best way to do it? > I have read chapter 15 of the manual, explaining how to create new > ns-3 modules, still I am unsure about how to proceed. > In particular, I do not think it makes sense to build such an entity > by inheriting from the class Object. Or am I wrong? > IMHO you are wrong. I would do a crosslayer manager precisely by subclassing Object and aggregating an instance of that class to each Node (via Object::AggregateObject). This is a good approach because it makes your crosslayer manager discoverable and binds its lifetime to the lifetime of the node. > As far as I can tell, it would only need to be inside the ns3 namespace. > What do you mean by ns3 namespace? C++ namespace, or Config namespace? Why? > > Any hint on the subject is highly appreciated. > Besides the Object subclass, you might want to create a helper class that has Install* methods, similar to the way InternetStackHelper works. -- 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 Fri Nov 6 09:31:14 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 6 Nov 2009 17:31:14 +0000 Subject: [Ns-developers] Pybindgen error ==> Buildbot errors In-Reply-To: <1257524034.6775.40.camel@localhost.localdomain> References: <4AE569D7.5070309@sophia.inria.fr> <4AE5D155.9070805@sophia.inria.fr> <1257522380.6775.9.camel@localhost.localdomain> <1257524034.6775.40.camel@localhost.localdomain> Message-ID: 2009/11/6 Mathieu Lacage > On Fri, 2009-11-06 at 16:46 +0100, Mathieu Lacage wrote: > > On Mon, 2009-10-26 at 18:02 +0000, Gustavo Carneiro wrote: > > > > > >> I'm sorry, pybindgen simply was not designed to be used like this. > It > > > >> does not come with a waf script because it assumes developers can > manage to > > > >> get waf (which is not the upstream waf, it's a mini-fork), and in > the > > > >> distribution tarballs waf is included for end users. > > > >> > > > >> You could try to copy the whole folder, waf-tools, into pybindgen. > Or you > > > >> could just grab waf from a pybindgen 0.12 release and copy/use that > one. > > > >> > > > >> This didn't work :-( > > > > > > > > > I'm pretty sure that at least dropping waf copied from pybindgen 0.12 > _has_ > > > to work, otherwise how would pybindgen releases be able to work at all > for > > > end users? You must be doing something wrong. Please keep in mind > there > > > are many binaries out there called 'waf' and containing very different > waf > > > versions, even incompatible ones. pybindgen bazaar branches will work > with > > > waf from pybindgen 0.12 or from ns-3.6, but not any other waf. > > > > To make that less painful for users (including me: I just got bitten by > > the fact that the waf required by pybindgen is incompatible with the waf > > required by ns-3-dev), please, could you store in your bazaar repo a > > copy of the _right_ waf binary just like we do in ns-3 ? Please ? > > I should have pointed out that I did try your suggestion of taking waf > from pybindgen 0.12 or ns-3.6: none of them worked and ns-3-dev appears > unable to work with pybindgen 0.12 (--with-pybindgen=../pybindgen-0.12 > seems to have no effect on pybindgen detection). How are we supposed to > use pybindgen with ns-3-dev ? > You did something wrong; waf from pybindgen 0.12 works. I just checked. The error you are seeing is probably ns-3 requiring not version 0.12.0 but some later version that wasn't released yet. OK, if this is causing so much problem, I am not a unreasonable person. WAF was added to the pybindgen repository. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From jpelkey at gatech.edu Fri Nov 6 12:17:54 2009 From: jpelkey at gatech.edu (Josh Pelkey) Date: Fri, 6 Nov 2009 15:17:54 -0500 Subject: [Ns-developers] MPI for ns-3 In-Reply-To: References: <909776950.303191257349681246.JavaMail.root@mail8.gatech.edu> <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> Message-ID: <688a18330911061217l7ca260ackc196f4e546e43d8e@mail.gmail.com> Thanks for the comments Faker and Gustavo. I'll be fixing up the code more over the next few days and will re-post. Gustavo, I will try to answer your questions below. > What does this mpic++ do? mpic++ is simply a wrapper around the underlying C++ compiler. Open MPI programs require some MPI specific libraries as well as some header files which may not be in a standard location. In short, it is easiest to just compile everything with mpic++ when --with-mpi is selected. The main issue I was having is automatically setting the CXX environment variable if --with-mpi was selected and the mpic++ program was found. I do suppose it would be possible to individually select which files should be compiled with mpic++, but again, I think it is just easiest to compile everything when --with-mpi is selected, since this will not affect non-MPI code in any way. > I can't imagine why building with WAF is harder than with Makefile. You are probably right here. I am just unsure of how to do this. There are two separate issues. First, the LD_LIBRARY_PATH needs to be set to the path of the ns-3 build directory before the examples are run with mpirun. Otherwise, mpirun can't find libns3.so. So I guess this is another case where I am wondering if we can automatically set environment variables when --with-mpi is selected. The second issue is mpirun. I know you mentioned that this could be done in much the same way as valgrind, but again, I am unfamiliar with this process. I'll just explain what needs to happen first. mpirun is expecting a number of command line arguments including the number of logical processors (among other things). So I guess the question is, can this be built into WAF? Something like ./waf --run --mpirun -np 2 ./test-distributed --NIX=0. In this case, the "np" argument is for the number of logical processors, and must be passed into mpirun. "test-distributed" is the user script that must be run with mpirun, accepting its own command line arguments. I imagine this is very possible, but I'm just not sure how to do it. Also, my mercurial branch is here: http://code.nsnam.org/jpelkey3/ns-3-distributed/ Thanks again, Josh Pelkey On Fri, Nov 6, 2009 at 10:12 AM, Gustavo Carneiro wrote: > > > 2009/11/4 > > Hi all, >> >> We have the distributed MPI code ready for review. Below is an >> overview of the code and the changes made. >> >> http://codereview.appspot.com/109068/show >> >> === >> Overview [updated 2 Nov 2009]. The distributed simulation code is >> designed to allow a single topology to be split into "n" >> sub-topologies and executed on "n" linux boxes in a distributed >> memory environment. The current implementation only allows packets >> sent across point-to-point links to be sent across simulator >> boundaries; the next release will support wireless we hope. >> We tried to change as little as possible of the existing code base >> and isolate our changes in separate modules where possible. >> >> Details. >> point-to-point-channel.[h,cc] - Made TransmitStart virtual so the >> new subclass (see below) can override. >> >> point-to-point-remote-channel.[h,cc] - new subclass of p2p channel; >> used to connect simulated nodes on one simulator to nodes on a >> separate simulator. Overrides the TransmitStart function and >> uses MPI to send the packet across simulator processes. >> >> point-to-point-helper.[h,cc]. Checks the system id on the two nodes >> being connected, and uses a p2p-remote-channel rather than a p2p-channel >> if the system id's do not match. >> >> node.[h,cc] - Added a "SetSystemId" function, to allow the system id to >> be set after the node is constructed, rather than passing parameter >> to constructor; this exists because there was no way to use >> non-default constructors on object creation. I believe this might have >> been fixed since then, so perhaps this might not be neded. >> >> global-route-manager.cc - Do not compute routes for any node whose >> system-id >> does not match the simulator's system id. Clearly, we don't need to >> compute routes in simulator A for nodes modeled in simulator B. >> >> default-simulator-impl.[h.cc] = Added virtual "GetSystemId" method, >> which returns the system id (MPI rank) of this process. For >> the default-simulator object it always returns zero. >> >> distributed-simulator-impl.[h.cc] - new subclass of >> default-simulator-impl. >> THe meat of this is the overridden "run" method that handles all of >> the time management needed, using MPI. >> >> mpi-interface.[h,cc] - All MPI related processing is here in a single >> spot, rather than across several modules. >> >> buffer.[h,cc] - Added a "CreateLimitedCopy" function which is used when >> serializing packets for MPI. CreateLimitedCopy does not copy into the >> buffer >> the zero byte data of a packet; it only includes the number of bytes of >> zero >> byte data. >> >> packet.[h,cc] - Added new constructor for rebuilding packets that cross >> simulator boundaries. Also added serialization/deserialization for MPI. >> The formato for this is shown in the function comments. >> >> packet-metadata.[h,cc] - Added a rank id to the packet-metadata which >> corresponds to >> the LP that the packet belongs. A new constructor is also available which >> creates >> packet-metadata with a specific rank. This is necessary for when packets >> cross simulator >> boundaries, and the packet (and metadata) must be rebuilt. >> === >> >> I also have two issues I'd like to discuss here about the MPI code. >> >> 1) Enabling mpi using --with-mpi switch >> I have modified the wscript to accept a --with-mpi switch to compile >> with NS3_MPI included in CXXDEFINES. In order to compile correctly, >> the CXX environment variable must also be set to the path of mpic++. >> Right now I force the user to do this manually. For example, if they >> choose the --with-mpi switch, but don't have CXX set appropriately, >> WAF will exit and alert the user of the issue. Is there a way to set >> this environment variable automatically if --with-mpi is chosen and the >> mpic++ program is found? >> > > What does this mpic++ do? Do you have to compile every source file with > it, or just selected source files? > > You can modify CXX on a per "taskgen" basis, for example: > > obj = bld.create_ns3_program('csma-bridge', ['bridge', 'csma', > 'internet-stack']) > obj.source = 'csma-bridge.cc' > obj.env['CXX'] = '/usr/bin/mpic++' # <<< added > > To make this conditional, run a configure check: > > def configure(conf): > conf.find_program('mpic++', var='MPICXX') > > def build(bld): > > obj = bld.create_task_gen(...) > if obj.env['MIPCXX']: > obj.env['CXX'] = 'MPICXX' > > > Or something like this... > > >> >> 2) MPI examples in examples/mpi/ >> These examples are not built automatically through WAF, as using MPI >> requires some additional setup. The examples must also be run with >> mpirun, rather than WAF. A README file exists in this directory >> which explains what must be done in order to run the MPI examples. >> I couldn't think of a good way to do this automatically, so that's >> why the examples are not built with WAF but a Makefile in their >> directory. >> > > I can't imagine why building with WAF is harder than with Makefile. Surely > we have example code already using external libraries, such as gtk+2 or > sqlite. Can you be more specific on what you don't know how to do? > > As for running with mpirun, I suppose we could modify waf --run to call > mpirun when mpi is enabled. If you are unable to do it, give me a mercurial > branch URL (I need code that I can build and extend, none of this review > stuff) and I'll post a patch. Anyway, the modifications should be similar > to what is already done with the --valgrind option, which modifies --run to > run via valgrind. > > Hope this helps. > > Regards, > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > From tomh at tomh.org Fri Nov 6 14:07:40 2009 From: tomh at tomh.org (Tom Henderson) Date: Fri, 06 Nov 2009 14:07:40 -0800 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <200911031648.56644.tbns@idlebox.net> References: <594D5AD5-660E-44D5-A00D-F8A7A784F08F@gmail.com> <200910301204.47152.boyko@iitp.ru> <200911031648.56644.tbns@idlebox.net> Message-ID: <4AF49E2C.7070400@tomh.org> Timo Bingmann wrote: > Hello guys, > > thanks for "waking me up" :). No really, I was absent from this whole world, > including reality, for the last few months due to an exam, which I finally > finished just last week. > > I am going to work on merging some of my code into the mainstream. However, > I'm definitely desynched from current development, as is my repo. > > I believe the feature most people are interested in is the frame capture. > This, I believe, I have no not integrated into the YansWifiPhy yet, because it > is conceptually incompatible. > > Nevertheless, I believe we can still combine the models by adding a capture > threshold separate from the PER calculations. Practical simulations will > benefit from this approach. Timo, Can you elaborate a bit on the above? Why do you think it is conceptually incompatible to merge these models? Are there further extensions planned that would make it incompatible? - Tom From craigdo at ee.washington.edu Fri Nov 6 16:42:44 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 6 Nov 2009 16:42:44 -0800 Subject: [Ns-developers] ns-3 on Windows Message-ID: <000001ca5f43$38eaa5f0$aabff1d0$@washington.edu> Hi all, There has been considerable discussion recently about the "official" ns-3 answer to running under Windows. I have personally been running Cygwin for years and it does allow me to run a subset of ns-3 fairly well. Although it allows me to do some things, other important features like Python bindings, NSC, emulation devices, tap devices and real-time simulations will not work under Cygwin. To use these, I generally ssh from Windows (via Cywgin) into a grown-up system; but this has its annoyances as well. We have talked for some time about using virtual machines as an answer to full-blown ns-3 on Windows; and I have had a HOWTO up on the nsnam wiki for some time spelling out how to use VMware to get virtual machines running and configured. There hasn't been anything available for VirtualBox which seems to be a more popular choice. I put together a HOWTO that describes in detail how to use Sun VirtualBox to get Fedora 11 running and then how to get ns-3 running on that virtual machine. For your reading pleasure: http://www.nsnam.org/wiki/index.php/HOWTO_use_VirtualBox_to_run_simulations_ on_Windows_machines It compares surprisingly well, performance-wise, to Cygwin; and it is real Linux so you get all of the expected bells and whistles (like NSC). Regards, -- Craig From mazo at iitp.ru Sat Nov 7 00:46:28 2009 From: mazo at iitp.ru (Andrey Mazo) Date: Sat, 07 Nov 2009 11:46:28 +0300 Subject: [Ns-developers] ns-3 on Windows In-Reply-To: <000001ca5f43$38eaa5f0$aabff1d0$@washington.edu> References: <000001ca5f43$38eaa5f0$aabff1d0$@washington.edu> Message-ID: Hi all, > For your reading pleasure: > > http://www.nsnam.org/wiki/index.php/HOWTO_use_VirtualBox_to_run_simulations_ > on_Windows_machines Excellent guide, Craig! Traditional spell-check from me is attached both as a patch and as an updated wiki page. (since I don't have write permissions to ns-3 wiki) -- Andrey Mazo. -------------- next part -------------- A non-text attachment was scrubbed... Name: HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machines.wiki Type: application/octet-stream Size: 9686 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091107/97344a63/HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machines.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machines.wiki.patch Type: text/x-diff Size: 9970 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091107/97344a63/HOWTO_use_VirtualBox_to_run_simulations_on_Windows_machines.wiki.bin From mk.banchi at gmail.com Sat Nov 7 03:53:32 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sat, 7 Nov 2009 12:53:32 +0100 Subject: [Ns-developers] Bug 602 status In-Reply-To: <1257452095.3658.7.camel@localhost.localdomain> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> <1256889694.17577.16.camel@localhost.localdomain> <4AEAB54E.8000708@cttc.es> <1256917766.21755.13.camel@localhost.localdomain> <4AF2A535.7040300@cttc.es> <1257421670.4287.13.camel@localhost.localdomain> <71E1F3CA-DB00-4A0A-BA1A-082645E7A5A2@gmail.com> <1257452095.3658.7.camel@localhost.localdomain> Message-ID: <0FFE7482-66EC-40F6-851F-0EC65367FF90@gmail.com> Il giorno 05/nov/09, alle ore 21:14, Mathieu Lacage ha scritto: > On Thu, 2009-11-05 at 13:11 +0100, Mirko Banchi wrote: > >> as Nicola suggested, when we receive an RTS we don't know for wich >> tid >> it was received. So, for example, how would you call >> WifiRemoteStationManager::Lookup method in MacLow::GetCtsTxModeForRts > > Ok, I see: thanks for the clarification. > >> function? I think that there are a lot of problems like this. If you > > What is the exact list of problems beyond this one ? Could you be more > specific ? > Looking again at the code, maybe the only problems with solution that you suggested are with RTS frames. 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/20091107/ede33818/smime-0001.bin From mk.banchi at gmail.com Sat Nov 7 04:07:40 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sat, 7 Nov 2009 13:07:40 +0100 Subject: [Ns-developers] Little bugs in MacLow Message-ID: i think that there is a little bug in MacLow. Functions like NormalAckTimeout, FastAckTimeout... call method GetStation with argument m_currentHdr.GetAddr1 () but should it be m_currentHdr.GetAddr2 () instead? Tx station should increment its retry counter not Rx station. Also at line 616, in MacLow::ReceiveOk method, i think that correct behaviour should be: ... WifiRemoteStation *station = GetStation (m_currentHdr.GetAddr2 ()); station->ReportRxOk (rxSnr, txMode); station->ReportDataOk (rxSnr, txMode, tag.Get ()); ... Tx station should reset its retry counter not Rx station. What do you think? 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/20091107/63e97287/smime.bin From craigdo at ee.washington.edu Sat Nov 7 13:55:22 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Sat, 7 Nov 2009 13:55:22 -0800 Subject: [Ns-developers] ns-3 on Windows In-Reply-To: References: <000001ca5f43$38eaa5f0$aabff1d0$@washington.edu> Message-ID: <009201ca5ff5$023a93a0$06afbae0$@washington.edu> > Traditional spell-check from me is attached both as a patch and as an > updated wiki page. (since I don't have write permissions to ns-3 wiki) Thanks, Andrey. Applied. -- C From tomh at tomh.org Sun Nov 8 21:35:53 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 08 Nov 2009 21:35:53 -0800 Subject: [Ns-developers] WiFi interference: coordination note Message-ID: <4AF7AA39.5020007@tomh.org> A few of us are working on improving the modeling of WiFi interference. I wanted to mention this for coordination with other people working on similar topics. We would like to improve the modeling in these areas: 1) Capture effect modeling Trevor has previously posted on this subject. It seems that Timo's Phy model forms a good basis for this. It would be useful to merge this Phy with YansWifiPhy so we only have to maintain one going forward. 2) Adjacent channel interference from same system It is possible in WiFi for frames on adjacent channels to interfere with (and even be received on) the tuned channel. We would like to be able to model this, but presently there is no way for packets to "jump" channels. There is more to it than simply jumping channels; we need to consider spectral masks of transmitter and receiver. Here, I have read Nicola and Marco's recent paper: http://www.dei.unipd.it/~baldo/mypapers/baldo2009spectrum.pdf and the spectral modeling repo and previous Miracle work, so it seems like we should harmonize with this work. Nicola, what are your near-term plans for the spectral modeling repo? One question I again have here is whether we can add this to existing YansWifiPhy and channel rather than developing independent Spectrum* model hierarchy. 3) Interference from other systems Bluetooth into wifi, or jamming signals into wifi, are of interest to us. This is somewhat related to the previous item but if there is a desire for a foreign signal to be treated differently from an interference perspective than a native wifi signal, then we may need to think about how to model this at the receiver (what signal attributes are important to convey across channels). Again, I realize Nicola and others have worked on this. I think it would be helpful to try to sketch out a small roadmap of how this work can be added over time. 4) Receiver model profiles In addition, we're working on experimentally deriving an 802.11g clear channel BER model and will post that when it becomes available. One thing that has become apparent is that it would be nice to be able to add "receiver profiles" to existing models (such as a suite of BER curves that were empirically derived from a particular testbed) without hacking on the device model. 5) subclassing YansWifiPhy Would it be acceptable to make StartReceivePacket a virtual function so that YansWifiChannel-compatible phys, with different reception behavior, can be experimented with? 6) directional antennas with WiFi Is anyone doing directional antenna modeling work? - Tom From faker.moatamri at sophia.inria.fr Mon Nov 9 03:17:27 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 09 Nov 2009 12:17:27 +0100 Subject: [Ns-developers] Waypoint Mobility model Message-ID: <4AF7FA47.4060700@sophia.inria.fr> Hi Phillip, Did you apply the requested changes? Can you please proceed with the merging of your code into the main stream ns-3-dev? Best regards Faker Moatamri From mathieu.lacage at sophia.inria.fr Mon Nov 9 08:00:20 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 09 Nov 2009 17:00:20 +0100 Subject: [Ns-developers] avoiding duplicate refcount implementations Message-ID: <1257782420.2932.8.camel@localhost.localdomain> hi, RefCountBase cannot be used by some classes within ns-3 which means duplicate refcount implementations. I spotted: - 2 for performance reasons - 5 to avoid multiple inheritance - 2 for no apparent good reason Based on some work in the multithreading simulator code by guillaume, I added a new template-based refcounting class which avoids both the performance and the multiple inheritance problems in src/core/simple-ref-count.h and got rid of all the duplicate implementations in our codebase. I left the existing RefCountBase class in src/core/ for compatibility reasons. For those who wonder about the SimpleRefCount name, I chose this because I have a couple of other refcount implementations in the multithreading code (AtomicRefCount, MutexRefCount, and HashTlsRefCount) which I intend to merge at some later point. Here is the full patch which does all of this: since it's pretty mechanical, straightforward, and source-level compatible, I intend to push it in 2 or 3 days unless I hear complaints about the idea. Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: ref-count.patch Type: text/x-patch Size: 29756 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091109/e275ce0f/ref-count-0001.bin From phillip.sitbon at gmail.com Mon Nov 9 09:37:00 2009 From: phillip.sitbon at gmail.com (Phillip Sitbon) Date: Mon, 9 Nov 2009 09:37:00 -0800 Subject: [Ns-developers] Waypoint Mobility model In-Reply-To: <4AF7FA47.4060700@sophia.inria.fr> References: <4AF7FA47.4060700@sophia.inria.fr> Message-ID: <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> Hello, > Did you apply the requested changes? I just made one last change to address Mathieu's comments, and the only things left are tests/examples which I am doing my best to make time for. > Can you please proceed with the merging > of your code into the main stream ns-3-dev? I'm not quite sure how to go about that; I'm new to mecrurial, so my best guess would be that I can upload or commit it myself? Sorry if I'm missing any helpful details on the website... Cheers, - Phillip From faker.moatamri at sophia.inria.fr Mon Nov 9 10:06:54 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 09 Nov 2009 19:06:54 +0100 Subject: [Ns-developers] Waypoint Mobility model In-Reply-To: <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> References: <4AF7FA47.4060700@sophia.inria.fr> <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> Message-ID: <4AF85A3E.60008@sophia.inria.fr> Phillip Sitbon wrote: > Hello, > > >> Did you apply the requested changes? >> > > I just made one last change to address Mathieu's comments, and the > only things left are tests/examples which I am doing my best to make > time for. > > Ok, we have 9 days left for merging. >> Can you please proceed with the merging >> of your code into the main stream ns-3-dev? >> > > I'm not quite sure how to go about that; I'm new to mecrurial, so my > best guess would be that I can upload or commit it myself? Sorry if > I'm missing any helpful details on the website... > Usually, you use your local mercurial repository, you commit your changes (hg ci) with good comments. You download the latest ns-3-dev code: hg pull You merge if needed: hg merge Then you push to the server if you have the right acces rights, do you?: hg push ssh://code at code.nsnam.org//home/code/repos/ns-3-dev If you can't push, you just generate a patch after hg merge and send it to me and I will upload it to the server. Best regards Faker Moatamri > Cheers, > > - Phillip > From tomh at tomh.org Mon Nov 9 22:07:28 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 09 Nov 2009 22:07:28 -0800 Subject: [Ns-developers] avoiding duplicate refcount implementations In-Reply-To: <1257782420.2932.8.camel@localhost.localdomain> References: <1257782420.2932.8.camel@localhost.localdomain> Message-ID: <4AF90320.8090700@tomh.org> Mathieu Lacage wrote: > hi, > > RefCountBase cannot be used by some classes within ns-3 which means > duplicate refcount implementations. I spotted: > - 2 for performance reasons > - 5 to avoid multiple inheritance > - 2 for no apparent good reason > > Based on some work in the multithreading simulator code by guillaume, I > added a new template-based refcounting class which avoids both the > performance and the multiple inheritance problems in > src/core/simple-ref-count.h and got rid of all the duplicate > implementations in our codebase. I left the existing RefCountBase class > in src/core/ for compatibility reasons. Do you want to add a doxygen comment in class RefCountBase that it is deprecated, and direct readers to the new class? Otherwise, looks fine to me. (by the way, I think packet.h can safely remove deprecated.h inclusion) From mathieu.lacage at sophia.inria.fr Mon Nov 9 22:46:47 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 10 Nov 2009 07:46:47 +0100 Subject: [Ns-developers] avoiding duplicate refcount implementations In-Reply-To: <4AF90320.8090700@tomh.org> References: <1257782420.2932.8.camel@localhost.localdomain> <4AF90320.8090700@tomh.org> Message-ID: <1257835607.2519.2.camel@localhost.localdomain> On Mon, 2009-11-09 at 22:07 -0800, Tom Henderson wrote: > Do you want to add a doxygen comment in class RefCountBase that it is > deprecated, and direct readers to the new class? I did not plan to make it deprecated but, if it is felt that it should be killed, I can mark it so in the doxygen. > Otherwise, looks fine to me. > > (by the way, I think packet.h can safely remove deprecated.h inclusion) Right: I pushed this as a separate patch. Thanks for pointing it out. Mathieu From mathieu.lacage at sophia.inria.fr Tue Nov 10 01:25:45 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 10 Nov 2009 10:25:45 +0100 Subject: [Ns-developers] Simulator::SetScheduler API change Message-ID: <1257845145.2572.5.camel@localhost.localdomain> hi, Although minor (no users that I am aware of), this is an API break and since I am not sure that this piece of the multithreading code guillaume posted earlier did get a review ack, I decided to post this here for 2 or 3 days before committing it. Anyone has objections with the following change ? diff -r 5718e4171536 src/simulator/simulator.h --- a/src/simulator/simulator.h Tue Nov 10 07:45:32 2009 +0100 +++ b/src/simulator/simulator.h Tue Nov 10 10:19:38 2009 +0100 - static void SetScheduler (Ptr scheduler); + static void SetScheduler (ObjectFactory schedulerFactory); Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: set-sched.patch Type: text/x-patch Size: 9217 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091110/e9651366/set-sched.bin From boyko at iitp.ru Tue Nov 10 03:53:54 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Tue, 10 Nov 2009 14:53:54 +0300 Subject: [Ns-developers] Default WiFi thresholds changed Message-ID: <200911101453.54123.boyko@iitp.ru> Hi, Please note, that I have changed default energy detection and CCA thresholds of yans WiFi PHY model. Relevant discussions can be found here: http://www.nsnam.org/bugzilla/show_bug.cgi?id=689 I'd like to Though all tests are ok now, this change can affect some of your wifi scripts which don't change PHY defaults. Pavel From faker.moatamri at sophia.inria.fr Tue Nov 10 04:39:45 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 10 Nov 2009 13:39:45 +0100 Subject: [Ns-developers] Waypoint Mobility model In-Reply-To: <536685ea0911091113h11550524o95a87630c4ee059@mail.gmail.com> References: <4AF7FA47.4060700@sophia.inria.fr> <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> <4AF85A3E.60008@sophia.inria.fr> <536685ea0911091113h11550524o95a87630c4ee059@mail.gmail.com> Message-ID: <4AF95F11.3070004@sophia.inria.fr> Hi Phillip, I added your patch to the mainstream ns-3-dev, I changed the class waypoint.h/cc to make the member variable names according to the standard m_time and m_position instead of time and position and I made them private. I added accessor functions. As I told you class member variables should always be private or protected so that the class can control the values that can be set to. Please update your repo and keep on working on tests and examples. Best regards Faker Moatamri From tomh at tomh.org Tue Nov 10 06:17:48 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 10 Nov 2009 06:17:48 -0800 Subject: [Ns-developers] avoiding duplicate refcount implementations In-Reply-To: <1257835607.2519.2.camel@localhost.localdomain> References: <1257782420.2932.8.camel@localhost.localdomain> <4AF90320.8090700@tomh.org> <1257835607.2519.2.camel@localhost.localdomain> Message-ID: <4AF9760C.5030406@tomh.org> Mathieu Lacage wrote: > On Mon, 2009-11-09 at 22:07 -0800, Tom Henderson wrote: > >> Do you want to add a doxygen comment in class RefCountBase that it is >> deprecated, and direct readers to the new class? > > I did not plan to make it deprecated but, if it is felt that it should > be killed, I can mark it so in the doxygen. I meant that if you are going to the trouble to change all of the existing instances, that you leave a comment for new users that they should consider the new class before using RefCountBase, which is being retained for backward compatibility reasons. - Tom From tomh at tomh.org Tue Nov 10 06:19:43 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 10 Nov 2009 06:19:43 -0800 Subject: [Ns-developers] Default WiFi thresholds changed In-Reply-To: <200911101453.54123.boyko@iitp.ru> References: <200911101453.54123.boyko@iitp.ru> Message-ID: <4AF9767F.4070606@tomh.org> Pavel Boyko wrote: > Hi, > > Please note, that I have changed default energy detection and CCA thresholds > of yans WiFi PHY model. Relevant discussions can be found here: > http://www.nsnam.org/bugzilla/show_bug.cgi?id=689 > I'd like to Pavel, your sentence trailed off here. > > Though all tests are ok now, this change can affect some of your wifi scripts > which don't change PHY defaults. Accordingly, this kind of change should be documented in CHANGES.html also (I just pushed an update). Thanks, Tom From phillip.sitbon at gmail.com Tue Nov 10 08:11:35 2009 From: phillip.sitbon at gmail.com (Phillip Sitbon) Date: Tue, 10 Nov 2009 08:11:35 -0800 Subject: [Ns-developers] Waypoint Mobility model In-Reply-To: <4AF95F11.3070004@sophia.inria.fr> References: <4AF7FA47.4060700@sophia.inria.fr> <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> <4AF85A3E.60008@sophia.inria.fr> <536685ea0911091113h11550524o95a87630c4ee059@mail.gmail.com> <4AF95F11.3070004@sophia.inria.fr> Message-ID: <536685ea0911100811q2f2ca593h346091907a72be2e@mail.gmail.com> Faker, Please refer to my comments on that topic in Rietveld- Waypoint is meant to be a data structure, and I was merely following the style of many other object types by using the 'class' keyword. If you insist on the changes, I'd rather pull the Waypoint type entirely and make it internal to WaypointMobilityModel. Also, please note that Time and Vector are the only things holding data, Waypoint doesn't need to maintain anything about them; for this reason, there is no error checking necessary in this class. I believe private members & accessors are an unnecessary level of indirection and don't fit with the design of other data structures in ns-3. Hope this clarifies things a bit. Cheers, Phillip On Tue, Nov 10, 2009 at 4:39 AM, Faker Moatamri wrote: > Hi Phillip, > I added your patch to the mainstream ns-3-dev, I changed the class > waypoint.h/cc to make the member variable names according to the standard > m_time and m_position instead of time and position and I made them private. > I added accessor functions. As I told you class member variables should > always be private or protected so that the class can control the values that > can be set to. > Please update your repo and keep on working on tests and examples. > Best regards > Faker Moatamri > From mk.banchi at gmail.com Tue Nov 10 08:14:10 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Tue, 10 Nov 2009 17:14:10 +0100 Subject: [Ns-developers] 802.11n Block ack review In-Reply-To: <4AF06A1B.9080305@sophia.inria.fr> References: <12BAD9BC-9D70-4B62-A3F3-44C89527504C@gmail.com> <4AF06A1B.9080305@sophia.inria.fr> Message-ID: <5177CAC7-17F3-4566-B177-13B24E0A1A8D@gmail.com> I've made changes to the code as Nicola, Faker and Andey suggested. New patchset is available on http://codereview.appspot.com/144050/show. Any advice and review are the welcome. 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/20091110/726b627b/smime.bin From andreev at iitp.ru Tue Nov 10 09:36:18 2009 From: andreev at iitp.ru (Kirill Andreev) Date: Tue, 10 Nov 2009 20:36:18 +0300 Subject: [Ns-developers] Wifi bugs Message-ID: Hi! There are 4 bugs in Wifi, that I have posted: 674: DcfManager instead of EIFS waits EIFS-SIFS after failed transmission. 700: Slot is not corrected with aAirPropagationTime. 706: Starting backoff procedure at the beginning of the simulation. These bugs are relatively simple to fix with patches are attached but have very significant impact on wireless simulations. All these bugs will change regression tests, so they require special attention. 737: Backoff procedure is not started after ACK or CTS timeout. This bug seems one of the most difficult to me, because serious changes in DcfManager are needed. Could anyone please pay more attention to these bugs and give any ideas (specially about bug 737) for solving them. Also the question with merging 802.11s regressions is still open. Regards, Kirill Andreev IITP RAS From craigdo at ee.washington.edu Tue Nov 10 12:23:05 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 10 Nov 2009 12:23:05 -0800 Subject: [Ns-developers] MPI for ns-3 In-Reply-To: <688a18330911061217l7ca260ackc196f4e546e43d8e@mail.gmail.com> References: <909776950.303191257349681246.JavaMail.root@mail8.gatech.edu> <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> <688a18330911061217l7ca260ackc196f4e546e43d8e@mail.gmail.com> Message-ID: <01e301ca6243$9cda8d20$d68fa760$@washington.edu> Hi, FYI, there is a conflict on Fedora systems between libotf and openmpi. Both provide a "%{-bindir}/otfdump". One OTF is apparently OpenTypeFont from emacs and the other is OpenTraceFormat from openmpi. If you "yum remove libotf" to get rid of the pre-existing /usr/bin/otfdump, it removes emacs where the other dependency lies. Some googling reveals that a new version of openmpi will fix this; but until that is released (I can't find one), a workaround seems to be: 1) If you care, rename the tiny otfdump which emacs says it needs (but I don't know what obscure thing uses it): mv /usr/bin/otfdump /usr/bin/otfdump.emacs-version 2) Manually resolve openmpi dependencies: sudo yum install libgfortran libtorque numactl 3) Download rpm packages, openmpi-1.3.1-1.fc11.i586.rpm openmpi-devel-1.3.1-1.fc11.i586.rpm openmpi-libs-1.3.1-1.fc11.i586.rpm openmpi-vt-1.3.1-1.fc11.i586.rpm from http://mirrors.kernel.org/fedora/releases/11/Everything/i386/os/Packages/ 4) Force the packages in: sudo rpm -ivh --force openmpi-1.3.1-1.fc11.i586.rpm openmpi-libs-1.3.1-1.fc11.i586.rpm openmpi-devel-1.3.1-1.fc11.i586.rpm openmpi-vt-1.3.1-1.fc11.i586.rpm I haven't run the example yet, but this does seem to install openmpi on Fedora 11. -- Craig From Faker.Moatamri at sophia.inria.fr Tue Nov 10 14:54:41 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Tue, 10 Nov 2009 23:54:41 +0100 (CET) Subject: [Ns-developers] Waypoint Mobility model In-Reply-To: <536685ea0911100811q2f2ca593h346091907a72be2e@mail.gmail.com> References: <4AF7FA47.4060700@sophia.inria.fr> <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> <4AF85A3E.60008@sophia.inria.fr> <536685ea0911091113h11550524o95a87630c4ee059@mail.gmail.com> <4AF95F11.3070004@sophia.inria.fr> <536685ea0911100811q2f2ca593h346091907a72be2e@mail.gmail.com> Message-ID: <50887.193.251.48.82.1257893681.squirrel@imap-sop.inria.fr> > Faker, > > Please refer to my comments on that topic in Rietveld- Waypoint is > meant to be a data structure, and I was merely following the style of > many other object types by using the 'class' keyword. If you insist on > the changes, I'd rather pull the Waypoint type entirely and make it > internal to WaypointMobilityModel. > > Also, please note that Time and Vector are the only things holding > data, Waypoint doesn't need to maintain anything about them; for this > reason, there is no error checking necessary in this class. I believe > private members & accessors are an unnecessary level of indirection > and don't fit with the design of other data structures in ns-3. Ok I will put it back as it was as soon as possible. Regards Faker Moatamri > > Hope this clarifies things a bit. > > > Cheers, > > Phillip > > On Tue, Nov 10, 2009 at 4:39 AM, Faker Moatamri > wrote: >> Hi Phillip, >> I added your patch to the mainstream ns-3-dev, I changed the class >> waypoint.h/cc to make the member variable names according to the >> standard >> m_time and m_position instead of time and position and I made them >> private. >> I added accessor functions. As I told you class member variables should >> always be private or protected so that the class can control the values >> that >> can be set to. >> Please update your repo and keep on working on tests and examples. >> Best regards >> Faker Moatamri >> > From nowatkom at gmail.com Tue Nov 10 20:56:06 2009 From: nowatkom at gmail.com (Michael Nowatkowski) Date: Tue, 10 Nov 2009 23:56:06 -0500 Subject: [Ns-developers] add WIFI_PHY_STANDARD_80211p_CCH and SCH Message-ID: <001e01ca628b$4803b860$d80b2920$@com> Hello, This change adds WIFI_PHY_STANDARD_80211p_SCH and WIFI_PHY_STANDARD_80211p_CCH as possible choices for WifiHelper::SetStandard (enum WifiPhyStandard standard) when using QadhocWifiMac. http://codereview.appspot.com/152058/show 802.11p uses 10 MHz channels, so I tried to use as much existing WIFI_PHY_STANDARD_80211_10Mhz code as possible. 802.11p also uses the 802.11e QOS model. The SCH follows the default EDCA parameters, but the CCH uses a different set of parameters. I added some lines of code to add 802.11p specifications for the service channels (SCH) and the control channel (CCH) per IEEE 1609.4-2006, sections 6.3.1 and 6.3.2. cwMax for both CCH and SCH is 511, versus 1023 in other standards. Thanks! Michael Nowatkowski I modified the following files: src/devices/wifi/qadhoc-wifi-mac.cc -- adds case statements for the added standards. CCH calls a new member function, ConfigureCCHDcf, because the CCH Dcf parameters are different from the default 10Mhz parameters, and cwMax is 511. SCH uses the default Dcf parameters, but cwMax is 511. src/devices/wifi/wifi-mac.h -- adds new member function prototypes ConfigureCCHDcf, Configure80211p_CCH() and SCH(). src/devices/wifi/wifi-mac.cc -- adds case statements for the added standards and adds new member functions Configure80211p_CCH() and SCH(), based on 10Mhz code, modifying the SetSlot time to 16 microseconds, per IEEE P802.11p, and ConfigureCCHDcf, based on ConfigureDcf with CCH-specific parameters set. src/devices/wifi/yans-wifi-phy.h -- adds prototypes Configure80211p_CCH (void) and SCH (void) src/devices/wifi/yans-wifi-phy.cc -- adds case statements for the added standards and adds new member functions Configure80211p_CCH(void) and SCH(void), based on 10Mhz code. I left m_channelStartingFrequency = 5e3. The actual starting frequency is at 5.860 GHz for the first CCH (channel number 172), but I think using the actual channel number with SetChannelNumber will account for that (5e3 + 172*5 = 5860). src/devices/wifi/wifi-phy-standard.h -- adds the enumeration of the CCH and SCH. **The changes can be tested by modifying a few lines in /tutorial/third.cc: WifiHelper wifi = WifiHelper::Default (); wifi.SetStandard(WIFI_PHY_STANDARD_80211p_CCH); // added this line wifi.SetRemoteStationManager ("ns3::AarfWifiManager"); QosWifiMacHelper mac = QosWifiMacHelper::Default (); // changed Nqos to Qos mac.SetType ("ns3::QadhocWifiMac"); // changed to QadhocWifiMac NetDeviceContainer staDevices; staDevices = wifi.Install (phy, mac, wifiStaNodes); mac.SetType ("ns3::QadhocWifiMac"); // changed to QadhocWifiMac NetDeviceContainer apDevices; apDevices = wifi.Install (phy, mac, wifiApNode); From mathieu.lacage at sophia.inria.fr Tue Nov 10 22:36:42 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 11 Nov 2009 07:36:42 +0100 Subject: [Ns-developers] Waypoint Mobility model In-Reply-To: <536685ea0911100811q2f2ca593h346091907a72be2e@mail.gmail.com> References: <4AF7FA47.4060700@sophia.inria.fr> <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> <4AF85A3E.60008@sophia.inria.fr> <536685ea0911091113h11550524o95a87630c4ee059@mail.gmail.com> <4AF95F11.3070004@sophia.inria.fr> <536685ea0911100811q2f2ca593h346091907a72be2e@mail.gmail.com> Message-ID: <1257921402.2496.0.camel@localhost.localdomain> On Tue, 2009-11-10 at 08:11 -0800, Phillip Sitbon wrote: > Also, please note that Time and Vector are the only things holding > data, Waypoint doesn't need to maintain anything about them; for this > reason, there is no error checking necessary in this class. I believe > private members & accessors are an unnecessary level of indirection > and don't fit with the design of other data structures in ns-3. +1 From Faker.Moatamri at sophia.inria.fr Wed Nov 11 03:02:11 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Wed, 11 Nov 2009 12:02:11 +0100 (CET) Subject: [Ns-developers] Waypoint Mobility model In-Reply-To: <50887.193.251.48.82.1257893681.squirrel@imap-sop.inria.fr> References: <4AF7FA47.4060700@sophia.inria.fr> <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> <4AF85A3E.60008@sophia.inria.fr> <536685ea0911091113h11550524o95a87630c4ee059@mail.gmail.com> <4AF95F11.3070004@sophia.inria.fr> <536685ea0911100811q2f2ca593h346091907a72be2e@mail.gmail.com> <50887.193.251.48.82.1257893681.squirrel@imap-sop.inria.fr> Message-ID: <61921.193.251.48.82.1257937331.squirrel@imap-sop.inria.fr> >> >> Also, please note that Time and Vector are the only things holding >> data, Waypoint doesn't need to maintain anything about them; for this >> reason, there is no error checking necessary in this class. I believe >> private members & accessors are an unnecessary level of indirection >> and don't fit with the design of other data structures in ns-3. > Ok I will put it back as it was as soon as possible. Done From Faker.Moatamri at sophia.inria.fr Wed Nov 11 03:06:25 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Wed, 11 Nov 2009 12:06:25 +0100 (CET) Subject: [Ns-developers] Waypoint Mobility model In-Reply-To: <1257921402.2496.0.camel@localhost.localdomain> References: <4AF7FA47.4060700@sophia.inria.fr> <536685ea0911090937u251e5848t4d6a584121c1a30f@mail.gmail.com> <4AF85A3E.60008@sophia.inria.fr> <536685ea0911091113h11550524o95a87630c4ee059@mail.gmail.com> <4AF95F11.3070004@sophia.inria.fr> <536685ea0911100811q2f2ca593h346091907a72be2e@mail.gmail.com> <1257921402.2496.0.camel@localhost.localdomain> Message-ID: <61937.193.251.48.82.1257937585.squirrel@imap-sop.inria.fr> > On Tue, 2009-11-10 at 08:11 -0800, Phillip Sitbon wrote: > >> Also, please note that Time and Vector are the only things holding >> data, Waypoint doesn't need to maintain anything about them; for this >> reason, there is no error checking necessary in this class. I believe >> private members & accessors are an unnecessary level of indirection >> and don't fit with the design of other data structures in ns-3. > > +1 > Done From vincent at clarinet.u-strasbg.fr Wed Nov 11 07:33:29 2009 From: vincent at clarinet.u-strasbg.fr (=?ISO-8859-1?Q?S=E9bastien_Vincent?=) Date: Wed, 11 Nov 2009 16:33:29 +0100 Subject: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) In-Reply-To: <4AEFD2D1.4020309@clarinet.u-strasbg.fr> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <000301ca57ef$46c5d150$d45173f0$@ch> <4AE91BE8.9090900@tomh.org> <4AE93B92.6000809@clarinet.u-strasbg.fr> <4AE97000.1090900@sophia.inria.fr> <001b01ca5938$16e382d0$44aa8870$@ch> <4AEAD0B8.8070202@sophia.inria.fr> <004301ca5b9e$4488b210$cd9a1630$@ch> <4AEFD2D1.4020309@clarinet.u-strasbg.fr> Message-ID: <4AFAD949.7080404@clarinet.u-strasbg.fr> Hi, I merge Fabian's repository (ns-3-ipv6-option) into ns-3-ipv6-ext repository (http://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext). I also fix comments from codereview. Best regards, -- Sebastien S?bastien Vincent a ?crit : > Hi Fabian, > > Fabian Mauchle a ?crit : >> Hi All, >> >> I looked over it again, and I'm not sure if removing the OptionDemux >> could >> limit the flexibility it currently provides. So I've put together my old >> Extension-Option link. You can find the code at >> http://sinv-56031.edu.hsr.ch/hg/ns-3-ipv6-option. >> >> The modification mainly simplifies the Assembly of Extension- and Option >> Headers. It leaves the OptionDemux as is, and only extends the >> Ipv6ExtensionHeader and Ipv6OptionHeader. It also includes a small >> refactoring to remove duplicate code in the Ipv6Extension* subclasses. >> >> So for now, I would propose to us this as a merge candidate. >> >> What do you think? >> Sebastien? >> >> > > I am very busy this week so I will try to review it by the end of > week. And I will apply today the "code duplication fix" part of your > patch. > > Regards, > -- > Sebastien > > >> Regards, >> >> Fabian >> >> >> -----Urspr?ngliche Nachricht----- >> Von: Faker Moatamri [mailto:faker.moatamri at sophia.inria.fr] Gesendet: >> Freitag, 30. Oktober 2009 12:41 >> An: Mauchle Fabian (f1mauchl at hsr.ch) >> Cc: vincent at clarinet.u-strasbg.fr; ns-developers at ISI.EDU; >> ns-3-reviews at googlegroups.com >> Betreff: Re: AW: [Ns-developers] Ipv6Extension (was UDPv6, missleading >> subject) >> ... >> Thanks for the explanation. It is clear that we can't merge both >> codes in the main tree, so which version should be taken as a merge >> candidate? >> ... >> >> Best regards >> Faker Moatamri >> >> >> >> > > From faker.moatamri at sophia.inria.fr Thu Nov 12 03:20:07 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 12 Nov 2009 12:20:07 +0100 Subject: [Ns-developers] Merge candidates- deadline approaching-Status update Message-ID: <4AFBEF67.6090707@sophia.inria.fr> Hi all, I wish to remind you that the deadline to merge modules into NS-3.7 is about to come: it is scheduled for Wednesday November 18th 2009. If there is any error in the list or the status is different please don't hesitate to tell me. Some modules are just waiting for +1s, so please Tom, Nicola, Andrey, Andreev, if you need to say +1 for a code to be merged please do as soon as possible (look at the list below: 802.11n block ack, AODV). We have also code that need to be reviewed: MPI-based parallalization, IPv6 Extensions The Merge candidates are: Underwater Acoustic Network Device * /Review location/: http://codereview.appspot.com/87043 * /reviewer(s)/: Craig Dowell, Faker Moatamri * Developer: Leonard Tracy * Current status: waiting for corrections WiMAX * /code location/: http://code.nsnam.org/iamine/ns-3-wimax-release/ * /reviewers/: Faker Moatamri, Mathieu Lacage, Craig Dowel, Tom Henderson * Developer: Amine Ismail * /Status/: Planning to merge by the end of this week AODV * /code location/: https://forge.iitp.ru/hgprojects/ns3aodv/ * /review location/: http://codereview.appspot.com/115075/show * /reviewers/: Faker Moatamri, Tom Henderson * Developer: Pavel Boyko * /Status: /Corrections made, waiting for +1s? NHDP * Code: No available code for the moment * Developer: Tom Wambold * Status: waiting to the code to be ready to review MPI-based parallelization * /review location/: http://codereview.appspot.com/109068/show * Reviewers: Faker Moatamri * Developer: Josh Pelkey * Status: needs other reviews 802.11n block ack * review location: http://codereview.appspot.com/144050 * Reviewers: Faker Moatamri, Nicola Baldo, Andrey Mazo, Andreev Kirill * Developer: Mirko Blanchi * Status: waiting for +1s Waypoint mobility model * review location: http://codereview.appspot.com/144064/show * Reviewers: Mathieu Lacage, Faker Moatamri * Developer: Phillip Sitbon * Status: merged into mainstream, needs tests and examples from Phillip IPv6 Extension and Option Headers * review location: http://codereview.appspot.com/144048 * Reviewers: Faker Moatamri * Developers: Sebastien Vincent, Fabian Mauchle * Status: Needs more reviews Thanks Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Thu Nov 12 06:33:21 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 12 Nov 2009 15:33:21 +0100 Subject: [Ns-developers] Building problem with RefCountBase/ python Message-ID: <4AFC1CB1.6070405@sophia.inria.fr> Hi Gustavo, Hi Mathieu, After the RefCountBase changes we have a problem to build ns-3-dev: debug/bindings/python/ns3_module_core.cc: In function ?int _wrap_PyNs3RefCountBase__tp_init__0(PyNs3RefCountBase*, PyObject*, PyObject*, PyObject**)?: debug/bindings/python/ns3_module_core.cc:6816: error: cannot allocate an object of abstract type ?ns3::RefCountBase? debug/ns3/ref-count-base.h:38: note: because the following virtual functions are pure within ?ns3::RefCountBase?: debug/ns3/ref-count-base.h:43: note: virtual ns3::RefCountBase::~RefCountBase() debug/ns3/ref-count-base.h:43: note: virtual ns3::RefCountBase::~RefCountBase() debug/bindings/python/ns3_module_core.cc: In function ?int _wrap_PyNs3RefCountBase__tp_init__1(PyNs3RefCountBase*, PyObject*, PyObject*, PyObject**)?: debug/bindings/python/ns3_module_core.cc:6835: error: cannot allocate an object of abstract type ?ns3::RefCountBase? debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has pure virtual functions debug/bindings/python/ns3_module_core.cc: In function ?PyObject* _wrap_PyNs3RefCountBase__copy__(PyNs3RefCountBase*)?: debug/bindings/python/ns3_module_core.cc:6870: error: cannot allocate an object of abstract type ?ns3::RefCountBase? debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has pure virtual functions Rescanning the python bindings gave me a weird problem: Waf: Leaving directory `/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev/build' Build failed -> task failed (err #1): {task: command_task ns3modulegen.py,ns3modulegen_generated.py,ns3modulegen_core_customizations.py,ns3_module_bridge.py,ns3_module_common.py,ns3_module_contrib.py,ns3_module_core.py,ns3_module_csma.py,ns3_module_dot11s.py,ns3_module_emu.py,ns3_module_flame.py,ns3_module_flow_monitor.py,ns3_module_global_routing.py,ns3_module_helper.py,ns3_module_internet_stack.py,ns3_module_list_routing.py,ns3_module_mesh.py,ns3_module_mobility.py,ns3_module_nix_vector_routing.py,ns3_module_node.py,ns3_module_olsr.py,ns3_module_onoff.py,ns3_module_packet_sink.py,ns3_module_ping6.py,ns3_module_point_to_point.py,ns3_module_radvd.py,ns3_module_simulator.py,ns3_module_static_routing.py,ns3_module_stats.py,ns3_module_tap_bridge.py,ns3_module_test.py,ns3_module_udp_echo.py,ns3_module_v4ping.py,ns3_module_virtual_net_device.py,ns3_module_wifi.py -> ns3module.cc,ns3module.h,ns3modulegen.log,ns3_module_bridge.cc,ns3_module_common.cc,ns3_module_contrib.cc,ns3_module_core.cc,ns3_module_csma.cc,ns3_module_dot11s.cc,ns3_module_emu.cc,ns3_module_flame.cc,ns3_module_flow_monitor.cc,ns3_module_global_routing.cc,ns3_module_helper.cc,ns3_module_internet_stack.cc,ns3_module_list_routing.cc,ns3_module_mesh.cc,ns3_module_mobility.cc,ns3_module_nix_vector_routing.cc,ns3_module_node.cc,ns3_module_olsr.cc,ns3_module_onoff.cc,ns3_module_packet_sink.cc,ns3_module_ping6.cc,ns3_module_point_to_point.cc,ns3_module_radvd.cc,ns3_module_simulator.cc,ns3_module_static_routing.cc,ns3_module_stats.cc,ns3_module_tap_bridge.cc,ns3_module_test.cc,ns3_module_udp_echo.cc,ns3_module_v4ping.cc,ns3_module_virtual_net_device.cc,ns3_module_wifi.cc} Any idea of how to fix that? Thanks Faker Moatamri From tomh at tomh.org Thu Nov 12 07:21:33 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 12 Nov 2009 07:21:33 -0800 Subject: [Ns-developers] Merge candidates- deadline approaching-Status update In-Reply-To: <4AFBEF67.6090707@sophia.inria.fr> References: <4AFBEF67.6090707@sophia.inria.fr> Message-ID: <4AFC27FD.4010902@tomh.org> Faker Moatamri wrote: > Hi all, > > I wish to remind you that the deadline to merge modules into NS-3.7 is > about to come: it is scheduled for Wednesday November 18th 2009. If > there is any error in the list or the status is different please don't > hesitate to tell me. Faker, please remember to include the NetAnim review: http://mailman.isi.edu/pipermail/ns-developers/2009-November/006914.html - Tom From j.d.brugge at student.utwente.nl Thu Nov 12 06:23:33 2009 From: j.d.brugge at student.utwente.nl (Jonathan Brugge) Date: Thu, 12 Nov 2009 15:23:33 +0100 Subject: [Ns-developers] [patch] Use transactions in SQLite output Message-ID: <200911121523.33333.j.d.brugge@student.utwente.nl> Hi all, I'm working on a routing protocol implementation in ns-3 (Cross-Entropy Ant System or CEAS for short). To be able to analyze how the protocol behaves, I've been using the SQLite data output interface. I'm logging relatively large amounts of data: currently about 5000 insert queries per simulation run and I expect that number to increase significantly. As storing the data started to take almost 50% of my simulation time, I took a look at the code in contrib/stats/sqlite-data-output.cc and found out that it doesn't use transactions. The attached patch is a crude but simple way to enable them. It shouldn't cause big delays in small batches of queries, but really helps with big numbers of inserts. A small benchmark gave the following results: - Simulation, don't store results: ca. 18s - Simulation + store without transactions: ca. 31s - Simulation + store with transactions: ca. 18s Effectively, the storage delay disappears completely - which is a welcome improvement. Would this be acceptable for inclusion in ns-3? Regards, Jonathan P.S.: I have some other code, such as an 'interval data collector' which samples a value multiple times during a simulation (to be able to graph how a value changes over time during a simulation) and the routing protocol implementation itself. I will try to post that when it's in a more publishable state - it's currently still in development and doesn't conform to the ns-3 coding standards yet. ============= --- sqlite-data-output.cc 2009-11-12 15:09:05.000000000 +0100 +++ sqlite-data-output-transaction.cc 2009-11-12 14:36:05.000000000 +0100 @@ -131,11 +131,13 @@ blob.second + "')"); } + Exec("BEGIN"); SqliteOutputCallback callback(this, run); for (DataCalculatorList::iterator i = dc.DataCalculatorBegin(); i != dc.DataCalculatorEnd(); i++) { (*i)->Output(callback); } + Exec("COMMIT"); sqlite3_close(m_db); -------------- next part -------------- A non-text attachment was scrubbed... Name: use_transaction.diff Type: text/x-patch Size: 451 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091112/46938804/use_transaction.bin From nbaldo at cttc.es Thu Nov 12 08:40:34 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 12 Nov 2009 17:40:34 +0100 Subject: [Ns-developers] WiFi interference: coordination note In-Reply-To: <4AF7AA39.5020007@tomh.org> References: <4AF7AA39.5020007@tomh.org> Message-ID: <4AFC3A82.2030302@cttc.es> Hi Tom and everybody, Tom Henderson wrote: > A few of us are working on improving the modeling of WiFi interference. > I wanted to mention this for coordination with other people working on > similar topics. > > We would like to improve the modeling in these areas: > > 1) Capture effect modeling > > Trevor has previously posted on this subject. It seems that Timo's > Phy model forms a good basis for this. It would be useful to merge this > Phy with YansWifiPhy so we only have to maintain one going forward. I agree that Capture effect should be included in YansWifiPhy, but I have some doubts on the approach proposed by Trevor. I'll reply directly to Trevor's email on the list so that we can keep on using that thread for the detailed discussion. > > 2) Adjacent channel interference from same system > > It is possible in WiFi for frames on adjacent channels to interfere > with (and even be received on) the tuned channel. We would like to be > able to model this, but presently there is no way for packets to "jump" > channels. There is more to it than simply jumping channels; we need to > consider spectral masks of transmitter and receiver. > > Here, I have read Nicola and Marco's recent paper: > http://www.dei.unipd.it/~baldo/mypapers/baldo2009spectrum.pdf > and the spectral modeling repo and previous Miracle work, so it seems > like we should harmonize with this work. > > Nicola, what are your near-term plans for the spectral modeling repo? > One question I again have here is whether we can add this to existing > YansWifiPhy and channel rather than developing independent Spectrum* > model hierarchy. I had a private discussion with Faker about this issue a couple of weeks (or so) ago. It is our intention to work for it to be merged in ns-3-dev, however the current status of our code is that it still needs a significant amount of work to be polished, so we though that this was clearly out of reach for ns-3.7. We will try for 3.8. As for merging the functionality of Spectrum into YansWifiPhy, I think it is not at all straightforward, since the impact of the modifications would be huge. Furthermore, it might not be desirable. If Spectrum is merged into YansWifiPhy, and you want to implement say an LTE phy using Spectrum functionalities, would then LtePhy inherit from YansWifiPhy? > > 3) Interference from other systems > > Bluetooth into wifi, or jamming signals into wifi, are of interest to > us. This is somewhat related to the previous item but if there is a > desire for a foreign signal to be treated differently from an > interference perspective than a native wifi signal, then we may need to > think about how to model this at the receiver (what signal attributes > are important to convey across channels). Again, I realize Nicola and > others have worked on this. I think it would be helpful to try to > sketch out a small roadmap of how this work can be added over time. Yes our Spectrum framework supports this, though for now apart from wifi we only support very simple jamming sources. Of course if there are alternative proposals for how to address the same problem we would be happy to start a discussion. > > 4) Receiver model profiles > > In addition, we're working on experimentally deriving an 802.11g clear > channel BER model and will post that when it becomes available. One > thing that has become apparent is that it would be nice to be able to > add "receiver profiles" to existing models (such as a suite of BER > curves that were empirically derived from a particular testbed) without > hacking on the device model. I agree that would be a nice feature. If I remember correctly Federico Maguolo had done something for this, and Mathieu was trying to recover and merge his code, but I don't know how the thing ended up. Regards, Nicola From nbaldo at cttc.es Thu Nov 12 08:53:16 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Thu, 12 Nov 2009 17:53:16 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> Message-ID: <4AFC3D7C.9070703@cttc.es> Hi Trevor, Trevor Bosaw wrote: > I've looked over the code located at: > > http://code.nsnam.org/timob/ns-3-wifiex/ > > And I believe that the wifiex phy model is complementary to the main > ns-3 wifi model, and that the two should be merged. The main difference > in the wifiex phy model and the main ns-3 repository is that it includes > an improvement to the wifi state machine that allows for 'Capture > Effect' implementation. > > For those that don't know, the 'Capture Effect' in wifi is the ability > of a receiver to synchronize to an incoming packet while it is already > sync'ed to a packet, when the incoming packet's power is higher than > that of the currently sync'ed packet, and is above a set threshold. > Currently, ns-3's wifi node state machine drops any packet that is > received while it is in the SYNC state (currently sync'ed to a packet). > Not only does the wifiex phy model implement the 'Capture Effect', which > more closely models actual receiver behavior, but it includes flags that > can be set which reverts node state machine behavior back to how ns-3 > main currently deals with things. > I agree that the Capture Effect modeling is a nice feature, but I do not agree in adding the threshold on the power of the new packet. In my opinion, you should re-sync on the new packet whenever it is stronger than the previous (regardless of the difference). The interference modeling in YansWifiPhy will take care of discarding the packet later if it is not enough stronger than the other superimposed packet(s). Regards, Nicola From jens.mittag at kit.edu Thu Nov 12 09:10:30 2009 From: jens.mittag at kit.edu (Jens Mittag) Date: Thu, 12 Nov 2009 18:10:30 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4AFC3D7C.9070703@cttc.es> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> Message-ID: <4AFC4186.7080309@kit.edu> Am 12.11.2009 17:53, schrieb Nicola Baldo: > Hi Trevor, > > Trevor Bosaw wrote: >> I've looked over the code located at: >> >> http://code.nsnam.org/timob/ns-3-wifiex/ >> >> And I believe that the wifiex phy model is complementary to the main >> ns-3 wifi model, and that the two should be merged. The main >> difference in the wifiex phy model and the main ns-3 repository is >> that it includes an improvement to the wifi state machine that allows >> for 'Capture Effect' implementation. >> >> For those that don't know, the 'Capture Effect' in wifi is the >> ability of a receiver to synchronize to an incoming packet while it >> is already sync'ed to a packet, when the incoming packet's power is >> higher than that of the currently sync'ed packet, and is above a set >> threshold. Currently, ns-3's wifi node state machine drops any >> packet that is received while it is in the SYNC state (currently >> sync'ed to a packet). Not only does the wifiex phy model implement >> the 'Capture Effect', which more closely models actual receiver >> behavior, but it includes flags that can be set which reverts node >> state machine behavior back to how ns-3 main currently deals with >> things. >> > > I agree that the Capture Effect modeling is a nice feature, but I do > not agree in adding the threshold on the power of the new packet. In > my opinion, you should re-sync on the new packet whenever it is > stronger than the previous (regardless of the difference). The > interference modeling in YansWifiPhy will take care of discarding the > packet later if it is not enough stronger than the other superimposed > packet(s). > > Regards, > > Nicola > Hi Nicola I understand your point, but capturing is no technical issue, not a "capability" itself and rather the trade-off between "staying synced to the first packet and hoping that FEC will solve the bit errors introduced by the interfering stronger packet" and "switching to the new frame and hoping that this will be more lucky than the first one". Capturing is NOT about what is possible to decode but rather WHICH strategic decision the reciever should do, i.e. which packet frame is favored over the other. As experimental studies have shown, this threshold is not based on any modulation techniques, but artificially selected by Atheros. Not adding this threshold would yield to anything but not to a model that reflects capturing... Jens -- Dipl.-Inform. Jens Mittag University of Karlsruhe Institute of Telematics Decentralized Systems and Network Services Research Group Engesserstr. 2, 76131 Karlsruhe, Germany Building 20.50, Room 112 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ From Amine.Ismail at sophia.inria.fr Thu Nov 12 09:47:39 2009 From: Amine.Ismail at sophia.inria.fr (Ismail Amine) Date: Thu, 12 Nov 2009 18:47:39 +0100 Subject: [Ns-developers] time conversion error Message-ID: <4AFC4A3B.2070809@sophia.inria.fr> Hi all, I have wrote the following lines of code: |TypeId WimaxSubscriberStationNetDevice::GetTypeId (void) { static TypeId tid = TypeId ("ns3::WimaxSubscriberStationNetDevice.") .SetParent () .AddConstructor () ... .AddAttribute ( "LostDlMapInterval", "Time since last received DL-MAP message before downlink synchronization is considered lost. Maximum is 600ms", TimeValue (Seconds(0.5)), MakeTimeAccessor (&WimaxSubscriberStationNetDevice::m_lostDlMapInterval), MakeTimeChecker ()) ... | I tried then to print the value of m_lostDlMapInterval by writing the following line: |std::cout << "lostDlMapInterval=" << GetLostDlMapInterval().GetSeconds() << std::endl;| and as a result I got: | lostDlMapInterval=5e-07| I was expecting 0.5!!! I have also tried with MilliSeconds(500) and MicroSeconds(500000) but they give the same result. However if I remove the previous lines from the GetTypeId function and I insert in the constructor of WimaxSubscriberStationNetDevice the follwing: m_lostDlMapInterval = Seconds (0.5); A correct value is printed in stdout: lostDlMapInterval=0.5 Does any one knows why the time conversion is not correctly performed with the AddAttribute function? What should I do to make it work correctly? Thank you Amine From Faker.Moatamri at sophia.inria.fr Thu Nov 12 14:12:13 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Thu, 12 Nov 2009 23:12:13 +0100 (CET) Subject: [Ns-developers] [patch] Use transactions in SQLite output In-Reply-To: <200911121523.33333.j.d.brugge@student.utwente.nl> References: <200911121523.33333.j.d.brugge@student.utwente.nl> Message-ID: <50019.193.251.48.82.1258063933.squirrel@imap-sop.inria.fr> > Hi all, > > I'm working on a routing protocol implementation in ns-3 (Cross-Entropy > Ant > System or CEAS for short). To be able to analyze how the protocol behaves, > I've been using the SQLite data output interface. I'm logging relatively > large > amounts of data: currently about 5000 insert queries per simulation run > and I > expect that number to increase significantly. > > As storing the data started to take almost 50% of my simulation time, I > took a > look at the code in contrib/stats/sqlite-data-output.cc and found out that > it > doesn't use transactions. The attached patch is a crude but simple way to > enable them. It shouldn't cause big delays in small batches of queries, > but > really helps with big numbers of inserts. > > A small benchmark gave the following results: > > - Simulation, don't store results: ca. 18s > - Simulation + store without transactions: ca. 31s > - Simulation + store with transactions: ca. 18s > Seems really interesting, plus the patch is really small. Did you check if there is any impact on existing code/functionalities? Tom, Craig, Gustavo, Others, what do you think? > Effectively, the storage delay disappears completely - which is a welcome > improvement. Would this be acceptable for inclusion in ns-3? > > Regards, > > Jonathan > > P.S.: I have some other code, such as an 'interval data collector' which > samples a value multiple times during a simulation (to be able to graph > how a > value changes over time during a simulation) and the routing protocol > implementation itself. I will try to post that when it's in a more > publishable > state - it's currently still in development and doesn't conform to the > ns-3 > coding standards yet. Cool, your contribution will be welcome ;) > > ============= > > --- sqlite-data-output.cc 2009-11-12 15:09:05.000000000 +0100 > +++ sqlite-data-output-transaction.cc 2009-11-12 14:36:05.000000000 > +0100 > @@ -131,11 +131,13 @@ > blob.second + "')"); > } > > + Exec("BEGIN"); > SqliteOutputCallback callback(this, run); > for (DataCalculatorList::iterator i = dc.DataCalculatorBegin(); > i != dc.DataCalculatorEnd(); i++) { > (*i)->Output(callback); > } > + Exec("COMMIT"); > > sqlite3_close(m_db); > > From tomh at tomh.org Thu Nov 12 21:52:27 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 12 Nov 2009 21:52:27 -0800 Subject: [Ns-developers] [patch] Use transactions in SQLite output In-Reply-To: <50019.193.251.48.82.1258063933.squirrel@imap-sop.inria.fr> References: <200911121523.33333.j.d.brugge@student.utwente.nl> <50019.193.251.48.82.1258063933.squirrel@imap-sop.inria.fr> Message-ID: <4AFCF41B.3020508@tomh.org> Faker.Moatamri at sophia.inria.fr wrote: >> Hi all, >> >> I'm working on a routing protocol implementation in ns-3 (Cross-Entropy >> Ant >> System or CEAS for short). To be able to analyze how the protocol behaves, >> I've been using the SQLite data output interface. I'm logging relatively >> large >> amounts of data: currently about 5000 insert queries per simulation run >> and I >> expect that number to increase significantly. >> >> As storing the data started to take almost 50% of my simulation time, I >> took a >> look at the code in contrib/stats/sqlite-data-output.cc and found out that >> it >> doesn't use transactions. The attached patch is a crude but simple way to >> enable them. It shouldn't cause big delays in small batches of queries, >> but >> really helps with big numbers of inserts. >> >> A small benchmark gave the following results: >> >> - Simulation, don't store results: ca. 18s >> - Simulation + store without transactions: ca. 31s >> - Simulation + store with transactions: ca. 18s >> > Seems really interesting, plus the patch is really small. Did you check if > there is any impact on existing code/functionalities? > Tom, Craig, Gustavo, Others, what do you think? Joe Kopena has been maintaining the stats code; perhaps he could have a look and push it if OK. - Tom From mathieu.lacage at sophia.inria.fr Thu Nov 12 23:57:45 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 13 Nov 2009 08:57:45 +0100 Subject: [Ns-developers] time conversion error In-Reply-To: <4AFC4A3B.2070809@sophia.inria.fr> References: <4AFC4A3B.2070809@sophia.inria.fr> Message-ID: <1258099065.13617.1.camel@localhost.localdomain> On Thu, 2009-11-12 at 18:47 +0100, Ismail Amine wrote: > Does any one knows why the time conversion is not correctly performed > with the AddAttribute function? What should I do to make it work correctly? It should work fine: we have similar code in src/devices/wifi/nqap-wifi-mac.cc .AddAttribute ("BeaconInterval", "Delay between two beacons", TimeValue (Seconds (0.1)), MakeTimeAccessor (&NqapWifiMac::GetBeaconInterval, &NqapWifiMac::SetBeaconInterval), MakeTimeChecker ()) How did you declare m_lostDlMapInterval ? Mathieu From faker.moatamri at sophia.inria.fr Fri Nov 13 00:44:39 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 13 Nov 2009 09:44:39 +0100 Subject: [Ns-developers] Merge candidates- deadline approaching-Status update In-Reply-To: <4AFC27FD.4010902@tomh.org> References: <4AFBEF67.6090707@sophia.inria.fr> <4AFC27FD.4010902@tomh.org> Message-ID: <4AFD1C77.1030502@sophia.inria.fr> Tom Henderson wrote: > Faker Moatamri wrote: >> Hi all, >> >> I wish to remind you that the deadline to merge modules into NS-3.7 >> is about to come: it is scheduled for Wednesday November 18th 2009. >> If there is any error in the list or the status is different please >> don't hesitate to tell me. > > Faker, please remember to include the NetAnim review: > http://mailman.isi.edu/pipermail/ns-developers/2009-November/006914.html > > - Tom NetAnim: -Review code:http://codereview.appspot.com/117051 -Reviewers: Tom Henderson, Faker Moatamri -Developers: George Riley and Josh Pelkey -Status: waiting for corrections and +1s Craig can you please update the NS-3.7 web page with those details about merging advancement? (http://www.nsnam.org/wiki/index.php/Ns-3.7) Best regards Faker Moatamri From Amine.Ismail at sophia.inria.fr Fri Nov 13 00:50:31 2009 From: Amine.Ismail at sophia.inria.fr (Ismail Amine) Date: Fri, 13 Nov 2009 09:50:31 +0100 Subject: [Ns-developers] time conversion error In-Reply-To: <1258099065.13617.1.camel@localhost.localdomain> References: <4AFC4A3B.2070809@sophia.inria.fr> <1258099065.13617.1.camel@localhost.localdomain> Message-ID: <4AFD1DD7.4010602@sophia.inria.fr> Hi Mathieu, It is declared as Time Time m_lostDlMapInterval; Mathieu Lacage wrote: > On Thu, 2009-11-12 at 18:47 +0100, Ismail Amine wrote: > > >> Does any one knows why the time conversion is not correctly performed >> with the AddAttribute function? What should I do to make it work correctly? >> > > It should work fine: we have similar code in > src/devices/wifi/nqap-wifi-mac.cc > > .AddAttribute ("BeaconInterval", "Delay between two beacons", > TimeValue (Seconds (0.1)), > MakeTimeAccessor (&NqapWifiMac::GetBeaconInterval, > &NqapWifiMac::SetBeaconInterval), > MakeTimeChecker ()) > > > How did you declare m_lostDlMapInterval ? > > Mathieu > > From boyko at iitp.ru Fri Nov 13 01:03:35 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Fri, 13 Nov 2009 12:03:35 +0300 Subject: [Ns-developers] time conversion error In-Reply-To: <4AFC4A3B.2070809@sophia.inria.fr> References: <4AFC4A3B.2070809@sophia.inria.fr> Message-ID: <200911131203.35964.boyko@iitp.ru> Hi, Ismail, On Thursday 12 November 2009 08:47:39 pm Ismail Amine wrote: > Hi all, > > I have wrote the following lines of code: > |TypeId > > WimaxSubscriberStationNetDevice::GetTypeId (void) > { > static TypeId tid = TypeId ("ns3::WimaxSubscriberStationNetDevice.") > .SetParent () > > .AddConstructor () > ... How many attributes WimaxSubscriberStationNetDevice already has? If I correctly remember that, only first 10 attributes are automatically initialized to their default values. I always try to duplicate attribute defaults in constructor. Pavel > .AddAttribute ( > "LostDlMapInterval", > "Time since last received DL-MAP message before downlink > synchronization is considered lost. Maximum is 600ms", > TimeValue (Seconds(0.5)), > MakeTimeAccessor > (&WimaxSubscriberStationNetDevice::m_lostDlMapInterval), > MakeTimeChecker ()) > ... > > I tried then to print the value of m_lostDlMapInterval by writing the > > following line: > |std::cout << "lostDlMapInterval=" << > > GetLostDlMapInterval().GetSeconds() << std::endl;| > > and as a result I got: > > lostDlMapInterval=5e-07| > > I was expecting 0.5!!! > > I have also tried with MilliSeconds(500) and MicroSeconds(500000) but > they give the same result. > > However if I remove the previous lines from the GetTypeId function and I > insert in the constructor of WimaxSubscriberStationNetDevice the follwing: > > m_lostDlMapInterval = Seconds (0.5); > > A correct value is printed in stdout: > > lostDlMapInterval=0.5 > > Does any one knows why the time conversion is not correctly performed > with the AddAttribute function? What should I do to make it work correctly? > > Thank you > Amine > From Amine.Ismail at sophia.inria.fr Fri Nov 13 01:58:29 2009 From: Amine.Ismail at sophia.inria.fr (Ismail Amine) Date: Fri, 13 Nov 2009 10:58:29 +0100 Subject: [Ns-developers] time conversion error In-Reply-To: <4AFD1DD7.4010602@sophia.inria.fr> References: <4AFC4A3B.2070809@sophia.inria.fr> <1258099065.13617.1.camel@localhost.localdomain> <4AFD1DD7.4010602@sophia.inria.fr> Message-ID: <4AFD2DC5.6070809@sophia.inria.fr> Hi, I have removed this line from the main function: TimeStepPrecision::Set (TimeStepPrecision::FS); And now the coversion is well done!! I don't know what was the problem but fortunately it works now! Thx Amine Ismail Amine wrote: > Hi Mathieu, > > It is declared as Time > Time m_lostDlMapInterval; > > > > Mathieu Lacage wrote: >> On Thu, 2009-11-12 at 18:47 +0100, Ismail Amine wrote: >> >> >>> Does any one knows why the time conversion is not correctly >>> performed with the AddAttribute function? What should I do to make >>> it work correctly? >>> >> >> It should work fine: we have similar code in >> src/devices/wifi/nqap-wifi-mac.cc >> >> .AddAttribute ("BeaconInterval", "Delay between two beacons", >> TimeValue (Seconds (0.1)), >> MakeTimeAccessor (&NqapWifiMac::GetBeaconInterval, >> &NqapWifiMac::SetBeaconInterval), >> MakeTimeChecker ()) >> >> >> How did you declare m_lostDlMapInterval ? >> Mathieu >> >> > From nbaldo at cttc.es Fri Nov 13 02:03:38 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 13 Nov 2009 11:03:38 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4AFC4186.7080309@kit.edu> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> Message-ID: <4AFD2EFA.9040806@cttc.es> Hi Jens, Jens Mittag wrote: > > I understand your point, but capturing is no technical issue, not a > "capability" itself and rather the trade-off between "staying synced > to the first packet and hoping that FEC will solve the bit errors > introduced by the interfering stronger packet" and "switching to the > new frame and hoping that this will be more lucky than the first > one". Capturing is NOT about what is possible to decode but rather > WHICH strategic decision the reciever should do, i.e. which packet > frame is favored over the other. As experimental studies have shown, > this threshold is not based on any modulation techniques, but > artificially selected by Atheros. Not adding this threshold would > yield to anything but not to a model that reflects capturing... We should clarify which type of capture we are talking about. In [1] (which I guess that you know well) two types are mentioned: preamble capture (Section 3.3.1) and frame body capture (Section 3.3.2). The comments in my previous email were relevant to preable capture. For this case, I argue that the stronger signal will get the highest correlation peak in the detection of the preamble, and hence will be the one that the receiving PHY synchronizes onto, no matter how small the difference in signal power. This is why I proposed not to have any threshold. I guess you are talking about frame body capture; for this case, I agree that a "capture threshold" makes sense, because if the difference in power is too small then the new transmission cannot be noticed. As a side note, you mention that capture is a "trade-off" and a "strategic decision", but actually I do not think that the device has any choice in the case of frame body capture. When a significantly stronger signal arrives during frame body reception of the previous frame, the AGC unlocks (I guess this is the events that triggers the frame body capture, by the way). I am not confident on how atheros chipsets handle this case, but I know how prism chipsets do: since an AGC unlock event screws up the whole rx process, no matter how strong your FEC is, the baseband will abort reception. So the previous frame is lost in any case; the reception of the new frame can be attempted if the baseband processor can re-initialize and do preamble detection fast enough. The prism chipset can't do that; I guess atheros can. Nicola [1] Qi Chen, Felix Schmidt-Eisenlohr, Daniel Jiang, "Overhaul of IEEE 802.11 Modeling and Simulation in NS-2" From j.d.brugge at student.utwente.nl Fri Nov 13 02:08:44 2009 From: j.d.brugge at student.utwente.nl (Jonathan Brugge) Date: Fri, 13 Nov 2009 11:08:44 +0100 Subject: [Ns-developers] [patch] Use transactions in SQLite output In-Reply-To: <50019.193.251.48.82.1258063933.squirrel@imap-sop.inria.fr> References: <200911121523.33333.j.d.brugge@student.utwente.nl> <50019.193.251.48.82.1258063933.squirrel@imap-sop.inria.fr> Message-ID: <200911131108.45131.j.d.brugge@student.utwente.nl> Torsdag 12. november 2009 23.12.13 skrev Faker.Moatamri at sophia.inria.fr : > Seems really interesting, plus the patch is really small. Did you check if > there is any impact on existing code/functionalities? The only in-tree user of the code is the WiFi example in examples/stats. That example seems to work without problems with the transactions enabled - I have checked that. My own code also gives the exact same results with or without transactions, so I don't expect problems. Jonathan From jens.mittag at kit.edu Fri Nov 13 02:58:25 2009 From: jens.mittag at kit.edu (Jens Mittag) Date: Fri, 13 Nov 2009 11:58:25 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4AFD2EFA.9040806@cttc.es> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> Message-ID: <4AFD3BD1.4050200@kit.edu> Hi Nicola! Nicola Baldo schrieb: > We should clarify which type of capture we are talking about. In [1] > (which I guess that you know well) two types are mentioned: preamble > capture (Section 3.3.1) and frame body capture (Section 3.3.2). > > The comments in my previous email were relevant to preable capture. For > this case, I argue that the stronger signal will get the highest > correlation peak in the detection of the preamble, and hence will be the > one that the receiving PHY synchronizes onto, no matter how small the > difference in signal power. This is why I proposed not to have any > threshold. > > I guess you are talking about frame body capture; for this case, I agree > that a "capture threshold" makes sense, because if the difference in > power is too small then the new transmission cannot be noticed. > > As a side note, you mention that capture is a "trade-off" and a > "strategic decision", but actually I do not think that the device has > any choice in the case of frame body capture. When a significantly > stronger signal arrives during frame body reception of the previous > frame, the AGC unlocks (I guess this is the events that triggers the > frame body capture, by the way). I am not confident on how atheros > chipsets handle this case, but I know how prism chipsets do: since an > AGC unlock event screws up the whole rx process, no matter how strong > your FEC is, the baseband will abort reception. So the previous frame is > lost in any case; the reception of the new frame can be attempted if the > baseband processor can re-initialize and do preamble detection fast > enough. The prism chipset can't do that; I guess atheros can. > Yes, that's what I was trying to explain. But even with your argumentation we need a threshold (imho), though you would name it "AGC unlock threshold". How AGC works is from my understanding/experience a matter of hardware implementation. And depending on the supported power range of the AGC, the "AGC unlock" happens earlier or later, right? With respect to the strategic decision, you could design your AGC to unlock after only a 5dB gain or only after a 10dB gain. From that perspective, its a strategic decision, though it has been made during the chipset design... (please correct me if I am wrong, I might be mistaken) Considering capture in general: from my knowledge and discussion with people who are more experienced in the lowest layers, capture is enabled by having two decoding units for the incoming signal. Both will try to detect a frame (either by looking for a steep rise of the energy or by correlating the signal to the known preamble sequence). If a frame is detected, one unit starts the reception, and the other unit continues to look for preambles. In case a stronger preamble is detected (either by a steep rise of the energy again, or by a high correlation), the chip can start to decode the new frame and skip the previous one, or just stick with the current frame. So capturing is also related to signal detection. Further details on signal detecting can be found in [1] below, which explains the techniques that are used in the Atheros chipset. Conclusion: I still believe that we should have a threshold for preamble capture. cheers Jens [1] Ilenia Tinnirello, Domenico Giustiniano, Luca Scalia, Giuseppe Bianchi: On the side-effects of proprietary solutions for fading and interference mitigation in IEEE 802.11b/g outdoor links. Computer Networks 53(2): 141-152 (2009) -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Engesserstr. 2, 76131 Karlsruhe, Germany Building 20.50, Room 112 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ From mathieu.lacage at sophia.inria.fr Fri Nov 13 03:18:48 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 13 Nov 2009 12:18:48 +0100 Subject: [Ns-developers] time conversion error In-Reply-To: <4AFD2DC5.6070809@sophia.inria.fr> References: <4AFC4A3B.2070809@sophia.inria.fr> <1258099065.13617.1.camel@localhost.localdomain> <4AFD1DD7.4010602@sophia.inria.fr> <4AFD2DC5.6070809@sophia.inria.fr> Message-ID: <1258111128.13617.6.camel@localhost.localdomain> On Fri, 2009-11-13 at 10:58 +0100, Ismail Amine wrote: > Hi, > > I have removed this line from the main function: > TimeStepPrecision::Set (TimeStepPrecision::FS); > And now the coversion is well done!! I don't know what was the problem > but fortunately it works now! Please, file a bug about this Mathieu From nbaldo at cttc.es Fri Nov 13 07:01:18 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 13 Nov 2009 16:01:18 +0100 Subject: [Ns-developers] r5511 (ChannelNumber attribute...) fails tests Message-ID: <4AFD74BE.2000805@cttc.es> Hi Pavel, test.py reports several failures when run with the current tip (r5511) of ns-3-dev, while the previous revision (r5510) is successful. I see that changeset 5511 is yours: http://code.nsnam.org/ns-3-dev/rev/d77201fa5ee2 would you mind having a look? Thanks & kind regards, Nicola From faker.moatamri at sophia.inria.fr Fri Nov 13 07:10:02 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 13 Nov 2009 16:10:02 +0100 Subject: [Ns-developers] Python bindings failure Message-ID: <4AFD76CA.3050009@sophia.inria.fr> Hi, Since the latest changes in ns-3-dev, the building with python are failing. The reasons are two changes: /Guillaume Seguin/ *Simulator::SetScheduler now takes an ObjectFactory* /Mathieu Lacage/ *replace RefCountBase with SimpleRefCount<> to avoid duplicate refcounting implementations.* Those two gives the following errors: For SetScheduler changes: debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* _wrap_PyNs3Simulator_SetScheduler(PyNs3Simulator*, PyObject*, PyObject*)': debug/bindings/python/ns3_module_simulator.cc:1530: error: no matching function for call to 'ns3::Simulator::SetScheduler(ns3::Ptr)' debug/ns3/simulator.h:84: note: candidates are: static void ns3::Simulator::SetScheduler(ns3::ObjectFactory) debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* _wrap_PyNs3SimulatorImpl_SetScheduler(PyNs3SimulatorImpl*, PyObject*, PyObject*)': debug/bindings/python/ns3_module_simulator.cc:5960: error: no matching function for call to 'ns3::SimulatorImpl::SetScheduler(ns3::Ptr)' debug/ns3/simulator-impl.h:53: note: candidates are: virtual void ns3::SimulatorImpl::SetScheduler(ns3::ObjectFactory) debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* _wrap_PyNs3DefaultSimulatorImpl_SetScheduler(PyNs3DefaultSimulatorImpl*, PyObject*, PyObject*)': debug/bindings/python/ns3_module_simulator.cc:9888: error: no matching function for call to 'ns3::DefaultSimulatorImpl::SetScheduler(ns3::Ptr)' debug/ns3/default-simulator-impl.h:59: note: candidates are: virtual void ns3::DefaultSimulatorImpl::SetScheduler(ns3::ObjectFactory) debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* _wrap_PyNs3RealtimeSimulatorImpl_SetScheduler(PyNs3RealtimeSimulatorImpl*, PyObject*, PyObject*)': debug/bindings/python/ns3_module_simulator.cc:13904: error: no matching function for call to 'ns3::RealtimeSimulatorImpl::SetScheduler(ns3::Ptr)' debug/ns3/realtime-simulator-impl.h:69: note: candidates are: virtual void ns3::RealtimeSimulatorImpl::SetScheduler(ns3::ObjectFactory) Waf: Leaving directory `/home/buildslave/slave/full-rahan-g++-4.4.0/build/build' Which should be fixed by rescanning the python bindings For RefCountBase changes: debug/bindings/python/ns3_module_core.cc: In function ?int _wrap_PyNs3RefCountBase__tp_init__0(PyNs3RefCountBase*, PyObject*, PyObject*, PyObject**)?: debug/bindings/python/ns3_module_core.cc:6816: error: cannot allocate an object of abstract type ?ns3::RefCountBase? debug/ns3/ref-count-base.h:38: note: because the following virtual functions are pure within ?ns3::RefCountBase?: debug/ns3/ref-count-base.h:43: note: virtual ns3::RefCountBase::~RefCountBase() debug/ns3/ref-count-base.h:43: note: virtual ns3::RefCountBase::~RefCountBase() debug/bindings/python/ns3_module_core.cc: In function ?int _wrap_PyNs3RefCountBase__tp_init__1(PyNs3RefCountBase*, PyObject*, PyObject*, PyObject**)?: debug/bindings/python/ns3_module_core.cc:6835: error: cannot allocate an object of abstract type ?ns3::RefCountBase? debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has pure virtual functions debug/bindings/python/ns3_module_core.cc: In function ?PyObject* _wrap_PyNs3RefCountBase__copy__(PyNs3RefCountBase*)?: debug/bindings/python/ns3_module_core.cc:6870: error: cannot allocate an object of abstract type ?ns3::RefCountBase? debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has pure virtual functions Which is fixed by replacing in src/core/ref-count-base.h /virtual ~RefCountBase () = 0; /by /~RefCountBase () ;/. Mathieu can I commit this change? Now the big problem that I was unable to fix for now is that after making the above change and after successfully scanning python bindings, I get this error: uild failed -> task failed (err #1): {task: command_task ns3modulegen.py,ns3modulegen_generated.py,.......} When I look at the log file less build/debug/bindings/python/ns3modulegen.log I get the following error: Traceback (most recent call last): File "../bindings/python/ns3modulegen.py", line 166, in main() File "../bindings/python/ns3modulegen.py", line 86, in main register_types(root_module) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3modulegen_generated.py", line 56, in register_types ns3_module_core.register_types(module) File "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_core.py", line 157, in register_types module.add_class('SimpleRefCount', template_parameters=['ns3::PbbPacket', 'ns3::Header'], parent=root_module['ns3::Header']) KeyError: 'ns3::Header' Can anyone tell me why the ns3::Header is not recognized in python bindings? Gustavo? Mathieu? anyone? Best regards Faker Moatamri From boyko at iitp.ru Fri Nov 13 07:22:18 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Fri, 13 Nov 2009 18:22:18 +0300 Subject: [Ns-developers] r5511 (ChannelNumber attribute...) fails tests In-Reply-To: <4AFD74BE.2000805@cttc.es> References: <4AFD74BE.2000805@cttc.es> Message-ID: <200911131822.18373.boyko@iitp.ru> On Friday 13 November 2009 06:01:18 pm Nicola Baldo wrote: > Hi Pavel, > > test.py reports several failures when run with the current tip (r5511) > of ns-3-dev, while the previous revision (r5510) is successful. I see > that changeset 5511 is yours: > > http://code.nsnam.org/ns-3-dev/rev/d77201fa5ee2 > > would you mind having a look? fixed, I'm sorry. Pavel From gjcarneiro at gmail.com Fri Nov 13 07:23:51 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 13 Nov 2009 15:23:51 +0000 Subject: [Ns-developers] Python bindings failure In-Reply-To: <4AFD76CA.3050009@sophia.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> Message-ID: 2009/11/13 Faker Moatamri > Hi, > Since the latest changes in ns-3-dev, the building with python are failing. > The reasons are two changes: > /Guillaume Seguin/ *Simulator::SetScheduler now takes an ObjectFactory* < > http://code.nsnam.org/ns-3-dev/rev/915abd2b907b> > /Mathieu Lacage/ *replace RefCountBase with SimpleRefCount<> to avoid > duplicate refcounting implementations.* < > http://code.nsnam.org/ns-3-dev/rev/c0ac392289c3> > Those two gives the following errors: > For SetScheduler changes: > > debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* > _wrap_PyNs3Simulator_SetScheduler(PyNs3Simulator*, PyObject*, PyObject*)': > debug/bindings/python/ns3_module_simulator.cc:1530: error: no matching > function for call to > 'ns3::Simulator::SetScheduler(ns3::Ptr)' > debug/ns3/simulator.h:84: note: candidates are: static void > ns3::Simulator::SetScheduler(ns3::ObjectFactory) > debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* > _wrap_PyNs3SimulatorImpl_SetScheduler(PyNs3SimulatorImpl*, PyObject*, > PyObject*)': > debug/bindings/python/ns3_module_simulator.cc:5960: error: no matching > function for call to > 'ns3::SimulatorImpl::SetScheduler(ns3::Ptr)' > debug/ns3/simulator-impl.h:53: note: candidates are: virtual void > ns3::SimulatorImpl::SetScheduler(ns3::ObjectFactory) > debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* > _wrap_PyNs3DefaultSimulatorImpl_SetScheduler(PyNs3DefaultSimulatorImpl*, > PyObject*, PyObject*)': > debug/bindings/python/ns3_module_simulator.cc:9888: error: no matching > function for call to > 'ns3::DefaultSimulatorImpl::SetScheduler(ns3::Ptr)' > debug/ns3/default-simulator-impl.h:59: note: candidates are: virtual void > ns3::DefaultSimulatorImpl::SetScheduler(ns3::ObjectFactory) > debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* > _wrap_PyNs3RealtimeSimulatorImpl_SetScheduler(PyNs3RealtimeSimulatorImpl*, > PyObject*, PyObject*)': > debug/bindings/python/ns3_module_simulator.cc:13904: error: no matching > function for call to > 'ns3::RealtimeSimulatorImpl::SetScheduler(ns3::Ptr)' > debug/ns3/realtime-simulator-impl.h:69: note: candidates are: virtual void > ns3::RealtimeSimulatorImpl::SetScheduler(ns3::ObjectFactory) > Waf: Leaving directory > `/home/buildslave/slave/full-rahan-g++-4.4.0/build/build' > > Which should be fixed by rescanning the python bindings > For RefCountBase changes: > debug/bindings/python/ns3_module_core.cc: In function ?int > _wrap_PyNs3RefCountBase__tp_init__0(PyNs3RefCountBase*, PyObject*, > PyObject*, PyObject**)?: > debug/bindings/python/ns3_module_core.cc:6816: error: cannot allocate an > object of abstract type ?ns3::RefCountBase? > debug/ns3/ref-count-base.h:38: note: because the following virtual > functions are pure within ?ns3::RefCountBase?: > debug/ns3/ref-count-base.h:43: note: virtual > ns3::RefCountBase::~RefCountBase() > debug/ns3/ref-count-base.h:43: note: virtual > ns3::RefCountBase::~RefCountBase() > debug/bindings/python/ns3_module_core.cc: In function ?int > _wrap_PyNs3RefCountBase__tp_init__1(PyNs3RefCountBase*, PyObject*, > PyObject*, PyObject**)?: > debug/bindings/python/ns3_module_core.cc:6835: error: cannot allocate an > object of abstract type ?ns3::RefCountBase? > debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has > pure virtual functions > debug/bindings/python/ns3_module_core.cc: In function ?PyObject* > _wrap_PyNs3RefCountBase__copy__(PyNs3RefCountBase*)?: > debug/bindings/python/ns3_module_core.cc:6870: error: cannot allocate an > object of abstract type ?ns3::RefCountBase? > debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has > pure virtual functions > > Which is fixed by replacing in src/core/ref-count-base.h /virtual > ~RefCountBase () = 0; /by /~RefCountBase () ;/. Mathieu can I commit this > change? > > Now the big problem that I was unable to fix for now is that after making > the above change and after successfully scanning python bindings, I get this > error: > uild failed > -> task failed (err #1): > {task: command_task ns3modulegen.py,ns3modulegen_generated.py,.......} > > When I look at the log file > less build/debug/bindings/python/ns3modulegen.log I get the following > error: > Traceback (most recent call last): > File "../bindings/python/ns3modulegen.py", line 166, in > main() > File "../bindings/python/ns3modulegen.py", line 86, in main > register_types(root_module) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3modulegen_generated.py", > line 56, in register_types > ns3_module_core.register_types(module) > File > "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_core.py", > line 157, in register_types > module.add_class('SimpleRefCount', template_parameters=['ns3::PbbPacket', > 'ns3::Header'], parent=root_module['ns3::Header']) > KeyError: 'ns3::Header' > > Can anyone tell me why the ns3::Header is not recognized in python > bindings? Gustavo? Mathieu? anyone? > It is something new that breaks pybindgen scanning and the way code is being split into different python files. Basically, SimpleRefCount is a class that belongs in module core, and so pybindgen tries to register this class, with all seen template instantiations of that class, inside the module 'core'. However, one such instantiation uses a type from module 'node', but the types for that module are registered later. I guess I'll have to fix pybindgen. Tomorrow, maybe?... -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From nbaldo at cttc.es Fri Nov 13 07:25:56 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 13 Nov 2009 16:25:56 +0100 Subject: [Ns-developers] r5511 (ChannelNumber attribute...) fails tests In-Reply-To: <200911131822.18373.boyko@iitp.ru> References: <4AFD74BE.2000805@cttc.es> <200911131822.18373.boyko@iitp.ru> Message-ID: <4AFD7A84.5050502@cttc.es> Thank you for the rapid fix! Have a nice weekend... Nicola Pavel Boyko wrote: > On Friday 13 November 2009 06:01:18 pm Nicola Baldo wrote: >> Hi Pavel, >> >> test.py reports several failures when run with the current tip (r5511) >> of ns-3-dev, while the previous revision (r5510) is successful. I see >> that changeset 5511 is yours: >> >> http://code.nsnam.org/ns-3-dev/rev/d77201fa5ee2 >> >> would you mind having a look? > > fixed, I'm sorry. > > Pavel From faker.moatamri at sophia.inria.fr Fri Nov 13 08:10:03 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 13 Nov 2009 17:10:03 +0100 Subject: [Ns-developers] Bug 471 - [PATCH] access point address manager Message-ID: <4AFD84DB.8040505@sophia.inria.fr> Hi all, I've been looking in bugzilla for some bugs and I've seen the bug 471 with its patch. The discussion began at the beginning of the year and I took a look at the code. I took the files included in bugzilla ap-address-manager.h/cc and put them into the src/contrib folder (as suggested by mathieu at that time) and tried to compile them. It didn't work saying that Ipv4 class doesn't have a function called GetAddress (). My question is: is it worth it to spend time on adapting the obsolete code in ap-address-manager.h/cc to the current version of the ns-3? If yes I'll try to find the time to fix this, otherwise I will remove this enhancement from bugzilla. Here is the contribution explanation by Francesco Malandrino (5/1/2009): "Hi, Attached the "magic DHCP" I was talking about. Functions are (shortly) documented with comments; you basically do the following: 1. add APs, stating base (network) address, e.g. "192.168.1." and first available IP (eg. 2 if the AP has 192.168.1.1). Note that only /24 networks are supported; 2. add stations. The manager takes care for both addressing and routing. Additionally, you may specify one or more multicast route, in case you use it (by default, multicast frames sent from your stations won't be automatically forwarded). Also note that if you use this component you do NOT have to call GlobalRouteManager::PopulateTables. Ah, stations (more correctly: WifiNetDevices of stations) do need to have a (any, possibly a bogus one) address when they are not associated, so please make sure not to Add WifiNetDevices without an address, or Send from your applications will fail. Comments or suggestions are welcome (especially if you want to turn this stuff into a DHCP implementation ;)) Francesco" Best regards Faker Moatamri From nbaldo at cttc.es Fri Nov 13 09:00:55 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 13 Nov 2009 18:00:55 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4AFD3BD1.4050200@kit.edu> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> Message-ID: <4AFD90C7.1040505@cttc.es> Hi Jens, > How AGC works is from my understanding/experience a matter of hardware > implementation. And depending on the supported power range of the AGC, > the "AGC unlock" happens earlier or later, right? With respect to the > strategic decision, you could design your AGC to unlock after only a 5dB > gain or only after a 10dB gain. From that perspective, its a strategic > decision, though it has been made during the chipset design... (please > correct me if I am wrong, I might be mistaken) I don't know for sure... your hypothesis makes sense, but I guess that also the characteristics of the demodulator constrain the design of the AGC. We should ask some PHY layer people ;-) > > Considering capture in general: from my knowledge and discussion with > people who are more experienced in the lowest layers, capture is enabled > by having two decoding units for the incoming signal. Both will try to > detect a frame (either by looking for a steep rise of the energy or by > correlating the signal to the known preamble sequence). If a frame is > detected, one unit starts the reception, and the other unit continues to > look for preambles. In case a stronger preamble is detected (either by a > steep rise of the energy again, or by a high correlation), the chip can > start to decode the new frame and skip the previous one, or just stick > with the current frame. So capturing is also related to signal > detection. Further details on signal detecting can be found in [1] > below, which explains the techniques that are used in the Atheros chipset. > > Conclusion: I still believe that we should have a threshold for preamble > capture. > From the paper that you cited I understand that atheros devices detect the start of a new frame using either AGC jump or preamble detection. For prism devices I know that AGC jump, Preamble Detection and Energy Detection can be all used for frame start detection, with different logical combinations (e.g., logical OR, or logical AND of some or all events). On the other hand, YansWifiPhy currently implements Energy Detection only. Your proposed change would introduce AGC for capture only, so I think it would lead to a poorly consistent YansWifiPhy, with an ideal model for transitions IDLE->SYNC but a more real-world-oriented model for re-SYNC (i.e., capture) events. If you can produce a patch that: 1) introduces the modeling of preamble detection (PD) and AGC 2) allows doing transitions from IDLE to SYNC according to different logical combinations of ED, PD and AGC jumps 3) uses PD and AGC jumps for preamble capture 4) uses AGC jumps for frame body capture then you can count on my +1. Regards, Nicola From mathieu.lacage at sophia.inria.fr Sat Nov 14 04:40:53 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sat, 14 Nov 2009 13:40:53 +0100 Subject: [Ns-developers] Python bindings failure In-Reply-To: <4AFD76CA.3050009@sophia.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> Message-ID: <1258202453.21469.3.camel@localhost.localdomain> On Fri, 2009-11-13 at 16:10 +0100, Faker Moatamri wrote: > Hi, > Since the latest changes in ns-3-dev, the building with python are failing. > The reasons are two changes: > /Guillaume Seguin/ *Simulator::SetScheduler now takes an ObjectFactory* > > /Mathieu Lacage/ *replace RefCountBase with SimpleRefCount<> to avoid > duplicate refcounting implementations.* > > Those two gives the following errors: > For SetScheduler changes: > > debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* _wrap_PyNs3Simulator_SetScheduler(PyNs3Simulator*, PyObject*, PyObject*)': > debug/bindings/python/ns3_module_simulator.cc:1530: error: no matching function for call to 'ns3::Simulator::SetScheduler(ns3::Ptr)' > debug/ns3/simulator.h:84: note: candidates are: static void ns3::Simulator::SetScheduler(ns3::ObjectFactory) > debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* _wrap_PyNs3SimulatorImpl_SetScheduler(PyNs3SimulatorImpl*, PyObject*, PyObject*)': > debug/bindings/python/ns3_module_simulator.cc:5960: error: no matching function for call to 'ns3::SimulatorImpl::SetScheduler(ns3::Ptr)' > debug/ns3/simulator-impl.h:53: note: candidates are: virtual void ns3::SimulatorImpl::SetScheduler(ns3::ObjectFactory) > debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* _wrap_PyNs3DefaultSimulatorImpl_SetScheduler(PyNs3DefaultSimulatorImpl*, PyObject*, PyObject*)': > debug/bindings/python/ns3_module_simulator.cc:9888: error: no matching function for call to 'ns3::DefaultSimulatorImpl::SetScheduler(ns3::Ptr)' > debug/ns3/default-simulator-impl.h:59: note: candidates are: virtual void ns3::DefaultSimulatorImpl::SetScheduler(ns3::ObjectFactory) > debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* _wrap_PyNs3RealtimeSimulatorImpl_SetScheduler(PyNs3RealtimeSimulatorImpl*, PyObject*, PyObject*)': > debug/bindings/python/ns3_module_simulator.cc:13904: error: no matching function for call to 'ns3::RealtimeSimulatorImpl::SetScheduler(ns3::Ptr)' > debug/ns3/realtime-simulator-impl.h:69: note: candidates are: virtual void ns3::RealtimeSimulatorImpl::SetScheduler(ns3::ObjectFactory) > Waf: Leaving directory `/home/buildslave/slave/full-rahan-g++-4.4.0/build/build' > > Which should be fixed by rescanning the python bindings > For RefCountBase changes: > debug/bindings/python/ns3_module_core.cc: In function ?int > _wrap_PyNs3RefCountBase__tp_init__0(PyNs3RefCountBase*, PyObject*, > PyObject*, PyObject**)?: > debug/bindings/python/ns3_module_core.cc:6816: error: cannot allocate an > object of abstract type ?ns3::RefCountBase? > debug/ns3/ref-count-base.h:38: note: because the following virtual > functions are pure within ?ns3::RefCountBase?: > debug/ns3/ref-count-base.h:43: note: virtual > ns3::RefCountBase::~RefCountBase() > debug/ns3/ref-count-base.h:43: note: virtual > ns3::RefCountBase::~RefCountBase() > debug/bindings/python/ns3_module_core.cc: In function ?int > _wrap_PyNs3RefCountBase__tp_init__1(PyNs3RefCountBase*, PyObject*, > PyObject*, PyObject**)?: > debug/bindings/python/ns3_module_core.cc:6835: error: cannot allocate an > object of abstract type ?ns3::RefCountBase? > debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has > pure virtual functions > debug/bindings/python/ns3_module_core.cc: In function ?PyObject* > _wrap_PyNs3RefCountBase__copy__(PyNs3RefCountBase*)?: > debug/bindings/python/ns3_module_core.cc:6870: error: cannot allocate an > object of abstract type ?ns3::RefCountBase? > debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has > pure virtual functions > > Which is fixed by replacing in src/core/ref-count-base.h /virtual > ~RefCountBase () = 0; /by /~RefCountBase () ;/. Mathieu can I commit > this change? RefCountBase has always been documented as having a virtual destructor so, removing that would break large amounts of existing code. Removing the 'pure' (aka, '= 0') would be ok and I guess that it should be enough to make pybindgen happy. i.e., I would be ok with this: s/virtual ~RefCountBase () = 0;/virtual ~RefCountBase ();/ Mathieu From mathieu.lacage at sophia.inria.fr Sat Nov 14 08:17:43 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sat, 14 Nov 2009 17:17:43 +0100 Subject: [Ns-developers] time conversion error In-Reply-To: <200911131203.35964.boyko@iitp.ru> References: <4AFC4A3B.2070809@sophia.inria.fr> <200911131203.35964.boyko@iitp.ru> Message-ID: <1258215463.26175.7.camel@localhost.localdomain> On Fri, 2009-11-13 at 12:03 +0300, Pavel Boyko wrote: > How many attributes WimaxSubscriberStationNetDevice already has? If I > correctly remember that, only first 10 attributes are automatically initialized > to their default values. I always try to duplicate attribute defaults in > constructor. I am not aware of any hardcoded upper bound on the number of attributes with default values in Object. So, if you had problems like that, please, file a bug. Mathieu From mathieu.lacage at sophia.inria.fr Sat Nov 14 08:29:32 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sat, 14 Nov 2009 17:29:32 +0100 Subject: [Ns-developers] ./waf --regresion failing Message-ID: <1258216172.26175.14.camel@localhost.localdomain> hi, I noticed that ./waf --regression fails in ns-3-dev. The first bad revision is: changeset: 5503:c305c6e122c9 user: Sebastien Vincent date: Wed Nov 11 16:21:18 2009 +0100 summary: Bug #729 IPv6 over PPP. Which hints at something being wrong in vincent's commit. Vincent ? Mathieu From mathieu.lacage at sophia.inria.fr Sat Nov 14 11:37:12 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sat, 14 Nov 2009 20:37:12 +0100 Subject: [Ns-developers] per-event node id Message-ID: <1258227432.26175.40.camel@localhost.localdomain> hi, At the start of the 3.6 release process, guillaume submitted for review an early version of his multithreading work. While the multithreading scheduler is still not fully baked, some parts did get an ack from tom and gustavo in september but, because of lack of time, guillaume never separated them from the rest of his code and never completed the changes requested by tom. I have thus removed the thread-safety parts of his changesets, focused on the sole support for node contexts, and pushed this. What is the change ? 1) NS_LOG now prints the node id of the calling code 2) If you implement a NetDevice/Channel subclass, you need to use Simulator::ScheduleWithContext instead of Simulator::Schedule in your Channel::Send method 3) If you implement an adhoc packet generator in your script, you need to use ScheduleWithContext to call Socket::Send Mathieu From Faker.Moatamri at sophia.inria.fr Sat Nov 14 14:38:03 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Sat, 14 Nov 2009 23:38:03 +0100 (CET) Subject: [Ns-developers] [patch] Use transactions in SQLite output In-Reply-To: <4AFCF41B.3020508@tomh.org> References: <200911121523.33333.j.d.brugge@student.utwente.nl> <50019.193.251.48.82.1258063933.squirrel@imap-sop.inria.fr> <4AFCF41B.3020508@tomh.org> Message-ID: <55118.193.251.48.82.1258238283.squirrel@imap-sop.inria.fr> > Faker.Moatamri at sophia.inria.fr wrote: >>> Hi all, >>> >>> I'm working on a routing protocol implementation in ns-3 (Cross-Entropy >>> Ant >>> System or CEAS for short). To be able to analyze how the protocol >>> behaves, >>> I've been using the SQLite data output interface. I'm logging >>> relatively >>> large >>> amounts of data: currently about 5000 insert queries per simulation run >>> and I >>> expect that number to increase significantly. >>> >>> As storing the data started to take almost 50% of my simulation time, I >>> took a >>> look at the code in contrib/stats/sqlite-data-output.cc and found out >>> that >>> it >>> doesn't use transactions. The attached patch is a crude but simple way >>> to >>> enable them. It shouldn't cause big delays in small batches of queries, >>> but >>> really helps with big numbers of inserts. >>> >>> A small benchmark gave the following results: >>> >>> - Simulation, don't store results: ca. 18s >>> - Simulation + store without transactions: ca. 31s >>> - Simulation + store with transactions: ca. 18s >>> >> Seems really interesting, plus the patch is really small. Did you check >> if >> there is any impact on existing code/functionalities? >> Tom, Craig, Gustavo, Others, what do you think? > > Joe Kopena has been maintaining the stats code; perhaps he could have a > look and push it if OK. > > - Tom > Joe? what do you think of the patch? Best regards Faker -------------- next part -------------- A non-text attachment was scrubbed... Name: use_transaction.diff Type: application/octet-stream Size: 450 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091114/ce7ec938/use_transaction.obj From tomh at tomh.org Sat Nov 14 21:32:52 2009 From: tomh at tomh.org (Tom Henderson) Date: Sat, 14 Nov 2009 21:32:52 -0800 Subject: [Ns-developers] ./waf --regresion failing In-Reply-To: <1258216172.26175.14.camel@localhost.localdomain> References: <1258216172.26175.14.camel@localhost.localdomain> Message-ID: <4AFF9284.5040607@tomh.org> Mathieu Lacage wrote: > hi, > > I noticed that ./waf --regression fails in ns-3-dev. > > The first bad revision is: > changeset: 5503:c305c6e122c9 > user: Sebastien Vincent > date: Wed Nov 11 16:21:18 2009 +0100 > summary: Bug #729 IPv6 over PPP. > > Which hints at something being wrong in vincent's commit. Vincent ? Two things changed; the above PPP changes, and the change I pushed this morning regarding IPv4 broadcast TTL. I pushed the updates for the non-Python tests (python is still an issue for me due to the RefCountBase issue). Note that test.py did not catch this behavior change, which suggests that we still have some migration work to do for test.py to take over ./waf --regression. Tom From mathieu.lacage at sophia.inria.fr Sun Nov 15 00:24:35 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sun, 15 Nov 2009 09:24:35 +0100 Subject: [Ns-developers] ./waf --regresion failing In-Reply-To: <4AFF9284.5040607@tomh.org> References: <1258216172.26175.14.camel@localhost.localdomain> <4AFF9284.5040607@tomh.org> Message-ID: <1258273475.2485.7.camel@localhost.localdomain> On Sat, 2009-11-14 at 21:32 -0800, Tom Henderson wrote: > > Which hints at something being wrong in vincent's commit. Vincent ? > > Two things changed; the above PPP changes, and the change I pushed this > morning regarding IPv4 broadcast TTL. > > I pushed the updates for the non-Python tests (python is still an issue Ok, I pushed the change I mentioned previously on the ML to ref-count-base.h. I have no idea if this is what is needed for the python bindings because they fail for me with or without the change. > this behavior change, which suggests that we still have some migration > work to do for test.py to take over ./waf --regression. The first step would be to figure out how to make ./test.py run the regression tests directly to make sure that users do not have to run two 'test' commands. Then, we can slowly migrate the regression tests to the new test framework. Mathieu From gjcarneiro at gmail.com Sun Nov 15 08:25:30 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Sun, 15 Nov 2009 16:25:30 +0000 Subject: [Ns-developers] Python bindings failure In-Reply-To: References: <4AFD76CA.3050009@sophia.inria.fr> Message-ID: I started to look at this, but got blocked by the weird pygccxml API. Awaiting some feedback from the pygccxml developer. 2009/11/13 Gustavo Carneiro > > > 2009/11/13 Faker Moatamri > > Hi, >> Since the latest changes in ns-3-dev, the building with python are >> failing. >> The reasons are two changes: >> /Guillaume Seguin/ *Simulator::SetScheduler now takes an ObjectFactory* < >> http://code.nsnam.org/ns-3-dev/rev/915abd2b907b> >> /Mathieu Lacage/ *replace RefCountBase with SimpleRefCount<> to avoid >> duplicate refcounting implementations.* < >> http://code.nsnam.org/ns-3-dev/rev/c0ac392289c3> >> Those two gives the following errors: >> For SetScheduler changes: >> >> debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* >> _wrap_PyNs3Simulator_SetScheduler(PyNs3Simulator*, PyObject*, PyObject*)': >> debug/bindings/python/ns3_module_simulator.cc:1530: error: no matching >> function for call to >> 'ns3::Simulator::SetScheduler(ns3::Ptr)' >> debug/ns3/simulator.h:84: note: candidates are: static void >> ns3::Simulator::SetScheduler(ns3::ObjectFactory) >> debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* >> _wrap_PyNs3SimulatorImpl_SetScheduler(PyNs3SimulatorImpl*, PyObject*, >> PyObject*)': >> debug/bindings/python/ns3_module_simulator.cc:5960: error: no matching >> function for call to >> 'ns3::SimulatorImpl::SetScheduler(ns3::Ptr)' >> debug/ns3/simulator-impl.h:53: note: candidates are: virtual void >> ns3::SimulatorImpl::SetScheduler(ns3::ObjectFactory) >> debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* >> _wrap_PyNs3DefaultSimulatorImpl_SetScheduler(PyNs3DefaultSimulatorImpl*, >> PyObject*, PyObject*)': >> debug/bindings/python/ns3_module_simulator.cc:9888: error: no matching >> function for call to >> 'ns3::DefaultSimulatorImpl::SetScheduler(ns3::Ptr)' >> debug/ns3/default-simulator-impl.h:59: note: candidates are: virtual void >> ns3::DefaultSimulatorImpl::SetScheduler(ns3::ObjectFactory) >> debug/bindings/python/ns3_module_simulator.cc: In function 'PyObject* >> _wrap_PyNs3RealtimeSimulatorImpl_SetScheduler(PyNs3RealtimeSimulatorImpl*, >> PyObject*, PyObject*)': >> debug/bindings/python/ns3_module_simulator.cc:13904: error: no matching >> function for call to >> 'ns3::RealtimeSimulatorImpl::SetScheduler(ns3::Ptr)' >> debug/ns3/realtime-simulator-impl.h:69: note: candidates are: virtual void >> ns3::RealtimeSimulatorImpl::SetScheduler(ns3::ObjectFactory) >> Waf: Leaving directory >> `/home/buildslave/slave/full-rahan-g++-4.4.0/build/build' >> >> Which should be fixed by rescanning the python bindings >> For RefCountBase changes: >> debug/bindings/python/ns3_module_core.cc: In function ?int >> _wrap_PyNs3RefCountBase__tp_init__0(PyNs3RefCountBase*, PyObject*, >> PyObject*, PyObject**)?: >> debug/bindings/python/ns3_module_core.cc:6816: error: cannot allocate an >> object of abstract type ?ns3::RefCountBase? >> debug/ns3/ref-count-base.h:38: note: because the following virtual >> functions are pure within ?ns3::RefCountBase?: >> debug/ns3/ref-count-base.h:43: note: virtual >> ns3::RefCountBase::~RefCountBase() >> debug/ns3/ref-count-base.h:43: note: virtual >> ns3::RefCountBase::~RefCountBase() >> debug/bindings/python/ns3_module_core.cc: In function ?int >> _wrap_PyNs3RefCountBase__tp_init__1(PyNs3RefCountBase*, PyObject*, >> PyObject*, PyObject**)?: >> debug/bindings/python/ns3_module_core.cc:6835: error: cannot allocate an >> object of abstract type ?ns3::RefCountBase? >> debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has >> pure virtual functions >> debug/bindings/python/ns3_module_core.cc: In function ?PyObject* >> _wrap_PyNs3RefCountBase__copy__(PyNs3RefCountBase*)?: >> debug/bindings/python/ns3_module_core.cc:6870: error: cannot allocate an >> object of abstract type ?ns3::RefCountBase? >> debug/ns3/ref-count-base.h:38: note: since type ?ns3::RefCountBase? has >> pure virtual functions >> >> Which is fixed by replacing in src/core/ref-count-base.h /virtual >> ~RefCountBase () = 0; /by /~RefCountBase () ;/. Mathieu can I commit this >> change? >> >> Now the big problem that I was unable to fix for now is that after making >> the above change and after successfully scanning python bindings, I get this >> error: >> uild failed >> -> task failed (err #1): >> {task: command_task ns3modulegen.py,ns3modulegen_generated.py,.......} >> >> When I look at the log file >> less build/debug/bindings/python/ns3modulegen.log I get the following >> error: >> Traceback (most recent call last): >> File "../bindings/python/ns3modulegen.py", line 166, in >> main() >> File "../bindings/python/ns3modulegen.py", line 86, in main >> register_types(root_module) >> File >> "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3modulegen_generated.py", >> line 56, in register_types >> ns3_module_core.register_types(module) >> File >> "/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev/bindings/python/apidefs/gcc-LP64/ns3_module_core.py", >> line 157, in register_types >> module.add_class('SimpleRefCount', template_parameters=['ns3::PbbPacket', >> 'ns3::Header'], parent=root_module['ns3::Header']) >> KeyError: 'ns3::Header' >> >> Can anyone tell me why the ns3::Header is not recognized in python >> bindings? Gustavo? Mathieu? anyone? >> > > It is something new that breaks pybindgen scanning and the way code is > being split into different python files. Basically, SimpleRefCount is a > class that belongs in module core, and so pybindgen tries to register this > class, with all seen template instantiations of that class, inside the > module 'core'. However, one such instantiation uses a type from module > 'node', but the types for that module are registered later. > > I guess I'll have to fix pybindgen. Tomorrow, maybe?... > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From tomh at tomh.org Sun Nov 15 20:31:00 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 15 Nov 2009 20:31:00 -0800 Subject: [Ns-developers] Ad hoc On Demand Distance Vector (AODV) routing protocol code review In-Reply-To: <59342.217.128.71.243.1256244467.squirrel@imap-sop.inria.fr> References: <59342.217.128.71.243.1256244467.squirrel@imap-sop.inria.fr> Message-ID: <4B00D584.20001@tomh.org> Faker.Moatamri at sophia.inria.fr wrote: > Hi Pavel & all, > In the effort to merge the code for merging the AODV routing protocol, > I've been through your code review submitted in > http://codereview.appspot.com/115075/show and I have few comments on it. > Craig, Gustavo, anyone else, can you please take a look at the code and > give the Pavel some feedback? Faker, I went through several review cycles and I think AODV model is ready for merging. I just wanted to point out that this overall patch includes the following: - the Duplicate Packet Detection (DPD) model has been factored out of AODV, for use by other protocols - proposal to create a src/routing/manet directory, which would include AODV and the new DPD module, but also would argue for moving olsr and packetbb to this new directory - extensions to IPv4 Ping application, including the ability to configure different ping sizes and time intervals (via new attributes) Tom From tomh at tomh.org Sun Nov 15 21:41:13 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 15 Nov 2009 21:41:13 -0800 Subject: [Ns-developers] topology helpers for NetAnim merge In-Reply-To: <4AFD1C77.1030502@sophia.inria.fr> References: <4AFBEF67.6090707@sophia.inria.fr> <4AFC27FD.4010902@tomh.org> <4AFD1C77.1030502@sophia.inria.fr> Message-ID: <4B00E5F9.6000701@tomh.org> Faker, I left some fresh comments on the NetAnim patch in the tracker here: http://codereview.appspot.com/117051/show but I just wanted to note for others who may not be paying close attention to this review that part of the proposal is to change the class convention for helper topology objects. Specifically, this patch introduces separate PointToPointGridHelper and PointToPointDumbbellHelper classes rather than trying to deal with these topologies in a special Install method within PointToPointHelper such as InstallStar(). I expect that, for ns-3.7, after merging this patch, we would create a PointToPointStarHelper and remove PointToPointHelper::InstallStar() (and the Csma equivalent), to align with this new convention. - Tom p.s. this topic was introduced on the developers list back in January: http://mailman.isi.edu/pipermail/ns-developers/2009-January/005194.html From nbaldo at cttc.es Mon Nov 16 01:09:27 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Mon, 16 Nov 2009 10:09:27 +0100 Subject: [Ns-developers] Merge candidates- deadline approaching-Status update In-Reply-To: <4AFBEF67.6090707@sophia.inria.fr> References: <4AFBEF67.6090707@sophia.inria.fr> Message-ID: <4B0116C7.3060904@cttc.es> Hi Faker, Faker Moatamri wrote: > Hi all, > > I wish to remind you that the deadline to merge modules into NS-3.7 is > about to come: it is scheduled for Wednesday November 18th 2009. If > there is any error in the list or the status is different please don't > hesitate to tell me. > > Some modules are just waiting for +1s, so please Tom, Nicola, Andrey, > Andreev, if you need to say +1 for a code to be merged please do as soon > as possible (look at the list below: 802.11n block ack, AODV). > > 802.11n block ack > > * review location: http://codereview.appspot.com/144050 > * Reviewers: Faker Moatamri, Nicola Baldo, Andrey Mazo, Andreev Kirill > * Developer: Mirko Blanchi > * Status: waiting for +1s > +1 to merge after Mirko adressed the last minor comments as discussed on ns-3-reviews. Note that I assume that the discussion on the possibility of removing DcaTxOp is postponed. Regards, Nicola From faker.moatamri at sophia.inria.fr Mon Nov 16 01:38:02 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 16 Nov 2009 10:38:02 +0100 Subject: [Ns-developers] Ad hoc On Demand Distance Vector (AODV) routing protocol code review In-Reply-To: <4B00D584.20001@tomh.org> References: <59342.217.128.71.243.1256244467.squirrel@imap-sop.inria.fr> <4B00D584.20001@tomh.org> Message-ID: <4B011D7A.30400@sophia.inria.fr> Tom Henderson wrote: > Faker.Moatamri at sophia.inria.fr wrote: >> Hi Pavel & all, >> In the effort to merge the code for merging the AODV routing protocol, >> I've been through your code review submitted in >> http://codereview.appspot.com/115075/show and I have few comments on it. >> Craig, Gustavo, anyone else, can you please take a look at the code and >> give the Pavel some feedback? > > > Faker, I went through several review cycles and I think AODV model is > ready for merging. I just wanted to point out that this overall patch > includes the following: > > - the Duplicate Packet Detection (DPD) model has been factored out of > AODV, for use by other protocols > - proposal to create a src/routing/manet directory, which would > include AODV and the new DPD module, but also would argue for moving > olsr and packetbb to this new directory > - extensions to IPv4 Ping application, including the ability to > configure different ping sizes and time intervals (via new attributes) > > Tom > Ok perfect, Pavel can you please proceed today with the merge? Best regards Faker Moatamri From boyko at iitp.ru Mon Nov 16 01:43:38 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 16 Nov 2009 12:43:38 +0300 Subject: [Ns-developers] Ad hoc On Demand Distance Vector (AODV) routing protocol code review In-Reply-To: <4B011D7A.30400@sophia.inria.fr> References: <59342.217.128.71.243.1256244467.squirrel@imap-sop.inria.fr> <4B00D584.20001@tomh.org> <4B011D7A.30400@sophia.inria.fr> Message-ID: <200911161243.39018.boyko@iitp.ru> On Monday 16 November 2009 12:38:02 pm Faker Moatamri wrote: > Tom Henderson wrote: > > Faker.Moatamri at sophia.inria.fr wrote: > >> Hi Pavel & all, > >> In the effort to merge the code for merging the AODV routing protocol, > >> I've been through your code review submitted in > >> http://codereview.appspot.com/115075/show and I have few comments on it. > >> Craig, Gustavo, anyone else, can you please take a look at the code and > >> give the Pavel some feedback? > > > > Faker, I went through several review cycles and I think AODV model is > > ready for merging. I just wanted to point out that this overall patch > > includes the following: > > > > - the Duplicate Packet Detection (DPD) model has been factored out of > > AODV, for use by other protocols > > - proposal to create a src/routing/manet directory, which would > > include AODV and the new DPD module, but also would argue for moving > > olsr and packetbb to this new directory > > - extensions to IPv4 Ping application, including the ability to > > configure different ping sizes and time intervals (via new attributes) > > > > Tom > > Ok perfect, Pavel can you please proceed today with the merge? Sure ;) Pavel From boyko at iitp.ru Mon Nov 16 02:18:59 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 16 Nov 2009 13:18:59 +0300 Subject: [Ns-developers] time conversion error In-Reply-To: <1258215463.26175.7.camel@localhost.localdomain> References: <4AFC4A3B.2070809@sophia.inria.fr> <200911131203.35964.boyko@iitp.ru> <1258215463.26175.7.camel@localhost.localdomain> Message-ID: <200911161319.00022.boyko@iitp.ru> On Saturday 14 November 2009 07:17:43 pm you wrote: > On Fri, 2009-11-13 at 12:03 +0300, Pavel Boyko wrote: > > How many attributes WimaxSubscriberStationNetDevice already has? If I > > correctly remember that, only first 10 attributes are automatically > > initialized to their default values. I always try to duplicate attribute > > defaults in constructor. > > I am not aware of any hardcoded upper bound on the number of attributes > with default values in Object. That's true, I've checked. Now I can't remember why I had this prejudice about first 10 attributes. Pavel > So, if you had problems like that, > please, file a bug. > > Mathieu > From mathieu.lacage at sophia.inria.fr Mon Nov 16 02:24:46 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Nov 2009 11:24:46 +0100 Subject: [Ns-developers] Bug 471 - [PATCH] access point address manager In-Reply-To: <4AFD84DB.8040505@sophia.inria.fr> References: <4AFD84DB.8040505@sophia.inria.fr> Message-ID: <1258367086.29256.11.camel@diese.inria.fr> On Fri, 2009-11-13 at 17:10 +0100, Faker Moatamri wrote: > My question is: is it worth it to spend time on adapting the obsolete > code in ap-address-manager.h/cc to the current version of the ns-3? I do not think so. > If yes I'll try to find the time to fix this, otherwise I will remove > this enhancement from bugzilla. If you do this, we should put this code somewhere in our wiki where we keep track of code written by users which might be of some use to other users. Mathieu From boyko at iitp.ru Mon Nov 16 03:27:42 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 16 Nov 2009 14:27:42 +0300 Subject: [Ns-developers] AODV routing model merged In-Reply-To: <200911161243.39018.boyko@iitp.ru> References: <59342.217.128.71.243.1256244467.squirrel@imap-sop.inria.fr> <4B011D7A.30400@sophia.inria.fr> <200911161243.39018.boyko@iitp.ru> Message-ID: <200911161427.42699.boyko@iitp.ru> Hi, I'm happy to announce that AODV (RFC 3561) model is merged into the mainline. Sources can be found at src/routing/manet/aodv Example is examples/routing/aodv.cc Model documentation can be found in doxygen module Routing/AODV. Relevant test suites are routing-id-cache, routing-aodv (unit tests) and routing-aodv-regression (system tests). Together with AODV several minor features and enhancements are merged: - routing/manet/dpd module -- simple UID based duplicate packet detection heuristic which can be used by other MANET routing protocols. - Enhancements to V4Ping application. Now one can setup ICMP packets payload size and interval as well as see usual ping output. - contrib/average.h -- almost trivial template class for averaging. Best regards, Pavel From mathieu.lacage at sophia.inria.fr Mon Nov 16 03:47:39 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Nov 2009 12:47:39 +0100 Subject: [Ns-developers] Python bindings failure In-Reply-To: References: <4AFD76CA.3050009@sophia.inria.fr> Message-ID: <1258372059.31976.6.camel@diese.inria.fr> On Sun, 2009-11-15 at 16:25 +0000, Gustavo Carneiro wrote: > I started to look at this, but got blocked by the weird pygccxml API. > Awaiting some feedback from the pygccxml developer. Faker, could we try to disable all python builds from buildbot to clear up the build status until this issue is resolved ? Mathieu From mathieu.lacage at sophia.inria.fr Mon Nov 16 03:52:58 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Nov 2009 12:52:58 +0100 Subject: [Ns-developers] Merge candidates- deadline approaching-Status update In-Reply-To: <4B0116C7.3060904@cttc.es> References: <4AFBEF67.6090707@sophia.inria.fr> <4B0116C7.3060904@cttc.es> Message-ID: <1258372378.31976.10.camel@diese.inria.fr> On Mon, 2009-11-16 at 10:09 +0100, Nicola Baldo wrote: > +1 to merge after Mirko adressed the last minor comments as discussed on > ns-3-reviews. Note that I assume that the discussion on the possibility > of removing DcaTxOp is postponed. I apologize for not being able to complete this review before. I looked at the code 2 weeks ago but was unable to finish the review for lack of time while being away from work: my current feeling is that there are a couple of small issues as well as one big issue to deal with before merging. I would like to be given a couple more days to finish my review. Mathieu From mathieu.lacage at sophia.inria.fr Mon Nov 16 04:04:28 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Nov 2009 13:04:28 +0100 Subject: [Ns-developers] [patch] Use transactions in SQLite output In-Reply-To: <4AFCF41B.3020508@tomh.org> References: <200911121523.33333.j.d.brugge@student.utwente.nl> <50019.193.251.48.82.1258063933.squirrel@imap-sop.inria.fr> <4AFCF41B.3020508@tomh.org> Message-ID: <1258373068.31976.20.camel@diese.inria.fr> On Thu, 2009-11-12 at 21:52 -0800, Tom Henderson wrote: > > Seems really interesting, plus the patch is really small. Did you check if > > there is any impact on existing code/functionalities? > > Tom, Craig, Gustavo, Others, what do you think? > > Joe Kopena has been maintaining the stats code; perhaps he could have a > look and push it if OK. The only reason to not commit this patch would be that transaction support in sqllite is recent or is not present on all platforms. If it's not something we can rely on, we just need to check this at compile-time and #ifdef the relevant code. Jonathan, do you know which version of sqllite started supporting this and if it supports on all its supported platforms ? Mathieu From j.d.brugge at student.utwente.nl Mon Nov 16 04:37:19 2009 From: j.d.brugge at student.utwente.nl (Jonathan Brugge) Date: Mon, 16 Nov 2009 13:37:19 +0100 Subject: [Ns-developers] [patch] Use transactions in SQLite output In-Reply-To: <1258373068.31976.20.camel@diese.inria.fr> References: <200911121523.33333.j.d.brugge@student.utwente.nl> <4AFCF41B.3020508@tomh.org> <1258373068.31976.20.camel@diese.inria.fr> Message-ID: <200911161337.19517.j.d.brugge@student.utwente.nl> Mandag 16. november 2009 13.04.28 skrev Mathieu Lacage : > The only reason to not commit this patch would be that transaction > support in sqllite is recent or is not present on all platforms. If it's > not something we can rely on, we just need to check this at compile-time > and #ifdef the relevant code. > > Jonathan, do you know which version of sqllite started supporting this > and if it supports on all its supported platforms ? As far as I can see on the SQLite website, support for transactions was introduced in April 2001 (version 1.0.28 - see http://www.sqlite.org/changes.html). I have not been able to find any reference to transactions not being available on one or more of the supported platforms and I would be very surprised if that was the case. The SQLite documentation on transactions (http://www.sqlite.org/lang_transaction.html) states that any INSERT/UPDATE query automatically starts a transaction if one is not already in effect. That implies that the old code was already using transactions - effectively one transaction per query, which is exactly the cause of the low speed in the first place. Jonathan From mathieu.lacage at sophia.inria.fr Mon Nov 16 04:47:09 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Nov 2009 13:47:09 +0100 Subject: [Ns-developers] [patch] Use transactions in SQLite output In-Reply-To: <200911161337.19517.j.d.brugge@student.utwente.nl> References: <200911121523.33333.j.d.brugge@student.utwente.nl> <4AFCF41B.3020508@tomh.org> <1258373068.31976.20.camel@diese.inria.fr> <200911161337.19517.j.d.brugge@student.utwente.nl> Message-ID: <1258375629.31976.32.camel@diese.inria.fr> On Mon, 2009-11-16 at 13:37 +0100, Jonathan Brugge wrote: > As far as I can see on the SQLite website, support for transactions was > introduced in April 2001 (version 1.0.28 - see > http://www.sqlite.org/changes.html). I have not been able to find any reference > to transactions not being available on one or more of the supported platforms > and I would be very surprised if that was the case. The SQLite documentation > on transactions (http://www.sqlite.org/lang_transaction.html) states that any > INSERT/UPDATE query automatically starts a transaction if one is not already > in effect. That implies that the old code was already using transactions - > effectively one transaction per query, which is exactly the cause of the low > speed in the first place. This seems like a no-brainer: I would be willing to push this change myself and take responsability for any breakage it introduces if joe kopena does not ack it this week. Mathieu From faker.moatamri at sophia.inria.fr Mon Nov 16 04:51:09 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 16 Nov 2009 13:51:09 +0100 Subject: [Ns-developers] [patch] Use transactions in SQLite output In-Reply-To: <1258375629.31976.32.camel@diese.inria.fr> References: <200911121523.33333.j.d.brugge@student.utwente.nl> <4AFCF41B.3020508@tomh.org> <1258373068.31976.20.camel@diese.inria.fr> <200911161337.19517.j.d.brugge@student.utwente.nl> <1258375629.31976.32.camel@diese.inria.fr> Message-ID: <4B014ABD.30503@sophia.inria.fr> Mathieu Lacage wrote: > On Mon, 2009-11-16 at 13:37 +0100, Jonathan Brugge wrote: > > >> As far as I can see on the SQLite website, support for transactions was >> introduced in April 2001 (version 1.0.28 - see >> http://www.sqlite.org/changes.html). I have not been able to find any reference >> to transactions not being available on one or more of the supported platforms >> and I would be very surprised if that was the case. The SQLite documentation >> on transactions (http://www.sqlite.org/lang_transaction.html) states that any >> INSERT/UPDATE query automatically starts a transaction if one is not already >> in effect. That implies that the old code was already using transactions - >> effectively one transaction per query, which is exactly the cause of the low >> speed in the first place. >> > > This seems like a no-brainer: I would be willing to push this change > myself and take responsability for any breakage it introduces if joe > kopena does not ack it this week. > > Mathieu > > +1 for pushing this patch. From mk.banchi at gmail.com Mon Nov 16 05:10:15 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Mon, 16 Nov 2009 14:10:15 +0100 Subject: [Ns-developers] Merge candidates- deadline approaching-Status update In-Reply-To: <1258372378.31976.10.camel@diese.inria.fr> References: <4AFBEF67.6090707@sophia.inria.fr> <4B0116C7.3060904@cttc.es> <1258372378.31976.10.camel@diese.inria.fr> Message-ID: <7EC5B28C-6BCA-4332-B244-88EA2EE06CCE@gmail.com> Il giorno 16/nov/09, alle ore 12:52, Mathieu Lacage ha scritto: > On Mon, 2009-11-16 at 10:09 +0100, Nicola Baldo wrote: > >> +1 to merge after Mirko adressed the last minor comments as >> discussed on >> ns-3-reviews. Note that I assume that the discussion on the >> possibility >> of removing DcaTxOp is postponed. > > I apologize for not being able to complete this review before. I > looked > at the code 2 weeks ago but was unable to finish the review for lack > of > time while being away from work: my current feeling is that there > are a > couple of small issues as well as one big issue to deal with before > merging. I would like to be given a couple more days to finish my > review. > > Mathieu > Ok. No problem. But which are these issues? If you are more specific i could try to take a look at them. 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/20091116/8790e221/smime.bin From faker.moatamri at sophia.inria.fr Mon Nov 16 07:22:29 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 16 Nov 2009 16:22:29 +0100 Subject: [Ns-developers] Python bindings failure In-Reply-To: <1258372059.31976.6.camel@diese.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> Message-ID: <4B016E35.3040604@sophia.inria.fr> Mathieu Lacage wrote: > On Sun, 2009-11-15 at 16:25 +0000, Gustavo Carneiro wrote: > >> I started to look at this, but got blocked by the weird pygccxml API. >> Awaiting some feedback from the pygccxml developer. >> > > Faker, could we try to disable all python builds from buildbot to clear > up the build status until this issue is resolved ? > > Mathieu > > Done, I put a comment in the buildbot file: '##disabled python until fixed' so that we can put it back as it was after python bindings problem is fixed. Please note that regression tests are still failing. Building does not fail though. Best regards Faker From mathieu.lacage at sophia.inria.fr Mon Nov 16 07:23:55 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Nov 2009 16:23:55 +0100 Subject: [Ns-developers] Wifi bugs In-Reply-To: References: Message-ID: <1258385035.31976.50.camel@diese.inria.fr> Thanks for bringing these bugs to my attention. I have commented on them. Mathieu On Tue, 2009-11-10 at 20:36 +0300, Kirill Andreev wrote: > Hi! > > There are 4 bugs in Wifi, that I have posted: > 674: DcfManager instead of EIFS waits EIFS-SIFS after > failed transmission. > 700: Slot is not corrected with aAirPropagationTime. > 706: Starting backoff procedure at the beginning of the > simulation. > These bugs are relatively simple to fix with patches are > attached but have very significant impact on wireless > simulations. > All these bugs will change regression tests, so they > require special attention. > > 737: Backoff procedure is not started after ACK or CTS > timeout. > This bug seems one of the most difficult to me, because > serious changes in DcfManager are needed. > > Could anyone please pay more attention to these bugs and > give any ideas (specially about bug 737) for solving them. > > Also the question with merging 802.11s regressions is > still open. > > Regards, Kirill Andreev > IITP RAS From boyko at iitp.ru Mon Nov 16 07:38:53 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 16 Nov 2009 18:38:53 +0300 Subject: [Ns-developers] Moving things into src/routing/manet Message-ID: <200911161838.53615.boyko@iitp.ru> Hi, routing/manet directory is introduced by AODV merge. Now I propose to move packetbb (maintainer -- Tom Wambold) and OLSR (maintainer -- Gustavo Carneiro) models to routing/manet/packetbb and routing/manet/olsr respectively. Tom, Gustavo -- what do you think? Best regards, Pavel From mathieu.lacage at sophia.inria.fr Mon Nov 16 07:43:24 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Nov 2009 16:43:24 +0100 Subject: [Ns-developers] MPI for ns-3 In-Reply-To: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> References: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> Message-ID: <1258386204.31976.58.camel@diese.inria.fr> hi josh, I will review your code more thoroughly later but, here are a few comments below. On Wed, 2009-11-04 at 10:48 -0500, jpelkey at gatech.edu wrote: > node.[h,cc] - Added a "SetSystemId" function, to allow the system id to > be set after the node is constructed, rather than passing parameter > to constructor; this exists because there was no way to use > non-default constructors on object creation. I believe this might have > been fixed since then, so perhaps this might not be neded. Yes: you can now remove SetSystemId and do this: Ptr node = CreateObject (mySystemId); > global-route-manager.cc - Do not compute routes for any node whose system-id > does not match the simulator's system id. Clearly, we don't need to > compute routes in simulator A for nodes modeled in simulator B. What happens if I want to send ip packets from node 0 in simulator A to node 1 in simulator B ? How does ns-3 know the route from 0 to 1 ? Mathieu From mathieu.lacage at sophia.inria.fr Mon Nov 16 07:49:56 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Nov 2009 16:49:56 +0100 Subject: [Ns-developers] Moving things into src/routing/manet In-Reply-To: <200911161838.53615.boyko@iitp.ru> References: <200911161838.53615.boyko@iitp.ru> Message-ID: <1258386596.31976.62.camel@diese.inria.fr> On Mon, 2009-11-16 at 18:38 +0300, Pavel Boyko wrote: > routing/manet directory is introduced by AODV merge. Now I propose to move > packetbb (maintainer -- Tom Wambold) and OLSR (maintainer -- Gustavo Carneiro) > models to routing/manet/packetbb and routing/manet/olsr respectively. Tom, > Gustavo -- what do you think? I don't really have a strong opinion on this issue so, feel free to ignore me, but I personally like shallow rather than deep hierarchies when the number of items at each level is not too huge (say, less than 20) because that makes it easier to discover what is in the tree. Right now, there are 6 protocols in src/routing: in my book, that would not qualify for an extra depth level and I would argue for removing the src/routing/manet level instead of moving more things in there. Mathieu From gjcarneiro at gmail.com Mon Nov 16 07:50:23 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 16 Nov 2009 15:50:23 +0000 Subject: [Ns-developers] Moving things into src/routing/manet In-Reply-To: <200911161838.53615.boyko@iitp.ru> References: <200911161838.53615.boyko@iitp.ru> Message-ID: 2009/11/16 Pavel Boyko > Hi, > > routing/manet directory is introduced by AODV merge. Now I propose to move > packetbb (maintainer -- Tom Wambold) and OLSR (maintainer -- Gustavo > Carneiro) > models to routing/manet/packetbb and routing/manet/olsr respectively. Tom, > Gustavo -- what do you think? > Personally, I don't think the number of routing protocols yet justifies the need to have a hierarchy of subdirectories. Though I don't mind the change, if it were up to me I'd leave it flat until we have more than 10 routing protocols to worry about. > > Best regards, > Pavel > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From jpelkey at gatech.edu Mon Nov 16 08:48:00 2009 From: jpelkey at gatech.edu (Josh Pelkey) Date: Mon, 16 Nov 2009 11:48:00 -0500 Subject: [Ns-developers] MPI for ns-3 In-Reply-To: <1258386204.31976.58.camel@diese.inria.fr> References: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> <1258386204.31976.58.camel@diese.inria.fr> Message-ID: <688a18330911160848q50bbaff7ue1fa25a24c836eed@mail.gmail.com> Hi Mathieu, > What happens if I want to send ip packets from node 0 in simulator A to > node 1 in simulator B ? How does ns-3 know the route from 0 to 1 ? The full topology is built at each logical processor. So the packet will go from node 0 to node 1 as normal. The only difference is when it reaches the simulator boundary at simulator A, the packet is serialized and sent via MPI to simulator B. It is then received and deserialized into a packet and sent on its way. Since both simulators have a full view of the topology, they can route packets normally. -- Josh On Mon, Nov 16, 2009 at 10:43 AM, Mathieu Lacage < mathieu.lacage at sophia.inria.fr> wrote: > hi josh, > > I will review your code more thoroughly later but, here are a few > comments below. > > On Wed, 2009-11-04 at 10:48 -0500, jpelkey at gatech.edu wrote: > > > node.[h,cc] - Added a "SetSystemId" function, to allow the system id to > > be set after the node is constructed, rather than passing parameter > > to constructor; this exists because there was no way to use > > non-default constructors on object creation. I believe this might have > > been fixed since then, so perhaps this might not be neded. > > Yes: you can now remove SetSystemId and do this: > > Ptr node = CreateObject (mySystemId); > > > global-route-manager.cc - Do not compute routes for any node whose > system-id > > does not match the simulator's system id. Clearly, we don't need to > > compute routes in simulator A for nodes modeled in simulator B. > > What happens if I want to send ip packets from node 0 in simulator A to > node 1 in simulator B ? How does ns-3 know the route from 0 to 1 ? > > Mathieu > > From boyko at iitp.ru Mon Nov 16 08:54:59 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 16 Nov 2009 19:54:59 +0300 Subject: [Ns-developers] Moving things into src/routing/manet In-Reply-To: References: <200911161838.53615.boyko@iitp.ru> Message-ID: <200911161954.59816.boyko@iitp.ru> Mathieu, Gustavo, Thank you for quick response. > Personally, I don't think the number of routing protocols yet justifies the > need to have a hierarchy of subdirectories. > > Though I don't mind the change, if it were up to me I'd leave it flat until > we have more than 10 routing protocols to worry about. Well, 10 (or even 20 as Mathieu likes) routing models is just a matter of time. Now we have 6. DSR project was discussed in the list some time ago, SMF and NHDP are in progress, OLSRv2 is natural to follow -- just to count to 10 and say nothing about classical routing protocols. This is not a secret that development of MANET routing protocol model RFC [draft number here] for [simulator name here] is a relatively easy way of doing course projects -- that's why they are discussed in the list in September and will appear in January or May (you'll see). Meanwhile our experience with AODV shows that MANET routing protocol models (not _protocols_ but _models_) share a lot of common component parts and I'd like to have routing/manet as a place to factor them out in the future instead of endless copy-pasting. Current routing/manet/dpd is a first step towards this goal. Should we wait for the first 20 folders in src/routing before that? Another example of common part used by manet routing protocols is a packetbb library -- do you really think that pushing all such libraries into the "node" module is a viable strategy? Pavel From gjcarneiro at gmail.com Mon Nov 16 09:31:52 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 16 Nov 2009 17:31:52 +0000 Subject: [Ns-developers] Moving things into src/routing/manet In-Reply-To: <200911161954.59816.boyko@iitp.ru> References: <200911161838.53615.boyko@iitp.ru> <200911161954.59816.boyko@iitp.ru> Message-ID: 2009/11/16 Pavel Boyko > Mathieu, Gustavo, > > Thank you for quick response. > > > Personally, I don't think the number of routing protocols yet justifies > the > > need to have a hierarchy of subdirectories. > > > > Though I don't mind the change, if it were up to me I'd leave it flat > until > > we have more than 10 routing protocols to worry about. > > Well, 10 (or even 20 as Mathieu likes) routing models is just a matter of > time. Now we have 6. DSR project was discussed in the list some time ago, > SMF > and NHDP NHDP is not even routing, it's neighbor sensing, it's just a component that routing protocols can use. > are in progress, OLSRv2 is natural to follow -- just to count to 10 > and say nothing about classical routing protocols. This is not a secret > that > development of MANET routing protocol model RFC [draft number here] for > [simulator name here] is a relatively easy way of doing course projects -- > that's why they are discussed in the list in September and will appear in > January or May (you'll see). Meanwhile our experience with AODV shows that > MANET routing protocol models (not _protocols_ but _models_) share a lot of > common component parts and I'd like to have routing/manet as a place to > factor > them out in the future instead of endless copy-pasting. Current > routing/manet/dpd is a first step towards this goal. Should we wait for the > first 20 folders in src/routing before that? Another example of common part > used by manet routing protocols is a packetbb library -- do you really > think > that pushing all such libraries into the "node" module is a viable > strategy? > > Sounds like you're making the case for creating a "manet-common" module, it has nothing to do with flat vs nested directory hierarchies. You can share code without creating another level. Besides, what you think can be shared often cannot. The dpd module you pointed out and I seen for the first time detects duplicates via Packet::GetUid(). This cannot be used for OLSR, which uses an ID inside the OLSR header, and detects duplicates on a per-message rather than per-packet basis. Besides, that dtd code is trivial, not worth sharing, and fragile, since some NetDevices might use Packet::Copy () which will produce another copy of the packet with a different ID. But, if you are confident we'll have 20 routing protocols in a few months, I can only be glad :-) And since I see that src/routing/manet already exists, it must have been already approved, so why are we even discussing it? Obviously OLSR must go to src/routing/manet, or else src/routing/manet cannot exist. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From tomh at tomh.org Mon Nov 16 10:10:07 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 16 Nov 2009 11:10:07 -0700 Subject: [Ns-developers] Moving things into src/routing/manet In-Reply-To: References: <200911161838.53615.boyko@iitp.ru> <200911161954.59816.boyko@iitp.ru> Message-ID: >> > The dpd module you > pointed out and I seen for the first time detects duplicates via > Packet::GetUid(). This cannot be used for OLSR, which uses an ID inside > the > OLSR header, and detects duplicates on a per-message rather than per-packet > basis. I missed that detail; GetUid() is not appropriate for DPD (we need to fix that). > And since I see that src/routing/manet already > exists, > it must have been already approved, so why are we even discussing it? As I mentioned in my post yesterday, and in my AODV review, I felt that discussion of these issues that were not self-contained within AODV should be discussed on the developers list because they impact other developers (and we are having that discussion now). So far, it seems that sentiment runs against src/routing/manet subdirectory. Other comments on that or on how DPD may need to be more generalalized? Tom From craigdo at ee.washington.edu Mon Nov 16 11:04:31 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Mon, 16 Nov 2009 11:04:31 -0800 Subject: [Ns-developers] MPI for ns-3 In-Reply-To: <688a18330911160848q50bbaff7ue1fa25a24c836eed@mail.gmail.com> References: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> <1258386204.31976.58.camel@diese.inria.fr> <688a18330911160848q50bbaff7ue1fa25a24c836eed@mail.gmail.com> Message-ID: <004e01ca66ef$a165ca20$e4315e60$@washington.edu> > > What happens if I want to send ip packets from node 0 in simulator A > to > > node 1 in simulator B ? How does ns-3 know the route from 0 to 1 ? > > The full topology is built at each logical processor. So the packet > will go > from node 0 to node 1 as normal. The only difference is when it > reaches the > simulator boundary at simulator A, the packet is serialized and sent > via MPI > to simulator B. It is then received and deserialized into a packet and > sent > on its way. Since both simulators have a full view of the topology, > they > can route packets normally. This is one of the subjects that concerned me. Right now, as you say, the example code builds the entire topology and applications are either enabled or not based on the LP number. What happens in more complicated topologies that include other devices than point-to-point? Consider a dumbbell with wifi or other hybrid networks on both sides, the idea being to split the processing of the left side and the right side of the dumbbell onto two processors. How do you create this thing? What guidance do we provide? If you don't switch the wifi network creation on LP, you have both sides running everything. If you create the entire topology on both sides and only enable applications by switching on LP, you have, for example, device beacons, ARP, mobility models, tracing, etc. running on both wireless networks on both processors. It seems to me that the optimal thing to do would be NOT to build the entire topology on both LPs, but to switch the building of the left-side topology and the right-side topology on LP as well as the applications. In this case, global routing cannot work. Have we tested this? I took mixed-wireless.cc and replaced the wireless backbone with a point-to-point link and enabled mpi, only switching applications according to LP. I created nodes with the appropriate LP. When I ran it, an assert popped: check(m_current) error in buffer.h I didn't debug this, so I don't know exactly what is happening; but this is a surprisingly low-level thing for such a simple port. I am concerned about fragility. I think we need more examples like an mpi-mixed-wireless. WRT documentation, what is the recommended plan for parallelizing something like a mixed-wireless.cc with the backbone replaced with a point-to-point? What is the basic model for running which bits on what processor? How is routing expected to work? Should we switch topology creation on rank? Should we run OLSR across ranks? What are the options? Tradeoffs? How is tracing expected to work? You have got to switch tracing on LP number, unless you are really running on multiple machines, right? We should document stuff like this, otherwise a simple change to machinefile could crash the scripts. I think there are a lot of unanswered questions here. We really need some more documentation (in fact, I don't think there's any Doxygen at all on the additions) and some more examples. We also need some tests. I found no tests anywhere. We need something for the new channel, the new simulator and a system test if mpi is present. This would be much easier if the code was integrated into the system better. The build system changes seem to be fairly straightforward. Adding Doxygen seems to be straightforward. Adding manual entries just requires time. I could maybe be convinced that these could be treated as P1 bugs with a commitment to address them. What do you think Faker -- you are the RM? What really concerns me is fragility. I would really like to see some more involved examples ported to this environment. mixed-wireless comes immediately to mind. So does tcp-star-server.cc, star.cc, simple-point-to-point-olsr.cc, and dynamic-global-routing.cc. This would also serve to find the porting points that cause unnecessary pain (like the create node with system id bit). We need more tests. -- Craig From Faker.Moatamri at sophia.inria.fr Mon Nov 16 12:13:34 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Mon, 16 Nov 2009 21:13:34 +0100 (CET) Subject: [Ns-developers] Bug 471 - [PATCH] access point address manager In-Reply-To: <1258367086.29256.11.camel@diese.inria.fr> References: <4AFD84DB.8040505@sophia.inria.fr> <1258367086.29256.11.camel@diese.inria.fr> Message-ID: <49658.193.251.48.82.1258402414.squirrel@imap-sop.inria.fr> > On Fri, 2009-11-13 at 17:10 +0100, Faker Moatamri wrote: > >> My question is: is it worth it to spend time on adapting the obsolete >> code in ap-address-manager.h/cc to the current version of the ns-3? > > I do not think so. Me neither > >> If yes I'll try to find the time to fix this, otherwise I will remove >> this enhancement from bugzilla. > > If you do this, we should put this code somewhere in our wiki where we > keep track of code written by users which might be of some use to other > users. Ok I will put it in the non merged contribution's page: http://www.nsnam.org/wiki/index.php/Contributed_Code#Contributed_code_not_maintained_by_the_project > > Mathieu > > Faker From vincent at clarinet.u-strasbg.fr Mon Nov 16 23:06:01 2009 From: vincent at clarinet.u-strasbg.fr (=?ISO-8859-1?Q?S=E9bastien_Vincent?=) Date: Tue, 17 Nov 2009 08:06:01 +0100 Subject: [Ns-developers] ./waf --regresion failing In-Reply-To: <1258216172.26175.14.camel@localhost.localdomain> References: <1258216172.26175.14.camel@localhost.localdomain> Message-ID: <4B024B59.3020200@clarinet.u-strasbg.fr> Hi, Sorry for late response, I fix regression tests that was introduced in "Bug #729 IPv6 over PPP" commit. It remains three regression tests failing that are not related to the previous commit (test-csma-broadcast, test-csma-ping, test-simple-point-to-point-olsr). Best regards, -- Sebastien Mathieu Lacage a ?crit : > hi, > > I noticed that ./waf --regression fails in ns-3-dev. > > The first bad revision is: > changeset: 5503:c305c6e122c9 > user: Sebastien Vincent > date: Wed Nov 11 16:21:18 2009 +0100 > summary: Bug #729 IPv6 over PPP. > > Which hints at something being wrong in vincent's commit. Vincent ? > > Mathieu > > > From boyko at iitp.ru Mon Nov 16 23:51:50 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Tue, 17 Nov 2009 10:51:50 +0300 Subject: [Ns-developers] Moving things into src/routing/manet In-Reply-To: References: <200911161838.53615.boyko@iitp.ru> <200911161954.59816.boyko@iitp.ru> Message-ID: <200911171051.50834.boyko@iitp.ru> Gustavo, Tom, On Monday 16 November 2009 08:31:52 pm you wrote: > Sounds like you're making the case for creating a "manet-common" module, it > has nothing to do with flat vs nested directory hierarchies. You can share > code without creating another level. Agree, this is just a matter of taste. > Besides, what you think can be shared often cannot. The dpd module you > pointed out and I seen for the first time detects duplicates via > Packet::GetUid(). This cannot be used for OLSR, which uses an ID inside > the OLSR header, and detects duplicates on a per-message rather than > per-packet basis. Besides, that dtd code is trivial, not worth sharing, > and fragile, since some NetDevices might use Packet::Copy () which will > produce another copy of the packet with a different ID. Thank you for pointing me Packet::Copy () problem. I should rewrite duplicates detection in the near future. > But, if you are confident we'll have 20 routing protocols in a few months, > I can only be glad :-) And since I see that src/routing/manet already > exists, it must have been already approved, so why are we even discussing > it? Obviously OLSR must go to src/routing/manet, or else src/routing/manet > cannot exist. Now I see the following resolution of the discussion above: 1. I integrate dpd module back into AODV as is with a bug "Packet UID is not acceptable for duplicate detection" 2. aodv is moved to src/routing and src/routing/manet is removed If you have no objections I will proceed later today. Regards, Pavel From mathieu.lacage at sophia.inria.fr Mon Nov 16 23:59:58 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Nov 2009 08:59:58 +0100 Subject: [Ns-developers] MPI for ns-3 In-Reply-To: <688a18330911160848q50bbaff7ue1fa25a24c836eed@mail.gmail.com> References: <6999454.303281257349699008.JavaMail.root@mail8.gatech.edu> <1258386204.31976.58.camel@diese.inria.fr> <688a18330911160848q50bbaff7ue1fa25a24c836eed@mail.gmail.com> Message-ID: <1258444798.13172.3.camel@diese.inria.fr> On Mon, 2009-11-16 at 11:48 -0500, Josh Pelkey wrote: > > What happens if I want to send ip packets from node 0 in simulator A > to > > node 1 in simulator B ? How does ns-3 know the route from 0 to 1 ? > > The full topology is built at each logical processor. So the packet > will go from node 0 to node 1 as normal. The only difference is when > it reaches the simulator boundary at simulator A, the packet is > serialized and sent via MPI to simulator B. It is then received and > deserialized into a packet and sent on its way. Since both simulators > have a full view of the topology, they can route packets normally. I have not yet looked at the code but your original comment said: global-route-manager.cc - Do not compute routes for any node whose system-id does not match the simulator's system id. Clearly, we don't need to compute routes in simulator A for nodes modeled in simulator B. So, what I am asking is: if you don't compute routes to reach the nodes in simulator B from simulator A, how does the forwarding code know which device to send a packet to to reach a node in simulator B from a node in simulator A. Mathieu From mathieu.lacage at sophia.inria.fr Tue Nov 17 00:00:53 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Nov 2009 09:00:53 +0100 Subject: [Ns-developers] ./waf --regresion failing In-Reply-To: <4B024B59.3020200@clarinet.u-strasbg.fr> References: <1258216172.26175.14.camel@localhost.localdomain> <4B024B59.3020200@clarinet.u-strasbg.fr> Message-ID: <1258444853.13172.4.camel@diese.inria.fr> On Tue, 2009-11-17 at 08:06 +0100, S?bastien Vincent wrote: > Sorry for late response, I fix regression tests that was introduced in > "Bug #729 IPv6 over PPP" commit. thanks ! > It remains three regression tests failing that are not related to the > previous commit (test-csma-broadcast, test-csma-ping, > test-simple-point-to-point-olsr). More bisection ahead :) Mathieu From mathieu.lacage at sophia.inria.fr Tue Nov 17 00:10:29 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Nov 2009 09:10:29 +0100 Subject: [Ns-developers] Gauss-Markov Mobility Model In-Reply-To: <766502.98572.qm@smtp103.sbc.mail.mud.yahoo.com> References: <766502.98572.qm@smtp103.sbc.mail.mud.yahoo.com> Message-ID: <1258445429.13172.9.camel@diese.inria.fr> hi, On Mon, 2009-11-16 at 14:11 -0600, Dan Broyles wrote: > Mathieu, > I am a student at the University of Kansas and am working on a > 3-dimensional Gauss-Markov mobility model. I email you because you are > the major contributor of the mobility models in ns-3, and I wanted to yes, but it's generally best to send these emails on our developers ML: other developers might know better than me. > know what might be the best approach for me to submit a Gauss-Markov > model to the ns-3 codebase. cool. > For example, the BOUNDS parameter would likely need to use a 3 > dimensional cube instead of a 2-dimensional rectangle. Would it be > better for the codebase to include a new cube structure or keep with > the current rectangle? yes, I think so. > Also, the initial positions of the mobile nodes needs to be set. Is it > better to use the current 2-D position allocator class or should the > position allocator be modified into 3-dimensions? The current PositionAllocator base class is not 2d-specific. Some of its subclasses (Grid, Disc, Rectangle, and UniformDisc) are 2d-specific and I think that it would be appropriate to introduce other subclasses which are 3d-specific. > I am also trying to figure out the best way to set up the Gaussian > (Normal) distribution for the group of mobile nodes that will be > assigned to use this mobility model. Is it OK to have the user specify > the acceptable range for the mean and standard deviation, or should > all the mobile nodes be assigned values that come from a single > Gaussian distribution? I don't really know much about that: I guess it really depends on what your model is supposed to do and I know nothing about a gauss-markov mobility model :/ Mathieu From jens.mittag at kit.edu Tue Nov 17 01:34:53 2009 From: jens.mittag at kit.edu (Jens Mittag) Date: Tue, 17 Nov 2009 10:34:53 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4AFD90C7.1040505@cttc.es> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> <4AFD90C7.1040505@cttc.es> Message-ID: <4B026E3D.1070209@kit.edu> Hi Nicola! Nicola Baldo schrieb: > From the paper that you cited I understand that atheros devices detect > the start of a new frame using either AGC jump or preamble detection. > For prism devices I know that AGC jump, Preamble Detection and Energy > Detection can be all used for frame start detection, with different > logical combinations (e.g., logical OR, or logical AND of some or all > events). > On the other hand, YansWifiPhy currently implements Energy Detection > only. Your proposed change would introduce AGC for capture only, so I > think it would lead to a poorly consistent YansWifiPhy, with an ideal > model for transitions IDLE->SYNC but a more real-world-oriented model > for re-SYNC (i.e., capture) events. > > If you can produce a patch that: > 1) introduces the modeling of preamble detection (PD) and AGC > 2) allows doing transitions from IDLE to SYNC according to different > logical combinations of ED, PD and AGC jumps > 3) uses PD and AGC jumps for preamble capture > 4) uses AGC jumps for frame body capture > then you can count on my +1. One comment in advance: I don't see the need to implement all the details of the paper I cited in my previous mail (accurate signal detection...) because we can't implement them in a packet-level simulator. I used this reference only to support my argumentation. I believe that a simple threshold (either fixed or as a continuous/stepwise function) is the appropriate way to cover the effects of all the underlying details on a packet-level basis. So, regarding your proposed/desired patch with PD, ED and AGC jumps: (1) believe that these mechanisms can not be modeled in a packet-level simulator, because we would need to operate on time samples and individual symbols to do so. The time samples are required to execute any correlation algorithms. (2) I believe that these mechanisms do different things technically, but with the same logical objective/result: frame detection. Due to this, we can capture this behavior only statistically in our models. Further, we can only capture it based on the only physical layer characterization that we have in NS-3 wifi: the SINR. Our research group has recently implemented a physical layer for OFDM wifi that goes down to the time sample level by breaking the abstraction of a packet and implementing the transceiver technology entirely in software. However, again, since we are not working on time samples in standard NS-3 but on a packet-level basis with per-packet received signal strengths, we have to make a distinction between what is happening in a real hardware and the way we capture the effect of these internals. We can capture them only statistically. Using a threshold is therefore from my experience, and according to experimental results [1], a reasonable abstraction and modeling approach. Or do you know an example where this approach would fail? If yes, please elaborate. Of course, following [2], the threshold can also be implemented as a function of the SINR instead of a fixed threshold. But this doesn't change in my opinion the fact of having a threshold. Jens [1] "An experimental study on the capture effect in 802.11a networks", Lee et. al, ACM WiNTECH Workshop 2007 Revised version: http://mmlab.snu.ac.kr/~jklee/papers/wintech405-lee-rev080321.pdf [2] "Revamping the IEEE 802.11a PHY simulation models", Ryu et. al, 2008, MSWiM -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Engesserstr. 2, 76131 Karlsruhe, Germany Building 20.50, Room 112 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ From faker.moatamri at sophia.inria.fr Tue Nov 17 01:53:07 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 17 Nov 2009 10:53:07 +0100 Subject: [Ns-developers] Bug 471 - [PATCH] access point address manager In-Reply-To: <49658.193.251.48.82.1258402414.squirrel@imap-sop.inria.fr> References: <4AFD84DB.8040505@sophia.inria.fr> <1258367086.29256.11.camel@diese.inria.fr> <49658.193.251.48.82.1258402414.squirrel@imap-sop.inria.fr> Message-ID: <4B027283.8000300@sophia.inria.fr> Faker.Moatamri at sophia.inria.fr wrote: >> On Fri, 2009-11-13 at 17:10 +0100, Faker Moatamri wrote: >> >> >>> My question is: is it worth it to spend time on adapting the obsolete >>> code in ap-address-manager.h/cc to the current version of the ns-3? >>> >> I do not think so. >> > Me neither > >>> If yes I'll try to find the time to fix this, otherwise I will remove >>> this enhancement from bugzilla. >>> >> If you do this, we should put this code somewhere in our wiki where we >> keep track of code written by users which might be of some use to other >> users. >> > Ok I will put it in the non merged contribution's page: > http://www.nsnam.org/wiki/index.php/Contributed_Code#Contributed_code_not_maintained_by_the_project > Done, from the wiki page we can take a look at the closed bug and we can download the ap-address-manager.cc/h files. Best regards Faker Moatamri >> Mathieu >> >> >> > Faker > > From nbaldo at cttc.es Tue Nov 17 02:33:38 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Tue, 17 Nov 2009 11:33:38 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4B026E3D.1070209@kit.edu> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> <4AFD90C7.1040505@cttc.es> <4B026E3D.1070209@kit.edu> Message-ID: <4B027C02.9030108@cttc.es> Hi Jens, Jens Mittag wrote: > > One comment in advance: I don't see the need to implement all the > details of the paper I cited in my previous mail (accurate signal > detection...) because we can't implement them in a packet-level > simulator. I used this reference only to support my argumentation. I > believe that a simple threshold (either fixed or as a > continuous/stepwise function) is the appropriate way to cover the > effects of all the underlying details on a packet-level basis. > > So, regarding your proposed/desired patch with PD, ED and AGC jumps: (1) > believe that these mechanisms can not be modeled in a packet-level > simulator, because we would need to operate on time samples and > individual symbols to do so. The time samples are required to execute > any correlation algorithms. (2) I believe that these mechanisms do > different things technically, but with the same logical > objective/result: frame detection. Due to this, we can capture this > behavior only statistically in our models. Further, we can only capture > it based on the only physical layer characterization that we have in > NS-3 wifi: the SINR. > > Our research group has recently implemented a physical layer for OFDM > wifi that goes down to the time sample level by breaking the abstraction > of a packet and implementing the transceiver technology entirely in > software. > > However, again, since we are not working on time samples in standard > NS-3 but on a packet-level basis with per-packet received signal > strengths, we have to make a distinction between what is happening in a > real hardware and the way we capture the effect of these internals. We > can capture them only statistically. Using a threshold is therefore from > my experience, and according to experimental results [1], a reasonable > abstraction and modeling approach. Or do you know an example where this > approach would fail? If yes, please elaborate. > > Of course, following [2], the threshold can also be implemented as a > function of the SINR instead of a fixed threshold. But this doesn't > change in my opinion the fact of having a threshold. > I am NOT proposing to go beyond packet-level simulations. I agree with you that simulating things on a symbol scale is overkill. What I meant is the following: 1) Energy Detection (ED) is comparing absolute rx power against a threshold. This is what YansWifiPhy currently provides for synchronization. 2) Preamble Detection (PD) is currently not modeled in YansWifiPhy. A simple way of implementing it is to compare SINR with a threshold; if SINR > threshold, then the preamble can be detected successfully, otherwise not; the threshold will typically be below 0dB. Note that, even if a threshold model is used in both cases, PD can give different output than ED in several situations. A more complex model for PD (but still feasible in a network simulator) would be to use a detection probability as a function of SINR. Also, preamble length should be accounted for when determining the threshold (or the detection probability). 3) AGC is currently not modeled. A simple way of implementing it is a state machine which fires an event whenever there is a jump on the total energy detected at the receiver (including noise). The events fired by the AGC can be used for synchronization (i.e., transition from IDLE to SYNC) as well as for frame body capture. That's it. In practical terms, we agree on most stuff (i.e., using thresholds). My point is that rather than just saying "let's put a threshold for capture" I would prefer to clearly state what is the underlying phenomenon that we are trying to model (ED, PD, AGC). And, if we model a phenomenon (e.g., AGC), try to be consistent and consider it in all cases in which it is relevant (i.e., not only for capture, but also for synchronization, and for aborting RX if the device does not support frame body capture). Nicola From jens.mittag at kit.edu Tue Nov 17 02:47:35 2009 From: jens.mittag at kit.edu (Jens Mittag) Date: Tue, 17 Nov 2009 11:47:35 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4B027C02.9030108@cttc.es> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> <4AFD90C7.1040505@cttc.es> <4B026E3D.1070209@kit.edu> <4B027C02.9030108@cttc.es> Message-ID: <4B027F47.2060102@kit.edu> Hi Nicola, > I am NOT proposing to go beyond packet-level simulations. I agree with > you that simulating things on a symbol scale is overkill. > > What I meant is the following: > > 1) Energy Detection (ED) is comparing absolute rx power against a > threshold. This is what YansWifiPhy currently provides for synchronization. > > 2) Preamble Detection (PD) is currently not modeled in YansWifiPhy. A > simple way of implementing it is to compare SINR with a threshold; if > SINR > threshold, then the preamble can be detected successfully, > otherwise not; the threshold will typically be below 0dB. Note that, > even if a threshold model is used in both cases, PD can give different > output than ED in several situations. A more complex model for PD (but > still feasible in a network simulator) would be to use a detection > probability as a function of SINR. Also, preamble length should be > accounted for when determining the threshold (or the detection > probability). Ah, now I get you ;) When you say energy detection (ED) you are talking about an absolute threshold. I understood it as a steep rise of the signal energy, which is relative again. One question: do you see the energy detection threshold as an artificial value that can be set by a network designer to suppress nodes from a different network that is close to your own network? Or do you see it as a technological restriction, that the hardware can only decode above this energy level? Or why has it been introduced in YansWifiPhy? Is it an artifact from the old NS-2 implementation (before the changes from Schmidt-Eisenlohr et. al) where we had a Rx and a Cs threshold? In the code of Timo Bingmann (he worked in our group during his diploma thesis), we do not consider energy detection at all and model only preamble detection... the energy detection threshold is from our understanding implicitly given by the noise floor and the SINR threshold for the preamble. Thanks for your clarification Jens -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Engesserstr. 2, 76131 Karlsruhe, Germany Building 20.50, Room 112 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ From mathieu.lacage at sophia.inria.fr Tue Nov 17 04:13:17 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Nov 2009 13:13:17 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4B026E3D.1070209@kit.edu> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> <4AFD90C7.1040505@cttc.es> <4B026E3D.1070209@kit.edu> Message-ID: <1258459997.13172.25.camel@diese.inria.fr> On Tue, 2009-11-17 at 10:34 +0100, Jens Mittag wrote: > Our research group has recently implemented a physical layer for OFDM > wifi that goes down to the time sample level by breaking the abstraction > of a packet and implementing the transceiver technology entirely in > software. Hint, hint: It would be nice to see this PHY layer integrated in the ns-3 wifi module :) Mathieu From mathieu.lacage at sophia.inria.fr Tue Nov 17 04:21:38 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Nov 2009 13:21:38 +0100 Subject: [Ns-developers] WiFi interference: coordination note In-Reply-To: <4AFC3A82.2030302@cttc.es> References: <4AF7AA39.5020007@tomh.org> <4AFC3A82.2030302@cttc.es> Message-ID: <1258460498.13172.32.camel@diese.inria.fr> On Thu, 2009-11-12 at 17:40 +0100, Nicola Baldo wrote: > > In addition, we're working on experimentally deriving an 802.11g clear > > channel BER model and will post that when it becomes available. One > > thing that has become apparent is that it would be nice to be able to > > add "receiver profiles" to existing models (such as a suite of BER > > curves that were empirically derived from a particular testbed) without > > hacking on the device model. > > I agree that would be a nice feature. If I remember correctly Federico > Maguolo had done something for this, and Mathieu was trying to recover > and merge his code, but I don't know how the thing ended up. The interpolation code implemented by federico to interpolate the ber surface between snr/number of bits points generated a discontinuous interpolation surface full of singularities which made it generally hopeless. I discussed this matter (that is, what is the proper way to generate an interpolated surface from an arbitrary number of arbitrarily positioned discrete points) with a few co-workers: what came out of it is that the proper way to do this is to generate a delaunay triangulation of the supporting points, and then linearly interpolate on the edges of the triangles. Although my co-workers helpfully pointed me to simple and classic algorithms to generate this triangulation, I never found a way to get enough time to do it. I would be happy to mentor anyone willing to do this and I am sure nicola or myself can retrieve the proper measurement data which federico originally used. Mathieu From nbaldo at cttc.es Tue Nov 17 04:28:11 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Tue, 17 Nov 2009 13:28:11 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4B027F47.2060102@kit.edu> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> <4AFD90C7.1040505@cttc.es> <4B026E3D.1070209@kit.edu> <4B027C02.9030108@cttc.es> <4B027F47.2060102@kit.edu> Message-ID: <4B0296DB.9010705@cttc.es> > Ah, now I get you ;) When you say energy detection (ED) you are talking > about an absolute threshold. I understood it as a steep rise of the > signal energy, which is relative again. I didn't invent that definition by myself ;-) The process of synchronizing upon reception is defined in IEEE 802.11-2007 section 15.2.7. Two primitives can be used for this purpose: PMD_ED and PMD_SQ. PMD_ED (section 15.4.5.13) indicates "that the receiver has detected RF energy [...] that is above a predefined threshold". PMD_SQ (15.4.5.11) "provides to the PLCP and MAC entity the SQ of the DSSS PHY PN code correlation. The SQ shall be sampled when the DSSS PHY achieves code lock and shall be held until the next code lock acquisition." In other words, PMD_SQ is fired when preamble is detected. Note that the same primitives (PMD_ED and PMD_SQ) are used for Clear Channel Assessment (CCA). Also note that things change slightly for PHY specifications other than DSSS. > One question: do you see the energy detection threshold as an artificial > value that can be set by a network designer to suppress nodes from a > different network that is close to your own network? Yes, that's also the way it is defined in the standard. > Or do you see it as > a technological restriction, that the hardware can only decode above > this energy level? No. > Or why has it been introduced in YansWifiPhy? Is it > an artifact from the old NS-2 implementation (before the changes from > Schmidt-Eisenlohr et. al) where we had a Rx and a Cs threshold? I think there is some confusion about the current YansWifiPhy. Have a look for instance at the discussion for bug 689: http://www.nsnam.org/bugzilla/show_bug.cgi?id=689 the fact is that we have an "EnergyDetectionThreshold" and a "CcaMode1Threshold". The standard (section 15.4.8.4) says that CCA mode 1 corresponds to the use of ED only (no preamble detection). So CccaMode1Threshold is the one for ED, and what about EnergyDetectionThreshold? I am tempted to reopen bug 689... > > In the code of Timo Bingmann (he worked in our group during his diploma > thesis), we do not consider energy detection at all and model only > preamble detection... That's a possible choice. The standard allows the use of PMD_SQ alone, both for reception (section 15.2.7) and CCA (section 15.4.8.4). Note that the standard also allows the use of PMD_ED alone, I think that YansWifiPhy was designed with this latter choice. > the energy detection threshold is from our > understanding implicitly given by the noise floor and the SINR threshold > for the preamble. This reasoning is not correct. The standard allows you to set the ED threshold high enough so that low power signals for which preamble can be detected will still fail ED. As you mentioned earlier, this is done so that you can transmit over weak signals and achieve a higher channel utilization in dense deployments. Also note that, if we model preamble reception with a SNR threshold, the value of this threshold will be in practice imposed by the PHY specifications (type of preamble and length). Nicola From mathieu.lacage at sophia.inria.fr Tue Nov 17 04:41:47 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Nov 2009 13:41:47 +0100 Subject: [Ns-developers] Bug 602 status In-Reply-To: <4AF2CD69.3070209@cttc.es> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> <1256889694.17577.16.camel@localhost.localdomain> <4AEAB54E.8000708@cttc.es> <1256917766.21755.13.camel@localhost.localdomain> <4AF2A535.7040300@cttc.es> <1257421670.4287.13.camel@localhost.localdomain> <4AF2CD69.3070209@cttc.es> Message-ID: <1258461707.13172.33.camel@diese.inria.fr> On Thu, 2009-11-05 at 14:04 +0100, Nicola Baldo wrote: > > The main reason I dislike the approach currently implemented by mirko is > > that it makes it very hard to do the right thing in non-trivial rate > > control algorithms which override the NeedRtsRetransmission family of > > methods. i.e., implementing the approach nicola and myself suggested > > first is much more friendly to rate control algorithm implementors which > > is why I am so reluctant to go towards the solution proposed by mirko. > > So if I understand correctly you are talking about the fact that, with > Mirko's patch, Ssrc counters are per AC, but there would be only one > WifiRemoteStationManager for all ACs, which would then receive all > notifications (such as ReportRtsFailed) for all ACs jointly. This breaks > how some rate adaptation algorithms work, unless we make all managers > AC-aware, which I agree is not a good idea. Mmmmmmhhhhhh. yes, precisely. Mathieu From faker.moatamri at sophia.inria.fr Tue Nov 17 04:53:29 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 17 Nov 2009 13:53:29 +0100 Subject: [Ns-developers] ./waf --regression failing In-Reply-To: <1258444853.13172.4.camel@diese.inria.fr> References: <1258216172.26175.14.camel@localhost.localdomain> <4B024B59.3020200@clarinet.u-strasbg.fr> <1258444853.13172.4.camel@diese.inria.fr> Message-ID: <4B029CC9.7060301@sophia.inria.fr> Mathieu Lacage wrote: > On Tue, 2009-11-17 at 08:06 +0100, S?bastien Vincent wrote: > > >> Sorry for late response, I fix regression tests that was introduced in >> "Bug #729 IPv6 over PPP" commit. >> > > thanks ! > > >> It remains three regression tests failing that are not related to the >> previous commit (test-csma-broadcast, test-csma-ping, >> test-simple-point-to-point-olsr). >> > > More bisection ahead :) > > Mathieu > > It is much more complicated than I thought: - Using revision 92 in ns-3-dev-ref-traces: * Revision 5502, works perfectly fine * Revision 5503: test-dynamic-global-routing, test-global-routing-slash32, test-simple-error-model, test-simple-global-routing, test-simple-point-to-point-olsr, test-static-routing-slash32, test-tcp-large-transfer fail * Revision 5743: test-csma-broadcast, test-csma-ping, test-dynamic-global-routing, test-global-routing-slash32, test-simple-error-model, test-simple-global-routing, test-simple-point-to-point-olsr, test-static-routing-slash32, test-tcp-large-transfer * Revision 5744(tip): failed (test-csma-broadcast, test-csma-ping, test-simple-point-to-point-olsr) - Using revision 93 (tip) in ns-3-dev-ref-traces: * Revision 5503-5509: test-csma-broadcast, test-simple-point-to-point-olsr fail * Revision 5743: failed (test-csma-broadcast, test-csma-ping, test-simple-point-to-point-olsr) * Revision 5744(tip): (test-csma-broadcast, test-csma-ping, test-dynamic-global-routing, test-global-routing-slash32, test-simple-error-model, test-simple-global-routing, test-simple-point-to-point-olsr, test-static-routing-slash32, test-tcp-large-transfer) To simplify analysis, I will consider the couple (ns-3-dev revision, ns-3-dev-ref-traces revision). For revision (5503,93) we have failure in test-csma-broadcast and test-simple-point-to-point-olsr failures. In rev (5739-5743, 93), we have one failure added test-csma-ping which might be due to the patch added by Pavel, is this possible Pavel? Now revision (5744,93) we still have the 9 failures (test-csma-broadcast, test-csma-ping, test-dynamic-global-routing, test-global-routing-slash32, test-simple-error-model, test-simple-global-routing, test-simple-point-to-point-olsr, test-static-routing-slash32, test-tcp-large-transfer), Sebastien did you update your reference traces before submitting the patch in 5744? should we come back to revision 92 in reference traces? Best regards Faker From vincent at clarinet.u-strasbg.fr Tue Nov 17 05:17:35 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Tue, 17 Nov 2009 14:17:35 +0100 Subject: [Ns-developers] ./waf --regression failing In-Reply-To: <4B029CC9.7060301@sophia.inria.fr> References: <1258216172.26175.14.camel@localhost.localdomain> <4B024B59.3020200@clarinet.u-strasbg.fr> <1258444853.13172.4.camel@diese.inria.fr> <4B029CC9.7060301@sophia.inria.fr> Message-ID: <4B02A26F.6060800@clarinet.u-strasbg.fr> Faker Moatamri a ?crit : > Mathieu Lacage wrote: >> On Tue, 2009-11-17 at 08:06 +0100, S?bastien Vincent wrote: >> >> >>> Sorry for late response, I fix regression tests that was introduced >>> in "Bug #729 IPv6 over PPP" commit. >>> >> >> thanks ! >> >> >>> It remains three regression tests failing that are not related to >>> the previous commit (test-csma-broadcast, test-csma-ping, >>> test-simple-point-to-point-olsr). >>> >> >> More bisection ahead :) >> >> Mathieu >> >> > It is much more complicated than I thought: > - Using revision 92 in ns-3-dev-ref-traces: > > * Revision 5502, works perfectly fine > * Revision 5503: test-dynamic-global-routing, > test-global-routing-slash32, test-simple-error-model, > test-simple-global-routing, test-simple-point-to-point-olsr, > test-static-routing-slash32, test-tcp-large-transfer fail > * Revision 5743: test-csma-broadcast, test-csma-ping, > test-dynamic-global-routing, test-global-routing-slash32, > test-simple-error-model, test-simple-global-routing, > test-simple-point-to-point-olsr, test-static-routing-slash32, > test-tcp-large-transfer > * Revision 5744(tip): failed (test-csma-broadcast, test-csma-ping, > test-simple-point-to-point-olsr) > > - Using revision 93 (tip) in ns-3-dev-ref-traces: > > * Revision 5503-5509: test-csma-broadcast, > test-simple-point-to-point-olsr fail > * Revision 5743: failed (test-csma-broadcast, test-csma-ping, > test-simple-point-to-point-olsr) > * Revision 5744(tip): (test-csma-broadcast, test-csma-ping, > test-dynamic-global-routing, test-global-routing-slash32, > test-simple-error-model, test-simple-global-routing, > test-simple-point-to-point-olsr, test-static-routing-slash32, > test-tcp-large-transfer) > > To simplify analysis, I will consider the couple (ns-3-dev revision, > ns-3-dev-ref-traces revision). > For revision (5503,93) we have failure in test-csma-broadcast and > test-simple-point-to-point-olsr failures. In rev (5739-5743, 93), we > have one failure added test-csma-ping which might be due to the patch > added by Pavel, is this possible Pavel? > Now revision (5744,93) we still have the 9 failures > (test-csma-broadcast, test-csma-ping, test-dynamic-global-routing, > test-global-routing-slash32, test-simple-error-model, > test-simple-global-routing, test-simple-point-to-point-olsr, > test-static-routing-slash32, test-tcp-large-transfer), Sebastien did > you update your reference traces before submitting the patch in 5744? > should we come back to revision 92 in reference traces? No I have not done it :(. > Best regards > Faker > > From jens.mittag at kit.edu Tue Nov 17 05:48:21 2009 From: jens.mittag at kit.edu (Jens Mittag) Date: Tue, 17 Nov 2009 14:48:21 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4B0296DB.9010705@cttc.es> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> <4AFD90C7.1040505@cttc.es> <4B026E3D.1070209@kit.edu> <4B027C02.9030108@cttc.es> <4B027F47.2060102@kit.edu> <4B0296DB.9010705@cttc.es> Message-ID: <4B02A9A5.70109@kit.edu> Hi Nicola! Nicola Baldo schrieb: >> Ah, now I get you ;) When you say energy detection (ED) you are talking >> about an absolute threshold. I understood it as a steep rise of the >> signal energy, which is relative again. > > I didn't invent that definition by myself ;-) > > The process of synchronizing upon reception is defined in IEEE > 802.11-2007 section 15.2.7. Two primitives can be used for this purpose: > PMD_ED and PMD_SQ. > > PMD_ED (section 15.4.5.13) indicates "that the receiver has detected RF > energy [...] that is above a predefined threshold". > > PMD_SQ (15.4.5.11) "provides to the PLCP and MAC entity the SQ of the > DSSS PHY PN code correlation. The SQ shall be sampled when the DSSS PHY > achieves code lock and shall be held until the next code lock acquisition." > In other words, PMD_SQ is fired when preamble is detected. > > Note that the same primitives (PMD_ED and PMD_SQ) are used for Clear > Channel Assessment (CCA). Also note that things change slightly for PHY > specifications other than DSSS. Great, now I understand the reason why I did not understand this. Our group doesn't look at DSSS mode and only on OFDM operation (Section 17 in the IEEE Standard). There we don't have PMD_ED and PMD_SQ, but only PHY-CCA and (not explicitly mentioned) the PMD_CS. >> Or why has it been introduced in YansWifiPhy? Is it >> an artifact from the old NS-2 implementation (before the changes from >> Schmidt-Eisenlohr et. al) where we had a Rx and a Cs threshold? > > I think there is some confusion about the current YansWifiPhy. > Have a look for instance at the discussion for bug 689: > http://www.nsnam.org/bugzilla/show_bug.cgi?id=689 > > the fact is that we have an "EnergyDetectionThreshold" and a > "CcaMode1Threshold". The standard (section 15.4.8.4) says that CCA mode > 1 corresponds to the use of ED only (no preamble detection). > So CccaMode1Threshold is the one for ED, and what about > EnergyDetectionThreshold? > > I am tempted to reopen bug 689... I guess the confusing comes from the different PHY specifications (as stated above): OFDM mode has only PHY-CCA and PMD_CS, whereas DSSS has (optionally) also PMD_ED and PMD_SQ to support PHY-CCA. How about having two different PHY implementation classes, one for OFDM and one for DSSS? Of course we would have duplicate code, but this way it would be a clear separation of the two modes, and more obvious to the user. And it would be easier to have default parameters for both modes... (from my knowledge/experience the BER functions are also different). >> In the code of Timo Bingmann (he worked in our group during his diploma >> thesis), we do not consider energy detection at all and model only >> preamble detection... > > That's a possible choice. The standard allows the use of PMD_SQ alone, > both for reception (section 15.2.7) and CCA (section 15.4.8.4). Note > that the standard also allows the use of PMD_ED alone, I think that > YansWifiPhy was designed with this latter choice. >> the energy detection threshold is from our >> understanding implicitly given by the noise floor and the SINR threshold >> for the preamble. > > This reasoning is not correct. The standard allows you to set the ED > threshold high enough so that low power signals for which preamble can > be detected will still fail ED. As you mentioned earlier, this is done > so that you can transmit over weak signals and achieve a higher channel > utilization in dense deployments. Also note that, if we model preamble > reception with a SNR threshold, the value of this threshold will be in > practice imposed by the PHY specifications (type of preamble and length). I agree, with this reasoning, you would definitely need to model the energy detection threshold explicitly to support the suppression. However, this suppression is apparently only standardized for DSSS and not for OFDM mode. Jens -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Engesserstr. 2, 76131 Karlsruhe, Germany Building 20.50, Room 112 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ From jens.mittag at kit.edu Tue Nov 17 05:52:18 2009 From: jens.mittag at kit.edu (Jens Mittag) Date: Tue, 17 Nov 2009 14:52:18 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <1258459997.13172.25.camel@diese.inria.fr> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> <4AFD90C7.1040505@cttc.es> <4B026E3D.1070209@kit.edu> <1258459997.13172.25.camel@diese.inria.fr> Message-ID: <4B02AA92.7030600@kit.edu> Hi Matthieu, Mathieu Lacage schrieb: > On Tue, 2009-11-17 at 10:34 +0100, Jens Mittag wrote: > >> Our research group has recently implemented a physical layer for OFDM >> wifi that goes down to the time sample level by breaking the abstraction >> of a packet and implementing the transceiver technology entirely in >> software. > > Hint, hint: It would be nice to see this PHY layer integrated in the > ns-3 wifi module :) Our implementation has been developed as an integration into NS-3 from the beginning. Indeed its a drop-in replacement for the current YansWifiPhy. Whether and when we will publish it is currently under discussion (the implementation is a joint work with Chalmers University in Gothenburg). Jens -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Engesserstr. 2, 76131 Karlsruhe, Germany Building 20.50, Room 112 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ From faker.moatamri at sophia.inria.fr Tue Nov 17 06:34:44 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 17 Nov 2009 15:34:44 +0100 Subject: [Ns-developers] ./waf --regression failing In-Reply-To: <4B02A26F.6060800@clarinet.u-strasbg.fr> References: <1258216172.26175.14.camel@localhost.localdomain> <4B024B59.3020200@clarinet.u-strasbg.fr> <1258444853.13172.4.camel@diese.inria.fr> <4B029CC9.7060301@sophia.inria.fr> <4B02A26F.6060800@clarinet.u-strasbg.fr> Message-ID: <4B02B484.7030202@sophia.inria.fr> Sebastien Vincent wrote: > Faker Moatamri a ?crit : >> It is much more complicated than I thought: >> - Using revision 92 in ns-3-dev-ref-traces: >> >> * Revision 5502, works perfectly fine >> * Revision 5503: test-dynamic-global-routing, >> test-global-routing-slash32, test-simple-error-model, >> test-simple-global-routing, test-simple-point-to-point-olsr, >> test-static-routing-slash32, test-tcp-large-transfer fail >> * Revision 5743: test-csma-broadcast, test-csma-ping, >> test-dynamic-global-routing, test-global-routing-slash32, >> test-simple-error-model, test-simple-global-routing, >> test-simple-point-to-point-olsr, test-static-routing-slash32, >> test-tcp-large-transfer >> * Revision 5744(tip): failed (test-csma-broadcast, test-csma-ping, >> test-simple-point-to-point-olsr) >> >> - Using revision 93 (tip) in ns-3-dev-ref-traces: >> >> * Revision 5503-5509: test-csma-broadcast, >> test-simple-point-to-point-olsr fail >> * Revision 5743: failed (test-csma-broadcast, test-csma-ping, >> test-simple-point-to-point-olsr) >> * Revision 5744(tip): (test-csma-broadcast, test-csma-ping, >> test-dynamic-global-routing, test-global-routing-slash32, >> test-simple-error-model, test-simple-global-routing, >> test-simple-point-to-point-olsr, test-static-routing-slash32, >> test-tcp-large-transfer) >> >> To simplify analysis, I will consider the couple (ns-3-dev revision, >> ns-3-dev-ref-traces revision). >> For revision (5503,93) we have failure in test-csma-broadcast and >> test-simple-point-to-point-olsr failures. In rev (5739-5743, 93), we >> have one failure added test-csma-ping which might be due to the patch >> added by Pavel, is this possible Pavel? >> Now revision (5744,93) we still have the 9 failures >> (test-csma-broadcast, test-csma-ping, test-dynamic-global-routing, >> test-global-routing-slash32, test-simple-error-model, >> test-simple-global-routing, test-simple-point-to-point-olsr, >> test-static-routing-slash32, test-tcp-large-transfer), Sebastien did >> you update your reference traces before submitting the patch in 5744? >> should we come back to revision 92 in reference traces? > > No I have not done it :(. > The question is now should we keep rev 92 or 93 for reference traces? Tom? Sebastien? >> Best regards >> Faker >> >> > From tbns at idlebox.net Tue Nov 17 06:46:11 2009 From: tbns at idlebox.net (Timo Bingmann) Date: Tue, 17 Nov 2009 15:46:11 +0100 Subject: [Ns-developers] TrafficApplication and a Wifi maximum throughput example. Message-ID: <200911171546.11729.tbns@idlebox.net> Reviewers: , Message: First extract from my wifiex repo: TrafficApplication is a modification of OnOffApplication to allow a) stochastic inter-packet intervals like Poisson packet streams b) a versatile packet factory to create packets with different sizes (e.g. from some random distribution), data contents and maybe special Tags. c) always accept incoming Rx as a sink, see below. Also included is an example simulation, which tests the maximum throughput between two wifi nodes: one has a TrafficApplication, the other a PacketSink. The reason for TrafficApp's Rx functions becomes plain here: it no Rx is installed, then _all_ data is queues somewhere in the PacketSocket stack and the experiment explodes. So tell me what you think? Coming soon are the wifi modifications. Timo Please review this at http://codereview.appspot.com/154183 Affected files: A examples/wireless/wifi-throughput.cc M examples/wireless/wscript A src/applications/traffic/traffic-application.cc A src/applications/traffic/traffic-application.h A src/applications/traffic/wscript A src/helper/traffic-helper.cc A src/helper/traffic-helper.h M src/helper/wscript M src/wscript From faker.moatamri at sophia.inria.fr Tue Nov 17 07:40:22 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 17 Nov 2009 16:40:22 +0100 Subject: [Ns-developers] Bug #622, fiendly names for pcap files Message-ID: <4B02C3E6.9070609@sophia.inria.fr> Hi all, I updated the patch already submitted for this bug, you can find it attached. Here is a reminder of the patch behavior: 'Attached is a patch that gives out more meaningful names for trace files. Instead of filename-nodeid-deviceid, which can get quite cumbersome if you have lots of devices, this one uses format filename-nodename-devname if they have been given via Names::Add facility. For Nodes, simply use Ptr TestBoxNode; Names::Add("TestBox", TestBoxNode) For devices, you need to specify the name belongs to specific node (so you can use e.g. "eth0" for multiple nodes), like so: Ptr TestDev = TestBoxNode->GetDevice(0); Names::Add(TestBoxNode, "eth0", TestDev); End result what you'll see when you use e.g. PointToPointHelper::EnablePcapAll ("testtrace"); will be that instead of testrace-0-0.pcap, you get testrace-TestBox-eth0.pcap ...which I think is quite useful addition.' It already got +1 from Tom, I will checkin the patch if no one has any problem with this. Thanks Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: friendlyNames.patch Type: text/x-patch Size: 2051 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091117/7b93d4d1/friendlyNames.bin From nbaldo at cttc.es Tue Nov 17 07:50:17 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Tue, 17 Nov 2009 16:50:17 +0100 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <4B02A9A5.70109@kit.edu> References: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> <4AFC3D7C.9070703@cttc.es> <4AFC4186.7080309@kit.edu> <4AFD2EFA.9040806@cttc.es> <4AFD3BD1.4050200@kit.edu> <4AFD90C7.1040505@cttc.es> <4B026E3D.1070209@kit.edu> <4B027C02.9030108@cttc.es> <4B027F47.2060102@kit.edu> <4B0296DB.9010705@cttc.es> <4B02A9A5.70109@kit.edu> Message-ID: <4B02C639.6010005@cttc.es> Jens Mittag wrote: > Great, now I understand the reason why I did not understand this. Our > group doesn't look at DSSS mode and only on OFDM operation (Section 17 > in the IEEE Standard). There we don't have PMD_ED and PMD_SQ, but only > PHY-CCA and (not explicitly mentioned) the PMD_CS. > Now I understand as well :-) Moreover, I get the impression that the CCA specs for OFDM are much more vague than for DSSS. For instance, in 17.5.5.7.4 when talking about PMD_RSSI they say: "The RSSI may be used as part of a CCA scheme." I wonder what do real 802.11a chipset use... > I guess the confusing comes from the different PHY specifications (as > stated above): OFDM mode has only PHY-CCA and PMD_CS, whereas DSSS has > (optionally) also PMD_ED and PMD_SQ to support PHY-CCA. How about having > two different PHY implementation classes, one for OFDM and one for DSSS? > > Of course we would have duplicate code, but this way it would be a clear > separation of the two modes, and more obvious to the user. And it would > be easier to have default parameters for both modes... (from my > knowledge/experience the BER functions are also different). > I see your point, however I also hope we will have 802.11g in the near future. Since it's a mixture of DSSS and OFDM, I get the impression that it will be easier to do if we keep everything within a single PHY class. Furthermore, BER function are already differentiated on a per-WifiMode basis, so I don't see the improvement you would get by having separate PHY classes in this case. Why don't we just implement both PMD_ED and PMD_CS, and then choose which to use for every PHY specification? By default, DSSS could use PMD_ED AND PMD_CS, while OFDM could use PMD_CS only. Nicola From Florian.Schmidt at cs.rwth-aachen.de Tue Nov 17 05:17:03 2009 From: Florian.Schmidt at cs.rwth-aachen.de (Florian Schmidt) Date: Tue, 17 Nov 2009 14:17:03 +0100 Subject: [Ns-developers] Packet data replacement Message-ID: Hi all, while looking at the doxygen for ErrorModel, I noticed the following statement: "Depending on the error model, the packet itself may have its packet data buffer errored or not" However, I am not sure how an error model would alter the actual packet data, because I can only see read-only access to the packet data inside the Packet class (PeekData giving a const pointer, and CopyData a copy). If this is the case, I would propose adding a method to the Packet class that allows write access to the packet data. This leads me to the second problem/question, which I have detailed in Bug #686 on bugtracker. I don't see a way to recognize from outside whether parts of a Buffer are a zero area. Reading from a buffer with a zero area makes it seem as if it was actually existing in memory. However, writing to a Buffer in a way that touches the zero area does not transparently expand it, but crashes ns-3. Maybe it would be helpful to have a method in the Buffer class that allows to "inflate" the zero area to real memory, so write access is possible? I'd just like to make sure that in both cases, I am not missing something. It would just be a waste of time if there was already a way to do what I want, without extending central Classes such as Packet and Buffer. Best regards, Florian -- Florian Schmidt, Ph.D. Student Distributed Systems Group Chair for Computer Science IV, RWTH Aachen, Germany http://ds.cs.rwth-aachen.de/members/schmidt From craigdo at ee.washington.edu Tue Nov 17 11:04:40 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 17 Nov 2009 11:04:40 -0800 Subject: [Ns-developers] Bug #622, fiendly names for pcap files In-Reply-To: <4B02C3E6.9070609@sophia.inria.fr> References: <4B02C3E6.9070609@sophia.inria.fr> Message-ID: <018001ca67b8$d1378300$73a68900$@washington.edu> -1 I have a problem with it since it only works on csma and point-to-point, adds the same code in two places (making the current code duplication problem worse since it should really go in 6 places to be consistent, I think) and mow makes these two devices behave differently than the others that use pcap. It's simple, but has problems. I have an enhancement in progress ... > -----Original Message----- > From: Faker Moatamri [mailto:faker.moatamri at sophia.inria.fr] > Sent: Tuesday, November 17, 2009 7:40 AM > To: ns-developers at ISI.EDU; Mathieu Lacage; Craig Dowell; Tom Henderson > Subject: Bug #622, fiendly names for pcap files > > Hi all, > I updated the patch already submitted for this bug, you can find it > attached. Here is a reminder of the patch behavior: > > 'Attached is a patch that gives out more meaningful names for trace > files. > Instead of filename-nodeid-deviceid, which can get quite cumbersome if > you have > lots of devices, this one uses format filename-nodename-devname if they > have > been given via Names::Add facility. > > For Nodes, simply use > > Ptr TestBoxNode; > Names::Add("TestBox", TestBoxNode) > > For devices, you need to specify the name belongs to specific node (so > you can > use e.g. "eth0" for multiple nodes), like so: > > Ptr TestDev = TestBoxNode->GetDevice(0); > Names::Add(TestBoxNode, "eth0", TestDev); > > End result what you'll see when you use e.g. > > PointToPointHelper::EnablePcapAll ("testtrace"); > > will be that instead of testrace-0-0.pcap, you get testrace-TestBox- > eth0.pcap > > ...which I think is quite useful addition.' > > > It already got +1 from Tom, I will checkin the patch if no one has any > problem with this. > Thanks > Faker Moatamri > From tomh at tomh.org Tue Nov 17 14:08:15 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 17 Nov 2009 15:08:15 -0700 Subject: [Ns-developers] ns-3.7 merge plans In-Reply-To: <4B016E35.3040604@sophia.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> Message-ID: Faker, We are up against your deadline for ns-3.7 new feature merge with still quite a few loose ends on many repositories, and some new ones being proposed even this week. Can you please give us a status check on the list and proposed action items for the various proposals? I think that if we were to declare "all issues must be resolved now" before Nov. 18, probably we cannot make any more new feature merges for ns-3.7, but on the other hand, comments from maintainers are still rolling in (and some not reviewed yet) and there is not much time for authors to turn around responses due to comments this week. Can you please try to get together with the proposers and relevant maintainers for the proposals with a lot of outstanding comments (e.g. WiMAX, NetAnim, MPI) and see whether you can work out an action plan that could get their modules merged for ns-3.7? Thanks, Tom From tomh at tomh.org Tue Nov 17 21:40:58 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 17 Nov 2009 21:40:58 -0800 Subject: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) In-Reply-To: <4AFAD949.7080404@clarinet.u-strasbg.fr> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <000301ca57ef$46c5d150$d45173f0$@ch> <4AE91BE8.9090900@tomh.org> <4AE93B92.6000809@clarinet.u-strasbg.fr> <4AE97000.1090900@sophia.inria.fr> <001b01ca5938$16e382d0$44aa8870$@ch> <4AEAD0B8.8070202@sophia.inria.fr> <004301ca5b9e$4488b210$cd9a1630$@ch> <4AEFD2D1.4020309@clarinet.u-strasbg.fr> <4AFAD949.7080404@clarinet.u-strasbg.fr> Message-ID: <4B0388EA.6000702@tomh.org> S?bastien Vincent wrote: > Hi, > > I merge Fabian's repository (ns-3-ipv6-option) into ns-3-ipv6-ext > repository (http://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext). I also fix > comments from codereview. Fabian and Sebastien, I reviewed this again tonight. My main remaining comments are: 1) I would recommend some test code coverage for some of this (particularly fragmentation). I didn't notice any new tests added for these extensions. 2) coding style for the new files; we indent the braces such as the gnu indent program -bl or -bli2 options: if (x > 0) { x--; } 3) when you merge, please update RELEASE_NOTES and CHANGES.html Regards, Tom From mathieu.lacage at sophia.inria.fr Tue Nov 17 23:08:37 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 08:08:37 +0100 Subject: [Ns-developers] ns-3.7 merge plans In-Reply-To: References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> Message-ID: <1258528117.22863.2.camel@diese.inria.fr> hi, On Tue, 2009-11-17 at 15:08 -0700, Tom Henderson wrote: > I think that if we were to declare "all issues must be resolved now" before > Nov. 18, probably we cannot make any more new feature merges for ns-3.7, > but on the other hand, comments from maintainers are still rolling in (and > some not reviewed yet) and there is not much time for authors to turn > around responses due to comments this week. Can you please try to get > together with the proposers and relevant maintainers for the proposals with > a lot of outstanding comments (e.g. WiMAX, NetAnim, MPI) and see whether > you can work out an action plan that could get their modules merged for > ns-3.7? Although it's not my decision to make, I personally would support a one week extension for comment resolution but no more. i.e., I fail to see the problem with keeping work on the reviews/comments for 3.8 during december/november while we proceed with 3.7 stabilization. Mathieu From mathieu.lacage at sophia.inria.fr Tue Nov 17 23:13:01 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 08:13:01 +0100 Subject: [Ns-developers] ns-3.7 merge plans In-Reply-To: <1258528117.22863.2.camel@diese.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> <1258528117.22863.2.camel@diese.inria.fr> Message-ID: <1258528381.22863.6.camel@diese.inria.fr> it looks like I can't even write a complete email: sorry about that. On Wed, 2009-11-18 at 08:08 +0100, Mathieu Lacage wrote: > Although it's not my decision to make, I personally would support a one > week extension for comment resolution but no more. i.e., I fail to see > the problem with keeping work on the reviews/comments for 3.8 during > december/november while we proceed with 3.7 stabilization. I also wanted to point out it's pretty clear to me that it's impossible to merge the 3 repositories you mentioned within a 1 or even a 2 week period so, I think that the real issue is that our beloved RM needs to decide on a priority ordering for merging and focus on the highest-priority items first and, do this within a fixed period of time only. Mathieu From mathieu.lacage at sophia.inria.fr Tue Nov 17 23:44:53 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 08:44:53 +0100 Subject: [Ns-developers] Packet data replacement In-Reply-To: References: Message-ID: <1258530293.22863.15.camel@diese.inria.fr> On Tue, 2009-11-17 at 14:17 +0100, Florian Schmidt wrote: > while looking at the doxygen for ErrorModel, I noticed the following > statement: > "Depending on the error model, the packet itself may have its packet > data buffer errored or not" > However, I am not sure how an error model would alter the actual > packet data, because I can only see read-only access to the packet > data inside the Packet class (PeekData giving a const pointer, and > CopyData a copy). If this is the case, I would propose adding a method Technically, you could cast away constness from PeekData but, don't tell anyone I told you so. > to the Packet class that allows write access to the packet data. > > This leads me to the second problem/question, which I have detailed in > Bug #686 on bugtracker. I don't see a way to recognize from outside > whether parts of a Buffer are a zero area. Reading from a buffer with > a zero area makes it seem as if it was actually existing in memory. > However, writing to a Buffer in a way that touches the zero area does > not transparently expand it, but crashes ns-3. Maybe it would be > helpful to have a method in the Buffer class that allows to "inflate" > the zero area to real memory, so write access is possible? You can already do this by calling Packet::PeekData () which will transparently "inflate" the zero area to real memory. However, experience has shown that this API is both hard to implement (i.e., buggy) and generally brings lots of problems because giving direct access to the underlying byte buffer breaks a lot of things (even readonly) To summarize, I have been toying with the idea of marking PeekData deprecated and adding new API based on copy semantics (rather than peek semantics) to replace its functionality. In this case, this would first require that you change the ErrorModel base class API to make the Corrupt method return a new corrupted packet rather than corrupt the input packet in-place. Mathieu From vincent at clarinet.u-strasbg.fr Wed Nov 18 02:51:55 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Wed, 18 Nov 2009 11:51:55 +0100 Subject: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) In-Reply-To: <4B0388EA.6000702@tomh.org> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <000301ca57ef$46c5d150$d45173f0$@ch> <4AE91BE8.9090900@tomh.org> <4AE93B92.6000809@clarinet.u-strasbg.fr> <4AE97000.1090900@sophia.inria.fr> <001b01ca5938$16e382d0$44aa8870$@ch> <4AEAD0B8.8070202@sophia.inria.fr> <004301ca5b9e$4488b210$cd9a1630$@ch> <4AEFD2D1.4020309@clarinet.u-strasbg.fr> <4AFAD949.7080404@clarinet.u-strasbg.fr> <4B0388EA.6000702@tomh.org> Message-ID: <4B03D1CB.1050702@clarinet.u-strasbg.fr> Hi Tom, Tom Henderson a ?crit : > S?bastien Vincent wrote: >> Hi, >> >> I merge Fabian's repository (ns-3-ipv6-option) into ns-3-ipv6-ext >> repository (http://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext). I also fix >> comments from codereview. > > Fabian and Sebastien, > > I reviewed this again tonight. My main remaining comments are: > > 1) I would recommend some test code coverage for some of this > (particularly fragmentation). I didn't notice any new tests added for > these extensions. > I will try to do something next week. > 2) coding style for the new files; we indent the braces such as the > gnu indent program -bl or -bli2 options: > > if (x > 0) > { > x--; > } > Done. > 3) when you merge, please update RELEASE_NOTES and CHANGES.html > OK. -- Sebastien > Regards, > Tom > From faker.moatamri at sophia.inria.fr Wed Nov 18 03:11:01 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 18 Nov 2009 12:11:01 +0100 Subject: [Ns-developers] NS-3.7 new feature merge period expired Message-ID: <4B03D645.3080508@sophia.inria.fr> Hi all, As of today, Wednesday November 18^th , the new feature merge period is finished and the small feature development and bug fixing started. During this period you can: * Submit limited, small, self contained changes/features to ns-3-dev and to merged new features. As specified before, no more new feature merges are accepted * Submit code for review, this is very useful as this will make it easier to merge your code early in the next release * Cleanup the ns-3-dev bug tracker, solve as much bugs as possible However, since a lot of work have been done in the last few weeks to make some modules ready for merge, I will leave you one more week (Nov 19^th to Nov 25^th included) to address the reviewer's comments. During this week, you can submit a new version of your patch and if I get an email from every reviewer stating that his comments have been addressed, you will be granted a time slot next week to merge (Nov 26^th to Dec 3^rd included). The merging will be on a FIFO basis, the faster you submit the patch with reviewer's acks, the sooner you will get your time slot to merge. Here is a list of reviewers who are expected to send me an explicit ack email on the modules they reviewed: * Wimax: o Reviewers: Mathieu Lacage, Tom Henderson * MPI based parallelization: o Reviewers: Craig Dowell, Tom Henderson, Mathieu Lacage * Net-Anim: o Reviewers: Tom Henderson * 802.11n block ack: o Reviewers: Nicola Baldo, Andrey Mazo, Andreev Kirill, Mathieu Lacage * IPv6 Extensions: o Reviewers: Tom Henderson Please note that this is the time schedule for the NS-3.7 release: 1. Oct 21^st - Nov 18^th : New feature merge 2. Nov 18^th - Dec 16^th : Small feature development and bug fixing allowed 3. Dec 16^th - Jan 6^th : Only bug fixes allowed 4. Jan 6^th - Jan 20^th : Code freeze, RC releases For more details about the current release please take a look at this page: http://www.nsnam.org/wiki/index.php/Ns-3.7, you will find the submission recommendations, the list of allowed/forbidden things to do during each phase, the list of merges added to ns-3-dev and the list of merge candidates. Thank you for your cooperation Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Wed Nov 18 03:16:34 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 18 Nov 2009 12:16:34 +0100 Subject: [Ns-developers] Bug #622, fiendly names for pcap files In-Reply-To: <018001ca67b8$d1378300$73a68900$@washington.edu> References: <4B02C3E6.9070609@sophia.inria.fr> <018001ca67b8$d1378300$73a68900$@washington.edu> Message-ID: <4B03D792.4070105@sophia.inria.fr> craigdo at ee.washington.edu wrote: > -1 > > I have a problem with it since it only works on csma and point-to-point, > adds the same code in two places (making the current code duplication > problem worse since it should really go in 6 places to be consistent, I > think) and mow makes these two devices behave differently than the others > that use pcap. > > It's simple, but has problems. I have an enhancement in progress ... > > Please take a look also at the bug 683 (http://www.nsnam.org/bugzilla/show_bug.cgi?id=683) which proposes to have an explicit name instead of a somehow generated name. This might be useful for some users who would need a specific file name for their pcap file. Those two patches change the same places in the code and we need to decide which one we will keep or if we merge the two patches (allowing the user to have explicit file names and friendly file names). What do you guys think? Best regards Faker From gjcarneiro at gmail.com Wed Nov 18 04:08:16 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 18 Nov 2009 12:08:16 +0000 Subject: [Ns-developers] Python bindings failure In-Reply-To: <4B016E35.3040604@sophia.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> Message-ID: After *much* effort, Python bindings are fixed. The only problem is that I found a new GCC-XML bug[1], which affects scanning of Time as default parameter value, so that I had to manually fix the apidefs after scanning: in bindings/python/apidefs/*/ns3_module_aodv.py, replace ns3::MilliSeconds() with ns3::MilliSeconds(0). If anyone else re-scans bindings, pay attention to this problem. [1] http://www.gccxml.org/Bug/view.php?id=9915 2009/11/16 Faker Moatamri > Mathieu Lacage wrote: > >> On Sun, 2009-11-15 at 16:25 +0000, Gustavo Carneiro wrote: >> >> >>> I started to look at this, but got blocked by the weird pygccxml API. >>> Awaiting some feedback from the pygccxml developer. >>> >>> >> >> Faker, could we try to disable all python builds from buildbot to clear >> up the build status until this issue is resolved ? >> >> Mathieu >> >> >> > Done, I put a comment in the buildbot file: '##disabled python until fixed' > so that we can put it back as it was after python bindings problem is fixed. > > Please note that regression tests are still failing. Building does not fail > though. > > Best regards > Faker > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mathieu.lacage at sophia.inria.fr Wed Nov 18 04:09:13 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 13:09:13 +0100 Subject: [Ns-developers] removing calls to PeekData Message-ID: <1258546153.27438.10.camel@diese.inria.fr> hi, I just finally marked Packet::PeekData as deprecated because I was getting worried that some users would actually start to use it. I also discovered that we have code which uses it already. I should have done the deprecation before to avoid the pain now :/ The attached patch removes PeekData from the emulation code so, I would appreciate an ack from craig before committing it. You (craig) might be worried about this extra temporary memory allocation and memcpy but what is really happening here is that I am merely making these operations explicit: they were both already happening deep within the guts of the Packet code when you called PeekData so, this change should be neutral from the perspective of memory allocations and memcpys. As a further optimization, if you want me to, I could fairly easily avoid the memory allocation if you want me to add a sufficiently big per-device temporary buffer. The remaining uses of PeekData are all in the ipv6 code: I am planning to send patches to fix them but I guess that it will be better for everyone involved in ipv6 stuff if I wait until the merge of the new ipv6 code before doing this: I don't want to make the merging step harder for sebastien and tom. Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: peek-data.patch Type: text/x-patch Size: 1467 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091118/61cbe5ed/peek-data-0001.bin From mathieu.lacage at sophia.inria.fr Wed Nov 18 04:11:26 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 13:11:26 +0100 Subject: [Ns-developers] Python bindings failure In-Reply-To: References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> Message-ID: <1258546286.27438.12.camel@diese.inria.fr> On Wed, 2009-11-18 at 12:08 +0000, Gustavo Carneiro wrote: > The only problem is that I found a new GCC-XML bug[1], which affects > scanning of Time as default parameter value, so that I had to manually > fix the apidefs after scanning: in > bindings/python/apidefs/*/ns3_module_aodv.py, replace > ns3::MilliSeconds() with ns3::MilliSeconds(0). If anyone else Ouch :/ > re-scans bindings, pay attention to this problem. Is there something we can do in our code/ns-3 API to avoid this problem ? I would be willing to go to great pains to avoid this necessarily error-prone manual step. Mathieu From gjcarneiro at gmail.com Wed Nov 18 04:15:10 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 18 Nov 2009 12:15:10 +0000 Subject: [Ns-developers] Python bindings failure In-Reply-To: <1258546286.27438.12.camel@diese.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> <1258546286.27438.12.camel@diese.inria.fr> Message-ID: 2009/11/18 Mathieu Lacage > On Wed, 2009-11-18 at 12:08 +0000, Gustavo Carneiro wrote: > > The only problem is that I found a new GCC-XML bug[1], which affects > > scanning of Time as default parameter value, so that I had to manually > > fix the apidefs after scanning: in > > bindings/python/apidefs/*/ns3_module_aodv.py, replace > > ns3::MilliSeconds() with ns3::MilliSeconds(0). If anyone else > > Ouch :/ > > > re-scans bindings, pay attention to this problem. > > Is there something we can do in our code/ns-3 API to avoid this > problem ? I would be willing to go to great pains to avoid this > necessarily error-prone manual step. > I say give it some time to see if the GCC-XML developers can fix the bug, where it should be fixed. We can worry about it in a couple of weeks if it doesn't get fixed. I just reported the bug, right now, it's not some ancient bug... -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mathieu.lacage at sophia.inria.fr Wed Nov 18 04:25:08 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 13:25:08 +0100 Subject: [Ns-developers] Python bindings failure In-Reply-To: References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> <1258546286.27438.12.camel@diese.inria.fr> Message-ID: <1258547108.27438.15.camel@diese.inria.fr> On Wed, 2009-11-18 at 12:15 +0000, Gustavo Carneiro wrote: > > > 2009/11/18 Mathieu Lacage > On Wed, 2009-11-18 at 12:08 +0000, Gustavo Carneiro wrote: > > The only problem is that I found a new GCC-XML bug[1], which > affects > > scanning of Time as default parameter value, so that I had > to manually > > fix the apidefs after scanning: in > > bindings/python/apidefs/*/ns3_module_aodv.py, replace > > ns3::MilliSeconds() with ns3::MilliSeconds(0). If anyone > else > > > Ouch :/ > > > re-scans bindings, pay attention to this problem. > > > Is there something we can do in our code/ns-3 API to avoid > this > problem ? I would be willing to go to great pains to avoid > this > necessarily error-prone manual step. > > I say give it some time to see if the GCC-XML developers can fix the > bug, where it should be fixed. We can worry about it in a couple of > weeks if it doesn't get fixed. I just reported the bug, right now, > it's not some ancient bug... Well, the last time I tried to use a recent gcc-xml with pybindgen, all hell broke loose: it seems that until recently, we could use only a very specific and old version of gcc-xml so, it would be nice if we could work around it instead of requesting all developers to re-install a new version of gcc-xml. Mathieu From gjcarneiro at gmail.com Wed Nov 18 04:48:22 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 18 Nov 2009 12:48:22 +0000 Subject: [Ns-developers] Python bindings failure In-Reply-To: <1258547108.27438.15.camel@diese.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> <1258546286.27438.12.camel@diese.inria.fr> <1258547108.27438.15.camel@diese.inria.fr> Message-ID: 2009/11/18 Mathieu Lacage > On Wed, 2009-11-18 at 12:15 +0000, Gustavo Carneiro wrote: > > > > > > 2009/11/18 Mathieu Lacage > > On Wed, 2009-11-18 at 12:08 +0000, Gustavo Carneiro wrote: > > > The only problem is that I found a new GCC-XML bug[1], which > > affects > > > scanning of Time as default parameter value, so that I had > > to manually > > > fix the apidefs after scanning: in > > > bindings/python/apidefs/*/ns3_module_aodv.py, replace > > > ns3::MilliSeconds() with ns3::MilliSeconds(0). If anyone > > else > > > > > > Ouch :/ > > > > > re-scans bindings, pay attention to this problem. > > > > > > Is there something we can do in our code/ns-3 API to avoid > > this > > problem ? I would be willing to go to great pains to avoid > > this > > necessarily error-prone manual step. > > > > I say give it some time to see if the GCC-XML developers can fix the > > bug, where it should be fixed. We can worry about it in a couple of > > weeks if it doesn't get fixed. I just reported the bug, right now, > > it's not some ancient bug... > > Well, the last time I tried to use a recent gcc-xml with pybindgen, all > hell broke loose: it seems that until recently, we could use only a very > specific and old version of gcc-xml so, it would be nice if we could > work around it instead of requesting all developers to re-install a new > version of gcc-xml. > I had already updated the required gccxml version in the wiki page, see: http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings#The_semi-automatic_way I had started to use that gccxml snapshot from september, with pygccxml 1.0, and updated the wiki page, but I guess I forgot to notify the ns-developers list. Sorry about that. No, we cannot stick to old versions. Newer pygccxml does not work well with old gccxml, we have to move forward or we stagnate and die. I have today updated to gccxml HEAD and it works fine, apart from that bug I reported. I don't like constantly using bleeding edge (you know well how I like things stable), but I think about once a year is reasonable to request that people upgrade their tools, don't you think? Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From Florian.Schmidt at cs.rwth-aachen.de Wed Nov 18 04:48:51 2009 From: Florian.Schmidt at cs.rwth-aachen.de (Florian Schmidt) Date: Wed, 18 Nov 2009 13:48:51 +0100 Subject: [Ns-developers] Packet data replacement In-Reply-To: <1258530293.22863.15.camel@diese.inria.fr> References: <1258530293.22863.15.camel@diese.inria.fr> Message-ID: On Nov 18, 2009, at 8:44 AM, Mathieu Lacage wrote: > Technically, you could cast away constness from PeekData but, don't tell > anyone I told you so. I'll keep quiet ;) Although I think with your proposal to deprecate PeekData, this will soon become a moot point. > You can already do this by calling Packet::PeekData () which will > transparently "inflate" the zero area to real memory. Ah, I missed the inconspicuous method CreateFullCopy in Buffer, which PeekData calls. > To summarize, I have been toying with the idea of marking PeekData > deprecated and adding new API based on copy semantics (rather than peek > semantics) to replace its functionality. In this case, this would first > require that you change the ErrorModel base class API to make the > Corrupt method return a new corrupted packet rather than corrupt the > input packet in-place. Hmm, that would require an additional memory allocation and copy though, right? I might try out how much of a performance impact that creates, because it will be done to every packet in the simulation. Best regards, Florian -- Florian Schmidt, Ph.D. Student Distributed Systems Group Chair for Computer Science IV, RWTH Aachen, Germany http://ds.cs.rwth-aachen.de/members/schmidt From mathieu.lacage at sophia.inria.fr Wed Nov 18 04:53:36 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 13:53:36 +0100 Subject: [Ns-developers] Python bindings failure In-Reply-To: References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> <1258546286.27438.12.camel@diese.inria.fr> <1258547108.27438.15.camel@diese.inria.fr> Message-ID: <1258548816.27438.23.camel@diese.inria.fr> On Wed, 2009-11-18 at 12:48 +0000, Gustavo Carneiro wrote: > > I had already updated the required gccxml version in the wiki page, > see: > http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings#The_semi-automatic_way > > I had started to use that gccxml snapshot from september, with > pygccxml 1.0, and updated the wiki page, but I guess I forgot to > notify the ns-developers list. Sorry about that. > > No, we cannot stick to old versions. Newer pygccxml does not work > well with old gccxml, we have to move forward or we stagnate and Ok, that might explain some crazy warnings/errors I get on some systems I use. > die. I have today updated to gccxml HEAD and it works fine, apart > from that bug I reported. I don't like constantly using bleeding > edge (you know well how I like things stable), but I think about once > a year is reasonable to request that people upgrade their tools, don't > you think? Ok, fair enough for me. However, it would be nice to add a temporary hack to nstime.h if we can to make it easier for developers to rescan the bindings when needed and remove the hack once the fix is merged in gccxml. Mathieu From mathieu.lacage at sophia.inria.fr Wed Nov 18 05:07:01 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 14:07:01 +0100 Subject: [Ns-developers] Packet data replacement In-Reply-To: References: <1258530293.22863.15.camel@diese.inria.fr> Message-ID: <1258549621.27438.36.camel@diese.inria.fr> On Wed, 2009-11-18 at 13:48 +0100, Florian Schmidt wrote: > > You can already do this by calling Packet::PeekData () which will > > transparently "inflate" the zero area to real memory. > > Ah, I missed the inconspicuous method CreateFullCopy in Buffer, which PeekData calls. Yes, that method is the root of all evil. I spent so much time making sure that it is bug-free that it got annoying :/ > > To summarize, I have been toying with the idea of marking PeekData > > deprecated and adding new API based on copy semantics (rather than peek > > semantics) to replace its functionality. In this case, this would first > > require that you change the ErrorModel base class API to make the > > Corrupt method return a new corrupted packet rather than corrupt the > > input packet in-place. > > Hmm, that would require an additional memory allocation and copy > though, right? I might try out how much of a performance impact that > creates, because it will be done to every packet in the simulation. Theoretically, yes, but, the truth is that if you create a zero-filled-payload packet and then call PeekData, you trigger a memory re-allocation/memcpy deep within Buffer::CreateFullCopy so, if we force you to call CopyData, we are merely forcing you to make the hidden memory allocation/memcpy explicit. Now, I assume that you want to do something like this: packet->CopyData (m_temporaryErrorBuffer, packet->GetSize ()); ApplyBitErrorsInBuffer (m_temporaryErrorBuffer, packet->GetSize ()); p = Create (m_temporaryErrorBuffer, packet->GetSize ()); which is one extra memcpy (the one in Create ()) compared to the raw PeekData version. This is not really optimal, I agree. If the extra memcpy really is an issue for you performance-wise, I suspect that we could come up with a special Packet::Copy method which takes some kind of callback invoked once per copied byte to corrupt it in the copy: Ptr Packet::CopyWithFilter (uint8_t (*filter) (uint8_t byte, void *context), void *context); where the filter callback takes as argument a uncorrupted byte and returns a corrupted byte. I am not sure that would be much more efficient though so, we would need some kind of benchmark showing this being needed :) Mathieu From Florian.Schmidt at cs.rwth-aachen.de Wed Nov 18 05:35:24 2009 From: Florian.Schmidt at cs.rwth-aachen.de (Florian Schmidt) Date: Wed, 18 Nov 2009 14:35:24 +0100 Subject: [Ns-developers] Packet data replacement In-Reply-To: <1258549621.27438.36.camel@diese.inria.fr> References: <1258530293.22863.15.camel@diese.inria.fr> <1258549621.27438.36.camel@diese.inria.fr> Message-ID: <6B739DA4-67EC-4DB8-938D-AE13BEAEDFAA@cs.rwth-aachen.de> On Nov 18, 2009, at 2:07 PM, Mathieu Lacage wrote: > Theoretically, yes, but, the truth is that if you create a > zero-filled-payload packet and then call PeekData, you trigger a memory > re-allocation/memcpy deep within Buffer::CreateFullCopy so, if we force > you to call CopyData, we are merely forcing you to make the hidden > memory allocation/memcpy explicit. Ah, yes, I got that. This is not my point. This one is though: > Now, I assume that you want to do something like this: > > packet->CopyData (m_temporaryErrorBuffer, packet->GetSize ()); > ApplyBitErrorsInBuffer (m_temporaryErrorBuffer, packet->GetSize ()); > p = Create (m_temporaryErrorBuffer, packet->GetSize ()); > > which is one extra memcpy (the one in Create ()) compared to the > raw PeekData version. This is not really optimal, I agree. I can live with it, and I'm not too worried about performance right now. I was just talking from the view point of someone doing a large simulation with an error model. In the buffer implementation, for example, so much work went into making it very efficient, that it just feels like a shame if we made the simulator do an additional copy of each and every packet as soon as somebody applies an error model (any error model, really, if we changed ErrorModel itself). Now, I admit I don't have a great solution for that problem either right now. My first idea was a method Packet::ReplaceData that would take a uint8_t* that contained the altered packet data and overwrite the original data with it. But it doesn't feel very clean either. Also, it would still be a memcpy, though save the memory allocation and creation of a new Packet. The main advantage of that solution would be that whatever possible tags are in the original packet would be kept. I don't think your solution keeps them? Not that I use them myself right now, but it would feel weird if your'd just lose your tags that way. Florian From mathieu.lacage at sophia.inria.fr Wed Nov 18 05:59:04 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 14:59:04 +0100 Subject: [Ns-developers] Packet data replacement In-Reply-To: <6B739DA4-67EC-4DB8-938D-AE13BEAEDFAA@cs.rwth-aachen.de> References: <1258530293.22863.15.camel@diese.inria.fr> <1258549621.27438.36.camel@diese.inria.fr> <6B739DA4-67EC-4DB8-938D-AE13BEAEDFAA@cs.rwth-aachen.de> Message-ID: <1258552744.27438.49.camel@diese.inria.fr> On Wed, 2009-11-18 at 14:35 +0100, Florian Schmidt wrote: > right now. I was just talking from the view point of someone doing a > large simulation with an error model. In the buffer implementation, > for example, so much work went into making it very efficient, that it > just feels like a shame if we made the simulator do an additional copy > of each and every packet as soon as somebody applies an error model > (any error model, really, if we changed ErrorModel itself). Taking a step back, I have to confess that I am not sure what you expect an error model which corrupts the content of a packet to really do: 1) if you really corrupts the bits inside the packet, the ns-3 models are likely to stop working because most (all?) of them were written with the assumption that this (bit corruption) does not happen so, they will read corrupted headers and will fail to work, or worse. 2) What the ErrorModel class was designed to model is the ability of a checksum to detect that a packet is corrupted: it just looks at the packet and decides whether or not your MAC-level checksum detected an error without having to calculate a checksum. (Maybe the doxygen for the ErrorModel class is misleading) So, I have to ask now: what exactly are you trying to do ? i.e., what is the bigger picture, and how do you want to use your ErrorModel ? > Now, I admit I don't have a great solution for that problem either > right now. My first idea was a method Packet::ReplaceData that would > take a uint8_t* that contained the altered packet data and overwrite > the original data with it. But it doesn't feel very clean either. > Also, it would still be a memcpy, though save the memory allocation > and creation of a new Packet. The main advantage of that solution > would be that whatever possible tags are in the original packet would > be kept. I don't think your solution keeps them? Not that I use them my second solution would keep them. > myself right now, but it would feel weird if your'd just lose your > tags that way. yes. Mathieu From Florian.Schmidt at cs.rwth-aachen.de Wed Nov 18 06:30:48 2009 From: Florian.Schmidt at cs.rwth-aachen.de (Florian Schmidt) Date: Wed, 18 Nov 2009 15:30:48 +0100 Subject: [Ns-developers] Packet data replacement In-Reply-To: <1258552744.27438.49.camel@diese.inria.fr> References: <1258530293.22863.15.camel@diese.inria.fr> <1258549621.27438.36.camel@diese.inria.fr> <6B739DA4-67EC-4DB8-938D-AE13BEAEDFAA@cs.rwth-aachen.de> <1258552744.27438.49.camel@diese.inria.fr> Message-ID: <07911C37-B086-456A-8F38-9C7149A815E6@cs.rwth-aachen.de> On Nov 18, 2009, at 2:59 PM, Mathieu Lacage wrote: > Taking a step back, I have to confess that I am not sure what you expect > an error model which corrupts the content of a packet to really do: > > 1) if you really corrupts the bits inside the packet, the ns-3 models > are likely to stop working because most (all?) of them were written with > the assumption that this (bit corruption) does not happen so, they will > read corrupted headers and will fail to work, or worse. Actually, I did exactly that, and I already ran into a couple of the problems you mentioned. :) However, it is not too bad in the end, I tweaked a couple of the internet stack Classes, and it's running fine now. I want to create some own models looking into the effect of actual corruption, potential repair techniques, etc, potentially connecting it to a different in-house simulation environment at some point. > 2) What the ErrorModel class was designed to model is the ability of a > checksum to detect that a packet is corrupted: it just looks at the > packet and decides whether or not your MAC-level checksum detected an > error without having to calculate a checksum. (Maybe the doxygen for the > ErrorModel class is misleading) Yeah, that might very well be. I mean, the standard way I've known such error models to work in other simulators are exactly like that: set a flag that marks a packets as "containing errors" when the modeling has decided there should be an error in the packet. So I was pleasantly surprised when I saw the doxygen mentioning that an error model could potentially alter the actual packet data. However, I think it fits very well with the ns3 approach of representing packets as actual data buffers, and not abstract structures (even if that might have been done mostly for easier integration with network emulation?). Of course, implementing such an error model comes with other issues, such as the ones you mentioned above. >> and creation of a new Packet. The main advantage of that solution >> would be that whatever possible tags are in the original packet would >> be kept. I don't think your solution keeps them? Not that I use them > > my second solution would keep them. Ah right. I didn't really comment too much on that because it seemed to me you weren't very happy with that approach. Florian -- Florian Schmidt, Ph.D. Student Distributed Systems Group Chair for Computer Science IV, RWTH Aachen, Germany http://ds.cs.rwth-aachen.de/members/schmidt From tomh at tomh.org Wed Nov 18 06:41:48 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 18 Nov 2009 06:41:48 -0800 Subject: [Ns-developers] Bug #622, fiendly names for pcap files In-Reply-To: <4B03D792.4070105@sophia.inria.fr> References: <4B02C3E6.9070609@sophia.inria.fr> <018001ca67b8$d1378300$73a68900$@washington.edu> <4B03D792.4070105@sophia.inria.fr> Message-ID: <4B0407AC.8020004@tomh.org> Faker Moatamri wrote: > craigdo at ee.washington.edu wrote: >> -1 >> >> I have a problem with it since it only works on csma and point-to-point, >> adds the same code in two places (making the current code duplication >> problem worse since it should really go in 6 places to be consistent, I >> think) and mow makes these two devices behave differently than the others >> that use pcap. >> >> It's simple, but has problems. I have an enhancement in progress ... >> >> > Please take a look also at the bug 683 > (http://www.nsnam.org/bugzilla/show_bug.cgi?id=683) which proposes to > have an explicit name instead of a somehow generated name. This might be > useful for some users who would need a specific file name for their pcap > file. Those two patches change the same places in the code and we need > to decide which one we will keep or if we merge the two patches > (allowing the user to have explicit file names and friendly file names). > What do you guys think? (responding for Craig) Craig is working both of these bugs jointly, as you suggest. - Tom From mathieu.lacage at sophia.inria.fr Wed Nov 18 06:42:17 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 15:42:17 +0100 Subject: [Ns-developers] Packet data replacement In-Reply-To: <07911C37-B086-456A-8F38-9C7149A815E6@cs.rwth-aachen.de> References: <1258530293.22863.15.camel@diese.inria.fr> <1258549621.27438.36.camel@diese.inria.fr> <6B739DA4-67EC-4DB8-938D-AE13BEAEDFAA@cs.rwth-aachen.de> <1258552744.27438.49.camel@diese.inria.fr> <07911C37-B086-456A-8F38-9C7149A815E6@cs.rwth-aachen.de> Message-ID: <1258555337.27438.56.camel@diese.inria.fr> On Wed, 2009-11-18 at 15:30 +0100, Florian Schmidt wrote: > > Taking a step back, I have to confess that I am not sure what you > expect > > an error model which corrupts the content of a packet to really do: > > > > 1) if you really corrupts the bits inside the packet, the ns-3 > models > > are likely to stop working because most (all?) of them were written > with > > the assumption that this (bit corruption) does not happen so, they > will > > read corrupted headers and will fail to work, or worse. > > Actually, I did exactly that, and I already ran into a couple of the > problems you mentioned. :) However, it is not too bad in the end, I > tweaked a couple of the internet stack Classes, and it's running fine > now. I want to create some own models looking into the effect of > actual corruption, potential repair techniques, etc, potentially > connecting it to a different in-house simulation environment at some > point. uh, that is pretty scary :) > > > 2) What the ErrorModel class was designed to model is the ability of > a > > checksum to detect that a packet is corrupted: it just looks at the > > packet and decides whether or not your MAC-level checksum detected > an > > error without having to calculate a checksum. (Maybe the doxygen for > the > > ErrorModel class is misleading) > > Yeah, that might very well be. I mean, the standard way I've known > such error models to work in other simulators are exactly like that: > set a flag that marks a packets as "containing errors" when the > modeling has decided there should be an error in the packet. So I was > pleasantly surprised when I saw the doxygen mentioning that an error > model could potentially alter the actual packet data. However, I think > it fits very well with the ns3 approach of representing packets as > actual data buffers, and not abstract structures (even if that might > have been done mostly for easier integration with network emulation?). yes. > Of course, implementing such an error model comes with other issues, > such as the ones you mentioned above. ok. > >> and creation of a new Packet. The main advantage of that solution > >> would be that whatever possible tags are in the original packet > would > >> be kept. I don't think your solution keeps them? Not that I use > them > > > > my second solution would keep them. > > Ah right. I didn't really comment too much on that because it seemed > to me you weren't very happy with that approach. Yes, I am not too happy with it but I don't see any really cleaner approach: you want to play with my bytes but I don't want to let you get too close to them. Mathieu From faker.moatamri at sophia.inria.fr Wed Nov 18 07:11:14 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 18 Nov 2009 16:11:14 +0100 Subject: [Ns-developers] Python bindings failure In-Reply-To: <1258548816.27438.23.camel@diese.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> <1258546286.27438.12.camel@diese.inria.fr> <1258547108.27438.15.camel@diese.inria.fr> <1258548816.27438.23.camel@diese.inria.fr> Message-ID: <4B040E92.2090300@sophia.inria.fr> Mathieu Lacage wrote: > On Wed, 2009-11-18 at 12:48 +0000, Gustavo Carneiro wrote: > > >> I had already updated the required gccxml version in the wiki page, >> see: >> http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings#The_semi-automatic_way >> >> I had started to use that gccxml snapshot from september, with >> pygccxml 1.0, and updated the wiki page, but I guess I forgot to >> notify the ns-developers list. Sorry about that. >> >> No, we cannot stick to old versions. Newer pygccxml does not work >> well with old gccxml, we have to move forward or we stagnate and >> > > Ok, that might explain some crazy warnings/errors I get on some systems > I use. > > >> die. I have today updated to gccxml HEAD and it works fine, apart >> from that bug I reported. I don't like constantly using bleeding >> edge (you know well how I like things stable), but I think about once >> a year is reasonable to request that people upgrade their tools, don't >> you think? >> > > Ok, fair enough for me. However, it would be nice to add a temporary > hack to nstime.h if we can to make it easier for developers to rescan > the bindings when needed and remove the hack once the fix is merged in > gccxml. > > Mathieu > > > I re-enabled python bindings in buildbot automatic builder. Faker From tomh at tomh.org Wed Nov 18 07:24:35 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 18 Nov 2009 07:24:35 -0800 Subject: [Ns-developers] NS-3.7 new feature merge period expired In-Reply-To: <4B03D645.3080508@sophia.inria.fr> References: <4B03D645.3080508@sophia.inria.fr> Message-ID: <4B0411B3.9000005@tomh.org> Faker Moatamri wrote: > Hi all, > As of today, Wednesday November 18^th , the new feature merge period is > finished and the small feature development and bug fixing started. > During this period you can: > > * Submit limited, small, self contained changes/features to ns-3-dev > and to merged new features. As specified before, no more new > feature merges are accepted Can you please comment on whether the patch that Antti is working on for bug 742 (implementation of SO_BINDTODEVICE), and bug 671 (RecvIfIndex) are acceptable to you as small features (and other things like this)? > * Submit code for review, this is very useful as this will make it > easier to merge your code early in the next release > * Cleanup the ns-3-dev bug tracker, solve as much bugs as possible How would you like bug marking/prioritizing to work for the next phase? We have a number of bugs that are just in the tracker as default P5 but we could try to assign them as P1/P2 and Blocker/Critical-- do you want to do this or should the maintainers take a pass through them? As new bugs come in, should we receive an ack from you before we mark P1/Blockers? Ongoing, do you want us to update the ns-3.7 wiki page on "Bugs for 3.7" or do you want to use the tracker for this only? - Tom From jens.mittag at kit.edu Wed Nov 18 07:47:55 2009 From: jens.mittag at kit.edu (Jens Mittag) Date: Wed, 18 Nov 2009 16:47:55 +0100 Subject: [Ns-developers] Clarification regarding DCF Manager needed Message-ID: <4B04172B.2050008@kit.edu> Hi! I am working on a CCA implementation for Wifi and would like to make sure that I understand the DCF manager implementation correctly: When I call the following functions NotifyTxStartNow (Time duration); NotifyMaybeCcaBusyStartNow (Time duration); with the usage of 2 different values for the duration parameter, e.g. I would call NotifyTxStartNow (2secs); at time t = 1secs and NotifyMaybeCcaBusyStartNow (2secs); at time t = 2secs Does the DCF manager resolve the overlap internally automatically? From how I understand the code, I would say yes... Thanks for the clarification Jens -- Dipl.-Inform. Jens Mittag Karlsruhe Institute of Technology (KIT) Institute of Telematics Decentralized Systems and Network Services Research Group Engesserstr. 2, 76131 Karlsruhe, Germany Building 20.50, Room 112 Phone: +49 (721) 608 5768 Fax: +49 (721) 608 6789 http://dsn.tm.uni-karlsruhe.de/ From faker.moatamri at sophia.inria.fr Wed Nov 18 09:09:28 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 18 Nov 2009 18:09:28 +0100 Subject: [Ns-developers] Test regression Message-ID: <4B042A48.5090009@sophia.inria.fr> Hi Tom & all, Test pavel's patch: Revision 5534: updated traces to make them work Revision 5738: got 3 errors after Pavel's patch(test-csma-broadcast, test-csma-ping, test-simple-point-to-point-olsr) Revision 5740: No errors (after Pavel fixes) Revision 5744: using bisect we determine that it's this revision that is causing the problem, Sebastian's fix (test-dynamic-global-routing, test-global-routing-slash32, test-simple-error-model, test-simple-global-routing, test-simple-point-to-point-olsr, test-static-routing-slash32, test-tcp-large-transfer) Test Sebastian's patch: Revision 5502: update reference traces to make this works Revision 5503: doesn't work of course:(test-dynamic-global-routing, test-global-routing-slash32, test-simple-error-model, test-simple-global-routing, test-simple-point-to-point-olsr, test-static-routing-slash32, test-tcp-large-transfer) Revision 5740: failed (test-csma-broadcast, test-csma-ping, test-dynamic-global-routing, test-global-routing-slash32, test-simple-error-model, test-simple-global-routing, test-simple-point-to-point-olsr, test-static-routing-slash32, test-tcp-large-transfer) Revision 5744: failed (test-csma-broadcast, test-csma-ping, test-simple-point-to-point-olsr) Revision 5754: failed (test-csma-broadcast, test-csma-ping, test-simple-point-to-point-olsr) It looks like it is because of Sebastian's patchs or someone else's patch, assuming that pavel's regression failure is fixed in 5740. Hope this helps Best regards Faker Moatamri From Amine.Ismail at sophia.inria.fr Wed Nov 18 09:14:16 2009 From: Amine.Ismail at sophia.inria.fr (Ismail Amine) Date: Wed, 18 Nov 2009 18:14:16 +0100 Subject: [Ns-developers] WiMAX merge In-Reply-To: <4AEFCAF9.5030307@tomh.org> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <4AE57F14.4020205@clarinet.u-strasbg.fr> <4AEFCAF9.5030307@tomh.org> Message-ID: <4B042B68.7080607@sophia.inria.fr> Hi Tom and All, I have pushed a new version of the wimax module to http://code.nsnam.org/iamine/ns-3-wimax-release/. This new version provides: 1) 4 test suites for wimax - ns3-wimax-qos including 3 test cases - wimax-phy-layer including 2 test cases - wimax-bs-mac-layer including 2 test cases - wimax-ss-mac-layer including 5 test cases 2) Adding more attributes to the following classes: - wimax-ss-net-device: 17 Attributes - wimax-bs-net-device: 13 Attributes - simple-ofdm-wimax-phy: 7 Attributes 3) Aligning trace sources of wimax-ss-net-device, wimax-bs-net-device and wimax-phy with trace sources of the wifi module The module has been merged with the latest ns-3-dev version (changeset 5754) and has been successfully compiled under g++4.2.4, 4.3.3 and 4.4.0 in both debug and optimized mode. The examples I have developed have been successfully executed with valgrind which reports 0 error. I would like to ask you kindly to review this module. Thank you Regards Amine From mathieu.lacage at sophia.inria.fr Wed Nov 18 10:01:05 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 18 Nov 2009 19:01:05 +0100 Subject: [Ns-developers] Clarification regarding DCF Manager needed In-Reply-To: <4B04172B.2050008@kit.edu> References: <4B04172B.2050008@kit.edu> Message-ID: <1258567265.2481.31.camel@localhost.localdomain> On Wed, 2009-11-18 at 16:47 +0100, Jens Mittag wrote: > Does the DCF manager resolve the overlap internally automatically? From > how I understand the code, I would say yes... Theoretically, yes, but no one can be sure there are no bugs. The relevant piece of code is, I believe, the following from DcfManager::GetAccessGrantStart Time accessGrantedStart = MostRecent (rxAccessStart, busyAccessStart, txAccessStart, navAccessStart, ackTimeoutAccessStart, ctsTimeoutAccessStart, switchingAccessStart ); Mathieu From tomh at tomh.org Wed Nov 18 23:54:53 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 18 Nov 2009 23:54:53 -0800 Subject: [Ns-developers] Test regression In-Reply-To: <4B042A48.5090009@sophia.inria.fr> References: <4B042A48.5090009@sophia.inria.fr> Message-ID: <4B04F9CD.2070207@tomh.org> Faker, I went through the traces tonight to compare against ns-3.6 traces. These tests were failing: 1) test-csma-broadcast 2) test-csma-ping 3) test-dynamic-global-routing 4) test-global-routing-slash32 5) test-simple-error-model 6) test-simple-global-routing 7) test-simple-point-to-point-olsr 8) test-static-routing-slash32 9) tcp-large-transfer Sebastien made an ascii trace format change for PPP (from hex to decimal) and then reverted it. Since on Sunday night, I aligned ns-3-dev-ref-traces with Sebastien's intermediate ascii format, these traces had to be reverted. Only the ascii traces of these files changed. With this checkin, I double checked each one that they have not changed since ns-3.6 version. 3) test-dynamic-global-routing 4) test-global-routing-slash32 5) test-simple-error-model 6) test-simple-global-routing 8) test-static-routing-slash32 9) tcp-large-transfer The above reverts were committed in one changeset to ns-3-dev-ref-traces (rev 94) The remaining traces are expected to have changed since ns-3.6, due to Pavel's changes: 2) test-csma-ping These have changed due to ping application changes: - default length of ping changed - pings now repeat after every interval seconds I fixed this with rev 95 in ns-3-dev-ref-traces 1) test-csma-broadcast 7) test-simple-point-to-point-olsr The two fields that have changed in these traces are the TTL of broadcast messages (from 1 to 64) and the IP ID. The IP ID field changed due to the AODV checkin due to this change in UDP: --- a/src/internet-stack/udp-socket-impl.cc +++ b/src/internet-stack/udp-socket-impl.cc @@ -373,6 +373,8 @@ // Get the primary address Ipv4InterfaceAddress iaddr = ipv4->GetAddress (i, 0); Ipv4Address addri = iaddr.GetLocal (); + if (addri == Ipv4Address ("127.0.0.1")) + continue; Ipv4Mask maski = iaddr.GetMask (); if (maski == Ipv4Mask::GetOnes ()) which suppresses broadcast to loopback. I fixed this with ref 96 in ns-3-dev-ref-traces From faker.moatamri at sophia.inria.fr Thu Nov 19 01:49:28 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 19 Nov 2009 10:49:28 +0100 Subject: [Ns-developers] NS-3.7 new feature merge period expired In-Reply-To: <4B0411B3.9000005@tomh.org> References: <4B03D645.3080508@sophia.inria.fr> <4B0411B3.9000005@tomh.org> Message-ID: <4B0514A8.5030909@sophia.inria.fr> Tom Henderson wrote: > Faker Moatamri wrote: >> Hi all, >> As of today, Wednesday November 18^th , the new feature merge period >> is finished and the small feature development and bug fixing started. >> During this period you can: >> >> * Submit limited, small, self contained changes/features to ns-3-dev >> and to merged new features. As specified before, no more new >> feature merges are accepted > > Can you please comment on whether the patch that Antti is working on > for bug 742 (implementation of SO_BINDTODEVICE), and bug 671 > (RecvIfIndex) are acceptable to you as small features (and other > things like this)? > Yes, they are acceptable as small features. >> * Submit code for review, this is very useful as this will make it >> easier to merge your code early in the next release >> * Cleanup the ns-3-dev bug tracker, solve as much bugs as possible > > How would you like bug marking/prioritizing to work for the next > phase? We have a number of bugs that are just in the tracker as > default P5 but we could try to assign them as P1/P2 and > Blocker/Critical-- do you want to do this or should the maintainers > take a pass through them? As new bugs come in, should we receive an > ack from you before we mark P1/Blockers? It would be very helpful if the maintainers take a pass on the bugs and assign priorities and notify me if a bug is marked P1/Blocker and why he did that so that I can keep track of critical bugs. My bug policy now is to solve as many bugs as we can, starting with the most critical but not forgetting bugs who are in the bug tracker since 2007 and bugs with patches waiting to be reviewed. We have nearly two months for that and I think we can do it. > > Ongoing, do you want us to update the ns-3.7 wiki page on "Bugs for > 3.7" or do you want to use the tracker for this only? > I think keeping track of the bug on the wiki page might be of interest to have an overview of the release status. > - Tom From boyko at iitp.ru Thu Nov 19 02:42:38 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Thu, 19 Nov 2009 13:42:38 +0300 Subject: [Ns-developers] GetObject in DoStart Message-ID: <200911191342.38245.boyko@iitp.ru> Hi, I encounter a problem using DoStart () to find companion objects aggregated to the same node via GetObject () method. Attached start-get.cc program illustrates this. It's expected output is A::DoStart () B::DoStart () which means that both aggregated objects are started. Instead of this I have A::DoStart () A::DoStart () which means that object a is started two times and object b is never stared. The behavior returns to normal if GetObject() call is commented (try this). Am I wrong in using DoStart() and/or GetObject() or this is an Object's bug? Best regards, Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: start-get.cc Type: text/x-c++src Size: 1119 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091119/379d8ce3/start-get.bin From gjcarneiro at gmail.com Thu Nov 19 03:20:40 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 19 Nov 2009 11:20:40 +0000 Subject: [Ns-developers] Python bindings failure In-Reply-To: <1258548816.27438.23.camel@diese.inria.fr> References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> <1258546286.27438.12.camel@diese.inria.fr> <1258547108.27438.15.camel@diese.inria.fr> <1258548816.27438.23.camel@diese.inria.fr> Message-ID: 2009/11/18 Mathieu Lacage > On Wed, 2009-11-18 at 12:48 +0000, Gustavo Carneiro wrote: > > > > > I had already updated the required gccxml version in the wiki page, > > see: > > > http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings#The_semi-automatic_way > > > > I had started to use that gccxml snapshot from september, with > > pygccxml 1.0, and updated the wiki page, but I guess I forgot to > > notify the ns-developers list. Sorry about that. > > > > No, we cannot stick to old versions. Newer pygccxml does not work > > well with old gccxml, we have to move forward or we stagnate and > > Ok, that might explain some crazy warnings/errors I get on some systems > I use. > > > die. I have today updated to gccxml HEAD and it works fine, apart > > from that bug I reported. I don't like constantly using bleeding > > edge (you know well how I like things stable), but I think about once > > a year is reasonable to request that people upgrade their tools, don't > > you think? > > Ok, fair enough for me. However, it would be nice to add a temporary > hack to nstime.h if we can to make it easier for developers to rescan > the bindings when needed and remove the hack once the fix is merged in > gccxml. > > Done. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mathieu.lacage at sophia.inria.fr Thu Nov 19 03:23:57 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 19 Nov 2009 12:23:57 +0100 Subject: [Ns-developers] Python bindings failure In-Reply-To: References: <4AFD76CA.3050009@sophia.inria.fr> <1258372059.31976.6.camel@diese.inria.fr> <4B016E35.3040604@sophia.inria.fr> <1258546286.27438.12.camel@diese.inria.fr> <1258547108.27438.15.camel@diese.inria.fr> <1258548816.27438.23.camel@diese.inria.fr> Message-ID: <1258629837.2934.2.camel@diese.inria.fr> On Thu, 2009-11-19 at 11:20 +0000, Gustavo Carneiro wrote: > > Ok, fair enough for me. However, it would be nice to add a > temporary > hack to nstime.h if we can to make it easier for developers to > rescan > the bindings when needed and remove the hack once the fix is > merged in > gccxml. > > > Done. thanks a bunch ! Mathieu > From mathieu.lacage at sophia.inria.fr Thu Nov 19 03:28:28 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 19 Nov 2009 12:28:28 +0100 Subject: [Ns-developers] GetObject in DoStart In-Reply-To: <200911191342.38245.boyko@iitp.ru> References: <200911191342.38245.boyko@iitp.ru> Message-ID: <1258630108.2934.3.camel@diese.inria.fr> On Thu, 2009-11-19 at 13:42 +0300, Pavel Boyko wrote: > Am I wrong in using DoStart() and/or GetObject() or this is an Object's bug? This is a bug in Object. I will try to fix it asap. thanks for this helpful testcase, Mathieu From faker.moatamri at sophia.inria.fr Thu Nov 19 05:26:57 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 19 Nov 2009 14:26:57 +0100 Subject: [Ns-developers] Buildbot/Bazaar/PyBindgen Message-ID: <4B0547A1.30902@sophia.inria.fr> Hi all, Since PyBindgen is not working properly in buildbot I fixed some issues: - Updated the bazaar binary in Mingwin (bazaar is used to download PyBindgen) - Updated the bazaar binary in Mac OS ppc build slave - Changed the script in buildbot master to get the right version of pybingen - Changed the script in buildbot master to generate the version file in pybindgen using waf included in the pybindgen distribution Now updating pybindgen and generating the version should be ok. Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Thu Nov 19 06:58:32 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 19 Nov 2009 15:58:32 +0100 Subject: [Ns-developers] Bug #473 Message-ID: <4B055D18.4010804@sophia.inria.fr> Hi Tom & Francesco, I took a look at the bug #473 which deals with ns-2 mobility files. http://www.nsnam.org/bugzilla/show_bug.cgi?id=473 Mathieu said that we should have a mode variable which will check the manner in which we will interpret ns-2 mobility files. Francesco did you do anything about this? Does anyone of you have test files to test that this is actually working? Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Fri Nov 20 06:42:17 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 20 Nov 2009 15:42:17 +0100 Subject: [Ns-developers] Buildbots failures/Deprecated PeekData/AODV example test failing Message-ID: <4B06AAC9.4030406@sophia.inria.fr> Hi all, We have a buildbot errors for g++-3.4.6,4.0.4,4.1.2 under linux, for OSX-PPC g++-4.0 and for Mingw: [397/917] cxx: src\common\packet.cc -> build\debug\src\common\packet_1.o ..\src\common\packet.cc: In member function `virtual bool ns3::PacketTest::DoRun()': ..\src\common\packet.cc:929: warning: `PeekData' is deprecated (declared at ..\src\common\packet.cc:339) ..\src\common\packet.cc:1089: warning: `PeekData' is deprecated (declared at ..\src\common\packet.cc:339) This is simply a warning taken as an error. For Cygwin, there is a testing crash: ---------- begin standard err ---------- pure virtual method called terminate called without an active exception ---------- end standard err ---------- CRASH: Example routing/aodv Launch examples/stats/wifi-example-sim Synchronously execute /home/mathieu/buildslave/full-cygwin-g++/build/build/debug/examples/stats/wifi-example-sim Return code = 0 stderr = returncode = 0 It seems like there is a pure virtual method called??? =-O Any fixes/suggestions are welcome. Best regards Faker Moatamri From mathieu.lacage at sophia.inria.fr Fri Nov 20 06:58:29 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 20 Nov 2009 15:58:29 +0100 Subject: [Ns-developers] Buildbots failures/Deprecated PeekData/AODV example test failing In-Reply-To: <4B06AAC9.4030406@sophia.inria.fr> References: <4B06AAC9.4030406@sophia.inria.fr> Message-ID: <1258729109.4007.14.camel@diese.inria.fr> On Fri, 2009-11-20 at 15:42 +0100, Faker Moatamri wrote: > Hi all, > We have a buildbot errors for g++-3.4.6,4.0.4,4.1.2 under linux, for > OSX-PPC g++-4.0 and for Mingw: > > [397/917] cxx: src\common\packet.cc -> build\debug\src\common\packet_1.o > ..\src\common\packet.cc: In member function `virtual bool ns3::PacketTest::DoRun()': > > ..\src\common\packet.cc:929: warning: `PeekData' is deprecated (declared at ..\src\common\packet.cc:339) > > ..\src\common\packet.cc:1089: warning: `PeekData' is deprecated (declared at ..\src\common\packet.cc:339) I am waiting for the ipv6 stuff to be merged before fixing this. If it's a problem anyone can go ahead and remove the NS_DEPRECATED in packet.h From tomh at tomh.org Sun Nov 22 22:33:16 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 22 Nov 2009 22:33:16 -0800 Subject: [Ns-developers] Call for submissions: Workshop on ns-3 (March 2010) Message-ID: <4B0A2CAC.5040707@tomh.org> Workshop on ns-3, Call for Participation (CFP) ---------------------------------------------- The Workshop on ns-3 is a one day workshop held in conjunction with the Third International Conference on Simulation Tools and Techniques (SIMUTools 2010). The workshop will take place on March 15, 2010 in Torremolinos, Malaga, Spain. Workshop URL: http://www.wns3.org/ SIMUTools 2010 URL: http://www.simutools.org/ Purpose and scope -------- The purpose of the workshop is to provide a single-day event for ns-3 users and developers to get together and learn more about the simulator and related work. The workshop consists of a simulator overview, demonstrations, a poster session, and a session of talks organized around a particular theme. One theme for the workshop is "Frameworks for ns-3." One type of framework involves the combination of ns-3 with other tools, including simulators, testbeds or virtual machine-based emulators, to improve the ability to transition between the use of simulation and other experimental techniques. Another type of framework is completely simulation-based but includes tools to build around ns-3 to improve the overall simulation workflow, including automation, scenario development, validation, statistics, and data management. Contributors are free to suggest other types of frameworks. We are not soliciting full papers on ns-3 or its usage, opting instead for a workshop program that emphasizes more interaction and discussion. We are soliciting requests for brief talks, posters, or demonstrations. Participants to this portion of the workshop are requested to submit a short (single-page) abstract of the intended presentation, and we will accept as many as possible, with preference given to those that conform to the scope outlined below. Full papers are not being accepted and were previously directed to the SIMUTools main track. Posters, or brief introductions of talks accepted to the main SIMUTools track, are also welcome. Call for submissions -------------------- We would like to hear from the community what you are doing with ns-3, or what you would like to do with ns-3, regarding simulation frameworks. To that end, we plan for a flexible schedule that accommodates the interests of participants. We want this workshop to be less formal and more interactive than a typical workshop session. If you would like to participate by preparing or proposing either a short talk or a poster (we will provide space for all posters), please contact one of the organizers below prior to January 22, 2010, so that we may roughly plan the afternoon schedule. Short abstracts (100-200 words) are recommended. There will be no formal publication track for conference materials, but all materials contributed will be archived (with author's permission) on the web. Proposed Technical Program -------------------------- Morning session 1: ns-3 overview and demos Morning session 2: Short talks Afternoon session 1: Short talks Afternoon session 2: Poster session, and closing discussions Organizers ---------- Tom Henderson (Univ. of Washington) George Riley (Georgia Institute of Technology)