From mathieu.lacage at sophia.inria.fr Thu Oct 1 00:36:04 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 01 Oct 2009 09:36:04 +0200 Subject: [Ns-developers] Socket API Addition for TCP Bug fixes In-Reply-To: References: Message-ID: <1254382564.4367.24.camel@diese.inria.fr> hi george, The proposal below sounds fine but I am very nervous about adding new API in a core class such as Socket so late in the release cycle when there is no time to exercise the API and test it more broadly. Since we have been living with this bug for so long, I think that we could live with it a bit more for 2 or 3 more weeks and aim to fix it right after our next release, in the hope that we will have more time to shake any loose ends in the proposal. If I had a release manager hat on or if I was maintainer for the src/node/socket.h, I would have acked this a couple of weeks ago and I would probably nack this now, not on technical grounds, but purely on release management grounds. The following is really a generic comment not aimed at you or anyone in particular but I feel that this proposal is another example of our collective inability to merge new features/API early in our release cycles. I wonder if others share the same observation or if this is a figment of my naturally pessimistic imagination. A recurring event seems to be that new features are ignored early in the release cycle and everyone is rushing and pushing for new code just before the end of the release cycle. This leads to slippage in the release date (already twice in this cycle) and is making our job generally more painful than it should be by forcing us to work like madmen around the end of the cycle. More than this specific bug, I think that we need to address this more generic problem at some point. One solution could be to be really fascist about our release schedule and announce this early to make everyone aware that they can't get away with merging late. This means that every maintainer should take responsability for reviewing new features/patches timely. I don't know if this would fix the problem or if there is really a problem to be fixed but, well, I felt compelled to share my concerns publicly. Anyway, thanks a lot for taking time to look at this old nagging bug. Mathieu From mathieu.lacage at sophia.inria.fr Thu Oct 1 02:25:29 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 01 Oct 2009 11:25:29 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, September 30, 2009 In-Reply-To: <4AC44391.2030306@tomh.org> References: <10235E8E144B4CCA8EEF2BAECD7CF82D@CRAIGVAIO> <4AC44391.2030306@tomh.org> Message-ID: <1254389129.4367.67.camel@diese.inria.fr> On Wed, 2009-09-30 at 22:52 -0700, Tom Henderson wrote: > > 1.Bug 407 nor P1 Linu tomh at tomh.org NEW OLSR is missing HNA support > > Suggest to drop the above to P2-- it is a feature add. +1 for P2. > > > 4.Bug 555 nor P1 All ns-bugs at isi.edu NEW DCF immediate access bug > > The above has been hanging around for a while-- is it at a deadlock? I don't really know what to do about this bug. I see the bug, we have a testcase, but the proposed fix is making the code even more scary than it already is (makes a function have side-effects, overall confusion about function names: what does it mean to have a backoff expired ? how different is it from backoffslot == 0 ?). It's not clear if there is a better way to fix the bug. To summarize, I still strongly dislike the proposed fix: I can't make myself commit it. > > 6.Bug 612 nor P1 All ns-bugs at isi.edu NEW example scripts > > The above should not block a release, IMO. It probably could be easily > disposed of if there was agreement/support for adding some > subdirectories into examples directory. We need to make building examples optional: build times are getting out of hand for daily work. Gustavo: do you think you could propose a patch to do something like that ? > > > 8.Bug 645 nor P1 All ns-bugs at isi.edu NEW patch fixes for opening stats file > > with OMNeT++ > > I think you can assign the above to Joe, who has already responded in > the tracker. However, given that stats is in src/contrib, and that > there appears to need to be more work done to fix this formatting issue, > I would advocate bumping it to P2. +1 for P2. > > > 10.Bug 648 nor P1 All ns-bugs at isi.edu NEW Missing Doxygen for Several > > Helpers > > If we have the extra week, the above may be fixable. I will take it > once my other P1 bugs are done, if no one beats me to it. I have done 2, there are 2 left: tap-bridge-helper.h ipv4-static-routing-helper.h > > 15.Bug 669 nor P1 All ns-bugs at isi.edu NEW main-packet-printer broken > > I will take this, with the caveat that if we run out of time, this is > marked a WONTFIX and removed from the samples/ directory. It is a > sample that uses the old packet API, and has already been removed from > samples/wscript for some time. There is already good sample code to do this in src/common/packet.cc in the Packet::Print method so, I would suggest to kill samples/main-packet-printer.cc. Mathieu From mathieu.lacage at sophia.inria.fr Thu Oct 1 02:36:30 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 01 Oct 2009 11:36:30 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, September 30, 2009 In-Reply-To: <10235E8E144B4CCA8EEF2BAECD7CF82D@CRAIGVAIO> References: <10235E8E144B4CCA8EEF2BAECD7CF82D@CRAIGVAIO> Message-ID: <1254389790.4367.74.camel@diese.inria.fr> On Wed, 2009-09-30 at 21:51 -0700, craigdo at ee.washington.edu wrote: > We have not had a night where the nightly build and test cycle has completed > successfully in some time. This is bad, but it keeps looking more and more > promising. Hopefully the only casualty we will see tonight is from the > MinGW buildbot, and MinGW is not a supported platform. cygwin build crashes because of OOM error due to src/simulator/time.cc taking too much memory to compile. This is due to the test conversion: we could easily #if 0 the relevant test (fixing it correctly would take a couple of hours which I don't have right now). Anyone against #if 0 ? I don't know the status of the osx builds because the buildbot is dead there (last 3 days). I will try to bring it back from the dead later today. Finally, I am concerned about all the CRASH reported by ./test.py in the examples section. What are they due to ? Is anyone actually looking at this problem ? Mathieu From mazo at iitp.ru Thu Oct 1 02:05:30 2009 From: mazo at iitp.ru (Andrey Mazo) Date: Thu, 01 Oct 2009 13:05:30 +0400 Subject: [Ns-developers] Socket API Addition for TCP Bug fixes In-Reply-To: References: <1254382564.4367.24.camel@diese.inria.fr> Message-ID: > The following is really a generic comment not aimed at you or anyone in > particular but I feel that this proposal is another example of our > collective inability to merge new features/API early in our release > cycles. I wonder if others share the same observation or if this is a > figment of my naturally pessimistic imagination. > > A recurring event seems to be that new features are ignored early in the > release cycle and everyone is rushing and pushing for new code just > before the end of the release cycle. This leads to slippage in the > release date (already twice in this cycle) and is making our job > generally more painful than it should be by forcing us to work like > madmen around the end of the cycle. > > More than this specific bug, I think that we need to address this more > generic problem at some point. One solution could be to be really > fascist about our release schedule and announce this early to make > everyone aware that they can't get away with merging late. This means > that every maintainer should take responsability for reviewing new > features/patches timely. I don't know if this would fix the problem or > if there is really a problem to be fixed but, well, I felt compelled to > share my concerns publicly. Well, I think it's not easy to change people's deadline scheduler in their minds. Besides aggressively announcing release schedule, I propose to adapt the release schedule itself to changing needs if ns-3. As ns-3 is growing larger and larger attracting more contributions (and maintainers review work), I suppose, it's worth enlarging "Late merge period" and "Maintenance phase" to at least 2 and 3 weeks respectively. -- Andrey Mazo. From tomh at tomh.org Thu Oct 1 07:45:54 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 01 Oct 2009 08:45:54 -0600 Subject: [Ns-developers] Socket API Addition for TCP Bug fixes In-Reply-To: <1254382564.4367.24.camel@diese.inria.fr> References: <1254382564.4367.24.camel@diese.inria.fr> Message-ID: <7c659d6b038427500568e4a98740b8dd@tomh.org> On Thu, 01 Oct 2009 09:36:04 +0200, Mathieu Lacage wrote: > hi george, > > The proposal below sounds fine but I am very nervous about adding new > API in a core class such as Socket so late in the release cycle when > there is no time to exercise the API and test it more broadly. > > Since we have been living with this bug for so long, I think that we > could live with it a bit more for 2 or 3 more weeks and aim to fix it > right after our next release, in the hope that we will have more time to > shake any loose ends in the proposal. If I had a release manager hat on > or if I was maintainer for the src/node/socket.h, I would have acked > this a couple of weeks ago and I would probably nack this now, not on > technical grounds, but purely on release management grounds. I would like to see the API supported in NSC before we merge it. I haven't had any time yet to look at the implications. If we are at the revised code freeze date with no test experience or support in NSC, I agree that we should hold the API aspects to the next release (without holding back the other TCP close bug fixes). > > The following is really a generic comment not aimed at you or anyone in > particular but I feel that this proposal is another example of our > collective inability to merge new features/API early in our release > cycles. I wonder if others share the same observation or if this is a > figment of my naturally pessimistic imagination. > > A recurring event seems to be that new features are ignored early in the > release cycle and everyone is rushing and pushing for new code just > before the end of the release cycle. This leads to slippage in the > release date (already twice in this cycle) and is making our job > generally more painful than it should be by forcing us to work like > madmen around the end of the cycle. I think your comment applies to bug fixing as well. I agree with you that the "working like madmen" aspect is really painful. It is not clear how to completely cure this because it hinges on people's time and willingness to prioritize their maintenance activities, but one improvement (that we have discussed before but not implemented) would be to have a release manager in place from day one of the cycle and actively managing the bug list and feature adds. We have had several cases where we frantically try to fix something, back it off at the last hour, then the issue lies dormant until 1 week before the next code freeze. Craig has put up an ns-3.7 page [1]; we already have several models (AODV, WiMAX, Underwater Acoustic Device) queued for review. For things that slip off this release, they should be moved to the ns-3.7 page and finished before the end of November. We can try to do better in this regard for the next cycle. - Tom [1] http://www.nsnam.org/wiki/index.php/Ns-3.7 From mathieu.lacage at sophia.inria.fr Thu Oct 1 13:27:15 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 01 Oct 2009 13:27:15 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.4.0 Message-ID: <200910012027.n91KRFHY030352@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/177 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The web-page 'force build' button was pressed by 'craigdo': test.py Build Source Stamp: 9f457bebbcf4 Blamelist: BUILD FAILED: failed shell_6 shell_7 shell_11 shell_12 shell_15 shell_16 shell_17 sincerely, -The Buildbot From craigdo at ee.washington.edu Thu Oct 1 14:31:45 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 1 Oct 2009 14:31:45 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, September 30, 2009 In-Reply-To: <1254389790.4367.74.camel@diese.inria.fr> References: <10235E8E144B4CCA8EEF2BAECD7CF82D@CRAIGVAIO> <1254389790.4367.74.camel@diese.inria.fr> Message-ID: <00CDF1A2D3BB40CBAB4B8B858422FC8E@CRAIGVAIO> > Finally, I am concerned about all the CRASH reported by > ./test.py in the > examples section. What are they due to ? Is anyone actually looking at > this problem ? The failure seems to be a permissions issue. When test.py runs an example, it assumes that the trace files generated by the example will be uninteresting and arranges for the examples to write them in /tmp/unchecked-traces Test.py creates the directory and then tells the examples into that directory as the cwd. All of the crashes happen when an example tries to open a pcap file: file=../src/common/pcap-writer.cc, line=110, abort on="m_writer->fail ()", msg="PcapWriter::Open(): m_writer->open(csma-bridge-0-0.pcap) failed" I know absolutely nothing about the buildslave "rahanfrace" so I can't look to see what could be causing this. FYI, I removed the calls to "./waf --check" in the master.cfg since run-tests doesn't exist anymore. I also added a verbose option to wifi-ap since it was spewing bigabytes of trace information into standard out. It defaults to verbose, but test.py now calls it with "wifi-ap --verbose=0" -- Craig From mathieu.lacage at sophia.inria.fr Thu Oct 1 17:46:15 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 01 Oct 2009 17:46:15 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-3.4.6 Message-ID: <200910020046.n920kFYi031515@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/179 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_6 shell_10 shell_14 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Thu Oct 1 18:47:05 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 01 Oct 2009 18:47:05 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.0.4 Message-ID: <200910020147.n921l5sE031605@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/166 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_6 shell_10 shell_14 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Thu Oct 1 19:31:43 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 01 Oct 2009 19:31:43 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.1.2 Message-ID: <200910020231.n922Vh7J032581@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/187 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_6 shell_10 shell_14 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Thu Oct 1 20:03:31 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 01 Oct 2009 20:03:31 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.2.4 Message-ID: <200910020303.n9233VW8000537@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.2.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.2.4/builds/165 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_6 shell_10 shell_14 sincerely, -The Buildbot From craigdo at ee.washington.edu Thu Oct 1 23:31:35 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 1 Oct 2009 23:31:35 -0700 Subject: [Ns-developers] Setting Bug Priorities and Severities Message-ID: <7D3AE5288D6449938C492FF6494E6F26@CRAIGVAIO> Hi All, Tonight I found myself continuing in disbelief to watch bug 407 oscillate between P1 and P2. I think this may be the third or fourth release in which this has happened. I went back to review our criteria for assigning priorities and severities and all I can find are some list emails from around February, so I took it upon myself to write something up on the wiki: http://www.nsnam.org/wiki/index.php/User_FAQ#Bug_Priorities Please have a look and tell me what you think. Based on the interpretation in the wiki page above, I think bug 407, just as a convenient example, should be set to either a "P3 Enhancement" if someone is really blocked waiting for HNA support, or a "P4 Enhancement" if it's something we'd just like to add. I think 407 should stay P4 Enhancement (or P3) until someone comes up with a patch to submit for a release, at which time it gets merged like any other submission and the bug gets closed. If the maintainers decide that the lack of HNA support is something that is seriously affecting the usability of ns-3, it can be bumped to P1 Enhancement; but somebody has got to be assigned to actually work on it and be responsible for it. This oscillating bug situation seems to just dilute the meaning of P1. We do this way too much. Regards, -- Craig From craigdo at ee.washington.edu Fri Oct 2 00:47:23 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 2 Oct 2009 00:47:23 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 1, 2009 Message-ID: <2AFB84679E0A438D8EF5BA27028C0F59@CRAIGVAIO> Dear All, News and Comments: ================== The build and test situation continues to improve. The buildbots are much happier today than they have been in some time. One issue remains with the buildslave which manifests in the inability for examples to create trace files in /tmp/unchecked-traces. This results in an NS_ASSERT popping in any example that tries to create a trace file and this, in turn, is seen as a CRASH in the test.py output. Hopefully someone can convince Rahan to be a little less farouche and a little more civilis? :-) I wrote a little blurb on setting bug priorities and severities in the hope that it could help us make better sense of our bug list. You can find it in the User FAQ on the wiki, here: http://www.nsnam.org/wiki/index.php/User_FAQ#Bug_Priorities You may understand some of my comments below better if you read it. Thanks to everyone who pitched in to kill bug 675, the multiple test frameworks bug. That frees me up to go adopt some of the homeless bugs. Discussion: =========== Bug 407 nor P1 Linu tomh at tomh.org NEW OLSR is missing HNA support This has dropped back to P2 ... Again. I think this should go to "P4 Enhancement" instead of doing the priority oscillation it has been doing for almost a year now. ---------- Bug 555 nor P1 All ns-bugs at isi.edu NEW DCF immediate access bug Mathieu says, "I still strongly dislike the proposed fix: I can't make myself commit it." What are we going to do, Mathieu, if you cannot find a way out of this conundrum in the next six days? This could go to "P2 Critical" if we need some time to ponder it. ---------- Bug 612 nor P1 All ns-bugs at isi.edu NEW example scripts This bug is really about organization of the examples directory. As Tom has written, "[it] should not block a release" and "it probably could be easily disposed of if there was agreement/support for adding some subdirectories into examples directory." I agree that this isn't P1 material. I vote for making this bug something like "P3 Trivial" and fixing it if we have time. ---------- Bug 645 nor P1 All ns-bugs at isi.edu NEW patch fixes for opening stats file with OMNeT++ The consensus is that our buddy Joe Kopena should deal with this. I will assign it to you, Joe, unless I hear different by tomorrow. This also seems like an Enhancement to something in contrib, so I agree with Tom that this should be dropped in priority. According to my bug priorities scheme strawman, this should go to something like "P3 Enhancement." ---------- Bug 648 nor P1 All ns-bugs at isi.edu NEW Missing Doxygen for Several Helpers Tom is going to prioritize this after the rest of his bugs. If anyone has time to help him out, Tom is also swamped, so if you love writing Doxygen, this bug is for you. This seems like it could be a "P1 Trivial" bug to me since helpers are one place we really need good documentation. ---------- Bug 669 nor P1 All ns-bugs at isi.edu NEW main-packet-printer broken The consensus seems to be to remove this from the samples directory. It uses an old API and has not been built for some time and there is other working sample code to illustrate what is done. Bugs: ===== As of Thursday evening (PST), October 1, 2009, by my reckoning we have sixteen P1 bugs filed against ns-3-dev (I rechecked the wiki page against Bugzilla tonight). 1.Bug 424 nor P1 All riley at ece.gatech.edu NEW TCP FIN notification callback needed 2.Bug 426 nor P1 All riley at ece.gatech.edu NEW TCP: close does not send RST 3.Bug 555 nor P1 All ns-bugs at isi.edu NEW DCF immediate access bug 4.Bug 559 nor P1 All riley at ece.gatech.edu REOP TcpSocketImpl doesnt free endpoint quickly enough after being closed 5.Bug 612 nor P1 All craigdo at ee.washington.edu NEW example scripts 6.Bug 615 nor P1 All riley at ece.gatech.edu NEW TCP does not respond with RST to non-listening port 7.Bug 645 nor P1 All ns-bugs at isi.edu NEW patch fixes for opening stats file with OMNeT++ 8.Bug 647 nor P1 All riley at ece.gatech.edu NEW Ns-3 implementation of TCP fails to produce limited-queue CW sawtooth 9.Bug 648 nor P1 All craigdo at ee.washington.edu NEW Missing Doxygen for Several Helpers 10.Bug 663 nor P1 All riley at ece.gatech.edu NEW RST from remote TCP crashes ns-3 TCP 11.Bug 664 nor P1 All ns-bugs at isi.edu NEW memory fault/dangling pointer problems in tcp-socket-impl.cc, with suggested fixes 12.Bug 669 nor P1 All craigdo at ee.washington.edu NEW main-packet-printer broken 13.Bug 676 nor P1 All tomh at tomh.org NEW Align Ipv{4,6}L3Protocol Rx/Tx/Drop signatures 14.Bug 689 nor P1 All ns-bugs at isi.edu NEW default energy detection threshold is not useful 15.Bug 697 nor P1 All riley at ece.gatech.edu NEW TCP "Sent" callback reports wrong count 16.Bug 704 nor P1 All tomh at tomh.org NEW ns3-wifi-propagation-loss-models We also have four homeless bugs: 1.Bug 555 nor P1 All ns-bugs at isi.edu NEW DCF immediate access bug 2.Bug 645 nor P1 All ns-bugs at isi.edu NEW patch fixes for opening stats file with OMNeT++ 3.Bug 664 nor P1 All ns-bugs at isi.edu NEW memory fault/dangling pointer problems in tcp-socket-impl.cc, with suggested fixes 4.Bug 689 nor P1 All ns-bugs at isi.edu NEW default energy detection threshold is not useful Progress ======== Although it may not seem like it at times, we are making good progress. There is still a huge amount of work to do, but with the one week slip and all of the help we've received, I think we can make this happen. Next Steps: =========== Code freeze for ns-3.6 is currently planned for Wednesday, October 7, 2009. Comments, agreement and pushback always welcome (even though I might complain and moan for a while). Regards, -- Craig From faker.moatamri at sophia.inria.fr Fri Oct 2 02:37:12 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 02 Oct 2009 11:37:12 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 1, 2009 In-Reply-To: <2AFB84679E0A438D8EF5BA27028C0F59@CRAIGVAIO> References: <2AFB84679E0A438D8EF5BA27028C0F59@CRAIGVAIO> Message-ID: <4AC5C9C8.9080001@sophia.inria.fr> craigdo at ee.washington.edu wrote: > Dear All, > > News and Comments: > ================== > > The build and test situation continues to improve. The buildbots are much > happier today than they have been in some time. One issue remains with the > buildslave which manifests in the inability for examples to create trace > files in /tmp/unchecked-traces. This results in an NS_ASSERT popping in any > example that tries to create a trace file and this, in turn, is seen as a > CRASH in the test.py output. Hopefully someone can convince Rahan to be a > little less farouche and a little more civilis? :-) > Done, I changed access rights on this folder, now rahan is more civilis? :-) , all examples pass now but only ns3-wifi-propagation-loss-models fails. Best regards Faker From mathieu.lacage at sophia.inria.fr Fri Oct 2 04:30:49 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 02 Oct 2009 13:30:49 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 1, 2009 In-Reply-To: <2AFB84679E0A438D8EF5BA27028C0F59@CRAIGVAIO> References: <2AFB84679E0A438D8EF5BA27028C0F59@CRAIGVAIO> Message-ID: <1254483049.2505.1.camel@localhost.localdomain> On Fri, 2009-10-02 at 00:47 -0700, craigdo at ee.washington.edu wrote: > Bug 555 nor P1 All ns-bugs at isi.edu NEW DCF immediate access bug > > Mathieu says, "I still strongly dislike the proposed fix: I can't make > myself commit it." > > What are we going to do, Mathieu, if you cannot find a way out of this > conundrum in the next six days? This could go to "P2 Critical" if we need > some time to ponder it. > This means that I am not going to fix this bug for 3.6 and that I will have to try to figure out a solution within the 3.7 timeframe. Mathieu From tomh at tomh.org Fri Oct 2 10:35:23 2009 From: tomh at tomh.org (Tom Henderson) Date: Fri, 02 Oct 2009 11:35:23 -0600 Subject: [Ns-developers] OLSR HNA (was Re: ns-3.6 Daily Bug Status for Thursday, October 1, 2009) In-Reply-To: <2AFB84679E0A438D8EF5BA27028C0F59@CRAIGVAIO> References: <2AFB84679E0A438D8EF5BA27028C0F59@CRAIGVAIO> Message-ID: <7c1db93f6c84ec0b8ecd5463dcfeb38f@tomh.org> > > Discussion: > =========== > > Bug 407 nor P1 Linu tomh at tomh.org NEW OLSR is missing HNA support > > This has dropped back to P2 ... Again. I think this should go to "P4 > Enhancement" instead of doing the priority oscillation it has been doing > for > almost a year now. I agree to take this down from P2 to P4. I would like to see this support added but I haven't been able to find time to add it myself. So, maybe if someone interested in MANET wants to take a stab at it, I would be happy to help over the next release cycle. Tom From huynguyen531 at gmail.com Fri Oct 2 17:51:51 2009 From: huynguyen531 at gmail.com (Tommy Huy Nguyen) Date: Fri, 2 Oct 2009 20:51:51 -0400 Subject: [Ns-developers] Question about the Wireless Channel, Mac_802.11Ext, and PhyExt Message-ID: <789565320910021751l251aa8c9xa2aa0242766cfeb8@mail.gmail.com> Hi, I'm currently implementing a new protocol using your Physical and Mac802.11 extensions. I have a few technical questions relating would appreciate any kind of help. 1) There are two packets with two different sizes. The first packet being sent is a lot bigger than the second packet. Is it possible for the second packet to arrive at the designated node before the first packet? 2) Node A sends a big packet to Node B. Node B sends a small packet to Node A before Node A finish transmitting. Is it possible for Node B to send a packet to Node A, while Node A is still transmitting? If so, is it possible for Node A to receive Node B's small packet before finish transmitting the big packet? Thanks, Tommy From tomh at tomh.org Sun Oct 4 23:08:02 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 04 Oct 2009 23:08:02 -0700 Subject: [Ns-developers] 2009 Google Summer of Code (GSOC) wrapup Message-ID: <4AC98D42.1000803@tomh.org> We had a successful GSOC with all three of our students making nice contributions to ns-3. I would like to thank all of our students and mentors, and also Joe Kopena who served as Organizational Admin (OA) and helped a lot during the selection process. I also would like to recognize additional mentor volunteers who helped during the selection process (Nicola Baldo, Marcello Caleffi, and Florian Westphal); we simply did not have enough spots to take all of the students and mentors that we would have liked. Qasim Javed, mentored by Adrian Sai-wah Tam, has contributed Network Address Translation (NAT) for IPv4. NATs are an important model due to their pervasive deployment. To implement NAT, however, requires connection tracking state, and Qasim approached the problem by building a general framework patterned after Linux Netfilter that can be reused in the future for things such as firewall rulesets. He then implemented connection tracking (data structures for maintaining state about connections) and used the connection tracking API to implement NAT. At the end of the project, Qasim demonstrated NAT working within this framework. There remains some integration work before merging to ns-3-dev, but this code when merged will be a big step forward. Flavio Kubota, mentored by Juliana Freitag Borin, contributed an uplink scheduler for WiMAX. WiMAX is a model of great interest to network simulation, and Flavio was able to complete his primary goal of porting and validating the uplink scheduler from ns-2 model of the Computer Networks Laboratory at the Univeristy of Campinas. These extensions are necessary to model QoS provision on the uplink. Flavio followed through on the merging of his model to ns-3's WiMAX repository which is being prepared for our ns-3.7 release. Duy Nguyen, mentored by Ruben Merz, contributed a new rate control algorithm for 802.11. Called Minstrel, this rate control is based on a probing mechanism that seeks to gather statistics about different rates in the network and apply heuristics to determine the best observed rate. This approach has been shown to often outperform traditional rate controls that are based on estimating received signal strength, because signal strength is only one variable (among channel multipath and interference) that affects reception probability. Duy's implementation has already been merged to ns-3-dev, and I'm happy to see his continued active participation on our users' mailing list. All of our GSOC work has been archived on the wiki and at our organizational page here: http://socghop.appspot.com/org/home/google/gsoc2009/ns3 In summary, GSOC once again was a great experience for our project and hopefully for the individuals involved, and we are grateful to Google for selecting us again this year. - Tom From craigdo at ee.washington.edu Sun Oct 4 23:29:14 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Sun, 4 Oct 2009 23:29:14 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Sunday, October 4, 2009 Message-ID: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> Dear All, News and Comments: ================== The build and test situation continues to improve. Rahan has found himself more civilis? and now the buildbots are passing all of the examples. Tom has dealt with a crasher problem that was causing a couple of examples to fail and is now figuring out what to do about the "real" error in the Wifi propagation model tests. I haven't heard any wailing or gnashing of teeth so I have adopted the bug priority and severity scheme found here: http://www.nsnam.org/wiki/index.php/User_FAQ#Bug_Priorities Bugs: ===== As of Sunday evening (PST), October 4, 2009, by my reckoning we have twelve P1 bugs filed against ns-3-dev (I rechecked the wiki page against Bugzilla tonight). 1.Bug 424 blo P1 All riley at ece.gatech.edu NEW TCP FIN notification callback needed 2.Bug 426 blo P1 All riley at ece.gatech.edu NEW TCP: close does not send RST 3.Bug 559 blo P1 All riley at ece.gatech.edu REOP TcpSocketImpl doesnt free endpoint quickly enough after being closed 4.Bug 612 tri P1 All craigdo at ee.washington.edu NEW example scripts 5.Bug 615 blo P1 All riley at ece.gatech.edu NEW TCP does not respond with RST to non-listening port 6.Bug 647 blo P1 All riley at ece.gatech.edu NEW Ns-3 implementation of TCP fails to produce limited-queue CW sawtooth 7.Bug 663 blo P1 All riley at ece.gatech.edu NEW RST from remote TCP crashes ns-3 TCP 8.Bug 664 blo P1 All ns-bugs at isi.edu NEW memory fault/dangling pointer problems in tcp-socket-impl.cc, with suggested fixes 9.Bug 676 tri P1 All tomh at tomh.org NEW Align Ipv{4,6}L3Protocol Rx/Tx/Drop signatures 10.Bug 689 min P1 All mathieu.lacage at sophia.inria.fr NEW default energy detection threshold is not useful 11.Bug 697 blo P1 All riley at ece.gatech.edu NEW TCP "Sent" callback reports wrong count 12.Bug 704 min P1 All tomh at tomh.org NEW ns3-wifi-propagation-loss-models Since I had some unexpected time open up due to all of the great help I received dealing with the test framework, I have adopted the remaining homeless bugs. We now have zero homeless bugs (yay). Discussion ========== The elephant in the room is now the ns-3 TCP situation. Seven of our remaining bugs revolve around TCP: 1.Bug 424 blo P1 All riley at ece.gatech.edu NEW TCP FIN notification callback needed 2.Bug 426 blo P1 All riley at ece.gatech.edu NEW TCP: close does not send RST 3.Bug 559 blo P1 All riley at ece.gatech.edu REOP TcpSocketImpl doesnt free endpoint quickly enough after being closed 4.Bug 615 blo P1 All riley at ece.gatech.edu NEW TCP does not respond with RST to non-listening port 5.Bug 647 blo P1 All riley at ece.gatech.edu NEW Ns-3 implementation of TCP fails to produce limited-queue CW sawtooth 6.Bug 663 blo P1 All riley at ece.gatech.edu NEW RST from remote TCP crashes ns-3 TCP 7.Bug 697 blo P1 All riley at ece.gatech.edu NEW TCP "Sent" callback reports wrong count On September 30th, George sent out an email with patches that he says will fix 424, 426, 559 and 663. I believe George also has a fix for 697. I think Josh was working on 615 and has a fix for 647. It seems we have all of these well in hand, but nothing is pushed. We really need to look at these fixes and get them in ASAP. That leaves the following five bugs: ---------- 1. Bug 612 nor P1 All ns-bugs at isi.edu NEW example scripts This bug is really about organization of the examples directory. Unless I hear any objections I will try and wire in some subdirectories using waf and see what happens. If all goes smoothly I will propose the directory hierarchy tomorrow and we can close this bug fairly easily. If I do make the change it may trigger a need to do a documentation sweep. If something bad comes up, I will mark it "P3 Trivial" and just take it off the ns-3.6 critical path since there is nothing functionally wrong here. ---------- 2. Bug 664 blo P1 All ns-bugs at isi.edu NEW memory fault/dangling pointer problems in tcp-socket-impl.cc, with suggested fixes Craigdo will look at this tomorrow (Monday). ---------- 3. Bug 676 tri P1 All tomh at tomh.org NEW Align Ipv{4,6}L3Protocol Rx/Tx/Drop signatures I believe Gustavo posted some documentation and asked for comments. We can deal with this with a few +1s, hopefully. Please help! ---------- 4. Bug 689 min P1 All mathieu.lacage at sophia.inria.fr NEW default energy detection threshold is not useful The last I saw there was a suggested set of defaults in the tracker. Can we change the defaults and close this thing? ---------- 5. Bug 704 min P1 All tomh at tomh.org NEW ns3-wifi-propagation-loss-models Tom was looking at this tonight, the last I heard. The problem is that someone calculated expected SNRs by hand and the model doesn't agree. I have no idea which one is wrong. ---------- Progress ======== Bug 407 nor P1 Linu tomh at tomh.org NEW OLSR is missing HNA support Has gone to "P4 Enhancement" and is off the ns-3.6 critical path ---------- Bug 555 nor P1 All ns-bugs at isi.edu NEW DCF immediate access bug Has gone to "P2 Critical" and is off the ns-3.6 critical path. ---------- Bug 645 nor P1 All ns-bugs at isi.edu NEW patch fixes for opening stats file with OMNeT++ This bug has been assigned to Joe Kopena and has gone to "P3 Enhancement" and so is off the ns-3.6 critical path. ---------- Bug 648 nor P1 All ns-bugs at isi.edu NEW Missing Doxygen for Several Helpers Fixed. ---------- Bug 669 nor P1 All ns-bugs at isi.edu NEW main-packet-printer broken Fixed Next Steps: =========== Code freeze for ns-3.6 is currently planned for Wednesday, October 7, 2009. That is only three days away! Regards, -- Craig From felix.schmidt-eisenlohr at kit.edu Mon Oct 5 04:10:57 2009 From: felix.schmidt-eisenlohr at kit.edu (Felix Schmidt-Eisenlohr) Date: Mon, 05 Oct 2009 13:10:57 +0200 Subject: [Ns-developers] Question about the Wireless Channel, Mac_802.11Ext, and PhyExt In-Reply-To: <789565320910021751l251aa8c9xa2aa0242766cfeb8@mail.gmail.com> References: <789565320910021751l251aa8c9xa2aa0242766cfeb8@mail.gmail.com> Message-ID: <4AC9D441.9010204@kit.edu> Hi Tommy, Tommy Huy Nguyen schrieb: > Hi, > I'm currently implementing a new protocol using your Physical and Mac802.11 > extensions. I have a few technical questions relating would appreciate any > kind of help. > > 1) There are two packets with two different sizes. The first packet being > sent is a lot bigger than the second packet. Is it possible for the second > packet to arrive at the designated node before the first packet? It is possible, but depends on the propagation delay and is independent from the PHY model that is used. It can only happen if the transmitter of the second packet is much closer to the receiver than the transmitter of the first packet. Note that propagation delays for local networks are in the scale of microseconds (e.g. ~ 0.3 ?s for a distance of 100m), thus, we argue in very small time scales. > > 2) Node A sends a big packet to Node B. Node B sends a small packet to Node > A before Node A finish transmitting. Is it possible for Node B to send a > packet to Node A, while Node A is still transmitting? If so, is it possible > for Node A to receive Node B's small packet before finish transmitting the > big packet? > Node B is not allowed to transmit while it is receiving a packet. Thus, the only possibility that Node B transmits when a packet is sent from Node A to Node B is the case when Node B does not even sense the packet from Node A! And further, no, generally a WLAN node cannot receive anything while it is transmitting. > > Thanks, > Tommy Best regards, Felix From craigdo at ee.washington.edu Mon Oct 5 14:25:03 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Mon, 5 Oct 2009 14:25:03 -0700 Subject: [Ns-developers] Proposed examples directory hierarchy (was RE: ns-3.6 Daily Bug Status for Sunday, October 4, 2009) In-Reply-To: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> References: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> Message-ID: <2CE34C85C3804BFCBF6286A655C55265@CRAIGVAIO> [ ... ] > 1. Bug 612 nor P1 All ns-bugs at isi.edu NEW example scripts > > This bug is really about organization of the examples directory. > Unless I hear any objections I will try and wire in some > subdirectories using waf and see what happens. If all goes > smoothly I will propose the directory hierarchy tomorrow and > we can close this bug fairly easily. Nothing came up, so below is what I did with the subdirectories. If I don't hear an objection, I'll just push these changes tonight along with the four new wifi examples mentioned in the bug. To address the problem of it being very time consuming to build all of the examples, I added a blunt instrument. You now have two configuration options ./waf configure --disable-examples And ./waf configure --enable-examples If you --disable-examples none of the examples are built, none of the examples are tested in test.py, and regression testing won't run (since it depends on the examples). ---------- Begin File List ---------- ./examples: csma/ error-model/ ipv6/ naming/ routing/ tap/ tunneling/ udp/ wireless/ emulation/ flowmon/ mesh/ realtime/ stats/ tcp/ tutorial/ waf* wscript You can probably figure out what examples are in which directory, but if you are interested: ./csma: csma-bridge.cc csma-bridge-one-hop.cc csma-bridge.py csma-broadcast.cc csma-multicast.cc csma-one-subnet.cc csma-packet-socket.cc csma-ping.cc csma-raw-ip-socket.cc csma-star.cc waf* wscript ./emulation: emu-ping.cc emu-udp-echo.cc waf* wscript ./error-model: simple-error-model.cc waf* wscript ./flowmon: waf* wifi-olsr-flowmon.py wscript ./ipv6: icmpv6-redirect.cc ping6.cc radvd.cc radvd-two-prefix.cc test-ipv6.cc waf* wscript ./mesh: mesh.cc waf* Wscript ./naming: object-names.cc waf* wscript ./realtime: realtime-udp-echo.cc waf* wscript ./routing: dynamic-global-routing.cc global-injection-slash32.cc global-routing-slash32.cc mixed-global-routing.cc nix-simple.cc nms-p2p-nix.cc simple-alternate-routing.cc simple-global-routing.cc simple-point-to-point-olsr.cc simple-routing-ping6.cc simple-routing-ping6.py static-routing-slash32.cc waf* wscript ./stats: README waf* wifi-example-apps.cc wifi-example-apps.h wifi-example-db.sh* wifi-example.gnuplot wifi-example-sim.cc wscript ./tap: tap-wifi-dumbbell.cc waf* Wscript ./tcp: star.cc tcp-large-transfer.cc tcp-nsc-lfn.cc tcp-nsc-zoo.cc tcp-star-server.cc waf* wscript ./tunneling: virtual-net-device.cc waf* wscript ./tutorial: first.cc first.py hello-simulator.cc second.cc third.cc waf* wscript ./udp: udp-echo.cc waf* wscript ./wireless: mixed-wireless.cc mixed-wireless.py multirate.cc simple-wifi-frame-aggregation.cc waf* wifi-adhoc.cc wifi-ap.cc wifi-ap.py wifi-clear-channel-cmu.cc wifi-simple-adhoc.cc wifi-simple-adhoc-grid.cc wifi-simple-infra.cc wifi-simple-interference.cc wifi-wired-bridging.cc wscript From tomh at tomh.org Mon Oct 5 21:59:41 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 05 Oct 2009 21:59:41 -0700 Subject: [Ns-developers] Proposed examples directory hierarchy In-Reply-To: <2CE34C85C3804BFCBF6286A655C55265@CRAIGVAIO> References: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> <2CE34C85C3804BFCBF6286A655C55265@CRAIGVAIO> Message-ID: <4ACACEBD.1030107@tomh.org> craigdo at ee.washington.edu wrote: > [ ... ] > >> 1. Bug 612 nor P1 All ns-bugs at isi.edu NEW example scripts >> >> This bug is really about organization of the examples directory. >> Unless I hear any objections I will try and wire in some >> subdirectories using waf and see what happens. If all goes >> smoothly I will propose the directory hierarchy tomorrow and >> we can close this bug fairly easily. > > Nothing came up, so below is what I did with the subdirectories. If I don't > hear an objection, I'll just push these changes tonight along with the four > new wifi examples mentioned in the bug. I might suggest to wait a day for comments to come in. > > To address the problem of it being very time consuming to build all of the > examples, I added a blunt instrument. You now have two configuration > options > > ./waf configure --disable-examples > > And > > ./waf configure --enable-examples > > If you --disable-examples none of the examples are built, none of the > examples are tested in test.py, and regression testing won't run (since it > depends on the examples). How about, instead of a configure time option, a build option that does not try to link examples? Building the examples is not the typical recurring delay, it is linking them. It seems that "./waf" and "./waf build" are functionally the same now-- could we, for instance, make "./waf build" not try to link all examples? It would then be nice if there were an easy test.py option that avoided examples, including their linking, such as "test.py -i" (e.g. for internal, or pick your favorite option argument) that was equivalent to "test.py -c unit -c bvt -c system". So, for instance, this would support a workflow such as "edit file in src/, ./waf build, ./test.py -i" (or even have test.py figure out what needs to be built) that avoids linking and testing examples at each development step. We had similar behavior for a brief time with "./waf --check" but that now appears to be disabled. - Tom From tomh at tomh.org Mon Oct 5 22:18:13 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 05 Oct 2009 22:18:13 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Sunday, October 4, 2009 In-Reply-To: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> References: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> Message-ID: <4ACAD315.7020107@tomh.org> > Discussion > ========== > > The elephant in the room is now the ns-3 TCP situation. Seven of our > remaining bugs revolve around TCP: > > 1.Bug 424 blo P1 All riley at ece.gatech.edu NEW TCP FIN notification callback > needed > 2.Bug 426 blo P1 All riley at ece.gatech.edu NEW TCP: close does not send RST > 3.Bug 559 blo P1 All riley at ece.gatech.edu REOP TcpSocketImpl doesnt free > endpoint quickly enough after being closed > 4.Bug 615 blo P1 All riley at ece.gatech.edu NEW TCP does not respond with RST > to non-listening port > 5.Bug 647 blo P1 All riley at ece.gatech.edu NEW Ns-3 implementation of TCP > fails to produce limited-queue CW sawtooth > 6.Bug 663 blo P1 All riley at ece.gatech.edu NEW RST from remote TCP crashes > ns-3 TCP > 7.Bug 697 blo P1 All riley at ece.gatech.edu NEW TCP "Sent" callback reports > wrong count > > On September 30th, George sent out an email with patches that he says will > fix 424, 426, 559 and 663. I believe George also has a fix for 697. I > think Josh was working on 615 and has a fix for 647. It seems we have all > of these well in hand, but nothing is pushed. We really need to look at > these fixes and get them in ASAP. > I ran into some problems testing the patch on bug 424. It causes tcp-star-server example to run without termination, and I haven't found the reason why yet. I will look at it tomorrow again. Note that George's patch also fixes 697. - Tom From craigdo at ee.washington.edu Mon Oct 5 22:44:50 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Mon, 5 Oct 2009 22:44:50 -0700 Subject: [Ns-developers] Proposed examples directory hierarchy In-Reply-To: <4ACACEBD.1030107@tomh.org> References: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> <2CE34C85C3804BFCBF6286A655C55265@CRAIGVAIO> <4ACACEBD.1030107@tomh.org> Message-ID: <92E8490243F74628ACFB292C3845F5ED@CRAIGVAIO> [ ... ] > > If you --disable-examples none of the examples are built, > none of the > > examples are tested in test.py, and regression testing > won't run (since it > > depends on the examples). > > How about, instead of a configure time option, a build option > that does > not try to link examples? Building the examples is not the typical > recurring delay, it is linking them. I'm afraid I don't understand this comment. If you don't build the examples, you don't compile the source code and you don't link with anything. > It seems that "./waf" and "./waf build" are functionally the > same now-- > could we, for instance, make "./waf build" not try to link > all examples? I don't have a big problem with adding a flag to exclude the examples (and maybe one for samples) since the change is quite small. The deeper this goes, the more problem I have, though. We are talking about a change the day before code freeze now. > It would then be nice if there were an easy test.py option > that avoided > examples, including their linking, such as "test.py -i" (e.g. for > internal, or pick your favorite option argument) that was > equivalent to > "test.py -c unit -c bvt -c system". So, for instance, this would > support a workflow such as "edit file in src/, ./waf build, ./test.py > -i" (or even have test.py figure out what needs to be built) > that avoids > linking and testing examples at each development step. I really don't understand your comments. If you "./waf configure --disable-examples" you get exactly this behavior. The examples aren't built (or linked) and test.py doesn't run them. What am I missing? Anyway, if it turns out not straightforward and obvious, we should just mark this "P3 Enhancement" and move on. -- Craig From craigdo at ee.washington.edu Mon Oct 5 23:36:24 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Mon, 5 Oct 2009 23:36:24 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Monday, October 5, 2009 Message-ID: <3CA0AED85C5D49239F626F2E843FB281@CRAIGVAIO> Dear All, News and Comments: ================== There has been no significant change in status over the past 24 hours. I do believe that all of our supported platforms are building and testing properly now, though. That is nice. Executive summary: I might be convinced to make an ns-3.6-RC1 with one or two P1 bugs. Not with eleven. :-( Bugs: ===== No Change. As of Monday evening (PST), October 5, 2009, by my reckoning we have eleven P1 bugs filed against ns-3-dev. 1.Bug 424 blo P1 All riley at ece.gatech.edu NEW TCP FIN notification callback needed 2.Bug 426 blo P1 All riley at ece.gatech.edu NEW TCP: close does not send RST 3.Bug 559 blo P1 All riley at ece.gatech.edu REOP TcpSocketImpl doesnt free endpoint quickly enough after being closed 4.Bug 612 tri P1 All craigdo at ee.washington.edu NEW example scripts 5.Bug 615 blo P1 All riley at ece.gatech.edu NEW TCP does not respond with RST to non-listening port 6.Bug 647 blo P1 All riley at ece.gatech.edu NEW Ns-3 implementation of TCP fails to produce limited-queue CW sawtooth 7.Bug 663 blo P1 All riley at ece.gatech.edu NEW RST from remote TCP crashes ns-3 TCP 8.Bug 664 blo P1 All ns-bugs at isi.edu NEW memory fault/dangling pointer problems in tcp-socket-impl.cc, with suggested fixes 9.Bug 676 tri P1 All tomh at tomh.org NEW Align Ipv{4,6}L3Protocol Rx/Tx/Drop signatures 10.Bug 689 min P1 All mathieu.lacage at sophia.inria.fr NEW default energy detection threshold is not useful 11.Bug 697 blo P1 All riley at ece.gatech.edu NEW TCP "Sent" callback reports wrong count Discussion ========== Tom has mentioned that he has uncovered a problem with the TCP patches with respect to termination. ns-3 TCP remains the big issue for the release at this time. I am hesitant to do anything with Bug 664 which would upset the other TCP patches, so I won't commit any changes until "The TCP 7" are fixed. Progress ======== Bug 612 nor P1 All ns-bugs at isi.edu NEW example scripts I put together a new directory hierarchy of examples and added a switch to enable and disable examples from being built and used in test.py and regression. I sent mail sent to list and am awaiting further comments. Initial comments have not been promising. I am ready to just mark this one "P3 Enhancement" and move on. ---------- Bug 676 tri P1 All tomh at tomh.org NEW Align Ipv{4,6}L3Protocol Rx/Tx/Drop signatures Tom updated the patch with some typo corrections. I think this is good to go? Any objections? ---------- Bug 704 min P1 All tomh at tomh.org NEW ns3-wifi-propagation-loss-models Fixed. Next Steps: =========== Code freeze for ns-3.6 is currently planned for Wednesday, October 7, 2009. That is the day after tomorrow! We have eleven blockers! Regards, -- Craig From tomh at tomh.org Tue Oct 6 06:41:30 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 06 Oct 2009 06:41:30 -0700 Subject: [Ns-developers] Proposed examples directory hierarchy In-Reply-To: <92E8490243F74628ACFB292C3845F5ED@CRAIGVAIO> References: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> <2CE34C85C3804BFCBF6286A655C55265@CRAIGVAIO> <4ACACEBD.1030107@tomh.org> <92E8490243F74628ACFB292C3845F5ED@CRAIGVAIO> Message-ID: <4ACB490A.2050004@tomh.org> craigdo at ee.washington.edu wrote: > [ ... ] > >>> If you --disable-examples none of the examples are built, >> none of the >>> examples are tested in test.py, and regression testing >> won't run (since it >>> depends on the examples). >> How about, instead of a configure time option, a build option >> that does >> not try to link examples? Building the examples is not the typical >> recurring delay, it is linking them. > > I'm afraid I don't understand this comment. If you don't build the > examples, you don't compile the source code and you don't link with > anything. sorry for not being clear. There are these two build steps with an example: [371/453] cxx: csma-bridge.cc -> ../build/debug/examples/csma-bridge_16.o [420/453] cxx_link: ../build/debug/examples/csma-bridge_16.o -> ../build/debug/examples/csma-bridge If you edit the ns-3 core, you will, by default, get all of the example linkings again, but the example object files are not rebuilt. It is all of these linkings that consumes the most time. I mainly meant that we previously dealt with this after the configure stage; see bug 609: http://www.nsnam.org/bugzilla/show_bug.cgi?id=609 > >> It seems that "./waf" and "./waf build" are functionally the >> same now-- >> could we, for instance, make "./waf build" not try to link >> all examples? > > I don't have a big problem with adding a flag to exclude the examples (and > maybe one for samples) since the change is quite small. The deeper this > goes, the more problem I have, though. We are talking about a change the > day before code freeze now. > >> It would then be nice if there were an easy test.py option >> that avoided >> examples, including their linking, such as "test.py -i" (e.g. for >> internal, or pick your favorite option argument) that was >> equivalent to >> "test.py -c unit -c bvt -c system". So, for instance, this would >> support a workflow such as "edit file in src/, ./waf build, ./test.py >> -i" (or even have test.py figure out what needs to be built) >> that avoids >> linking and testing examples at each development step. > > I really don't understand your comments. If you "./waf configure > --disable-examples" you get exactly this behavior. The examples aren't > built (or linked) and test.py doesn't run them. > > What am I missing? > Maybe this is a matter of defaults and amount of typing. It seems to me that the only typical reason to build all examples is when the full test suite is run, and the full test suite is run after some build stages, sometimes not, so it seems cumbersome to me to have to reconfigure when you want to enable/disable this. Probably most to all users will not care about building all of the example executables most of the time, so maybe it is not the best default. So, from my perspective, if I understood your proposal correctly, having to type "./waf configure --enable-examples; ./test.py; ./waf configure --disable-examples" if I just want to run the full test.py once seems unnecessarily verbose. It might be nicer for most developers if examples were not built by default, but instead would be built under one of the following conditions: ./test.py -a (for "all" tests, although perhaps performance should be separated out) ./waf --run ./waf --target and the typical usage just built utils/ executables ./test.py (runs bvt, unit, system only) ./waf Anyway, the build system impacts a lot of daily users, so it would be nice to hear other preferences on this subject, which might mean slipping this fine tuning of test.py. Your examples/ directory organization looked fine to me. For the release, I don't mind reorganizing the examples (which seems to be a separate issue) and putting the pending examples of bug 612 in, and if we could restore ./waf --check's behavior after bug 609 was fixed (couldn't you make ./waf --check do "./waf --target test-runner; ./test.py -n -c bvt -c unit"), that would be enough for me. Tom From nill_akaser_tara at yahoo.com Mon Oct 5 12:01:38 2009 From: nill_akaser_tara at yahoo.com (qweq adcsad) Date: Mon, 5 Oct 2009 12:01:38 -0700 (PDT) Subject: [Ns-developers] Question about the Wireless Channel, Mac_802.11Ext, and PhyExt In-Reply-To: <789565320910021751l251aa8c9xa2aa0242766cfeb8@mail.gmail.com> Message-ID: <572190.18523.qm@web62405.mail.re1.yahoo.com> I am giving the answer below ur enquiry.... --- On Fri, 10/2/09, Tommy Huy Nguyen wrote: > From: Tommy Huy Nguyen > Subject: [Ns-developers] Question about the Wireless Channel, Mac_802.11Ext, and PhyExt > To: ns-developers at ISI.EDU > Date: Friday, October 2, 2009, 5:51 PM > Hi, > I'm currently implementing a new protocol using your > Physical and Mac802.11 > extensions. I have a few technical questions relating would > appreciate any > kind of help. > > 1) There are two packets with two different sizes.? > The first packet being > sent is a lot bigger than the second packet. Is it possible > for the second > packet to arrive at the designated node before the first > packet? > Your description is superficial.What kind of topology,agent,routing u are considering ? Any way, If all nodes are in the sensing range, then there should be one and only one transmission in the network at a time. The packet which will grab the channel first, will be transmitted first. Next TX initiation will start as soon as the NAV timer expires and CS becomes clear. Big packet and small packet is not the main issue. > 2) Node A sends a big packet to Node B. Node B sends a > small packet to Node > A before Node A finish transmitting. Is it possible for > Node B to send a > packet to Node A, while Node A is still transmitting? If > so, is it possible > for Node A to receive Node B's small packet before finish > transmitting the > big packet? > Pls see the above answer. By the way ,you can go through the basic principles of 802.11 DCF literature. > > Thanks, > Tommy > From craigdo at ee.washington.edu Tue Oct 6 11:51:49 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 6 Oct 2009 11:51:49 -0700 Subject: [Ns-developers] Proposed examples directory hierarchy In-Reply-To: <4ACB490A.2050004@tomh.org> References: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> <2CE34C85C3804BFCBF6286A655C55265@CRAIGVAIO> <4ACACEBD.1030107@tomh.org> <92E8490243F74628ACFB292C3845F5ED@CRAIGVAIO> <4ACB490A.2050004@tomh.org> Message-ID: Hi Tom, > For the release, I don't mind reorganizing the examples > (which seems to > be a separate issue) and putting the pending examples of bug > 612 in, and > if we could restore ./waf --check's behavior after bug 609 was fixed > (couldn't you make ./waf --check do "./waf --target test-runner; > ./test.py -n -c bvt -c unit"), that would be enough for me. I made a couple of very small changes that adds to the flexibility and I think gets you what you want. First, if you do nothing, and use "./test/py" you get existing behavior. Everything is built. This is nice for a newbie user who is just going to download, build and start poking around. If you know what you are doing, you can get more flexibility. If you leave --enable-examples set, you build all of the examples and samples once at the beginning and then use dependencies after that to control what is built. This seems useful for the ns-3 maintainer-types who will need to periodically make sure that they haven't broken any samples or examples but aren't generally interested in examples and samples. If a maintainer makes a change to the core (with --enable-examples configured), he can run "./test.py -c core". This tells test.py to constrain itself to running only the ns-3 core tests (BVT, UNIT and SYSTEM). This means that only the test-runner is built which has dependencies on all of the core tests. No examples or samples will be built. If Mr. maintainer then runs "./test.py" (with no constraints) all of the examples and samples get built; and test.py runs all of the examples (it should really run samples too, but that's another thing). If he makes another change to the core and runs "./test.py -c core" only the test-runner is linked and none of the examples and samples are built. I think this is what you wanted. If you are an experienced user writing your own models (and really not caring about running examples or samples) you can just turn them off and not deal with them at all using "./waf configure --disable-examples". There is a great deal of work left in waf to streamline what is built for the test-runner and the core, but that's another story we have to leave for a future release. -- Craig From tomh at tomh.org Tue Oct 6 14:37:36 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 06 Oct 2009 15:37:36 -0600 Subject: [Ns-developers] Proposed examples directory hierarchy In-Reply-To: References: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> <2CE34C85C3804BFCBF6286A655C55265@CRAIGVAIO> <4ACACEBD.1030107@tomh.org> <92E8490243F74628ACFB292C3845F5ED@CRAIGVAIO> <4ACB490A.2050004@tomh.org> Message-ID: On Tue, 6 Oct 2009 11:51:49 -0700, wrote: > Hi Tom, > >> For the release, I don't mind reorganizing the examples >> (which seems to >> be a separate issue) and putting the pending examples of bug >> 612 in, and >> if we could restore ./waf --check's behavior after bug 609 was fixed >> (couldn't you make ./waf --check do "./waf --target test-runner; >> ./test.py -n -c bvt -c unit"), that would be enough for me. > > I made a couple of very small changes that adds to the flexibility and I > think gets you what you want. > > First, if you do nothing, and use "./test/py" you get existing behavior. > Everything is built. This is nice for a newbie user who is just going to > download, build and start poking around. > > If you know what you are doing, you can get more flexibility. If you leave > --enable-examples set, you build all of the examples and samples once at > the > beginning and then use dependencies after that to control what is built. > This seems useful for the ns-3 maintainer-types who will need to > periodically make sure that they haven't broken any samples or examples but > aren't generally interested in examples and samples. > > If a maintainer makes a change to the core (with --enable-examples > configured), he can run "./test.py -c core". This tells test.py to > constrain itself to running only the ns-3 core tests (BVT, UNIT and > SYSTEM). > This means that only the test-runner is built which has dependencies on all > of the core tests. No examples or samples will be built. If Mr. > maintainer > then runs "./test.py" (with no constraints) all of the examples and samples > get built; and test.py runs all of the examples (it should really run > samples too, but that's another thing). If he makes another change to the > core and runs "./test.py -c core" only the test-runner is linked and none > of > the examples and samples are built. I think this is what you wanted. > > If you are an experienced user writing your own models (and really not > caring about running examples or samples) you can just turn them off and > not > deal with them at all using "./waf configure --disable-examples". This sounds good to me. I had a few more questions, though: 1) Can "./waf --check" run "./test.py -c core"? I recall we had discussed keeping this API alias, as being analogous to "make check". 2) what becomes of "./waf --regression" and "./waf --valgrind --regression" for this release cycle? I presume we are just keeping them in for now. 3) is there an easy way to enable valgrind via test.py? 4) is there an easy way to enable gdb for debugging problems that test.py uncovered in the tests that are not example programs? This is what I documented so far: http://www.nsnam.org/docs/testing/testing_19.html#SEC24 Thanks, Tom From craigdo at ee.washington.edu Tue Oct 6 22:30:48 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 6 Oct 2009 22:30:48 -0700 Subject: [Ns-developers] Proposed examples directory hierarchy In-Reply-To: References: <23E211CE03FA4DAAA13448D34373F089@CRAIGVAIO> <2CE34C85C3804BFCBF6286A655C55265@CRAIGVAIO> <4ACACEBD.1030107@tomh.org> <92E8490243F74628ACFB292C3845F5ED@CRAIGVAIO> <4ACB490A.2050004@tomh.org> Message-ID: > 1) Can "./waf --check" run "./test.py -c core"? I recall we > had discussed > keeping this API alias, as being analogous to "make check". Yes, it can be done. > 2) what becomes of "./waf --regression" and "./waf --valgrind > --regression" > for this release cycle? I presume we are just keeping them > in for now. Yes, they stay as-is. > 3) is there an easy way to enable valgrind via test.py? ./test.py -g > 4) is there an easy way to enable gdb for debugging problems > that test.py > uncovered in the tests that are not example programs? This is what I > documented so far: > http://www.nsnam.org/docs/testing/testing_19.html#SEC24 That's essentially what I did. From craigdo at ee.washington.edu Tue Oct 6 23:35:12 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 6 Oct 2009 23:35:12 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Tuesday, October 6, 2009 Message-ID: <83215FD8B03848ABA87804C33897752E@CRAIGVAIO> Dear All, We're getting right down to the wire ... News and Comments: ================== We have fixed a couple of our blockers but we still have a long way to go. Tomorrow seems to be the big day for nailing down our TCP bugs. It looks like George is going to provide a patch tomorrow that we hope will clear six of nine remaining blockers. Josh has fixes for two more P1 bugs which he needs to push/test tomorrow if we're going to do this release. That leaves one bug (689) and the consensus is that this should drop in priority if the defaults cannot be agreed upon. Amazingly enough, this brings us down to zero bugs if everything goes according to plan and opens the door for an ns-3.6-RC1 tomorrow night. [Of course, this all assumes an "ideal world, a sort of mathematician's paradise where everything happens as it does in textbooks." But ... I can't seem to find my ns-3.6 textbook. Where did it go ...] Bugs: ===== As of Tuesday evening (PST), October 6, 2009, by my reckoning we are down to nine P1 bugs filed against ns-3-dev. 1.Bug 424 blo P1 All riley at ece.gatech.edu NEW TCP FIN notification callback needed 2.Bug 426 blo P1 All riley at ece.gatech.edu NEW TCP: close does not send RST 3.Bug 559 blo P1 All riley at ece.gatech.edu REOP TcpSocketImpl doesnt free endpoint quickly enough after being closed 4.Bug 615 blo P1 All riley at ece.gatech.edu NEW TCP does not respond with RST to non-listening port 5.Bug 647 blo P1 All riley at ece.gatech.edu NEW Ns-3 implementation of TCP fails to produce limited-queue CW sawtooth 6.Bug 663 blo P1 All riley at ece.gatech.edu NEW RST from remote TCP crashes ns-3 TCP 7.Bug 664 blo P1 All ns-bugs at isi.edu NEW memory fault/dangling pointer problems in tcp-socket-impl.cc, with suggested fixes 8.Bug 689 min P1 All mathieu.lacage at sophia.inria.fr NEW default energy detection threshold is not useful 9.Bug 697 blo P1 All riley at ece.gatech.edu NEW TCP "Sent" callback reports wrong count Discussion ========== There is light at the end of the tunnel. There seems to be a path through all of these bugs ... ---------- 1.Bug 424 blo P1 All riley at ece.gatech.edu NEW TCP FIN notification callback needed George is providing a patch tomorrow morning that should fix this. ---------- 2.Bug 426 blo P1 All riley at ece.gatech.edu NEW TCP: close does not send RST George is providing a patch tomorrow that may fix this. There is a test case for this one that needs to pass. ---------- 3.Bug 559 blo P1 All riley at ece.gatech.edu REOP TcpSocketImpl doesnt free endpoint quickly enough after being closed George is providing a patch tomorrow that may clear this bug. ---------- 4.Bug 615 blo P1 All riley at ece.gatech.edu NEW TCP does not respond with RST to non-listening port Tom has acked this one in the tracker. Josh needs to address Tom's last comment and push and test this ASAP, making sure that it plays with all of George's changes. ---------- 5.Bug 647 blo P1 All riley at ece.gatech.edu NEW Ns-3 implementation of TCP fails to produce limited-queue CW sawtooth Josh needs to push and test this ASAP, making sure that it plays with all of George's changes. ---------- 6.Bug 663 blo P1 All riley at ece.gatech.edu NEW RST from remote TCP crashes ns-3 TCP George is providing a patch tomorrow that may clear this bug. ---------- 7.Bug 664 blo P1 All craigdo at ee.washington.edu NEW memory fault/dangling pointer problems in tcp-socket-impl.cc, with suggested fixes I was going to take this bug, but apparently George's patch takes care of this one. ---------- 8.Bug 689 min P1 All mathieu.lacage at sophia.inria.fr NEW default energy detection threshold is not useful We do not seem to be converging on an answer here. This is a minimal bug, and lots of people have their own idea about what the defaults should be. There is a workaround (set your own preferred value) so this will probably drop to P3 tomorrow. ---------- 9.Bug 697 blo P1 All riley at ece.gatech.edu NEW TCP "Sent" callback reports wrong count George's patch for tomorrow reportedly fixes this one. Progress ======== Bug 612 tri P1 All craigdo at ee.washington.edu NEW example scripts Fixed ---------- Bug 676 tri P1 All tomh at tomh.org NEW Align Ipv{4,6}L3Protocol Rx/Tx/Drop signatures Fixed Next Steps: =========== Code freeze for ns-3.6 is currently planned for Wednesday, October 7, 2009. That is tomorrow. Regards, -- Craig From mathieu.lacage at sophia.inria.fr Wed Oct 7 17:10:34 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 07 Oct 2009 17:10:34 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-3.4.6 Message-ID: <200910080010.n980AZh5024269@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/186 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Oct 7 17:19:53 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 07 Oct 2009 17:19:53 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.0.4 Message-ID: <200910080019.n980Jskd024463@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/172 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Oct 7 17:30:11 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 07 Oct 2009 17:30:11 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.1.2 Message-ID: <200910080030.n980UB9N024690@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/193 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Oct 7 17:41:27 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 07 Oct 2009 17:41:27 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.2.4 Message-ID: <200910080041.n980fRnt024934@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.2.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.2.4/builds/171 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Oct 7 17:51:23 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 07 Oct 2009 17:51:23 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.3.2 Message-ID: <200910080051.n980pNcT025076@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.3.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.3.2/builds/167 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Oct 7 18:01:14 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 07 Oct 2009 18:01:14 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.4.0 Message-ID: <200910080101.n9811EaX025105@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/187 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From craigdo at ee.washington.edu Thu Oct 8 02:06:18 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 8 Oct 2009 02:06:18 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 Message-ID: Dear All, News and Comments: ================== As they say, I have some good news and some bad news. The good news is that we got George's patch into ns-3-dev tonight and we have closed all of our P1 bugs according to the plan outlined yesterday. Thanks, George and Josh! The bad news is that more problems have come up. See "Discussion" for details. Bugs: ===== As of Wednesday night (PST), October 7, 2009, by my reckoning we are down to zero P1 bugs filed against ns-3-dev. This won't last long as I begin filing bugs on the new issues tomorrow, though. Discussion ========== You probably noticed that the buildbots reported build problems earlier tonight. Thanks to Sebastien Vincent for noticing and fixing a problem with Python bindings. We also had an issue with an implicit type conversion between double and unsigned int that has been fixed as well. Linux builds seem to be happier now. The builds are still broken on darwin-ppc (osx-ppc-g++-4.0 and osx-ppc-g++-4.2) though: [384/845] cxx: src/common/pcap-writer.cc -> build/debug/src/common/pcap-writer_1.o In file included from debug/ns3/high-precision-128.h:24, from debug/ns3/high-precision.h:29, from debug/ns3/nstime.h:29, from debug/ns3/simulator.h:27, from ../src/common/pcap-writer.cc:31: debug/ns3/cairo-wideint-private.h:67:2: error: #error Cannot find definitions for fixed-width integral types (uint8_t, uint32_t, etc.) Waf: Leaving directory `/Users/buildslave/slave/full-darwin-ppc-g++-4.0/build/build' We need to get these running again ASAP. I haven't seen successful results for Cygwin and I haven't run the tests on osx-intel so I'm not sure yet how they are faring. The next glitch is that the ns3-tcp-cwnd TestSuite is failing since we applied the TCP fixes. This may represent a change to correct behavior based on George's patch, but I want to take some time to verify this. If I run the test suite under -m (allow multiple failures) the suite crashes which is a little troubling. I have enabled valgrind under test.py (run using ./test.py -g) and this has revealed some problems. The two TCP test suites are crashing under valgrind: CRASH: TestSuite ns3-tcp-interoperability CRASH: TestSuite ns3-tcp-cwnd We also have a memory leak problem in one of the test suites: VALGR: TestSuite pcap-file-object Three examples (apparently otherwise untested) show memory leak problems too: VALGR: Example ipv6/icmpv6-redirect VALGR: Example wireless/simple-wifi-frame-aggregation VALGR: Example mesh/mesh 87 of 93 tests passed (87 passed, 0 failed, 2 crashed, 4 valgrind errors) I'm afraid I'm getting old and 02h00 is my limit. I am giving up for the night. If one of you kind folks on the other side of the world could step up and take a look at some of these problems I would be eternally grateful. Next Steps: =========== Code freeze for ns-3.6 was planned for today, Wednesday, October 7, 2009. This has obviously slipped, and ns-3.6-RC1 along with, until we can at least get our product built on all of our supported platforms. Regards, -- Craig From faker.moatamri at sophia.inria.fr Thu Oct 8 04:07:39 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 08 Oct 2009 13:07:39 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: References: Message-ID: <4ACDC7FB.5040000@sophia.inria.fr> craigdo at ee.washington.edu wrote: > > The builds are still broken on darwin-ppc (osx-ppc-g++-4.0 and > osx-ppc-g++-4.2) though: > > [384/845] cxx: src/common/pcap-writer.cc -> > build/debug/src/common/pcap-writer_1.o > In file included from debug/ns3/high-precision-128.h:24, > from debug/ns3/high-precision.h:29, > from debug/ns3/nstime.h:29, > from debug/ns3/simulator.h:27, > from ../src/common/pcap-writer.cc:31: > debug/ns3/cairo-wideint-private.h:67:2: error: #error Cannot find > definitions for fixed-width integral types (uint8_t, uint32_t, etc.) > Waf: Leaving directory > `/Users/buildslave/slave/full-darwin-ppc-g++-4.0/build/build' > We need to get these running again ASAP. > > I actually reactivated buildbot on darwin machine today and I also noticed this error. I fixed this bug and uploaded the patch to repository :-) . Best regards Faker Moatamri From vincent at clarinet.u-strasbg.fr Thu Oct 8 05:01:13 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Thu, 08 Oct 2009 14:01:13 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: References: Message-ID: <4ACDD489.7040001@clarinet.u-strasbg.fr> Hi all, craigdo at ee.washington.edu a ?crit : > We also have a memory leak problem in one of the test suites: > > VALGR: TestSuite pcap-file-object > > Three examples (apparently otherwise untested) show memory leak problems > too: > > VALGR: Example ipv6/icmpv6-redirect > VALGR: Example wireless/simple-wifi-frame-aggregation > VALGR: Example mesh/mesh > > 87 of 93 tests passed (87 passed, 0 failed, 2 crashed, 4 valgrind errors) > For icmpv6-redirect, It is not memory leak that causes valgrind warnings, just an uninitialized value. It is due when I add padding to packet, Buffer::AddAtEnd does not initialize it (the few bytes we add). Here a patch: diff -r 2b142c3fb89b src/common/buffer.cc --- a/src/common/buffer.cc Thu Oct 08 07:10:54 2009 +0200 +++ b/src/common/buffer.cc Thu Oct 08 13:54:00 2009 +0200 @@ -464,6 +464,7 @@ uint32_t newSize = GetInternalSize () + end; struct BufferData *newData = Buffer::Create (newSize); memcpy (newData->m_data, m_data->m_data + m_start, GetInternalSize ()); + memset(newData->m_data + GetInternalSize (), 0x00, end); m_data->m_count--; if (m_data->m_count == 0) { Mathieu OK to apply ? (I have not my SSH key stuff here, so I'll commit when I go back home or someone else could commit). Regards, -- Sebastien From mazo at iitp.ru Thu Oct 8 05:06:18 2009 From: mazo at iitp.ru (Andrey Mazo) Date: Thu, 08 Oct 2009 16:06:18 +0400 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: References: Message-ID: > Three examples (apparently otherwise untested) show memory leak problems > too: > > VALGR: Example ipv6/icmpv6-redirect > VALGR: Example wireless/simple-wifi-frame-aggregation > VALGR: Example mesh/mesh Could you please report your testing configuration (e.g. build type, compiler, os)? I've just checked "debug shared", "optimized shared", "optimized static" builds and mesh/mesh has successfully passed valgrind checks (./test -g). (rev e989563ab376, gcc 4.3.2, Gentoo Linux) -- Andrey Mazo. From mathieu.lacage at sophia.inria.fr Thu Oct 8 05:26:36 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 08 Oct 2009 14:26:36 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: <4ACDD489.7040001@clarinet.u-strasbg.fr> References: <4ACDD489.7040001@clarinet.u-strasbg.fr> Message-ID: <1255004796.13367.155.camel@diese.inria.fr> On Thu, 2009-10-08 at 14:01 +0200, Sebastien Vincent wrote: > diff -r 2b142c3fb89b src/common/buffer.cc > --- a/src/common/buffer.cc Thu Oct 08 07:10:54 2009 +0200 > +++ b/src/common/buffer.cc Thu Oct 08 13:54:00 2009 +0200 > @@ -464,6 +464,7 @@ > uint32_t newSize = GetInternalSize () + end; > struct BufferData *newData = Buffer::Create (newSize); > memcpy (newData->m_data, m_data->m_data + m_start, > GetInternalSize ()); > + memset(newData->m_data + GetInternalSize (), 0x00, end); > m_data->m_count--; > if (m_data->m_count == 0) > { > > > Mathieu OK to apply ? I don't think that it's safe to rely on AddAtEnd to initialize the buffer with zeros. If you plan to read these bytes, you need to initialize them yourself with a Trailer or Header. (sorry) Mathieu From mathieu.lacage at sophia.inria.fr Thu Oct 8 05:38:21 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 08 Oct 2009 14:38:21 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: <4ACDC7FB.5040000@sophia.inria.fr> References: <4ACDC7FB.5040000@sophia.inria.fr> Message-ID: <1255005501.13367.157.camel@diese.inria.fr> On Thu, 2009-10-08 at 13:07 +0200, Faker Moatamri wrote: > I actually reactivated buildbot on darwin machine today and I also > noticed this error. > I fixed this bug and uploaded the patch to repository :-) . Ok, link is still failing: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B% 2B-4.2/builds/115/steps/shell_5/logs/stdio I bet that it's the same error as: http://discussions.apple.com/thread.jspa?messageID=6678574 Which includes a description of how to fix it. Craig, tom, are you in a position to upgrade the relevant build tools ? Mathieu From faker.moatamri at sophia.inria.fr Thu Oct 8 05:44:47 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 08 Oct 2009 14:44:47 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: <1255005501.13367.157.camel@diese.inria.fr> References: <4ACDC7FB.5040000@sophia.inria.fr> <1255005501.13367.157.camel@diese.inria.fr> Message-ID: <4ACDDEBF.8060602@sophia.inria.fr> Mathieu Lacage wrote: > On Thu, 2009-10-08 at 13:07 +0200, Faker Moatamri wrote: > > >> I actually reactivated buildbot on darwin machine today and I also >> noticed this error. >> I fixed this bug and uploaded the patch to repository :-) . >> > > Ok, link is still failing: > http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B% > 2B-4.2/builds/115/steps/shell_5/logs/stdio > > I bet that it's the same error as: > http://discussions.apple.com/thread.jspa?messageID=6678574 > Yes absolutely, and someone with physical access to the machine has to fix that. > Which includes a description of how to fix it. Craig, tom, are you in a > position to upgrade the relevant build tools ? > The procedure should be something like this: http://www.askdavetaylor.com/how_to_install_apple_developer_tools_cc_gcc_mac_os_x.html Best regards Faker > Mathieu > > From gjcarneiro at gmail.com Thu Oct 8 06:35:14 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 8 Oct 2009 14:35:14 +0100 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: <4ACDC7FB.5040000@sophia.inria.fr> References: <4ACDC7FB.5040000@sophia.inria.fr> Message-ID: 2009/10/8 Faker Moatamri > craigdo at ee.washington.edu wrote: > >> >> The builds are still broken on darwin-ppc (osx-ppc-g++-4.0 and >> osx-ppc-g++-4.2) though: >> >> [384/845] cxx: src/common/pcap-writer.cc -> >> build/debug/src/common/pcap-writer_1.o >> In file included from debug/ns3/high-precision-128.h:24, >> from debug/ns3/high-precision.h:29, >> from debug/ns3/nstime.h:29, >> from debug/ns3/simulator.h:27, >> from ../src/common/pcap-writer.cc:31: >> debug/ns3/cairo-wideint-private.h:67:2: error: #error Cannot find >> definitions for fixed-width integral types (uint8_t, uint32_t, etc.) >> Waf: Leaving directory >> `/Users/buildslave/slave/full-darwin-ppc-g++-4.0/build/build' >> We need to get these running again ASAP. >> >> >> > I actually reactivated buildbot on darwin machine today and I also noticed > this error. > I fixed this bug and uploaded the patch to repository :-) . > OK, but I think your patch is just a workaround for a bug that might exist in the configuration code. This header test is not working on osx for some reason: conf.check(header_name='stdint.h', define_name='HAVE_STDINT_H') It might be interesting to find out why it fails on osx, by looking at build/config.log. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From vincent at clarinet.u-strasbg.fr Thu Oct 8 06:37:43 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Thu, 08 Oct 2009 15:37:43 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: <1255004796.13367.155.camel@diese.inria.fr> References: <4ACDD489.7040001@clarinet.u-strasbg.fr> <1255004796.13367.155.camel@diese.inria.fr> Message-ID: <4ACDEB27.9000003@clarinet.u-strasbg.fr> Mathieu Lacage a ?crit : > On Thu, 2009-10-08 at 14:01 +0200, Sebastien Vincent wrote: > > >> diff -r 2b142c3fb89b src/common/buffer.cc >> --- a/src/common/buffer.cc Thu Oct 08 07:10:54 2009 +0200 >> +++ b/src/common/buffer.cc Thu Oct 08 13:54:00 2009 +0200 >> @@ -464,6 +464,7 @@ >> uint32_t newSize = GetInternalSize () + end; >> struct BufferData *newData = Buffer::Create (newSize); >> memcpy (newData->m_data, m_data->m_data + m_start, >> GetInternalSize ()); >> + memset(newData->m_data + GetInternalSize (), 0x00, end); >> m_data->m_count--; >> if (m_data->m_count == 0) >> { >> >> >> Mathieu OK to apply ? >> > > I don't think that it's safe to rely on AddAtEnd to initialize the > buffer with zeros. If you plan to read these bytes, you need to > initialize them yourself with a Trailer or Header. > > (sorry) > > OK, I have found a different way to remove this warning: diff -r 2b142c3fb89b src/internet-stack/icmpv6-l4-protocol.cc --- a/src/internet-stack/icmpv6-l4-protocol.cc Thu Oct 08 07:10:54 2009 +0200 +++ b/src/internet-stack/icmpv6-l4-protocol.cc Thu Oct 08 15:28:18 2009 +0200 @@ -962,7 +962,8 @@ if ((redirectedPacketSize % 8) != 0) { - redirectedPacket->AddPaddingAtEnd (8 - (redirectedPacketSize % 8)); + Ptr pad = Create(8 - (redirectedPacketSize % 8)); + redirectedPacket->AddAtEnd (pad); } > Mathieu > > From mathieu.lacage at sophia.inria.fr Thu Oct 8 06:43:30 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 08 Oct 2009 15:43:30 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: <4ACDEB27.9000003@clarinet.u-strasbg.fr> References: <4ACDD489.7040001@clarinet.u-strasbg.fr> <1255004796.13367.155.camel@diese.inria.fr> <4ACDEB27.9000003@clarinet.u-strasbg.fr> Message-ID: <1255009410.18415.0.camel@diese.inria.fr> On Thu, 2009-10-08 at 15:37 +0200, Sebastien Vincent wrote: > OK, I have found a different way to remove this warning: > > diff -r 2b142c3fb89b src/internet-stack/icmpv6-l4-protocol.cc > --- a/src/internet-stack/icmpv6-l4-protocol.cc Thu Oct 08 07:10:54 > 2009 +0200 > +++ b/src/internet-stack/icmpv6-l4-protocol.cc Thu Oct 08 15:28:18 > 2009 +0200 > @@ -962,7 +962,8 @@ > > if ((redirectedPacketSize % 8) != 0) > { > - redirectedPacket->AddPaddingAtEnd (8 - (redirectedPacketSize % 8)); > + Ptr pad = Create(8 - (redirectedPacketSize % 8)); > + redirectedPacket->AddAtEnd (pad); > } good for me: +1 Mathieu From craigdo at ee.washington.edu Thu Oct 8 12:50:05 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 8 Oct 2009 12:50:05 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: <1255005501.13367.157.camel@diese.inria.fr> References: <4ACDC7FB.5040000@sophia.inria.fr> <1255005501.13367.157.camel@diese.inria.fr> Message-ID: <83EBD2B378584CA080A49640608208B6@CRAIGVAIO> > I bet that it's the same error as: > http://discussions.apple.com/thread.jspa?messageID=6678574 > > Which includes a description of how to fix it. I manually did a build on darwin-ppc and got: /usr/libexec/gcc/powerpc-apple-darwin8/4.2.1/ld: /usr/lib/gcc/powerpc-apple-darwin8/4.2.1/../../../libSystem.dylib unknown flags (type) of section 9 (__TEXT,__dof_plockstat) in load command 0 /usr/libexec/gcc/powerpc-apple-darwin8/4.2.1/ld: /usr/lib/libSystem.B.dylib unknown flags (type) of section 9 (__TEXT,__dof_ploc kstat) in load command 0 collect2: ld returned 1 exit status This is exactly what they are discussing in the link you provided. > Craig, tom, > are you in a > position to upgrade the relevant build tools ? I will be soon (this afternoon PST). Thanks, -- Craig From craigdo at ee.washington.edu Thu Oct 8 18:38:04 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 8 Oct 2009 18:38:04 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Wednesday, October 7, 2009 In-Reply-To: <83EBD2B378584CA080A49640608208B6@CRAIGVAIO> References: <4ACDC7FB.5040000@sophia.inria.fr> <1255005501.13367.157.camel@diese.inria.fr> <83EBD2B378584CA080A49640608208B6@CRAIGVAIO> Message-ID: <009401ca4881$2551a850$a3d75f80@ee.washington.edu> [ ... ] > > I bet that it's the same error as: > > http://discussions.apple.com/thread.jspa?messageID=6678574 > > > > Which includes a description of how to fix it. > > I manually did a build on darwin-ppc and got: > > /usr/libexec/gcc/powerpc-apple-darwin8/4.2.1/ld: > /usr/lib/gcc/powerpc-apple-darwin8/4.2.1/../../../libSystem.dy > lib unknown > flags > (type) of section 9 (__TEXT,__dof_plockstat) in load command 0 > /usr/libexec/gcc/powerpc-apple-darwin8/4.2.1/ld: > /usr/lib/libSystem.B.dylib > unknown flags (type) of section 9 (__TEXT,__dof_ploc > kstat) in load command 0 > collect2: ld returned 1 exit status > > This is exactly what they are discussing in the link you provided. I just got done upgrading darwin-ppc and ns-3-dev now builds fine and test.py runs great. -- Craig From craigdo at ee.washington.edu Fri Oct 9 00:15:45 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 9 Oct 2009 00:15:45 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 8, 2009 Message-ID: <010C7A098A2846E28E162AA48EEFA0DD@CRAIGVAIO> Dear All, News and Comments: ================== The last 24 hours has seen a flurry of uncovering and fixing relatively minor problems. I think we are currently in pretty good shape. As far as I can make out, we are now building on all of our supported platforms. We are running all of the tests correctly except for the ns-3-tcp-cwnd test that began failing when the TCP patch went in last night. We have four valgrind errors that have manifested over the last day or two when test.py launches tests under valgrind. I have filed five P1 bugs corresponding to the four valgrind errors and the TestSuite failure. I have manually verified that the system builds and runs on Cygwin, osx-ppc and osx-intel today. (I seem to have killed the buildslave connection to darwin-ppc when I rebooted it, but I think ns-3 will build and test our correctly there now that we have a new version of xcode). One remaining build nit is the fact that the test cased/suite code uses a Unix function to get execution times. This breaks the MinGW build. Now, MinGW is not a supported platform, but it seems cruel and unusual punishment to break MinGW just for this, so I will address this somehow before we ship. I convinced ns-3-run-tests.sh to use test.py, with and without valgrind, so we will begin seeing the nightly builds fail tonight with the five failures above. Be prepared for this. Andrey Mazo noticed today that print-introspected-doxygen had stopped working. This is because it used to be run as a side-effect of ./waf check which morphed into ./waf --check and was finally removed. I plumbed this into ./waf doxygen today, so the list of all trace sources, etc., should reappear in the ns-3-dev doxygen tonight. (I think we need to verify that the script to build the doxygen isn't trying to do a waf --check or any such thing before release). Anyway, if you want to generate doxygen, all you have to do is ./waf doxygen now. I think we lost ./waf --doxygen-no-build today, BTW. I am running low on patience at the moment and I can't make myself care right now :-/ Bugs: ===== As of Thursday night (PST), October 8, 2009, by my reckoning we have five P1 bugs filed against ns-3-dev. 1.Bug 710 blo P1 All ns-bugs at isi.edu NEW simple-wifi-frame-aggregation fails valgrind 2.Bug 711 blo P1 All ns-bugs at isi.edu NEW example mesh/mesh fails valgrind 3.Bug 712 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-cwnd crashes under valgrind 4.Bug 713 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-interoperability crashes under valgrind 5.Bug 714 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-cwnd fails All of these bugs are currently homeless. Discussion ========== I am not terribly worried about this new crop of bugs. I'm not going to hold up ns-3.6-RC1 for them since they are all valgrind-related except one -- and I think that one may be a non-bug. We do have to work through these puppies as soon as possible, though. Please feel free to fix all problems while I sleep :-) ---------- 1.Bug 710 blo P1 All ns-bugs at isi.edu NEW simple-wifi-frame-aggregation fails valgrind Valgrind is complaining that we are trying to write unitialized bytes to disk. I suspect that this may be due to uninitialized padding bytes in the msdu aggregator. ---------- 2.Bug 711 blo P1 All ns-bugs at isi.edu NEW example mesh/mesh fails valgrind This seems to be a real memory leak -- I glanced at it and it seems like something is being left in a std::list (I can't recall what). ---------- 3.Bug 712 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-cwnd crashes under valgrind I think this is an old familiar valgrind bug exposed by NSC TCP. I will verify this and if so, disable this test when running under valgrind. ---------- 4.Bug 713 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-interoperability crashes under valgrind I think this is an old familiar valgrind bug exposed by NSC TCP. I will verify this and if so, disable this test when running under valgrind. ---------- 5.Bug 714 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-cwnd fails I haven't had a chance to look at this in any detail to decide if there is a problem with the test or with TCP. I suspect it's a test problem. Next Steps: =========== Code freeze for ns-3.6 was originally planned for Wednesday, October 7, 2009. This has obviously slipped, and ns-3.6-RC1 along with it. If we can manage to have a period of stability until tomorrow afternoon, I will push out ns-3.6-RC1 then (~ 15h00 PST). The next step after that is ns-3.6-RC2 which is scheduled for October 12 (this coming Monday). Regards, -- Craig From vincent at clarinet.u-strasbg.fr Fri Oct 9 00:49:11 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Fri, 09 Oct 2009 09:49:11 +0200 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 8, 2009 In-Reply-To: <010C7A098A2846E28E162AA48EEFA0DD@CRAIGVAIO> References: <010C7A098A2846E28E162AA48EEFA0DD@CRAIGVAIO> Message-ID: <4ACEEAF7.4030103@clarinet.u-strasbg.fr> Hi, > Please feel free to fix all problems while I sleep :-) > > ---------- > > 1.Bug 710 blo P1 All ns-bugs at isi.edu NEW simple-wifi-frame-aggregation fails > valgrind > > Valgrind is complaining that we are trying to write unitialized bytes to > disk. I suspect that this may be due to uninitialized padding bytes in the > msdu aggregator. > > Patch in attachement to fix it (basically same kind of fix than icmpv6-redirect). It also fix compilation build on g++-4.4. I have not my SSH key here to commit it right now, so if patch looks good feel free to commit it. Thanks. Regards, -- Sebastien -------------- next part -------------- A non-text attachment was scrubbed... Name: fix.patch Type: text/x-patch Size: 1358 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091009/256db53b/fix.bin From mathieu.lacage at sophia.inria.fr Fri Oct 9 04:58:46 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 09 Oct 2009 04:58:46 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200910091158.n99BwkgD017544@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/176 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The web-page 'force build' button was pressed by 'bilel': build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_4 shell_5 sincerely, -The Buildbot From faker.moatamri at sophia.inria.fr Fri Oct 9 07:13:34 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 09 Oct 2009 16:13:34 +0200 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ In-Reply-To: <200910091158.n99BwkgD017544@ns-regression.ee.washington.edu> References: <200910091158.n99BwkgD017544@ns-regression.ee.washington.edu> Message-ID: <4ACF450E.8000009@sophia.inria.fr> mathieu.lacage at sophia.inria.fr wrote: > The Buildbot has detected a new failure of cygwin-g++ on NsNam. > Full details are available at: > http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/176 > > Buildbot URL: http://ns-regression.ee.washington.edu:8010/ > > Buildslave for this Build: cygwin > > The error is very similar to the one that was causing compiling problem with MacOS. I fixed it. Best regards Faker From craigdo at ee.washington.edu Sat Oct 10 00:49:56 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Sat, 10 Oct 2009 00:49:56 -0700 Subject: [Ns-developers] ns-3.6 Release Candidate 1 Posted Message-ID: <88073DC1530346C19DC8B459E7F51515@CRAIGVAIO> Hi All, I'm happy to announce that release candidate number one for ns-3.6 (ns-3.6-RC1) is now available at the below location (via tarball): http://www.nsnam.org/releases/ns-allinone-3.6-RC1.tar.bz2 And also (via Mercurial): hg clone http://code.nsnam.org/ns-3-allinone cd ns-3-allinone ./download.py -n ns-3.6-RC1 -r ns-3.6-RC1-ref-traces This is a release candidate, which means that we believe this version of ns-3.6 is almost ready for release, but we want to make absolutely sure that nothing has snuck in that could cause serious problems. We would appreciate it if you all could find time to look at this candidate with an eye to finding problems before we call it "golden." Please see this "getting started" page if you are new to ns-3: http://www.nsnam.org/getting_started.html >From the RELEASE_NOTES file in the distribution ... Release 3.6 =========== Availability ------------ This release is immediately available from: http://www.nsnam.org/releases/ns-allinone-3.6.tar.bz2 Supported platforms ------------------- ns-3.6 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) Not all ns-3 options are available on all platforms; consult the wiki for more information: http://www.nsnam.org/wiki/index.php/Installation New user-visible features ------------------------- a) 802.11 models: - Add an implementation of the minstrel rate control algorithm (Duy Nguyen for gsoc) - AthstatsHelper: enables the wifi device to produce periodic reports similar to the ones generated by madwifi's athstats tool (Nicola Baldo) - 10MHz and 5MHz channel width supported by 802.11a model (Ramon Bauza and Kirill Andreev) - Channel switching support. YansWifiPhy can now switch among different channels (Ramon Bauza and Pavel Boyko) b) IPv6 models: - IPv6 interface; - IPv6 layer; - IPv6 raw socket; - Static IPv6 routing; - ICMPv6 layer; - Some ICMPv6 error messages (destination unreachable, ...); - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); - Ping6 application (send Echo request); - Radvd application (send RA); - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, icmpv6-redirect). c) Wireless Mesh Networking models: - General multi-interface mesh stack infrastructure (devices/mesh module). - IEEE 802.11s (Draft 3.0) model including Peering Management Protocol and HWMP. - Forwarding Layer for Meshing (FLAME) protocol. d) Nix-vector routing: - Ipv4NixVectorHelper - Examples (nix-simple, nms-p2p-nix) e) New Test Framework - Use test.py instead of ./waf check or ./waf --regression - Previous unit tests have been ported to new framework. - Examples are tested for run-ability. API changes from ns-3.5 ----------------------- API changes for this release are documented in the file CHANGES.html of the distribution. Known issues ------------ ns-3.6-RC1 build is known to fail on the following platforms: - gcc 3.3 and earlier - optimized builds on gcc 3.4.4 and 3.4.5 - optimized builds on linux x86 gcc 4.0.x - MinGW. New test framework is known to fail the mesh example under valgrind. Regards, -- Craig From craigdo at ee.washington.edu Sat Oct 10 12:06:31 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Sat, 10 Oct 2009 12:06:31 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Saturday, October 10, 2009 Message-ID: Dear All, News and Comments: ================== Code freeze for ns-3.6 is now in effect! This means that no checkins to ns-3-dev are allowed until the release cycle has completed, unless explicitly approved by the release manager to address a P1 bug. We are going to be really strict about code changes, but if you want to add documentation changes, we will be fairly free about approving them until just before RC4. Ns-3.6-RC1 was posted last night. We have one P1 bug remaining. Bugs: ===== As of Saturday morning (PST), October 10, 2009, by my reckoning we have one P1 bug filed against ns-3-dev. 1. Bug 711 blo P1 All ns-bugs at isi.edu NEW example mesh/mesh fails valgrind Discussion ========== Bug 711 seems to be related to 64-bit Intel code only. I don't think anyone has a handle on this one yet. Progress ======== 1.Bug 710 blo P1 All ns-bugs at isi.edu NEW simple-wifi-frame-aggregation fails valgrind Fixed. ---------- 3.Bug 712 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-cwnd crashes under valgrind Fixed. ---------- 4.Bug 713 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-interoperability crashes under valgrind Fixed. ---------- 5.Bug 714 blo P1 All ns-bugs at isi.edu NEW TestSute ns3-tcp-cwnd fails Fixed. Next Steps: =========== ns-3.6-RC2 is scheduled for October 12 (this coming Monday). Regards, -- Craig From craigdo at ee.washington.edu Sat Oct 10 12:28:52 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Sat, 10 Oct 2009 12:28:52 -0700 Subject: [Ns-developers] Code Freeze for ns-3-dev is now in Effect Message-ID: <3DF053A773084AE39EC8793226095A12@CRAIGVAIO> Hi All, This is a reminder that ns-3.6 has entered the code freeze phase of the release. NS_3-DEV IS CLOSED FOR ROUTINE CHANGES until October 21st when ns-3.6 is scheduled for release. Only changes to resolve P1 bugs will be allowed from now until the ns-3.6 release. If you have a change that needs to go into ns-3-dev for ns-3.6, please contact me about arranging a time to merge and test your bits. If you check something in without pre-arrangement, it may be summarily removed and discarded from ns-3-dev without warning. I know this annoys some of you, but there are good reasons for doing it this way. You just have to wait for eleven days. The one exception to the P1 requirement is for documentation (doxygen, manual and tutorial). I won't be requiring a P1 bug to be filed for those changes, but I do want you to coordinate pushes with me, mainly so I can keep track of what remains to be done. Regards, -- Craig From craigdo at ee.washington.edu Tue Oct 13 00:27:37 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 13 Oct 2009 00:27:37 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Monday, October 12, 2009 Message-ID: <9DBA57189BAC411A89807698B657FE9C@CRAIGVAIO> Dear All, News and Comments: ================== None. Bugs: ===== As of Saturday morning (PST), October 10, 2009, by my reckoning we still have one P1 bug filed against ns-3-dev. 1. Bug 711 blo P1 All ns-bugs at isi.edu NEW example mesh/mesh fails valgrind Discussion ========== The main problems found relating to bug 711 so far were invalid reads and memory leaks. The invalid reads were valgrind problems. I found a workaround and checked in a fix tonight. There were a few memory leaks caused by not zeroing Ptr<> in stl containers. I also fixed these. There are still leaks remaining -- see bugzilla for details. If anyone wants to figure out what's happening here, feel free to give it a go, otherwise I'll get back to it tomorrow morning. Next Steps: =========== ns-3.6-RC2 was scheduled for tonight, October 12. There is no pressing reason to push out an RC (things seem to be going well with RC1), so I am going to wait to push out RC2 until we have a fix for bug 711 -- hopefully tomorrow. Regards, -- Craig From mathieu.lacage at sophia.inria.fr Tue Oct 13 17:44:16 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Tue, 13 Oct 2009 17:44:16 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200910140044.n9E0iHRN025268@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/179 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed failed slave lost sincerely, -The Buildbot From gjcarneiro at gmail.com Wed Oct 14 06:03:18 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 14 Oct 2009 14:03:18 +0100 Subject: [Ns-developers] BridgeChannel::~BridgeChannel Message-ID: Craig, can you please help me (maybe others) understand why this is needed? Presumably, the BridgeChannel destructor implicitly will call the destructor of m_bridgeChannels (vector), which would call the destructor for each element inside, and finally Ptr::~Ptr() would Unref the object. So, in theory C++ should take care of everything, and so isn't the code you inserted completely redundant? I would completely understand a "m_bridgedChannels.clear ();" statement added to BridgeChannel::DoDispose (), but maybe you are being overly cautious in this instance? Thanks in advance. # HG changeset patch # User Craig Dowell # Date 1255498890 25200 # Node ID 8996042990466b1eda718a848e1c02923c0add74 # Parent 9800d5479341f9b7b0e0426886b112adfd82dcab plug leaks (bug 711) --- a/src/devices/bridge/bridge-channel.cc Tue Oct 13 12:51:46 2009 -0700 +++ b/src/devices/bridge/bridge-channel.cc Tue Oct 13 22:41:30 2009 -0700 @@ -44,8 +44,16 @@ BridgeChannel::~BridgeChannel () { NS_LOG_FUNCTION_NOARGS (); + + for (std::vector< Ptr >::iterator iter = m_bridgedChannels.begin (); + iter != m_bridgedChannels.end (); iter++) + { + *iter = 0; + } + m_bridgedChannels.clear (); } + void BridgeChannel::AddChannel (Ptr bridgedChannel) { -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mazo at iitp.ru Wed Oct 14 07:09:26 2009 From: mazo at iitp.ru (Andrey Mazo) Date: Wed, 14 Oct 2009 18:09:26 +0400 Subject: [Ns-developers] BridgeChannel::~BridgeChannel In-Reply-To: References: Message-ID: > Craig, can you please help me (maybe others) understand why this is needed? > Presumably, the BridgeChannel destructor implicitly will call the destructor > of m_bridgeChannels (vector), which would call the destructor for each > element inside, and finally Ptr::~Ptr() would Unref the > object. So, in theory C++ should take care of everything, and so isn't the > code you inserted completely redundant? Have the same question in bug #711 [1]. The only answer is that it's an old problem [2].:) [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=711#c4 [2] http://www.nsnam.org/bugzilla/show_bug.cgi?id=711#c2 -- Andrey Mazo. From gjcarneiro at gmail.com Wed Oct 14 07:16:18 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 14 Oct 2009 15:16:18 +0100 Subject: [Ns-developers] BridgeChannel::~BridgeChannel In-Reply-To: References: Message-ID: 2009/10/14 Andrey Mazo > Craig, can you please help me (maybe others) understand why this is needed? >> Presumably, the BridgeChannel destructor implicitly will call the >> destructor >> of m_bridgeChannels (vector), which would call the destructor for each >> element inside, and finally Ptr::~Ptr() would Unref the >> object. So, in theory C++ should take care of everything, and so isn't >> the >> code you inserted completely redundant? >> > Have the same question in bug #711 [1]. > The only answer is that it's an old problem [2].:) > Yes, but if it's a problem, it is so fundamental that is worth investigating and documenting. Could it be that we are only working around a valgrind bug? If so, adding an explanatory comment stating this would be warranted. > > [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=711#c4 > [2] http://www.nsnam.org/bugzilla/show_bug.cgi?id=711#c2 > > > -- > Andrey Mazo. > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mazo at iitp.ru Wed Oct 14 08:01:06 2009 From: mazo at iitp.ru (Andrey Mazo) Date: Wed, 14 Oct 2009 19:01:06 +0400 Subject: [Ns-developers] BridgeChannel::~BridgeChannel In-Reply-To: References: Message-ID: >> The only answer is that it's an old problem [2].:) > Yes, but if it's a problem, it is so fundamental that is worth investigating > and documenting. Could it be that we are only working around a valgrind > bug? If so, adding an explanatory comment stating this would be warranted. Well, simple example with vector, map and Ptr works well. Unref() is called in desctructors when needed and valgrind is happy. -- Andrey Mazo. -------------- next part -------------- A non-text attachment was scrubbed... Name: qq.cc Type: application/octet-stream Size: 727 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091014/803e18d0/qq.obj From Joerg.Wagner at nw.neclab.eu Wed Oct 14 00:33:28 2009 From: Joerg.Wagner at nw.neclab.eu (Joerg Wagner) Date: Wed, 14 Oct 2009 09:33:28 +0200 Subject: [Ns-developers] NSC and multiple network interfaces within NS-3 Message-ID: <50A01DCBF4001B478A524C12CAA7EF4D0FF4FF@VENUS.office> Hello, I am currently trying to get an experimental mptcp stack running in NS-3. For ease of use I decided to go the nsc path (that is combine the stack with nsc and use the ns3-nsc interfacing then; ns-3 says that this is the way of using real-world stacks). However I stumbled across the following comment (taken from nsc-tcp-l4-protocol.cc:376) // we really don't need the loop, but its here to illustrate // how things _should_ be (once nsc can deal with multiple interfaces...) What is the reason for this? Is it a restriction of nsc or the ns3-nsc glue code? How easy would it be to solve it? Having a mptcp stack without multiple interfaces otherwise would be a little bit boring. Thanks for some advice or comments here! Best regards! Joerg From craigdo at ee.washington.edu Wed Oct 14 09:43:10 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 14 Oct 2009 09:43:10 -0700 Subject: [Ns-developers] BridgeChannel::~BridgeChannel In-Reply-To: References: Message-ID: > Craig, can you please help me (maybe others) understand why > this is needed? > Presumably, the BridgeChannel destructor implicitly will call > the destructor > of m_bridgeChannels (vector), which would call the destructor for each > element inside, and finally Ptr::~Ptr() > would Unref the > object. So, in theory C++ should take care of everything, > and so isn't the > code you inserted completely redundant? The short answer is, yes, in theory, C++ should take care of everything. [ ... ] From craigdo at ee.washington.edu Wed Oct 14 11:57:55 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 14 Oct 2009 11:57:55 -0700 Subject: [Ns-developers] ns-3.6 Release Candidate 2 Posted Message-ID: Hi All, I'm happy to announce that release candidate number two for ns-3.6 (ns-3.6-RC2) is now available at the below location (via tarball): http://www.nsnam.org/releases/ns-allinone-3.6-RC2.tar.bz2 And also (via Mercurial): hg clone http://code.nsnam.org/ns-3-allinone cd ns-3-allinone ./download.py -n ns-3.6-RC2 -r ns-3.6-RC2-ref-traces This is a release candidate, which means that we believe this version of ns-3.6 is almost ready for release, but we want to make absolutely sure that nothing has snuck in that could cause serious problems. We would appreciate it if you all could find time to look at this candidate with an eye to finding problems before we call it "golden." Please see this "getting started" page if you are new to ns-3: http://www.nsnam.org/getting_started.html >From the RELEASE_NOTES file in the distribution ... Release 3.6 =========== Availability ------------ This release is immediately available from: http://www.nsnam.org/releases/ns-allinone-3.6.tar.bz2 Supported platforms ------------------- ns-3.6 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) Not all ns-3 options are available on all platforms; consult the wiki for more information: http://www.nsnam.org/wiki/index.php/Installation New user-visible features ------------------------- a) 802.11 models: - Add an implementation of the minstrel rate control algorithm (Duy Nguyen for gsoc) - AthstatsHelper: enables the wifi device to produce periodic reports similar to the ones generated by madwifi's athstats tool (Nicola Baldo) - 10MHz and 5MHz channel width supported by 802.11a model (Ramon Bauza and Kirill Andreev) - Channel switching support. YansWifiPhy can now switch among different channels (Ramon Bauza and Pavel Boyko) b) IPv6 models: - IPv6 interface; - IPv6 layer; - IPv6 raw socket; - Static IPv6 routing; - ICMPv6 layer; - Some ICMPv6 error messages (destination unreachable, ...); - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); - Ping6 application (send Echo request); - Radvd application (send RA); - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, icmpv6-redirect). c) Wireless Mesh Networking models: - General multi-interface mesh stack infrastructure (devices/mesh module). - IEEE 802.11s (Draft 3.0) model including Peering Management Protocol and HWMP. - Forwarding Layer for Meshing (FLAME) protocol. d) Nix-vector routing: - Ipv4NixVectorHelper - Examples (nix-simple, nms-p2p-nix) e) New Test Framework - Use test.py instead of ./waf check or ./waf --regression - Previous unit tests have been ported to new framework. - Examples are tested for run-ability. API changes from ns-3.5 ----------------------- API changes for this release are documented in the file CHANGES.html of the distribution. Known issues ------------ ns-3.6-RC2 build is known to fail on the following platforms: - gcc 3.3 and earlier - optimized builds on gcc 3.4.4 and 3.4.5 - optimized builds on linux x86 gcc 4.0.x - MinGW. New test framework is known to fail the mesh example under valgrind. Regards, -- Craig From fw at strlen.de Wed Oct 14 12:01:08 2009 From: fw at strlen.de (Florian Westphal) Date: Wed, 14 Oct 2009 21:01:08 +0200 Subject: [Ns-developers] NSC and multiple network interfaces within NS-3 In-Reply-To: <50A01DCBF4001B478A524C12CAA7EF4D0FF4FF@VENUS.office> References: <50A01DCBF4001B478A524C12CAA7EF4D0FF4FF@VENUS.office> Message-ID: <20091014190108.GL24208@Chamillionaire.breakpoint.cc> Joerg Wagner wrote: > I am currently trying to get an experimental mptcp stack running in NS-3. [..] > However I stumbled across the following comment (taken from nsc-tcp-l4-protocol.cc:376) > > // we really don't need the loop, but its here to illustrate > // how things _should_ be (once nsc can deal with multiple interfaces...) > What is the reason for this? Is it a restriction of nsc or the ns3-nsc glue code? > How easy would it be to solve it? Both. On the nsc-side its an API-Problem (eg. missing "which interface is this packet being sent on" argument )? And a few other minor issues (hopefully easy to fix. some of them are listed in the topmost commit in the repository below). On the ns3 side of things, its a design problem. I did start working on this issue, but its hibernating again. Initial steps to getting things working are stashed here: http://code.nsnam.org/fw/ns-3-nsc/rev/ae536d9e0d6d From gjcarneiro at gmail.com Thu Oct 15 05:29:10 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 15 Oct 2009 13:29:10 +0100 Subject: [Ns-developers] ns-3.6 Release Candidate 2 Posted In-Reply-To: References: Message-ID: 2009/10/14 > > Hi All, > > I'm happy to announce that release candidate number two for ns-3.6 > (ns-3.6-RC2) is now available at the below location (via tarball): > > http://www.nsnam.org/releases/ns-allinone-3.6-RC2.tar.bz2 > > And also (via Mercurial): > > hg clone http://code.nsnam.org/ns-3-allinone > cd ns-3-allinone > ./download.py -n ns-3.6-RC2 -r ns-3.6-RC2-ref-traces > > This is a release candidate, which means that we believe this version of > ns-3.6 is almost ready for release, but we want to make absolutely sure > that > nothing has snuck in that could cause serious problems. We would > appreciate > it if you all could find time to look at this candidate with an eye to > finding problems before we call it "golden." > > Please see this "getting started" page if you are new to ns-3: > > http://www.nsnam.org/getting_started.html > > >From the RELEASE_NOTES file in the distribution ... > > Release 3.6 > =========== > > Availability > ------------ > This release is immediately available from: > > http://www.nsnam.org/releases/ns-allinone-3.6.tar.bz2 > > Supported platforms > ------------------- > ns-3.6 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) > > Not all ns-3 options are available on all platforms; consult the > wiki for more information: > > http://www.nsnam.org/wiki/index.php/Installation > > New user-visible features > ------------------------- > > a) 802.11 models: > - Add an implementation of the minstrel rate control algorithm > (Duy Nguyen for gsoc) > - AthstatsHelper: enables the wifi device to produce periodic > reports similar to the ones generated by madwifi's > athstats tool (Nicola Baldo) > - 10MHz and 5MHz channel width supported by 802.11a model > (Ramon Bauza and Kirill Andreev) > - Channel switching support. YansWifiPhy can now switch among > different channels (Ramon Bauza and Pavel Boyko) > > b) IPv6 models: > - IPv6 interface; > - IPv6 layer; > - IPv6 raw socket; > - Static IPv6 routing; > - ICMPv6 layer; > - Some ICMPv6 error messages (destination unreachable, ...); > - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); > - Ping6 application (send Echo request); > - Radvd application (send RA); > - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, > icmpv6-redirect). > > c) Wireless Mesh Networking models: > - General multi-interface mesh stack infrastructure (devices/mesh > module). > - IEEE 802.11s (Draft 3.0) model including Peering Management Protocol > and HWMP. > - Forwarding Layer for Meshing (FLAME) protocol. > > d) Nix-vector routing: > - Ipv4NixVectorHelper > - Examples (nix-simple, nms-p2p-nix) > > e) New Test Framework > - Use test.py instead of ./waf check or ./waf --regression > - Previous unit tests have been ported to new framework. > - Examples are tested for run-ability. > You could also mention: f) A new Flow Monitor module - To very easily measure flow metrics in a simulation - No need to use trace callbacks or parsing trace files Regards. > API changes from ns-3.5 > ----------------------- > API changes for this release are documented in the file CHANGES.html of the > distribution. > > Known issues > ------------ > ns-3.6-RC2 build is known to fail on the following platforms: > - gcc 3.3 and earlier > - optimized builds on gcc 3.4.4 and 3.4.5 > - optimized builds on linux x86 gcc 4.0.x > - MinGW. > > New test framework is known to fail the mesh example under valgrind. > > Regards, > > -- Craig > > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "ns-3-users" group. > To post to this group, send email to ns-3-users at googlegroups.com > To unsubscribe from this group, send email to > ns-3-users+unsubscribe at googlegroups.com > For more options, visit this group at > http://groups.google.com/group/ns-3-users?hl=en > -~----------~----~----~----~------~----~------~--~--- > > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From craigdo at ee.washington.edu Thu Oct 15 12:03:34 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 15 Oct 2009 12:03:34 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 15, 2009 Message-ID: Dear All, News and Comments: ================== It seems that examples/tap/tap-wifi-dumbbell has stopped working when using some of the non-default tap device operating modes (thanks for noticing this Tom -- still our Senior Master Chief Bugfinder). I will look into what has happened there. This may turn into a blocker soon. This brings up an important point: There are lots of examples and samples in the ns-3 distribution that are not automatically verified. We need to go through these things one-by-one and make sure that they are still working. If it's not checked by "./waf --regression" trace comparisons, we need to manually verify that it still works. "test.py" just makes sure that examples runnable in a default configuration run -- it doesn't check for any specific results, other than a zero return code from the program. Over the past few releases, it has been discovered quite late in the process that, for example, something in contrib no longer works, or some rarely used operating mode of some feature has stopped working. So if you are an example or sample author, please take some time to make sure that your code still works. We really need to exercise everything in the system ASAP and file bugs if something is found to be broken. Please, TEST, TEST and TEST some more. Please, TEST EVERYTHING IN SIGHT. Anyway, the big news of the day is that Andrey has killed our last blocker. During the process, it has been verified by a couple of us (including me) that releasing Ptr<> in stl containers is currently handled correctly. There used to be a problem making a manual iterate-and-ptr-release required. Code to do this can still be found in many places: for (TYPE_t::iterator i = container.begin (); i != container.end (); ++i) { *i = 0; } container.clear (); This now works without the extremely annoying manual releases. You can now safely just: container.clear (); and all of the Ptr stored in the container will be released properly. I have commented out every instance of this manual release stuff in a local repo and it works fine. It's not clear to me when, how or by whom this was fixed, but I'll take it :-) If this works, perhaps the manual zeroing of member Ptr variables in destructors is no longer required (I haven't verified that), and we now only have to deal with explicit pointer releases in Dispose(). Anyway, this all needs to be verified and written up in the manual in a clear fashion (with simple use examples, especially with Dispose()); and our codebase needs to reflect a single "approved" way to do this. Bugs: ===== As of Thursday morning (PST), October 15, 2009, we have zero P1 bugs filed against ns-3-dev. Next Steps: =========== ns-3.6-RC3 is scheduled for tonight, October 15. ns-3.6-RC4 is scheduled for Monday, October 19. ns-3.6 is scheduled for Wednesday, October 21. Regards, -- Craig From mathieu.lacage at sophia.inria.fr Thu Oct 15 17:47:12 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 15 Oct 2009 17:47:12 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200910160047.n9G0lCVV025018@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/181 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed failed slave lost sincerely, -The Buildbot From craigdo at ee.washington.edu Fri Oct 16 00:00:29 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 16 Oct 2009 00:00:29 -0700 Subject: [Ns-developers] ns-3.6 Release Candidate 3 Posted Message-ID: Hi All, I'm happy to announce that release candidate number three for ns-3.6 (ns-3.6-RC3) is now available at the below location (via tarball): http://www.nsnam.org/releases/ns-allinone-3.6-RC3.tar.bz2 And also (via Mercurial): hg clone http://code.nsnam.org/ns-3-allinone cd ns-3-allinone ./download.py -n ns-3.6-RC3 -r ns-3.6-RC3-ref-traces This is a release candidate, which means that we believe this version of ns-3.6 is almost ready for release, but we want to make absolutely sure that nothing has snuck in that could cause serious problems. We would appreciate it if you all could find time to look at this candidate with an eye to finding problems before we call it "golden." Please see this "getting started" page if you are new to ns-3: http://www.nsnam.org/getting_started.html >From the RELEASE_NOTES file in the distribution ... Release 3.6 =========== Availability ------------ This release is immediately available from: http://www.nsnam.org/releases/ns-allinone-3.6.tar.bz2 Supported platforms ------------------- ns-3.6 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) Not all ns-3 options are available on all platforms; consult the wiki for more information: http://www.nsnam.org/wiki/index.php/Installation New user-visible features ------------------------- a) 802.11 models: - Add an implementation of the minstrel rate control algorithm (Duy Nguyen for gsoc) - AthstatsHelper: enables the wifi device to produce periodic reports similar to the ones generated by madwifi's athstats tool (Nicola Baldo) - 10MHz and 5MHz channel width supported by 802.11a model (Ramon Bauza and Kirill Andreev) - Channel switching support. YansWifiPhy can now switch among different channels (Ramon Bauza and Pavel Boyko) b) IPv6 models: - IPv6 interface; - IPv6 layer; - IPv6 raw socket; - Static IPv6 routing; - ICMPv6 layer; - Some ICMPv6 error messages (destination unreachable, ...); - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); - Ping6 application (send Echo request); - Radvd application (send RA); - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, icmpv6-redirect). c) Wireless Mesh Networking models: - General multi-interface mesh stack infrastructure (devices/mesh module). - IEEE 802.11s (Draft 3.0) model including Peering Management Protocol and HWMP. - Forwarding Layer for Meshing (FLAME) protocol. d) Nix-vector routing: - Ipv4NixVectorHelper - Examples (nix-simple, nms-p2p-nix) e) New Test Framework - Use test.py instead of ./waf check or ./waf --regression - Previous unit tests have been ported to new framework. - Examples are tested for run-ability. f) A new Flow Monitor module - To very easily measure flow metrics in a simulation - No need to use trace callbacks or parsing trace files API changes from ns-3.5 ----------------------- API changes for this release are documented in the file CHANGES.html of the distribution. Known issues ------------ ns-3.6-RC3 build is known to fail on the following platforms: - gcc 3.3 and earlier - optimized builds on gcc 3.4.4 and 3.4.5 - optimized builds on linux x86 gcc 4.0.x - MinGW. Regards, -- Craig From mazo at iitp.ru Fri Oct 16 06:17:17 2009 From: mazo at iitp.ru (Andrey Mazo) Date: Fri, 16 Oct 2009 17:17:17 +0400 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 15, 2009 In-Reply-To: References: Message-ID: Dear ns-developers, > During the process, it has been verified by a couple of us (including me) > that releasing Ptr<> in stl containers is currently handled correctly. > There used to be a problem making a manual iterate-and-ptr-release required. > Code to do this can still be found in many places: > > for (TYPE_t::iterator i = container.begin (); i != container.end (); ++i) > { > *i = 0; > } > container.clear (); > > This now works without the extremely annoying manual releases. You can now > safely just: > > container.clear (); > > and all of the Ptr stored in the container will be released properly. I > have commented out every instance of this manual release stuff in a local > repo and it works fine. It's not clear to me when, how or by whom this was > fixed, but I'll take it :-) > > If this works, perhaps the manual zeroing of member Ptr variables in > destructors is no longer required (I haven't verified that), and we now only > have to deal with explicit pointer releases in Dispose(). Anyway, this all > needs to be verified and written up in the manual in a clear fashion (with > simple use examples, especially with Dispose()); and our codebase needs to > reflect a single "approved" way to do this. Also I vote for adding some words about cleaning up callbacks in DoDispose()'s. It may be not so clear, that creating a callback will increase reference counter on a particular object. For example, wifi code completely ignores destroying callbacks. I go for a memory management chapter for the manual containing something like: """ 1) Destructors must: 1.a) free allocated memory with delete/free() 1.b) explicitly cancel all events 2) Destructors should not (exception is when a special order of destructors is required): 2.a) explicitly zero all Ptr's () 2.b) explicitly clear all stl containers 3) DoDispose () must: 3.a) explicitly zero all Ptr's () 3.b) explicitly clear all stl containers 3.c) explicitly cancel all events 3.d) explicitly set all callbacks to MakeNullCallback<> () 3.e) free manually allocated memory with delete/free() """ with examples and references to the code. Also, I'd like to see some words about differences between DoDispose() and destructor and why to use them both. -- Andrey Mazo. From gjcarneiro at gmail.com Fri Oct 16 07:27:55 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 16 Oct 2009 15:27:55 +0100 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 15, 2009 In-Reply-To: References: Message-ID: 2009/10/16 Andrey Mazo > Dear ns-developers, > > During the process, it has been verified by a couple of us (including me) >> that releasing Ptr<> in stl containers is currently handled correctly. >> There used to be a problem making a manual iterate-and-ptr-release >> required. >> Code to do this can still be found in many places: >> >> for (TYPE_t::iterator i = container.begin (); i != container.end (); ++i) >> { >> *i = 0; >> } >> container.clear (); >> >> This now works without the extremely annoying manual releases. You can >> now >> safely just: >> >> container.clear (); >> >> and all of the Ptr stored in the container will be released properly. I >> have commented out every instance of this manual release stuff in a local >> repo and it works fine. It's not clear to me when, how or by whom this >> was >> fixed, but I'll take it :-) >> >> If this works, perhaps the manual zeroing of member Ptr variables in >> destructors is no longer required (I haven't verified that), and we now >> only >> have to deal with explicit pointer releases in Dispose(). Anyway, this >> all >> needs to be verified and written up in the manual in a clear fashion (with >> simple use examples, especially with Dispose()); and our codebase needs to >> reflect a single "approved" way to do this. >> > Also I vote for adding some words about cleaning up callbacks in > DoDispose()'s. > It may be not so clear, that creating a callback will increase reference > counter on a particular object. > It depends on how MakeCallback is called. When making method callbacks, you can you plain C++ pointers: m_myCallback = MakeCallback(&MyClass::MyMethod, this) Or you can make use of smart pointers: Ptr obj = ...; m_myCallback = MakeCallback(&SomeClass::MyMethod, obj) In the former case, the callback does not keep the object alive, while in the latter case the m_myCallback member keeps a smart pointer to the SomeClass instance 'obj', hence 'obj' is kept alive by the callback. In this case, clearing the callback in DoDispose () is recommended to break potential reference cycles. > For example, wifi code completely ignores destroying callbacks. > I go for a memory management chapter for the manual containing something > like: > """ > 1) Destructors must: > 1.a) free allocated memory with delete/free() > 1.b) explicitly cancel all events > > 2) Destructors should not (exception is when a special order of destructors > is required): > 2.a) explicitly zero all Ptr's () > 2.b) explicitly clear all stl containers > > 3) DoDispose () must: > 3.a) explicitly zero all Ptr's () > 3.b) explicitly clear all stl containers > 3.c) explicitly cancel all events > 3.d) explicitly set all callbacks to MakeNullCallback<> () > 3.e) free manually allocated memory with delete/free() > """ > Agreed except that I don't think destructors should be doing whatever it is DoDispose is already doing; that would be redundant... > with examples and references to the code. > Also, I'd like to see some words about differences between DoDispose() and > destructor and why to use them both. > > -- > Andrey Mazo. > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mazo at iitp.ru Fri Oct 16 08:35:09 2009 From: mazo at iitp.ru (Andrey Mazo) Date: Fri, 16 Oct 2009 19:35:09 +0400 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Thursday, October 15, 2009 In-Reply-To: References: Message-ID: >> It may be not so clear, that creating a callback will increase reference >> counter on a particular object. > It depends on how MakeCallback is called. When making method callbacks, you > can you plain C++ pointers: > > m_myCallback = MakeCallback(&MyClass::MyMethod, this) > > Or you can make use of smart pointers: > > Ptr obj = ...; > m_myCallback = MakeCallback(&SomeClass::MyMethod, obj) > > In the former case, the callback does not keep the object alive, while in > the latter case the m_myCallback member keeps a smart pointer to the > SomeClass instance 'obj', hence 'obj' is kept alive by the callback. In > this case, clearing the callback in DoDispose () is recommended to break > potential reference cycles. Yes, I already understood this while working on bug 711 and examining all Ref()/Unref()'s.:) This looks pretty clear and straightforward now. But this may be not obvious for new users, who tries to write a new model, so I think it worth mentioning in tutorial/manual. >> For example, wifi code completely ignores destroying callbacks. >> I go for a memory management chapter for the manual containing something >> like: >> """ >> 1) Destructors must: >> 1.a) free allocated memory with delete/free() >> 1.b) explicitly cancel all events >> >> 2) Destructors should not (exception is when a special order of destructors >> is required): >> 2.a) explicitly zero all Ptr's () >> 2.b) explicitly clear all stl containers >> >> 3) DoDispose () must: >> 3.a) explicitly zero all Ptr's () >> 3.b) explicitly clear all stl containers >> 3.c) explicitly cancel all events >> 3.d) explicitly set all callbacks to MakeNullCallback<> () >> 3.e) free manually allocated memory with delete/free() >> """ > Agreed except that I don't think destructors should be doing whatever it is > DoDispose is already doing; that would be redundant... I agree with you if both of them exist. But if DoDispose() is missing, destructor must do the work. -- Andrey Mazo. From gjcarneiro at gmail.com Fri Oct 16 11:02:05 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 16 Oct 2009 19:02:05 +0100 Subject: [Ns-developers] Python bindings bug Message-ID: Craig, care to make bug 723 P1 so that I can apply the fix? I will be traveling the next few days, probably without internet, so if the P1 is approved and you don't hear from me, please just apply the change. Thanks. http://www.nsnam.org/bugzilla/show_bug.cgi?id=723 -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From craigdo at ee.washington.edu Fri Oct 16 11:03:54 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 16 Oct 2009 11:03:54 -0700 Subject: [Ns-developers] Python bindings bug In-Reply-To: References: Message-ID: <16CF1653DC9744A5A786109FCFD0F5E5@CRAIGVAIO> go ahead and push your fix _____ From: Gustavo Carneiro [mailto:gjcarneiro at gmail.com] Sent: Friday, October 16, 2009 11:02 AM To: Craig Dowell Cc: ns-developers at ISI.EDU Subject: Python bindings bug Craig, care to make bug 723 P1 so that I can apply the fix? I will be traveling the next few days, probably without internet, so if the P1 is approved and you don't hear from me, please just apply the change. Thanks. http://www.nsnam.org/bugzilla/show_bug.cgi?id=723 -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From boyko at iitp.ru Mon Oct 19 04:57:23 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 19 Oct 2009 15:57:23 +0400 Subject: [Ns-developers] Trace based regression tests Message-ID: <200910191557.24039.boyko@iitp.ru> Hi, I'm trying to write simple pcap based regression (aka system) test using new framework. The only adequate example I have found is ns3tcp-interop-test- suite.cc . It can operate in two modes -- write packet traces ("test vectors") or compare actual transmitted packets (sniffed at IP level) with given correct traces. I like this. But this behavior is implemented "by hand", both packet tracing and comparison are implemented in Ns3TcpInteroperabilityTestCase and can not be reused by other tests. Also it happens that fancy PcapFile doesn't know about old PcapWriter, used by my favorite *Helper::EnablePcapAll (). And I want to use device level sniffer instead of IP level one. Does anybody have any plans / ideas how to implement trace based regression test behavior in reusable way? I can easily implement custom pcap diff for my WiFi based tests, but problem looks general and deserves some general solution. Pavel From faker.moatamri at sophia.inria.fr Mon Oct 19 01:57:25 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 19 Oct 2009 10:57:25 +0200 Subject: [Ns-developers] MacOS PPC automatic builder back in business Message-ID: <4ADC29F5.5020009@sophia.inria.fr> Hi all, I noticed since the last update of MacOS ppc buildbot slave that the automatic building was not working, I fixed it today so Mac PPC buildings are back in business. Best regards Faker Moatamri From mk.banchi at gmail.com Mon Oct 19 09:25:07 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Mon, 19 Oct 2009 18:25:07 +0200 Subject: [Ns-developers] MacRxMiddle::SequenceControlSmaller Message-ID: <95B57887-0B08-4785-82E1-8C04D81EA44A@gmail.com> Hi all, working on block ack support i found useful MacRxMiddle::SequenceControlSmaller function. In particular i found it useful in MacLow class. What do you think about moving it in qos- utils.h header changing its name in QosUtilsSequenceControlSmaller. This would avoid code duplication. Thanks, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091019/86ea63d0/smime.bin From mk.banchi at gmail.com Mon Oct 19 14:38:52 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Mon, 19 Oct 2009 23:38:52 +0200 Subject: [Ns-developers] WifiNetDevice section in manual Message-ID: Hi, reading the WifiNetDevice section in the manual (in particular 17.2.3) i saw that is still documented a function that has been removed from QosWifiMacHelper...method is SetEdcaParameterForAc. Are changes to ns-3-dev allowed? If no, Tom could you update the manual? Thanks, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091019/deed0d59/smime.bin From mathieu.lacage at sophia.inria.fr Mon Oct 19 17:18:46 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 19 Oct 2009 17:18:46 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-3.4.6 Message-ID: <200910200018.n9K0IkKe019876@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/200 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_13 shell_14 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Oct 19 17:35:56 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 19 Oct 2009 17:35:56 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.0.4 Message-ID: <200910200035.n9K0ZuJs024146@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/186 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_13 shell_14 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Oct 19 17:38:53 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 19 Oct 2009 17:38:53 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.1.2 Message-ID: <200910200038.n9K0crq6024158@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/206 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Oct 19 17:40:02 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 19 Oct 2009 17:40:02 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.3.2 Message-ID: <200910200040.n9K0e2jI024177@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.3.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.3.2/builds/180 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_4 shell_5 shell_6 shell_7 shell_8 shell_9 shell_10 shell_11 shell_12 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Oct 19 17:39:27 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 19 Oct 2009 17:39:27 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.2.4 Message-ID: <200910200039.n9K0dRiX024161@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.2.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.2.4/builds/184 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_2 shell_4 shell_5 shell_6 shell_7 shell_8 shell_9 shell_10 shell_11 shell_12 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Oct 19 17:40:31 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 19 Oct 2009 17:40:31 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.4.0 Message-ID: <200910200040.n9K0eVCW024180@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/201 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_4 shell_5 shell_6 shell_7 shell_8 shell_9 shell_10 shell_11 shell_12 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Mon Oct 19 17:41:23 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 19 Oct 2009 17:41:23 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.2 Message-ID: <200910200041.n9K0fNtU024183@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.2/builds/128 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_2 shell_3 shell_4 shell_5 shell_6 shell_7 shell_8 shell_9 shell_10 shell_11 shell_12 shell_13 shell_14 shell_15 sincerely, -The Buildbot From craigdo at ee.washington.edu Mon Oct 19 17:46:24 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Mon, 19 Oct 2009 17:46:24 -0700 Subject: [Ns-developers] Builtbots aren't (was RE: buildbot failure in NsNam on fc10-g++-4.2.4) In-Reply-To: <200910200039.n9K0dRiX024161@ns-regression.ee.washington.edu> References: <200910200039.n9K0dRiX024161@ns-regression.ee.washington.edu> Message-ID: <007901ca511e$c0d713f0$42853bd0$@washington.edu> The buildbots caught me right in the middle of something. This is not a "real" problem. From mathieu.lacage at sophia.inria.fr Mon Oct 19 18:40:51 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Mon, 19 Oct 2009 18:40:51 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200910200140.n9K1epso024325@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/186 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_4 sincerely, -The Buildbot From tomh at tomh.org Mon Oct 19 21:51:05 2009 From: tomh at tomh.org (Tom Henderson) Date: Mon, 19 Oct 2009 21:51:05 -0700 Subject: [Ns-developers] WifiNetDevice section in manual In-Reply-To: References: Message-ID: <4ADD41B9.8020206@tomh.org> Mirko Banchi wrote: > Hi, > > reading the WifiNetDevice section in the manual (in particular 17.2.3) i > saw that is still documented a function that has been removed from > QosWifiMacHelper...method is SetEdcaParameterForAc. Are changes to > ns-3-dev allowed? If no, Tom could you update the manual? Mirko, I made the correction but I'll let Craig decide whether to apply it now since he is preparing a release candidate. Thanks for pointing it out. - Tom From craigdo at ee.washington.edu Mon Oct 19 23:49:40 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Mon, 19 Oct 2009 23:49:40 -0700 Subject: [Ns-developers] ns-3.6 Release Candidate 4 Posted Message-ID: <009701ca5151$80152270$803f6750$@washington.edu> Hi All, I'm happy to announce that release candidate number four for ns-3.6 (ns-3.6-RC4) is now available at the below location (via tarball): http://www.nsnam.org/releases/ns-allinone-3.6-RC4.tar.bz2 And also (via Mercurial): hg clone http://code.nsnam.org/ns-3-allinone cd ns-3-allinone ./download.py -n ns-3.6-RC4 -r ns-3.6-RC4-ref-traces This is a release candidate, which means that we believe this version of ns-3.6 is almost ready for release, but we want to make absolutely sure that nothing has snuck in that could cause serious problems. We would appreciate it if you all could find time to look at this candidate with an eye to finding problems before we call it "golden." Please see this "getting started" page if you are new to ns-3: http://www.nsnam.org/getting_started.html >From the RELEASE_NOTES file in the distribution ... Release 3.6 =========== Availability ------------ This release is immediately available from: http://www.nsnam.org/releases/ns-allinone-3.6.tar.bz2 Supported platforms ------------------- ns-3.6 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) Not all ns-3 options are available on all platforms; consult the wiki for more information: http://www.nsnam.org/wiki/index.php/Installation New user-visible features ------------------------- a) 802.11 models: - Add an implementation of the minstrel rate control algorithm (Duy Nguyen for gsoc) - AthstatsHelper: enables the wifi device to produce periodic reports similar to the ones generated by madwifi's athstats tool (Nicola Baldo) - 10MHz and 5MHz channel width supported by 802.11a model (Ramon Bauza and Kirill Andreev) - Channel switching support. YansWifiPhy can now switch among different channels (Ramon Bauza and Pavel Boyko) b) IPv6 models: - IPv6 interface; - IPv6 layer; - IPv6 raw socket; - Static IPv6 routing; - ICMPv6 layer; - Some ICMPv6 error messages (destination unreachable, ...); - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); - Ping6 application (send Echo request); - Radvd application (send RA); - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, icmpv6-redirect). c) Wireless Mesh Networking models: - General multi-interface mesh stack infrastructure (devices/mesh module). - IEEE 802.11s (Draft 3.0) model including Peering Management Protocol and HWMP. - Forwarding Layer for Meshing (FLAME) protocol. d) Nix-vector routing: - Ipv4NixVectorHelper - Examples (nix-simple, nms-p2p-nix) e) New Test Framework - Use test.py instead of ./waf check or ./waf --regression - Previous unit tests have been ported to new framework. - Examples are tested for run-ability. f) A new Flow Monitor module - To very easily measure flow metrics in a simulation - No need to use trace callbacks or parsing trace files API changes from ns-3.5 ----------------------- API changes for this release are documented in the file CHANGES.html of the distribution. Known issues ------------ ns-3.6-RC4 build is known to fail on the following platforms: - gcc 3.3 and earlier - optimized builds on gcc 3.4.4 and 3.4.5 - optimized builds on linux x86 gcc 4.0.x - MinGW. Regards, -- Craig From mathieu.lacage at sophia.inria.fr Tue Oct 20 02:47:17 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 20 Oct 2009 11:47:17 +0200 Subject: [Ns-developers] buildbot failure in NsNam on mingw-g++ In-Reply-To: <4ADD68EE.2040600@sophia.inria.fr> References: <200910010008.n9108hWH017655@ns-regression.ee.washington.edu> <4ADD68EE.2040600@sophia.inria.fr> Message-ID: <1256032037.10679.16.camel@diese.inria.fr> On Tue, 2009-10-20 at 09:38 +0200, Faker Moatamri wrote: > This is a real problem because Mingwin compiler is missing the > sys/times.h header file. I checked and the only solution found is to > disable the tests that uses it in core/test.h/cc. But then we face > another problem which is missing socket.h and some headers that are > needed by NS-3. > If anybody else has any better solution, or has a Mingwin version > working with ns-3-dev, please share it with us so that we can make the > Mingwin builder build correctly. Gustavo sent me a patch privately to fix this issue correctly. Here it is. I realize that this should be attached to bugs 691 and 705 should depend on 691. I just did that. Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: test-times.diff Type: text/x-patch Size: 8418 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091020/f46da19c/test-times-0001.bin From mathieu.lacage at sophia.inria.fr Tue Oct 20 02:52:21 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 20 Oct 2009 11:52:21 +0200 Subject: [Ns-developers] wifi patch review Message-ID: <1256032341.10679.20.camel@diese.inria.fr> hi, I am going to be away for a while, unable to handle wifi issues myself so, before leaving, I wanted to make sure that someone would be able to ack wifi patches in ns-3-dev to avoid making them live forever unoticed in the bug trackers. I would like to ask mirko banchi, nicola baldo, and pavel boyko to be officially wifi reviewers. i.e., if you can get 2 out of these 3 people to ack a wifi patch, you can commit it without my explicit approval. Mathieu From mk.banchi at gmail.com Tue Oct 20 07:44:22 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Tue, 20 Oct 2009 16:44:22 +0200 Subject: [Ns-developers] Problems with ns-3-dev Message-ID: <67FFFED7-5728-4AE0-BA8C-36A94507C2CF@gmail.com> With last changes to ns-3-dev, ./waf configure fails. 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/20091020/99a40218/smime.bin From mk.banchi at gmail.com Tue Oct 20 08:23:25 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Tue, 20 Oct 2009 17:23:25 +0200 Subject: [Ns-developers] Problems with ns-3-dev In-Reply-To: <67FFFED7-5728-4AE0-BA8C-36A94507C2CF@gmail.com> References: <67FFFED7-5728-4AE0-BA8C-36A94507C2CF@gmail.com> Message-ID: <41268AB1-43E9-49C5-9BA7-2061189F359A@gmail.com> Il giorno 20/ott/09, alle ore 16:44, Mirko Banchi ha scritto: > With last changes to ns-3-dev, ./waf configure fails. > > Sorry, ./waf configure works. ./waf fails Thanks, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091020/657dcecd/smime.bin From mathieu.lacage at sophia.inria.fr Tue Oct 20 11:20:50 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Tue, 20 Oct 2009 11:20:50 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-3.4.6 Message-ID: <200910201820.n9KIKoUV028433@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/202 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The web-page 'force build' button was pressed by 'craigdo': Test patch Build Source Stamp: 827a3df7896a Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Tue Oct 20 11:24:04 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Tue, 20 Oct 2009 11:24:04 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.0.4 Message-ID: <200910201824.n9KIO47e028436@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/188 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The web-page 'force build' button was pressed by 'craigdo': Test patch Build Source Stamp: 827a3df7896a Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Tue Oct 20 11:27:55 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Tue, 20 Oct 2009 11:27:55 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.1.2 Message-ID: <200910201827.n9KIRt2V028441@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/208 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The web-page 'force build' button was pressed by 'craigdo': Test patch Build Source Stamp: 827a3df7896a Blamelist: BUILD FAILED: failed shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Tue Oct 20 13:19:28 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Tue, 20 Oct 2009 13:19:28 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200910202019.n9KKJSHL029384@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/188 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The web-page 'force build' button was pressed by 'craigdo': Test patch Build Source Stamp: 827a3df7896a Blamelist: BUILD FAILED: failed shell_2 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Tue Oct 20 14:58:23 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Tue, 20 Oct 2009 14:58:23 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.2 Message-ID: <200910202158.n9KLwNft029495@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.2/builds/130 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The web-page 'force build' button was pressed by 'craigdo': Test patch Build Source Stamp: 827a3df7896a Blamelist: BUILD FAILED: failed shell_9 shell_10 shell_11 shell_12 shell_13 shell_14 shell_15 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Tue Oct 20 20:39:49 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Tue, 20 Oct 2009 20:39:49 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.0 Message-ID: <200910210339.n9L3dnVD029874@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/133 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_2 shell_3 shell_4 shell_5 shell_6 shell_7 shell_8 shell_9 shell_10 shell_11 shell_12 shell_13 shell_14 shell_15 sincerely, -The Buildbot From craigdo at ee.washington.edu Tue Oct 20 21:28:17 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 20 Oct 2009 21:28:17 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Tuesday, October 20, 2009 Message-ID: <004201ca5206$ea610a30$bf231e90$@washington.edu> Dear All, News and Comments: ================== The end of the road is in sight. The release of ns-3.6 is scheduled for tomorrow. There is one issue remaining that needs to be nailed down. 1) The release fails to build on MinGW and is virtually untested there. A patch was suggested to address the build issue, but caused the builds to break on all FC-10 systems earlier today. I backed out the changes instead of fixing the problem since the proposed code actually makes an API change. On general principles we shouldn't make an API change the day before release; but I also don't like the new API very much. The millisecond system wall clock was changed to return some elapsed times in milliseconds as doubles. This is not what I would expect from it at all. I expect to see elapsed times in milliseconds returned as an unsigned integer of some kind. Additionally, one of the methods returns "unsigned long long" and two new ones return double. This is all very surprising and confusing. I would prefer to redo this change to have all methods return milliseconds as an uint32_t (why even use uint64_t with elapsed milliseconds). This is not the thing to be doing less than 24 hours before a release, though. Perhaps worse, since MinGW hasn't been building it obviously hasn't been tested. It turns out that test.py fails on MinGW as well. If we do a release that builds on MinGW, we are implying that it works; but we don't know that at all. I am not comfortable at all with dropping in a change tonight and releasing tomorrow with any suggestion or remote implication that MinGW is going to work. So we have a choice. We can either ship ns-3.6 explicitly without MinGW support tomorrow or we can slip the release and make MinGW work completely and prove so by actually testing it. I think we should aim to ship ns-3.6 tomorrow, as-is, since MinGW actually is not a supported ns-3 platform. We should decide up or down if we are going to MinGW an officially supported platform ASAP. If we decide it is, we should make an ns-3.6.1 with fully-tested MinGW support. If we decide not to support MinGW, then we can just forget it. I don't have a strong opinion on whether or not MinGW is worth it, but I don't like this half-in, half-out status quo very much at all. So I propose shipping ns-3.6 tomorrow as it stands. Opinions? Bugs: ===== As of Tuesday night (PST), October 20, 2009, we have zero P1 bugs filed against ns-3-dev. Next Steps: =========== ns-3.6 is scheduled for tomorrow, Wednesday, October 21. Regards, -- Craig From tomh at tomh.org Tue Oct 20 23:01:33 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 20 Oct 2009 23:01:33 -0700 Subject: [Ns-developers] ns-3.6 Daily Bug Status for Tuesday, October 20, 2009 In-Reply-To: <004201ca5206$ea610a30$bf231e90$@washington.edu> References: <004201ca5206$ea610a30$bf231e90$@washington.edu> Message-ID: <4ADEA3BD.9020300@tomh.org> > > I think we should aim to ship ns-3.6 tomorrow, as-is, since MinGW actually > is not a supported ns-3 platform. We should decide up or down if we are > going to MinGW an officially supported platform ASAP. If we decide it is, > we should make an ns-3.6.1 with fully-tested MinGW support. If we decide > not to support MinGW, then we can just forget it. I don't have a strong > opinion on whether or not MinGW is worth it, but I don't like this half-in, > half-out status quo very much at all. > > So I propose shipping ns-3.6 tomorrow as it stands. Opinions? I agree. It would be nice to hear whether we have any potential MinGW users. - Tom From mathieu.lacage at sophia.inria.fr Wed Oct 21 02:42:49 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 21 Oct 2009 02:42:49 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.2 Message-ID: <200910210942.n9L9gn9I030516@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.2/builds/133 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The web-page 'force build' button was pressed by 'craigdo': test before release Build Source Stamp: 0c8d1f5e0ffa Blamelist: BUILD FAILED: failed hg sincerely, -The Buildbot From faker.moatamri at sophia.inria.fr Wed Oct 21 05:18:51 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 21 Oct 2009 14:18:51 +0200 Subject: [Ns-developers] Review of underwater acoustic network device Message-ID: <4ADEFC2B.8040201@sophia.inria.fr> Hi Leonard & All, In the effort to merge your code in ns-3-dev main tree, I have been reviewing your code and the review is available here: http://codereview.appspot.com/87043. I also did builds and tests of the code available in http://code.nsnam.org/ltracy/ns-3-dev-uan. * Code review:* Overall the code is good, some changes are expected: - Coding style changes - More doxygen as requested by Craig - Folder changes in the examples and header files creation (create examples/uan and examples/uan/dat) - Remove commented code - Member variable should always be private unless you have a very good reason - Testing should be conform with the new testing framework (./test.py) *Compiling and testing: *I tried compiling under linux with g++ 3.4.6, 4.0.4, 4.1.2, 4.2.4, 4.3.3 and 4.4.0 from the repository http://code.nsnam.org/ltracy/ns-3-dev-uan Result: -g++ 3.4.6 Building failed with error: [560/703] cxx: src/devices/uan/uan-prop-model-ideal.cc -> build/debug/src/devices/uan/uan-prop-model-ideal_1.o ../src/devices/uan/uan-prop-model.cc: In member function `std::complex ns3::UanPdp::SumTapsFromMaxC(ns3::Time, ns3::Time) const': ../src/devices/uan/uan-prop-model.cc:219: warning: converting to `uint32_t' from `double' ../src/devices/uan/uan-prop-model.cc: In member function `double ns3::UanPdp::SumTapsFromMaxNc(ns3::Time, ns3::Time) const': ../src/devices/uan/uan-prop-model.cc:248: warning: converting to `uint32_t' from `double' [561/703] cxx: src/devices/uan/uan-mac-aloha.cc -> build/debug/src/devices/uan/uan-mac-aloha_1.o -g++ 4.0.4, g++ 4.1.2: Building failed because of this warning: [542/703] cxx: src/helper/qos-wifi-mac-helper.cc -> build/debug/src/helper/qos-wifi-mac-helper_1.o cc1plus: warnings being treated as errors debug/ns3/uan-phy.h:94: warning: ???class ns3::UanPhyListener??? has virtual functions but non-virtual destructor Waf: Leaving directory `/home/buildslave/slave/full-mimas-g++-4.0.4/build/build' -g++ 4.2.4, g++ 4.3.3, g++ 4.4.0: Debug building successful testing: failed: neither ./waf --check or ./test.py worked Optimized building failed: [571/703] cxx: src/devices/uan/uan-test.cc -> build/optimized/src/devices/uan/uan-test_1.o cc1plus: warnings being treated as errors ../src/devices/uan/uan-prop-model.cc: In member function ???double ns3::UanPdp::SumTapsFromMaxNc(ns3::Time, ns3::Time) const???: ../src/devices/uan/uan-prop-model.cc:236: warning: ???maxTapIndex??? may be used uninitialized in this function Waf: Leaving directory `/home/buildslave/slave/full-mimas-g++-4.2.4/build/build' Build failed Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Wed Oct 21 05:53:38 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 21 Oct 2009 14:53:38 +0200 Subject: [Ns-developers] Cygwin and MacOS builders are back in business Message-ID: <4ADF0452.3070202@sophia.inria.fr> Hi all, I put the buildslaves Cygwin and MacOS back in business. Regards Faker Moatamri From patxiazpiroz at gmail.com Tue Oct 20 08:12:51 2009 From: patxiazpiroz at gmail.com (Patxi Azpiroz) Date: Tue, 20 Oct 2009 17:12:51 +0200 Subject: [Ns-developers] wimax-release next features Message-ID: Dear WiMAX developers, I'm working on Wifi and WiMAX network simulation at Universidad Rey Juan Carlos I (Madrid, Spain). I'd like to know if the implemetation of 802.16j (Relay Stations) is scheduled. Is there any public site were the wimax current development schedule is accesible? Thanks & Regards, -- Patxi Azpiroz De Pedro From mathieu.lacage at sophia.inria.fr Wed Oct 21 11:03:18 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 21 Oct 2009 11:03:18 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.0 Message-ID: <200910211803.n9LI3INF013597@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/136 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The web-page 'force build' button was pressed by 'craigdo': Final Test Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed hg sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Wed Oct 21 12:37:23 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Wed, 21 Oct 2009 12:37:23 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.2.4 Message-ID: <200910211937.n9LJbNXm013682@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.2.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.2.4/builds/190 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The web-page 'force build' button was pressed by 'craigdo': Final Test Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_9 sincerely, -The Buildbot From mk.banchi at gmail.com Wed Oct 21 15:06:02 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 22 Oct 2009 00:06:02 +0200 Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x Message-ID: <546E0012-5F2F-43EF-98EE-376972E9E696@gmail.com> Hi all, compilation of ns-3-dev fails on os x ppc and g++ 4.0.1.Any idea? 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/20091022/c1630f2b/smime-0001.bin From craigdo at ee.washington.edu Wed Oct 21 15:53:09 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 21 Oct 2009 15:53:09 -0700 Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x In-Reply-To: <546E0012-5F2F-43EF-98EE-376972E9E696@gmail.com> References: <546E0012-5F2F-43EF-98EE-376972E9E696@gmail.com> Message-ID: <002001ca52a1$437ba770$ca72f650$@washington.edu> Can you be a little more specific? > -----Original Message----- > From: ns-developers-bounces at ISI.EDU [mailto:ns-developers- > bounces at ISI.EDU] On Behalf Of Mirko Banchi > Sent: Wednesday, October 21, 2009 3:06 PM > To: ns-developers mailing list > Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x > > Hi all, > > compilation of ns-3-dev fails on os x ppc and g++ 4.0.1.Any idea? > > 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 > > > From tomh at tomh.org Wed Oct 21 16:05:28 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 21 Oct 2009 17:05:28 -0600 Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x In-Reply-To: <002001ca52a1$437ba770$ca72f650$@washington.edu> References: <546E0012-5F2F-43EF-98EE-376972E9E696@gmail.com> <002001ca52a1$437ba770$ca72f650$@washington.edu> Message-ID: <676f4277473d1bd98762cf9473e61580@tomh.org> > >> -----Original Message----- >> From: ns-developers-bounces at ISI.EDU [mailto:ns-developers- >> bounces at ISI.EDU] On Behalf Of Mirko Banchi >> Sent: Wednesday, October 21, 2009 3:06 PM >> To: ns-developers mailing list >> Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x >> >> Hi all, >> >> compilation of ns-3-dev fails on os x ppc and g++ 4.0.1.Any idea? Is this the same problem reported here? http://www.nsnam.org/bugzilla/show_bug.cgi?id=726 From craigdo at ee.washington.edu Wed Oct 21 16:13:50 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 21 Oct 2009 16:13:50 -0700 Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x In-Reply-To: <676f4277473d1bd98762cf9473e61580@tomh.org> References: <546E0012-5F2F-43EF-98EE-376972E9E696@gmail.com> <002001ca52a1$437ba770$ca72f650$@washington.edu> <676f4277473d1bd98762cf9473e61580@tomh.org> Message-ID: <002e01ca52a4$270c1d60$75245820$@washington.edu> I just built ns-3-dev on Darwin-ppc with g++ 4.0.1 and am unable to reproduce any build problem. Y'all are going to give your friendly neighborhood release manager a heart attack! > -----Original Message----- > From: ns-developers-bounces at ISI.EDU [mailto:ns-developers- > bounces at ISI.EDU] On Behalf Of Tom Henderson > Sent: Wednesday, October 21, 2009 4:05 PM > To: craigdo at u.washington.edu > Cc: ns-developers mailing list > Subject: Re: [Ns-developers] ns-3-dev compilation problem on Mac Os x > > > > > >> -----Original Message----- > >> From: ns-developers-bounces at ISI.EDU [mailto:ns-developers- > >> bounces at ISI.EDU] On Behalf Of Mirko Banchi > >> Sent: Wednesday, October 21, 2009 3:06 PM > >> To: ns-developers mailing list > >> Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x > >> > >> Hi all, > >> > >> compilation of ns-3-dev fails on os x ppc and g++ 4.0.1.Any idea? > > Is this the same problem reported here? > > http://www.nsnam.org/bugzilla/show_bug.cgi?id=726 > From craigdo at ee.washington.edu Wed Oct 21 16:34:54 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 21 Oct 2009 16:34:54 -0700 Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x In-Reply-To: <002e01ca52a4$270c1d60$75245820$@washington.edu> References: <546E0012-5F2F-43EF-98EE-376972E9E696@gmail.com> <002001ca52a1$437ba770$ca72f650$@washington.edu> <676f4277473d1bd98762cf9473e61580@tomh.org> <002e01ca52a4$270c1d60$75245820$@washington.edu> Message-ID: <003701ca52a7$186c0970$49441c50$@washington.edu> I have built both debug and optimized on osx-ppc and osx-intel with g++-4.0.1 and have found no problems. I have built on all of the various Linux platforms and have found no problems. I have built on Cygwin and have found no problems. I am proceeding with the ns-3.6 release (after I finish off this bottle of Valium :-) -- Craig From craigdo at ee.washington.edu Wed Oct 21 18:38:29 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 21 Oct 2009 18:38:29 -0700 Subject: [Ns-developers] ns-3.6 Stable Release Posted Message-ID: <008101ca52b8$5f446b60$1dcd4220$@washington.edu> Hi All, I'm happy to announce that ns-3.6 (the latest stable release of ns-3) is now available at the below location (via tarball): http://www.nsnam.org/releases/ns-allinone-3.6.tar.bz2 And also (via Mercurial): hg clone http://code.nsnam.org/ns-3-allinone cd ns-3-allinone ./download.py -n ns-3.6 -r ns-3.6-ref-traces Note: Bazaar client software (bzr) must be upgraded to version 2.0 to use Python bindings with the Mercurial option. Try "bzr version" to see which version is currently installed on your system. Please see this "getting started" page if you are new to ns-3: http://www.nsnam.org/getting_started.html Supported platforms ------------------- ns-3.6 has been tested on the following platforms: - linux x86 gcc 4.4.1, 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) Not all ns-3 options are available on all platforms; consult the wiki for more information: http://www.nsnam.org/wiki/index.php/Installation New user-visible features ------------------------- a) 802.11 models: - Add an implementation of the minstrel rate control algorithm (Duy Nguyen for gsoc) - AthstatsHelper: enables the wifi device to produce periodic reports similar to the ones generated by madwifi's athstats tool (Nicola Baldo) - 10MHz and 5MHz channel width supported by 802.11a model (Ramon Bauza and Kirill Andreev) - Channel switching support. YansWifiPhy can now switch among different channels (Ramon Bauza and Pavel Boyko) b) IPv6 models: - IPv6 interface; - IPv6 layer; - IPv6 raw socket; - Static IPv6 routing; - ICMPv6 layer; - Some ICMPv6 error messages (destination unreachable, ...); - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection); - Ping6 application (send Echo request); - Radvd application (send RA); - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, icmpv6-redirect). c) Wireless Mesh Networking models: - General multi-interface mesh stack infrastructure (devices/mesh module). - IEEE 802.11s (Draft 3.0) model including Peering Management Protocol and HWMP. - Forwarding Layer for Meshing (FLAME) protocol. d) Nix-vector routing: - Ipv4NixVectorHelper - Examples (nix-simple, nms-p2p-nix) e) New Test Framework - Use test.py instead of ./waf check or ./waf --regression - Previous unit tests have been ported to new framework. - Examples are tested for run-ability. f) A new Flow Monitor module - To very easily measure flow metrics in a simulation - No need to use trace callbacks or parsing trace files API changes from ns-3.5 ----------------------- API changes for this release are documented in the file CHANGES.html. Known issues ------------ ns-3.6 build is known to fail on the following platforms: - gcc 3.3 and earlier - optimized builds on gcc 3.4.4 and 3.4.5 - optimized builds on linux x86 gcc 4.0.x - MinGW Enjoy! -- Craig From craigdo at ee.washington.edu Wed Oct 21 19:08:18 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 21 Oct 2009 19:08:18 -0700 Subject: [Ns-developers] Welcome to the ns-3.7 Open Phase Message-ID: <008201ca52bc$86831fb0$93895f10$@washington.edu> Hi All, With the completion of the ns-3.6 release, ns-3-dev has now entered the ns-3.7 open phase. This means that ns-3-dev is now open for routine checkins and changes. Thanks to everyone who has helped get ns-3.6 out the door. I am now passing the official ns-3 release manager baton (a really impressive looking thing) off to Faker Moatamri who has agreed to be responsible for the ns-3.7 release. Thanks from all of us for taking on this task, Faker. Please see the ns-3.7 release wiki page at http://www.nsnam.org/wiki/index.php/Ns-3.7 for details about ns-3.7 release planning. I'm sure I can speak for Faker when I ask everyone who has a pending submission for ns-3 to get their code approved and merged into ns-3-dev as soon as possible. It really does make everyone's life easier when we merge early in the release cycle. I now remind you that old release managers never die; they just fade away. And like those old release managers of the past, I now doff my release manager hat and just fade away. (with apologies to Douglas Macarthur). Regards, -- Craig From lentracy at u.washington.edu Wed Oct 21 21:48:37 2009 From: lentracy at u.washington.edu (Leonard Tracy) Date: Wed, 21 Oct 2009 21:48:37 -0700 Subject: [Ns-developers] Review of underwater acoustic network device In-Reply-To: <4ADEFC2B.8040201@sophia.inria.fr> References: <4ADEFC2B.8040201@sophia.inria.fr> Message-ID: <6c14d5550910212148v78aa47bakd9141a18f70ecc5@mail.gmail.com> Thanks Faker, I'll try and get this straightened out this weekend. Leonard On Wed, Oct 21, 2009 at 5:18 AM, Faker Moatamri < faker.moatamri at sophia.inria.fr> wrote: > Hi Leonard & All, > > In the effort to merge your code in ns-3-dev main tree, I have been > reviewing your code and the review is available here: > http://codereview.appspot.com/87043. I also did builds and tests of the > code available in http://code.nsnam.org/ltracy/ns-3-dev-uan. > * > Code review:* > Overall the code is good, some changes are expected: > - Coding style changes > - More doxygen as requested by Craig > - Folder changes in the examples and header files creation (create > examples/uan and examples/uan/dat) > - Remove commented code > - Member variable should always be private unless you have a very good > reason > - Testing should be conform with the new testing framework (./test.py) > > *Compiling and testing: > *I tried compiling under linux with g++ 3.4.6, 4.0.4, 4.1.2, 4.2.4, 4.3.3 > and 4.4.0 from the repository http://code.nsnam.org/ltracy/ns-3-dev-uan > Result: > -g++ 3.4.6 > Building failed with error: > > [560/703] cxx: src/devices/uan/uan-prop-model-ideal.cc -> > build/debug/src/devices/uan/uan-prop-model-ideal_1.o > ../src/devices/uan/uan-prop-model.cc: In member function > `std::complex ns3::UanPdp::SumTapsFromMaxC(ns3::Time, ns3::Time) > const': > ../src/devices/uan/uan-prop-model.cc:219: warning: converting to `uint32_t' > from `double' > ../src/devices/uan/uan-prop-model.cc: In member function `double > ns3::UanPdp::SumTapsFromMaxNc(ns3::Time, ns3::Time) const': > ../src/devices/uan/uan-prop-model.cc:248: warning: converting to `uint32_t' > from `double' > [561/703] cxx: src/devices/uan/uan-mac-aloha.cc -> > build/debug/src/devices/uan/uan-mac-aloha_1.o > > -g++ 4.0.4, g++ 4.1.2: > Building failed because of this warning: > > [542/703] cxx: src/helper/qos-wifi-mac-helper.cc -> > build/debug/src/helper/qos-wifi-mac-helper_1.o > cc1plus: warnings being treated as errors > debug/ns3/uan-phy.h:94: warning: ???class ns3::UanPhyListener??? has > virtual functions but non-virtual destructor > Waf: Leaving directory > `/home/buildslave/slave/full-mimas-g++-4.0.4/build/build' > > > -g++ 4.2.4, g++ 4.3.3, g++ 4.4.0: > Debug building successful > testing: failed: neither ./waf --check or ./test.py worked > Optimized building failed: > > [571/703] cxx: src/devices/uan/uan-test.cc -> > build/optimized/src/devices/uan/uan-test_1.o > cc1plus: warnings being treated as errors > ../src/devices/uan/uan-prop-model.cc: In member function ???double > ns3::UanPdp::SumTapsFromMaxNc(ns3::Time, ns3::Time) const???: > ../src/devices/uan/uan-prop-model.cc:236: warning: ???maxTapIndex??? may be > used uninitialized in this function > Waf: Leaving directory > `/home/buildslave/slave/full-mimas-g++-4.2.4/build/build' > Build failed > > Best regards > Faker Moatamri > > From tomh at tomh.org Wed Oct 21 22:25:42 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 21 Oct 2009 22:25:42 -0700 Subject: [Ns-developers] Welcome to the ns-3.7 Open Phase In-Reply-To: <008201ca52bc$86831fb0$93895f10$@washington.edu> References: <008201ca52bc$86831fb0$93895f10$@washington.edu> Message-ID: <4ADFECD6.1090106@tomh.org> craigdo at ee.washington.edu wrote: > Hi All, > > With the completion of the ns-3.6 release, ns-3-dev has now entered the > ns-3.7 open phase. This means that ns-3-dev is now open for routine > checkins and changes. > > Thanks to everyone who has helped get ns-3.6 out the door. > > I am now passing the official ns-3 release manager baton (a really > impressive looking thing) off to Faker Moatamri who has agreed to be > responsible for the ns-3.7 release. Thanks from all of us for taking on > this task, Faker. Craig, thanks for pulling the release together again, and I am especially grateful for all of the volunteers (Pavel, Andrey, Gustavo, Mathieu, others) who helped to convert all of the test code and fix documentation, among other things. I think we all agree that doing more things earlier in the release cycle will help improve the process and hopefully we can all support Faker in that regard. - Tom From f1mauchl at hsr.ch Thu Oct 22 00:11:14 2009 From: f1mauchl at hsr.ch (Fabian Mauchle) Date: Thu, 22 Oct 2009 09:11:14 +0200 Subject: [Ns-developers] Tunneling Protocols In-Reply-To: <008201ca52bc$86831fb0$93895f10$@washington.edu> References: <008201ca52bc$86831fb0$93895f10$@washington.edu> Message-ID: <001901ca52e6$d7a85750$86f905f0$@ch> Hi All I'm currently working on simulations which include some IP tunneling. There is only one example which implements a UDP tunnel, so I started to create my own implementations (IPoverIP and others). I just wondered if anybody else has put some effort in implementing tunneling protocols. If not, I will try to create kind of a 'tunneling framework' to implement different protocols, and provide simple tunnel setup thru helpers. Regards, Fabian Mauchle Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil, Switzerland From boyko at iitp.ru Thu Oct 22 00:23:04 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Thu, 22 Oct 2009 11:23:04 +0400 Subject: [Ns-developers] Tunneling Protocols In-Reply-To: <001901ca52e6$d7a85750$86f905f0$@ch> References: <008201ca52bc$86831fb0$93895f10$@washington.edu> <001901ca52e6$d7a85750$86f905f0$@ch> Message-ID: <200910221123.04320.boyko@iitp.ru> Hi, Fabian, > If not, I will try to create kind of a 'tunneling framework' to implement > different protocols, and provide simple tunnel setup thru helpers. Cool, I will greatly appreciate this work. Good luck, Pavel From mk.banchi at gmail.com Thu Oct 22 00:55:06 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 22 Oct 2009 09:55:06 +0200 Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x In-Reply-To: <676f4277473d1bd98762cf9473e61580@tomh.org> References: <546E0012-5F2F-43EF-98EE-376972E9E696@gmail.com> <002001ca52a1$437ba770$ca72f650$@washington.edu> <676f4277473d1bd98762cf9473e61580@tomh.org> Message-ID: Il giorno 22/ott/09, alle ore 01:05, Tom Henderson ha scritto: > >> >>> -----Original Message----- >>> From: ns-developers-bounces at ISI.EDU [mailto:ns-developers- >>> bounces at ISI.EDU] On Behalf Of Mirko Banchi >>> Sent: Wednesday, October 21, 2009 3:06 PM >>> To: ns-developers mailing list >>> Subject: [Ns-developers] ns-3-dev compilation problem on Mac Os x >>> >>> Hi all, >>> >>> compilation of ns-3-dev fails on os x ppc and g++ 4.0.1.Any idea? > > Is this the same problem reported here? > > http://www.nsnam.org/bugzilla/show_bug.cgi?id=726 > > No. The error was a python error. However i don't undestand the reason but a new clone of ns-3-dev fix the problem. 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/20091022/a561737e/smime-0001.bin From boyko at iitp.ru Thu Oct 22 01:18:37 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Thu, 22 Oct 2009 12:18:37 +0400 Subject: [Ns-developers] Welcome to the ns-3.7 Open Phase In-Reply-To: <4ADFECD6.1090106@tomh.org> References: <008201ca52bc$86831fb0$93895f10$@washington.edu> <4ADFECD6.1090106@tomh.org> Message-ID: <200910221218.37806.boyko@iitp.ru> Hi, On Thursday 22 October 2009 09:25:42 am Tom Henderson wrote: > craigdo at ee.washington.edu wrote: > > Hi All, > > > > With the completion of the ns-3.6 release, ns-3-dev has now entered the > > ns-3.7 open phase. This means that ns-3-dev is now open for routine > > checkins and changes. Well, does anybody have proposals about ns-3.7 release focus and goals apart of extensive merging contributed models & bugfixing week? I have two. First, ns-3.6 wifi model is sick. 14 of 76 open bugs are wifi specific, some of them are really serious. There are definitely not enough system tests for such complex model. Moreover, upcoming wimax merge will bring new bugs for sure. Also we have alternative and potentially better wifi PHY model still unmerged to the main tree. Should we announce ns-3.7 motto to be "Bugfree Wireless" and especially appreciate all wireless fixes & contributions? Second, ns-3.6 performance is unsatisfactory. I am practically unable to simulate more then 100 wifi stations in meaningful scenarios, see also http://www.nsnam.org/workshops/wns3-2009/talks/ns-3-scalability.pdf . Profiles show extensive potential for optimizations. Also we have unimplemented gsoc09 proposal for SNS optimization (http://www.nsnam.org/wiki/index.php/GSOC2009Projects) Initial multithreaded and MPI NS-3 versions are on the table and potentially are very useful. So, should we announce ns-3.7 motto to be "Unlimited Performance" and especially appreciate all performance/capacity optimizations and contributions? What do you think? Pavel > I think we all agree that doing more things earlier in the release cycle > will help improve the process and hopefully we can all support Faker in > that regard. > > - Tom From Amine.Ismail at sophia.inria.fr Thu Oct 22 01:29:46 2009 From: Amine.Ismail at sophia.inria.fr (Ismail Amine) Date: Thu, 22 Oct 2009 10:29:46 +0200 Subject: [Ns-developers] wimax-release next features In-Reply-To: References: Message-ID: <4AE017FA.8030805@sophia.inria.fr> Hi Patxi, > I'd like to know if the implemetation of 802.16j (Relay Stations) is > scheduled. > > No 802.16j is not in our road map for the moment > Is there any public site were the wimax current development schedule is > accesible? > > We don't have such public website, the documentation of the module could be found in wimax.h file under src/wimax > Thanks & Regards, > > > From faker.moatamri at sophia.inria.fr Thu Oct 22 02:03:54 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 22 Oct 2009 11:03:54 +0200 Subject: [Ns-developers] Merge wimax Message-ID: <4AE01FFA.2030801@sophia.inria.fr> Hi Amine & all, We are aiming, to merge wimax module into ns-3-dev before the end of next week. In order to get the merge go smoothly and to anticipate eventual problems I tested the builds under g++ 3.4.6, 4.0.4, 4.1.2, 4.2.4, 4.3.3 and 4.4.0 from the repository http://code.nsnam.org/iamine/ns-3-wimax-release/. Here are the results: g++ 3.4.6, 4.0.4, 4.1.2: Building error debug and optimized: [698/893] cxx: src/devices/wimax/simple-wimax-channel.cc -> build/debug/src/devices/wimax/simple-wimax-channel_1.o ../src/devices/wimax/simple-ofdm-wimax-phy.cc: In member function `ns3::Ptr ns3::SimpleOfdmWimaxPhy::ConvertBitsToBurst(itpp::bvec, ns3::Ptr)': ../src/devices/wimax/simple-ofdm-wimax-phy.cc:597: warning: converting to `uint8_t' from `double' g++ 4.2.4, 4.3.3 and 4.4.0: everything is green :-) Can you please pull ns-3-dev code into your repository and merge it specially that there are a new testing framework? This will considerably speed up the merging time since it will be easier to provide a patch based on ns-3-dev and you will anticipate eventual small merging problems. Also what is the status of bug 575 which is the only bug left for wimax? Thanks Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Thu Oct 22 02:23:21 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 22 Oct 2009 11:23:21 +0200 Subject: [Ns-developers] Welcome to the ns-3.7 Open Phase In-Reply-To: <200910221218.37806.boyko@iitp.ru> References: <008201ca52bc$86831fb0$93895f10$@washington.edu> <4ADFECD6.1090106@tomh.org> <200910221218.37806.boyko@iitp.ru> Message-ID: <4AE02489.9040802@sophia.inria.fr> Pavel Boyko wrote: > Hi, > > On Thursday 22 October 2009 09:25:42 am Tom Henderson wrote: > >> craigdo at ee.washington.edu wrote: >> >>> Hi All, >>> >>> With the completion of the ns-3.6 release, ns-3-dev has now entered the >>> ns-3.7 open phase. This means that ns-3-dev is now open for routine >>> checkins and changes. >>> > > Hi Pavel, > Well, does anybody have proposals about ns-3.7 release focus and goals apart > of extensive merging contributed models & bugfixing week? I have two. > Yes and I will send it soon. > First, ns-3.6 wifi model is sick. 14 of 76 open bugs are wifi specific, some of > them are really serious. There are definitely not enough system tests for such > 76 open bugs is a high number I think and we should reduce this number, that's why we will limit merging time to 4 weeks from yesterday, after which we won't allow big changes/merges and we will focus on debugging and testing. > complex model. Moreover, upcoming wimax merge will bring new bugs for sure. > The merged code will be reviewed by at least 2 persons before merging, and we will make sure that the code compiles and runs smoothly and that it is as bug free as possible. > Also we have alternative and potentially better wifi PHY model still unmerged > You can propose it for merging in this release, but your code has to be reviewed as specified above and you have only 4 weeks left (don't come in the last week because you will have high risk that your merge will be for next release). > to the main tree. Should we announce ns-3.7 motto to be "Bugfree Wireless" and > especially appreciate all wireless fixes & contributions? > Yes a bug free NS-3.7 release, after November 18th, we will focus only on cleaning, fixing bugs and eventually adding small self contained, bug free features (after reviews and acceptation from maintainers). > Second, ns-3.6 performance is unsatisfactory. I am practically unable to > simulate more then 100 wifi stations in meaningful scenarios, see also > http://www.nsnam.org/workshops/wns3-2009/talks/ns-3-scalability.pdf . > Profiles show extensive potential for optimizations. Also we have unimplemented > gsoc09 proposal for SNS optimization > (http://www.nsnam.org/wiki/index.php/GSOC2009Projects) > Initial multithreaded and MPI NS-3 versions are on the table and potentially > are very useful. So, should we announce ns-3.7 motto to be "Unlimited > Performance" and especially appreciate all performance/capacity optimizations > and contributions? > I'm not sure that multithreaded ns-3 makes it really faster, if someone proves the contrary, I have no objection on that. We would be happy to have contributions that will speed up ns-3, do you have any proposal/idea? any code? > What do you think? > > Pavel > > >> I think we all agree that doing more things earlier in the release cycle >> will help improve the process and hopefully we can all support Faker in >> that regard. >> >> - Tom >> > > Best regads Faker Moatamri From mathieu.lacage at sophia.inria.fr Thu Oct 22 02:31:58 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 22 Oct 2009 02:31:58 -0700 Subject: [Ns-developers] buildbot failure in NsNam on cygwin-g++ Message-ID: <200910220931.n9M9Vwsk008927@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of cygwin-g++ on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/cygwin-g%2B%2B/builds/191 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: cygwin Build Reason: The web-page 'force build' button was pressed by 'craigdo': test before release Build Source Stamp: 0c8d1f5e0ffa Blamelist: BUILD FAILED: failed failed slave lost sincerely, -The Buildbot From boyko at iitp.ru Thu Oct 22 04:08:34 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Thu, 22 Oct 2009 15:08:34 +0400 Subject: [Ns-developers] Welcome to the ns-3.7 Open Phase In-Reply-To: <4AE02489.9040802@sophia.inria.fr> References: <008201ca52bc$86831fb0$93895f10$@washington.edu> <200910221218.37806.boyko@iitp.ru> <4AE02489.9040802@sophia.inria.fr> Message-ID: <200910221508.34818.boyko@iitp.ru> Hi, Faker, thank you for quick response. > > Also we have alternative and potentially better wifi PHY model still > > unmerged > > You can propose it for merging in this release, but your code has to be > reviewed as specified above and you have only 4 weeks left (don't come > in the last week because you will have high risk that your merge will be > for next release). I mean wifiex model by Timo Bingmann (http://code.nsnam.org/timob/ns-3- wifiex/). Timo, do you plan to support its merge into the mainline? > Yes a bug free NS-3.7 release, after November 18th, we will focus only > on cleaning, fixing bugs and eventually adding small self contained, bug > free features (after reviews and acceptation from maintainers). Ok, now I see your ns-3.7 release goal, thank you. > I'm not sure that multithreaded ns-3 makes it really faster, Potentially it does, look at qualnet. > if someone > proves the contrary, I have no objection on that. We would be happy to > have contributions that will speed up ns-3, do you have any > proposal/idea? any code? We have posted some optimization patches as bugs and will sure post/push more. But we can't critically optimize ns by ourself, now I am talking about the need of coordinated community effort. M.b. I'm too idealistic about this and ns-3.7 will be made of available independent contributions as ns-3.6 is. Pavel From tomh at tomh.org Thu Oct 22 06:11:23 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 22 Oct 2009 06:11:23 -0700 Subject: [Ns-developers] Welcome to the ns-3.7 Open Phase In-Reply-To: <200910221218.37806.boyko@iitp.ru> References: <008201ca52bc$86831fb0$93895f10$@washington.edu> <4ADFECD6.1090106@tomh.org> <200910221218.37806.boyko@iitp.ru> Message-ID: <4AE059FB.6040609@tomh.org> Pavel Boyko wrote: > Hi, > > On Thursday 22 October 2009 09:25:42 am Tom Henderson wrote: >> craigdo at ee.washington.edu wrote: >>> Hi All, >>> >>> With the completion of the ns-3.6 release, ns-3-dev has now entered the >>> ns-3.7 open phase. This means that ns-3-dev is now open for routine >>> checkins and changes. > > Well, does anybody have proposals about ns-3.7 release focus and goals apart > of extensive merging contributed models & bugfixing week? I have two. > > First, ns-3.6 wifi model is sick. 14 of 76 open bugs are wifi specific, some of > them are really serious. There are definitely not enough system tests for such > complex model. Moreover, upcoming wimax merge will bring new bugs for sure. > Also we have alternative and potentially better wifi PHY model still unmerged > to the main tree. Should we announce ns-3.7 motto to be "Bugfree Wireless" and > especially appreciate all wireless fixes & contributions? > > Second, ns-3.6 performance is unsatisfactory. I am practically unable to > simulate more then 100 wifi stations in meaningful scenarios, see also > http://www.nsnam.org/workshops/wns3-2009/talks/ns-3-scalability.pdf . > Profiles show extensive potential for optimizations. Also we have unimplemented > gsoc09 proposal for SNS optimization > (http://www.nsnam.org/wiki/index.php/GSOC2009Projects) > Initial multithreaded and MPI NS-3 versions are on the table and potentially > are very useful. So, should we announce ns-3.7 motto to be "Unlimited > Performance" and especially appreciate all performance/capacity optimizations > and contributions? > > What do you think? Fixing bugs is at the top of my list. Also, improving usability in the areas of statistics, topologies/helpers, and configuration management. There are a lot of loose ends that have accumulated and I wouldn't mind just focusing on them for a while. However, I do not want to get in the way of new models that are ready to go in now. So, I think that a shorter open merge phase is a good way to handle this for now. Regarding wifi, Mathieu sent a note out to delegate maintainership to a few people; maybe you and the others could get together and propose to Faker a plan for either dealing with or deferring the open wifi issues, including wifiex and performance profiling results? Regarding performance, Josh and George are trying to prepare the MPI repository for a merge proposal; they told me that they are evaluating it and testing it against some larger topologies. However, I have been told that Guillaume's multithreaded repo will not be ready for this release cycle. Anyway, performance profiling is certainly in scope and I think Craig will be able to help in this area. One thing we have lacked in the past is users contributing their large test cases so we can look at the large simulations that people care about. Finally, regarding bugs and model validation, now that we have the new test framework in place, I hope that we can use it to promote more testing before and during the merge cycle. The gold standard so far in how to use this has been Tom Wambold's packetbb test suite (src/node/packetbb-test-suite.cc). Where possible, it would be nice if people who made patches to bugs contributed the test case in the form of an ns-3 test that could slide into the framework with the bugfix patch. Regards, Tom From vincent at clarinet.u-strasbg.fr Thu Oct 22 06:35:01 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Thu, 22 Oct 2009 15:35:01 +0200 Subject: [Ns-developers] IPv6 extension support Message-ID: <4AE05F85.7040107@clarinet.u-strasbg.fr> Hi all, I have found some time to integrate IPv6 extensions contributed last year by David Gross during a placement and some improvement patch from Fabian Mauchle. I will release source by the end of the week. And I propose this feature for a merge in ns-3.7. Basically it support parsing IPv6 extensions and options. The most useful stuff is fragmentation and routing type 0 (deprecated and dangerous extension but we include it for some case studies). Other extensions can be parsed (hop-by-hop, AH, ESP, ...) but for now there are no special processing. IPv6 extension support is the base for an future implementation of Mobile IPv6. If I remember correctly someone (Fabian Mauchle ?) worked on a MIPv6 implementation last year. Best regards, -- Sebastien From faker.moatamri at sophia.inria.fr Thu Oct 22 06:37:33 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 22 Oct 2009 15:37:33 +0200 Subject: [Ns-developers] Very old repositories Message-ID: <4AE0601D.4050206@sophia.inria.fr> Hi Tom & all, In the repositories page we have repositories that remained untouched from one day to 2 years! http://code.nsnam.org/?sort=lastchange Should we remove let's say repositories that hasn't been touched for 1 year or more with owner's permission if any? Best regards Faker Moatamri From mk.banchi at gmail.com Thu Oct 22 06:45:29 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 22 Oct 2009 15:45:29 +0200 Subject: [Ns-developers] Bug 602 status Message-ID: <97CF7656-F30C-4E65-A1DB-8721AE2FCEEB@gmail.com> A non-text attachment was scrubbed... Name: QosRetryCounters.patch Type: application/octet-stream Size: 19212 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091022/e7c6b52d/QosRetryCounters.obj -------------- next part -------------- This is a possible patch for bug 602. Please take a look at it. 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/20091022/e7c6b52d/smime.bin From mazo at iitp.ru Thu Oct 22 07:01:51 2009 From: mazo at iitp.ru (Andrey Mazo) Date: Thu, 22 Oct 2009 18:01:51 +0400 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE0601D.4050206@sophia.inria.fr> References: <4AE0601D.4050206@sophia.inria.fr> Message-ID: > In the repositories page we have repositories that remained untouched > from one day to 2 years! > http://code.nsnam.org/?sort=lastchange > Should we remove let's say repositories that hasn't been touched for 1 > year or more with owner's permission if any? I'd like to remove the following kinds of repositories: 1) "*-old" repositories 2) all repositories, already merged into ns-3-dev 3) all ns-3{rc,RC}* repositories -- Andrey Mazo. From faker.moatamri at sophia.inria.fr Thu Oct 22 07:12:47 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 22 Oct 2009 16:12:47 +0200 Subject: [Ns-developers] Very old repositories In-Reply-To: References: <4AE0601D.4050206@sophia.inria.fr> Message-ID: <4AE0685F.8080809@sophia.inria.fr> Andrey Mazo wrote: >> In the repositories page we have repositories that remained untouched >> from one day to 2 years! >> http://code.nsnam.org/?sort=lastchange >> Should we remove let's say repositories that hasn't been touched for 1 >> year or more with owner's permission if any? > I'd like to remove the following kinds of repositories: > 1) "*-old" repositories > 2) all repositories, already merged into ns-3-dev > 3) all ns-3{rc,RC}* repositories > > +1 from me if we are sure that the removed repositories are useless. Others? From mk.banchi at gmail.com Thu Oct 22 07:16:43 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 22 Oct 2009 16:16:43 +0200 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE0685F.8080809@sophia.inria.fr> References: <4AE0601D.4050206@sophia.inria.fr> <4AE0685F.8080809@sophia.inria.fr> Message-ID: Il giorno 22/ott/09, alle ore 16:12, Faker Moatamri ha scritto: > Andrey Mazo wrote: >>> In the repositories page we have repositories that remained >>> untouched >>> from one day to 2 years! >>> http://code.nsnam.org/?sort=lastchange >>> Should we remove let's say repositories that hasn't been touched >>> for 1 >>> year or more with owner's permission if any? >> I'd like to remove the following kinds of repositories: >> 1) "*-old" repositories >> 2) all repositories, already merged into ns-3-dev >> 3) all ns-3{rc,RC}* repositories >> >> > +1 from me if we are sure that the removed repositories are useless. > Others? +1 from me 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/20091022/7ac60501/smime.bin From faker.moatamri at sophia.inria.fr Thu Oct 22 07:22:25 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 22 Oct 2009 16:22:25 +0200 Subject: [Ns-developers] IPv6 extension support In-Reply-To: <4AE05F85.7040107@clarinet.u-strasbg.fr> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> Message-ID: <4AE06AA1.5010500@sophia.inria.fr> Sebastien Vincent wrote: > Hi all, > > I have found some time to integrate IPv6 extensions contributed last > year by David Gross during a placement and some improvement patch from > Fabian Mauchle. > cool > I will release source by the end of the week. And I propose this > feature for a merge in ns-3.7. > Yes sure, please ask for a review as soon as your code is ready. Here are guidelines (just in case you didn't hear about it) for code submission: http://www.nsnam.org/code-submission.html. > Basically it support parsing IPv6 extensions and options. The most > useful stuff is fragmentation and routing type 0 (deprecated and > dangerous extension but we include it for some case studies). Other > extensions can be parsed (hop-by-hop, AH, ESP, ...) but for now there > are no special processing. > IPv6 extension support is the base for an future implementation of > Mobile IPv6. If I remember correctly someone (Fabian Mauchle ?) worked > on a MIPv6 implementation last year. > > Best regards, > -- > Sebastien > Best regards Faker Moatamri From Faker.Moatamri at sophia.inria.fr Thu Oct 22 13:47:47 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Thu, 22 Oct 2009 22:47:47 +0200 (CEST) Subject: [Ns-developers] Ad hoc On Demand Distance Vector (AODV) routing protocol code review Message-ID: <59342.217.128.71.243.1256244467.squirrel@imap-sop.inria.fr> 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? Code review: Overall the code is good, some changes are expected: - Minor coding style changes - More doxygen and some documentation needs to be doxygen style - Testing should be conform with the new testing framework, tests are still using the old testing framework - Please make sure to clean memory: Ptr variables and created classes should be cleaned - aodv.h should contain more details about the implementation, what is done, what is left to do... - Member variable should never be public unless you have a good reason to do that Compiling and testing: I tried compiling under linux with g++ 3.4.6, 4.0.4, 4.1.2, 4.2.4, 4.3.3 and 4.4.0 from the repository https://forge.wenos.ru/hgprojects/ns3aodv/ Result using buildbot: -g++ 3.4.6 , 4.0.4, 4.1.2, 4.2.4, 4.3.3 and 4.4.0: all the builds finished properly but the testing failed: ... FAIL: TestSuite ns3-tcp-cwnd ... CRASH: Example csma/csma-bridge CRASH: Example csma/csma-bridge-one-hop CRASH: Example csma/csma-broadcast CRASH: Example csma/csma-one-subnet CRASH: Example csma/csma-multicast CRASH: Example csma/csma-ping CRASH: Example csma/csma-raw-ip-socket CRASH: Example error-model/simple-error-model CRASH: Example ipv6/icmpv6-redirect CRASH: Example ipv6/ping6 CRASH: Example ipv6/radvd CRASH: Example ipv6/radvd-two-prefix ... CRASH: Example realtime/realtime-udp-echo CRASH: Example routing/dynamic-global-routing CRASH: Example routing/global-injection-slash32 CRASH: Example routing/global-routing-slash32 CRASH: Example routing/mixed-global-routing PASS: Example routing/nix-simple CRASH: Example routing/simple-alternate-routing CRASH: Example routing/simple-global-routing CRASH: Example routing/simple-point-to-point-olsr CRASH: Example routing/simple-routing-ping6 CRASH: Example routing/static-routing-slash32 PASS: Example stats/wifi-example-sim CRASH: Example tcp/star CRASH: Example tcp/tcp-large-transfer CRASH: Example tcp/tcp-star-server CRASH: Example tunneling/virtual-net-device PASS: Example tutorial/first PASS: Example tutorial/hello-simulator CRASH: Example tutorial/second CRASH: Example tutorial/third CRASH: Example udp/udp-echo CRASH: Example wireless/simple-wifi-frame-aggregation CRASH: Example wireless/wifi-ap --verbose=0 CRASH: Example wireless/wifi-simple-adhoc PASS: Example wireless/mixed-wireless CRASH: Example wireless/wifi-simple-infra CRASH: Example wireless/wifi-simple-interference CRASH: Example wireless/wifi-wired-bridging CRASH: Example csma/csma-star PASS: Example wireless/wifi-simple-adhoc-grid PASS: Example mesh/mesh 57 of 94 tests passed (57 passed, 1 failed, 36 crashed, 0 valgrind errors) I tried to compile manually with gcc 4.3.3 all tests passed except FAIL: TestSuite ns3-tcp-cwnd For regression and valgrind tests output is always "target 'aodv2' does not exist", Gustavo any Idea? Best regards Faker Moatamri From mathieu.lacage at sophia.inria.fr Thu Oct 22 17:00:04 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 22 Oct 2009 17:00:04 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.0 Message-ID: <200910230000.n9N004cH001715@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.0/builds/140 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed hg sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Thu Oct 22 17:00:07 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Thu, 22 Oct 2009 17:00:07 -0700 Subject: [Ns-developers] buildbot failure in NsNam on osx-ppc-g++-4.2 Message-ID: <200910230000.n9N007Ii001718@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of osx-ppc-g++-4.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/osx-ppc-g%2B%2B-4.2/builds/139 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: darwin-ppc Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed hg sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Fri Oct 23 00:42:51 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 23 Oct 2009 09:42:51 +0200 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: <1256283771.2546.1.camel@localhost.localdomain> On Thu, 2009-10-22 at 22:47 +0200, Faker.Moatamri at sophia.inria.fr wrote: Most of the following are probably just because this tree has not been updated to the latest ns-3-dev which should fix these issues. > ... > FAIL: TestSuite ns3-tcp-cwnd > ... > CRASH: Example csma/csma-bridge > CRASH: Example csma/csma-bridge-one-hop > CRASH: Example csma/csma-broadcast > CRASH: Example csma/csma-one-subnet > CRASH: Example csma/csma-multicast > CRASH: Example csma/csma-ping CRASH: Example > csma/csma-raw-ip-socket > CRASH: Example error-model/simple-error-model > CRASH: Example ipv6/icmpv6-redirect > CRASH: Example ipv6/ping6 > CRASH: Example ipv6/radvd > CRASH: Example ipv6/radvd-two-prefix > ... > CRASH: Example realtime/realtime-udp-echo > CRASH: Example routing/dynamic-global-routing > CRASH: Example routing/global-injection-slash32 > CRASH: Example routing/global-routing-slash32 > CRASH: Example routing/mixed-global-routing > PASS: Example routing/nix-simple > CRASH: Example routing/simple-alternate-routing > CRASH: Example routing/simple-global-routing > CRASH: Example routing/simple-point-to-point-olsr > CRASH: Example routing/simple-routing-ping6 > CRASH: Example routing/static-routing-slash32 > PASS: Example stats/wifi-example-sim > CRASH: Example tcp/star > CRASH: Example tcp/tcp-large-transfer > CRASH: Example tcp/tcp-star-server > CRASH: Example tunneling/virtual-net-device > PASS: Example tutorial/first > PASS: Example tutorial/hello-simulator > CRASH: Example tutorial/second > CRASH: Example tutorial/third > CRASH: Example udp/udp-echo > CRASH: Example wireless/simple-wifi-frame-aggregation > CRASH: Example wireless/wifi-ap --verbose=0 > CRASH: Example wireless/wifi-simple-adhoc > PASS: Example wireless/mixed-wireless > CRASH: Example wireless/wifi-simple-infra > CRASH: Example wireless/wifi-simple-interference > CRASH: Example wireless/wifi-wired-bridging > CRASH: Example csma/csma-star > PASS: Example wireless/wifi-simple-adhoc-grid > PASS: Example mesh/mesh Mathieu From andreev at iitp.ru Fri Oct 23 00:52:59 2009 From: andreev at iitp.ru (Kirill Andreev) Date: Fri, 23 Oct 2009 11:52:59 +0400 Subject: [Ns-developers] Ad hoc On Demand Distance Vector (AODV) routing protocol code review Message-ID: >On Thu, 2009-10-22 at 22:47 +0200, Faker.Moatamri at sophia.inria.fr wrote: >Most of the following are probably just because this tree has not been >updated to the latest ns-3-dev which should fix these issues. A tree shall be updated at the beginning of the next week and next patchset with minor changes and fixes will be uploaded for review. Regards, Kirill Andreev, IITP RAS From faker.moatamri at sophia.inria.fr Fri Oct 23 00:52:33 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 23 Oct 2009 09:52:33 +0200 Subject: [Ns-developers] Ad hoc On Demand Distance Vector (AODV) routing protocol code review In-Reply-To: <1256283771.2546.1.camel@localhost.localdomain> References: <59342.217.128.71.243.1256244467.squirrel@imap-sop.inria.fr> <1256283771.2546.1.camel@localhost.localdomain> Message-ID: <4AE160C1.9030902@sophia.inria.fr> Mathieu Lacage wrote: > On Thu, 2009-10-22 at 22:47 +0200, Faker.Moatamri at sophia.inria.fr wrote: > > Most of the following are probably just because this tree has not been > updated to the latest ns-3-dev which should fix these issues. > > what is weird is that when I compile and run manually, all the crashes disappear and we are left with only one test failing! Builbot might have something to do with that? Faker Moatamri From faker.moatamri at sophia.inria.fr Fri Oct 23 00:59:27 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 23 Oct 2009 09:59:27 +0200 Subject: [Ns-developers] NS-3.7 Release Message-ID: <4AE1625F.6080307@sophia.inria.fr> Hi all, As outlined by Craig and Tom, I will be the one helping the community to get a smooth ns-3.7 release up and running by January 20th. Since the bug list of ns-3-dev is relatively full, we will limit the merging period to November 18th, date after which no more merges are allowed, only small features might be included, if they have limited impact on existing code and are self contained. This way we will focus more on fixing bugs and getting the code as clean as possible. Here is a more detailed time schedule for ns-3.7 release: 1.October 21 -- ns-3.7 Open phase begins; 2.October 21 ? Ns-3-dev open for new features merge and all kind of changes: -Review the code that might be merged -Clean up the bug tracker: solve as much bugs as possible -Merge the new features that has +1 and from maintainers -Accept new code for review, they will be scheduled for next release 3.November 18 ? Deadline for new feature merge: -after this deadline, no more merges will be accepted, and no more new feature review requests are accepted 4.November 18 ? Begin the phase of small feature development and bug fixing: -We can accept limited, small, self contained changes/features to ns-3-dev and to merged new features. As specified before, no more merges are accepted. -Review the code to be merged for next releases -Cleanup the ns-3-dev bug tracker, solve as much bugs as possible 5.December 16 ? Small feature development and bug fixing ends 6.December 16 -- Open phase ends; 7.December 16 -- Maintenance phase begins; -We accept only bug fixes for ns-3-dev and for merged code. Small features might be accepted but will not be guaranteed acceptation (if the code is good of course) as in the previous phase. 8.January 6 -- Maintenance phase ends; 9.January 6 -- Code freeze phase begins; -No more features are accepted, only bug fixes are accepted 10.January 6 -- ns-3.7-RC1; 11.January 8 -- ns-3.7-RC2; 12.January 12 -- ns-3.7-RC3; 13.January 15 -- ns-3.7-RC4; 14.January 20 -- ns-3.7 posted; 15.January 20 -- Code freeze phase ends; 16.January 20 -- ns-3.8 Open phase begins We are now in the open phase, so if you have a new feature you wish to add, now it's the time. Thanks Best regards Faker Moatamri From mk.banchi at gmail.com Fri Oct 23 02:36:09 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 23 Oct 2009 11:36:09 +0200 Subject: [Ns-developers] Bug 602 status In-Reply-To: <1256284759.3008.4.camel@localhost.localdomain> References: <97CF7656-F30C-4E65-A1DB-8721AE2FCEEB@gmail.com> <1256284759.3008.4.camel@localhost.localdomain> Message-ID: Il giorno 23/ott/09, alle ore 09:59, Mathieu Lacage ha scritto: > I think it might be better to just change the signature of > WifiRemoteStationManager::Lookup and add an enum AccessClass argument. > Every caller would need to be modified to pass the right value. non- > qos > callers would be required to pass AC_BE unconditionally. > > Mathieu > How could that help us? could you be a little more specific? Thank you 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/20091023/72748342/smime.bin From faker.moatamri at sophia.inria.fr Fri Oct 23 02:40:16 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 23 Oct 2009 11:40:16 +0200 Subject: [Ns-developers] Bug 602 status In-Reply-To: <97CF7656-F30C-4E65-A1DB-8721AE2FCEEB@gmail.com> References: <97CF7656-F30C-4E65-A1DB-8721AE2FCEEB@gmail.com> Message-ID: <4AE17A00.6000603@sophia.inria.fr> Mirko Banchi wrote: > > > This is a possible patch for bug 602. Please take a look at it. > Hi Mirko, Thanks for submitting the patch. The patch looks good for me but I have some remarks: - In mac-low.cc the same piece of code replacing station->ReportDataFailed() is repeated 3 times using copy & paste, can you create a small function instead or encapsulate the behavior in another routine. You can do the same for ReportDataOk, ReportRtsFailed... -In wifi-remote-station-manager.cc: -line 811, please do not use NS_ASSERT (false) and use instead NS_FATAL_ERROR and include a comprehensive message -Also the code if (ac == AC_UNDEF) .... is repeated several times using copy and paste, sometimes with minor changes like *mqosSsrc.find (ac)->second = 0 instead of ++, please encapsulate this piece of code into a function with comprehensive name -Line 927: //How should we use ac parameter here? I have no answer for that, do you have one? some plans?? Other than that, the patch is cool for me, once you finish fixing the above you will get +1 from me. Someone else has comments about the patch? Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Fri Oct 23 02:44:24 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 23 Oct 2009 11:44:24 +0200 Subject: [Ns-developers] Bug 622 review result and merge to ns-3-dev Message-ID: <4AE17AF8.1090701@sophia.inria.fr> Hi Antti and All, I've been through the patch proposed for bug 622. This patch makes it possible to have comprehensive names of pcap files. I have been through this patch and I think small coding style stuff has to be fixed: -Coding style (space after parentheses, space before and after != & = ...) Other than that +1 for patch to be added to ns-3-dev. It already got +1 from Tom. Anyone has comments about the patch? Thanks Faker Moatamri From andreev at iitp.ru Fri Oct 23 03:00:56 2009 From: andreev at iitp.ru (Kirill Andreev) Date: Fri, 23 Oct 2009 14:00:56 +0400 Subject: [Ns-developers] Bug 602 status Message-ID: >>Mirko Banchi wrote: >>This is a possible patch for bug 602. Please take a look at it. >Hi Mirko, >Thanks for submitting the patch. The patch looks good for me but I have >some remarks: >- In mac-low.cc the same piece of code replacing >station->ReportDataFailed() is repeated 3 times using copy & paste, can >you create a small function instead or encapsulate the behavior in >another routine. You can do the same for ReportDataOk, ReportRtsFailed... >-In wifi-remote-station-manager.cc: >-line 811, please do not use NS_ASSERT (false) and use instead >NS_FATAL_ERROR and include a comprehensive message >-Also the code if (ac == AC_UNDEF) .... is repeated several times >using copy and paste, sometimes with minor changes like >*mqosSsrc.find (ac)->second = 0 instead of ++, please encapsulate >this piece of code into a function with comprehensive name >-Line 927: //How should we use ac parameter here? I have no answer >for that, do you have one? some plans?? >Other than that, the patch is cool for me, once you finish fixing the >above you will get +1 from me. >Someone else has comments about the patch? >Best regards >Faker Moatamri Hi!, in addition to said above, could you, please, fix this copy&paste in WifiRemoteStationManager class: TracedValue m_ssrc; TracedValue m_slrc; /* voice access class retry counters */ TracedValue m_voSsrc; TracedValue m_voSlrc; /* video access class retry counters */ TracedValue m_viSsrc; TracedValue m_viSlrc; /* best-effort access class retry counters */ TracedValue m_beSsrc; TracedValue m_beSlrc; /* background access class retry counters */ TracedValue m_bkSsrc; TracedValue m_bkSlrc;. May be is it better to make std::map and call traced callback at each change of each retry counter like the following TracedCallback m_slrcCallback; and call m_slrcCallback(ac, retryCount)? Is it worth to replace this huge set of traced values (and trace sources in GetTypeId) with two maps and two traced callbacks? It seems to me that fixed number of available access classes is not good here. Regards, Kirill Andreev, IITP RAS From mk.banchi at gmail.com Fri Oct 23 04:43:26 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 23 Oct 2009 13:43:26 +0200 Subject: [Ns-developers] Bug 602 status In-Reply-To: <4AE17A00.6000603@sophia.inria.fr> References: <97CF7656-F30C-4E65-A1DB-8721AE2FCEEB@gmail.com> <4AE17A00.6000603@sophia.inria.fr> Message-ID: <20DA0EF1-579D-4358-B23C-3DFC2AB680E0@gmail.com> Il giorno 23/ott/09, alle ore 11:40, Faker Moatamri ha scritto: > Mirko Banchi wrote: >> >> >> This is a possible patch for bug 602. Please take a look at it. >> > Hi Mirko, > Thanks for submitting the patch. The patch looks good for me but I > have some remarks: > - In mac-low.cc the same piece of code replacing station- > >ReportDataFailed() is repeated 3 times using copy & paste, can you > create a small function instead or encapsulate the behavior in > another routine. You can do the same for ReportDataOk, > ReportRtsFailed... Yes, you are right. i'll create two functions ReportDataFailed, ReportDataOk that could be useful in order to avoid future copy and paste. About ReportRtsFailed and ReportCtsOk i think that there is no need to create separate routine because they will use only one time: when we'll receive a Cts and when a CtsTimeout occurs. > -In wifi-remote-station-manager.cc: > -line 811, please do not use NS_ASSERT (false) and use instead > NS_FATAL_ERROR and include a comprehensive message Ok. > -Also the code if (ac == AC_UNDEF) .... is repeated several times > using copy and paste, sometimes with minor changes like > *mqosSsrc.find (ac)->second = 0 instead of ++, please encapsulate > this piece of code into a function with comprehensive name I agree. I'll define two function: WifiRemoteStation::UpdateSsrcCounter (enum AccessClass ac, bool reset) WifiRemoteStation::UpdateSlrcCounter (enum AccessClass ac, bool reset) > -Line 927: //How should we use ac parameter here? I have no answer > for that, do you have one? some plans?? Unfortunately i have no idea. Maybe we should ask Mathieu or other authors of wifi managers. 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/20091023/9b3c446a/smime.bin From mk.banchi at gmail.com Fri Oct 23 04:50:23 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 23 Oct 2009 13:50:23 +0200 Subject: [Ns-developers] Bug 602 status In-Reply-To: References: Message-ID: <99D6F882-92C2-4473-B5A7-F847B2F156BD@gmail.com> Il giorno 23/ott/09, alle ore 12:00, Kirill Andreev ha scritto: > > Hi!, in addition to said above, could you, please, fix this > copy&paste in WifiRemoteStationManager class: > > TracedValue m_ssrc; > TracedValue m_slrc; > /* voice access class retry counters */ > TracedValue m_voSsrc; > TracedValue m_voSlrc; > /* video access class retry counters */ > TracedValue m_viSsrc; > TracedValue m_viSlrc; > /* best-effort access class retry counters */ > TracedValue m_beSsrc; > TracedValue m_beSlrc; > /* background access class retry counters */ > TracedValue m_bkSsrc; > TracedValue m_bkSlrc;. > > May be is it better to make std::map and call > traced callback at each change of each retry counter like the > following > TracedCallback m_slrcCallback; and call > m_slrcCallback(ac, retryCount)? > > Is it worth to replace this huge set of traced values (and trace > sources in GetTypeId) with two maps and two traced callbacks? > It seems to me that fixed number of available access classes is not > good here. Maybe the best way is to add in future other counters for the new access classes. The total number of possible access classes is 8; 9 if we consider AC_BE_NQOS access class. If this number was variable i'd agree with you, but in this condition i think that use of traced callback is tedius. 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/20091023/8f3de717/smime.bin From mk.banchi at gmail.com Fri Oct 23 05:32:29 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 23 Oct 2009 14:32:29 +0200 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: References: Message-ID: Here is the patch for bug #602 with the corrections that Faker suggested. If there are no objections or advices i'll apply it. Thank you all. Mirko -------------- next part -------------- A non-text attachment was scrubbed... Name: QosRetryCounters.patch Type: application/octet-stream Size: 34812 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091023/3ff2b77a/QosRetryCounters-0001.obj -------------- next part -------------- -- 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/20091023/3ff2b77a/smime-0001.bin From andreev at iitp.ru Fri Oct 23 05:48:26 2009 From: andreev at iitp.ru (Kirill Andreev) Date: Fri, 23 Oct 2009 16:48:26 +0400 Subject: [Ns-developers] Bug 602 status (patch) Message-ID: >Here is the patch for bug #602 with the corrections that Faker suggested. >If there are no objections or advices i'll apply it. > >Thank you all. > >Mirko To apply a patch you need one more +1 from Pavel Boyko, but he is away till monday. or by Nicola Baldo. I am doing on behalf of Pavel Boyko because he is away now. I still do not agree with copy-paste in WifiRemoteStationManager Regard, Kirill Andreev, IITP RAS From craigdo at ee.washington.edu Fri Oct 23 10:19:34 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Fri, 23 Oct 2009 10:19:34 -0700 Subject: [Ns-developers] Bug 622 review result and merge to ns-3-dev In-Reply-To: <4AE17AF8.1090701@sophia.inria.fr> References: <4AE17AF8.1090701@sophia.inria.fr> Message-ID: <01a001ca5404$fe5d2500$fb176f00$@washington.edu> > Hi Antti and All, > I've been through the patch proposed for bug 622. This patch makes it > possible to have comprehensive names of pcap files. > I have been through this patch and I think small coding style stuff has > to be fixed: > -Coding style (space after parentheses, space before and after != & = > ...) > Other than that +1 for patch to be added to ns-3-dev. It already got +1 > from Tom. > Anyone has comments about the patch? This patch only adds names support to the csma and point-to-point helpers. If it were added as-is it would make the trace-enabled helpers inconsistent for no particular reason. This is bad. For consistency, this needs to be extended to all helpers that generate trace files -- not just two. There is already lots of code duplicated across the helpers. Adding names support this way is going to make it worse. It's time to break this cycle. For a number of reasons, I think we factor the implementation of the current common functionality. We can then implement object names support once, consistently, across the helpers, and remove all of the almost identical code spread across many of the helpers. I think it should actually be more difficult to implement this inconsistently across helpers than consistently using a common class. I volunteer to make the required changes and write the (cough) documentation. -- Craig From nbaldo at cttc.es Fri Oct 23 10:26:14 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 23 Oct 2009 19:26:14 +0200 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: References: Message-ID: <4AE1E736.6040501@cttc.es> Hi Mirco & all, I understand that Bug 602 is an issue and I acknowledge your effort in trying to solve that; however, I am not very convinced about it. I would rather propose to change WifiRemoteStationManager so that it maintains an instance of WifiRemoteStation for every receiver address and access category (tid). This would require the following modifications: - add a new member variable to WifiRemoteStation: uint8_t m_tid; - change this member method of WifiRemoteStationManager WifiRemoteStation *Lookup (Mac48Address address) to the following: WifiRemoteStation *Lookup (Mac48Address address, uint8_t tid) - change 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. BTW, I've just been re-reading prior emails on this subject, and I get the impression that this is similar to what Mathieu was proposing. What do you think? Regards, Nicola Kirill Andreev wrote: >> Here is the patch for bug #602 with the corrections that Faker suggested. >> If there are no objections or advices i'll apply it. >> >> Thank you all. >> >> Mirko > > To apply a patch you need one more +1 from Pavel Boyko, but he is away > till monday. > or by Nicola Baldo. > I am doing on behalf of Pavel Boyko because he is away now. > I still do not agree with copy-paste in WifiRemoteStationManager > > Regard, > Kirill Andreev, > IITP RAS From jpelkey at gatech.edu Fri Oct 23 11:29:30 2009 From: jpelkey at gatech.edu (jpelkey@gatech.edu) Date: Fri, 23 Oct 2009 14:29:30 -0400 (EDT) Subject: [Ns-developers] nsnam server upgrade In-Reply-To: <569379165.961781256322345068.JavaMail.root@mail8.gatech.edu> Message-ID: <208336261.962991256322569999.JavaMail.root@mail8.gatech.edu> Hi all, We will be upgrading the nsnam server, which hosts the ns-3 website and mercurial repositories, on Monday, October 26. There will be several hours of downtime, and hopefully the upgrade process goes smoothly. Note that all directories under "/home" are backed up daily; however, if you have anything very important (that you haven't already backed up!), I recommend you copy it from the server. I plan to start the upgrade around 14:00 EDT (18:00 UTC). I will send out an email after I'm done. Also note that the server will be getting a new IP, so this may cause some extra delay. -- Josh Pelkey From Faker.Moatamri at sophia.inria.fr Fri Oct 23 13:44:55 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Fri, 23 Oct 2009 22:44:55 +0200 (CEST) Subject: [Ns-developers] Bug 622 review result and merge to ns-3-dev In-Reply-To: <01a001ca5404$fe5d2500$fb176f00$@washington.edu> References: <4AE17AF8.1090701@sophia.inria.fr> <01a001ca5404$fe5d2500$fb176f00$@washington.edu> Message-ID: <60023.217.128.71.243.1256330695.squirrel@imap-sop.inria.fr> > For a number of reasons, I think we factor the implementation of the > current > common functionality. We can then implement object names support once, > consistently, across the helpers, and remove all of the almost identical > code spread across many of the helpers. Actually that's very similar to what I was proposing, if we factor the code and encapsulate it into one method call, it would be much better. I thought about including the file naming functionality in PcapWriter but if you have better idea, it's fine with me (please see my last comment in bug page:http://www.nsnam.org/bugzilla/show_bug.cgi?id=622). > > I think it should actually be more difficult to implement this > inconsistently across helpers than consistently using a common class. > > I volunteer to make the required changes and write the (cough) > documentation. > Thanks craig, we will appreciate that :) > -- Craig > > > > From mathieu.lacage at sophia.inria.fr Fri Oct 23 17:11:51 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 23 Oct 2009 17:11:51 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-3.4.6 Message-ID: <200910240011.n9O0BpOP031082@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-3.4.6 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-3.4.6/builds/209 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Fri Oct 23 17:22:29 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 23 Oct 2009 17:22:29 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.0.4 Message-ID: <200910240022.n9O0MTEZ031103@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.0.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.0.4/builds/195 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Fri Oct 23 17:34:01 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 23 Oct 2009 17:34:01 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.1.2 Message-ID: <200910240034.n9O0Y1UY031108@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.1.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.1.2/builds/215 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Fri Oct 23 17:54:02 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 23 Oct 2009 17:54:02 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.2.4 Message-ID: <200910240054.n9O0s2Uv031128@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.2.4 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.2.4/builds/194 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Fri Oct 23 18:05:42 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 23 Oct 2009 18:05:42 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.3.2 Message-ID: <200910240105.n9O15gYT031146@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.3.2 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.3.2/builds/189 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mathieu.lacage at sophia.inria.fr Fri Oct 23 18:17:00 2009 From: mathieu.lacage at sophia.inria.fr (mathieu.lacage@sophia.inria.fr) Date: Fri, 23 Oct 2009 18:17:00 -0700 Subject: [Ns-developers] buildbot failure in NsNam on fc10-g++-4.4.0 Message-ID: <200910240117.n9O1H08X031152@ns-regression.ee.washington.edu> The Buildbot has detected a new failure of fc10-g++-4.4.0 on NsNam. Full details are available at: http://ns-regression.ee.washington.edu:8010/builders/fc10-g%2B%2B-4.4.0/builds/210 Buildbot URL: http://ns-regression.ee.washington.edu:8010/ Buildslave for this Build: rahan Build Reason: The Nightly scheduler named 'before-work' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell_3 shell_5 shell_6 shell_7 shell_9 shell_10 shell_11 sincerely, -The Buildbot From mk.banchi at gmail.com Sat Oct 24 01:54:54 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sat, 24 Oct 2009 10:54:54 +0200 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <4AE1E736.6040501@cttc.es> References: <4AE1E736.6040501@cttc.es> Message-ID: Il giorno 23/ott/09, alle ore 19:26, Nicola Baldo ha scritto: > Hi Mirco & all, > > I understand that Bug 602 is an issue and I acknowledge your effort > in trying to solve that; however, I am not very convinced about it. > I would rather propose to change WifiRemoteStationManager so that it > maintains an instance of WifiRemoteStation for every receiver > address and access category (tid). This would require the following > modifications: > > - add a new member variable to WifiRemoteStation: > uint8_t m_tid; > > - change this member method of WifiRemoteStationManager > WifiRemoteStation *Lookup (Mac48Address address) > to the following: > WifiRemoteStation *Lookup (Mac48Address address, uint8_t tid) > > - change 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. > > BTW, I've just been re-reading prior emails on this subject, and I > get the impression that this is similar to what Mathieu was proposing. > > What do you think? I think that it could be a solution but i don't understand the advantages in respect to my patch. Moreover, changing signature of WifiRemoteStationManager::Lookup method involves a lot of tedious changes. 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/20091024/57b22f51/smime.bin From mathieu.lacage at sophia.inria.fr Sun Oct 25 01:19:25 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sun, 25 Oct 2009 09:19:25 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: References: <4AE1E736.6040501@cttc.es> Message-ID: <1256458765.2896.2.camel@localhost.localdomain> On Sat, 2009-10-24 at 10:54 +0200, Mirko Banchi wrote: > > I understand that Bug 602 is an issue and I acknowledge your effort > > in trying to solve that; however, I am not very convinced about it. > > I would rather propose to change WifiRemoteStationManager so that it > > maintains an instance of WifiRemoteStation for every receiver agreed. > > address and access category (tid). This would require the following > > modifications: > > > > - add a new member variable to WifiRemoteStation: > > uint8_t m_tid; > > > > - change this member method of WifiRemoteStationManager > > WifiRemoteStation *Lookup (Mac48Address address) > > to the following: > > WifiRemoteStation *Lookup (Mac48Address address, uint8_t tid) > > > > - change 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. > > > > BTW, I've just been re-reading prior emails on this subject, and I > > get the impression that this is similar to what Mathieu was proposing. > > > > What do you think? > > I think that it could be a solution but i don't understand the > advantages in respect to my patch. Moreover, changing signature of > WifiRemoteStationManager::Lookup method involves a lot of tedious > changes. The compiler will trivially catch all of the needed changes as errors so, it's just automated work: you can switch off your brain and get it done in less than 30mins :) If you need access to a nice build machine, I can give you an account on the 8-core/16GB box rahan.inria.fr. Mathieu From mk.banchi at gmail.com Sun Oct 25 03:12:14 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sun, 25 Oct 2009 11:12:14 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <1256458765.2896.2.camel@localhost.localdomain> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> Message-ID: <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> Il giorno 25/ott/09, alle ore 09:19, Mathieu Lacage ha scritto: > On Sat, 2009-10-24 at 10:54 +0200, Mirko Banchi wrote: > >>> I understand that Bug 602 is an issue and I acknowledge your effort >>> in trying to solve that; however, I am not very convinced about it. >>> I would rather propose to change WifiRemoteStationManager so that it >>> maintains an instance of WifiRemoteStation for every receiver > > agreed. > >>> address and access category (tid). This would require the following >>> modifications: >>> >>> - add a new member variable to WifiRemoteStation: >>> uint8_t m_tid; This doens't work. :( The counter must be mainteined for each access class. See section 9.9.1.6 in IEEE802.11 standard. Better a variable like the following: AccessClass m_ac. >>> >>> - change this member method of WifiRemoteStationManager >>> WifiRemoteStation *Lookup (Mac48Address address) >>> to the following: >>> WifiRemoteStation *Lookup (Mac48Address address, uint8_t tid) The same of above: WifiRemoteStation *Lookup (Mac48Address address, AccessClass ac) > The compiler will trivially catch all of the needed changes as errors > so, it's just automated work: you can switch off your brain and get it > done in less than 30mins :) > > If you need access to a nice build machine, I can give you an > account on > the 8-core/16GB box rahan.inria.fr. > Ok! If i need it i'll ask you! Thank you. 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/20091025/6b4a0798/smime.bin From mathieu.lacage at sophia.inria.fr Sun Oct 25 10:31:23 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sun, 25 Oct 2009 18:31:23 +0100 Subject: [Ns-developers] Tunneling Protocols In-Reply-To: <001901ca52e6$d7a85750$86f905f0$@ch> References: <008201ca52bc$86831fb0$93895f10$@washington.edu> <001901ca52e6$d7a85750$86f905f0$@ch> Message-ID: <1256491883.3384.3.camel@localhost.localdomain> The wimax people have told me they did work on something like that. Amine, what is the status of your tunneling work ? Mathieu On Thu, 2009-10-22 at 09:11 +0200, Fabian Mauchle wrote: > Hi All > > I'm currently working on simulations which include some IP tunneling. There > is only one example which implements a UDP tunnel, so I started to create my > own implementations (IPoverIP and others). I just wondered if anybody else > has put some effort in implementing tunneling protocols. > > If not, I will try to create kind of a 'tunneling framework' to implement > different protocols, and provide simple tunnel setup thru helpers. > > Regards, > > > Fabian Mauchle > > Institute for Internet Technologies and Applications > University of Applied Sciences Rapperswil, Switzerland > > > > From tomh at tomh.org Sun Oct 25 22:49:20 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 25 Oct 2009 22:49:20 -0700 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE0601D.4050206@sophia.inria.fr> References: <4AE0601D.4050206@sophia.inria.fr> Message-ID: <4AE53860.2020909@tomh.org> Faker Moatamri wrote: > Hi Tom & all, > In the repositories page we have repositories that remained untouched > from one day to 2 years! > http://code.nsnam.org/?sort=lastchange > Should we remove let's say repositories that hasn't been touched for 1 > year or more with owner's permission if any? Faker, I would be fine with your suggested cleanup and Andrey's subsequent suggestion. I created a contributed/ folder on the web server to store some of the older repositories that may have some archival value: http://www.nsnam.org/wiki/index.php/Contributed_Code#Archived_repositories but I did not remove those repositories from code.nsnam.org. Developers should feel free to make use of this archive directory as they see fit; in general, it seems like 12 months is enough dormancy to move a repo to an archive. - Tom From faker.moatamri at sophia.inria.fr Mon Oct 26 01:47:22 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 26 Oct 2009 09:47:22 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE53860.2020909@tomh.org> References: <4AE0601D.4050206@sophia.inria.fr> <4AE53860.2020909@tomh.org> Message-ID: <4AE5621A.8040001@sophia.inria.fr> Tom Henderson wrote: > Faker Moatamri wrote: >> Hi Tom & all, >> In the repositories page we have repositories that remained untouched >> from one day to 2 years! >> http://code.nsnam.org/?sort=lastchange >> Should we remove let's say repositories that hasn't been touched for >> 1 year or more with owner's permission if any? > > Faker, > I would be fine with your suggested cleanup and Andrey's subsequent > suggestion. I created a contributed/ folder on the web server to > store some of the older repositories that may have some archival value: > > http://www.nsnam.org/wiki/index.php/Contributed_Code#Archived_repositories > > > but I did not remove those repositories from code.nsnam.org. > Hi Tom and all, As a first step to cleaning, I will remove the following repositories which are more that 1 year old on Wednesday October 28th at 10 am (GMT+1): raj/docs/wns2-ns-3-tutorial WNS2 2008 Tutorial Files raj/ns-3-dev-http toy http model gjc/ns-3-wifi-scanning ns-3 experimental WiFi scanning ns-3.2 ns-3.2 release ns-3.2-ref-traces reference traces for ns-3.2 gjc/ns-3-virtual-netdevice unknownunknown lj/quagga-porting quagga porting lj/ns-3-netlink ns3 netlink sockets fw/ns-3-nsc-old ns-3 Network Simulation Cradle portFlorian Westphal mathieu/ns-3-nam unknownunknown ns-3-sigcomm Sigcomm demo tree pfeifer/ns-3-para ns-3 parallelized branch ns-3.1 ns-3.1 relese ns-3.1-ref-traces reference traces for ns-3.1 pfeifer/ns-3-para-mpi MPI infrastructure docs s3 Documentation mathieu/ns-3-yans unknownunknown Next step we will remove RC* repositories and Old repositories. If anyone has any objection, please tell us as soon as possible. Best regards Faker Moatamri > Developers should feel free to make use of this archive directory as > they see fit; in general, it seems like 12 months is enough dormancy > to move a repo to an archive. > > - Tom From nbaldo at cttc.es Mon Oct 26 02:16:31 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Mon, 26 Oct 2009 10:16:31 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> Message-ID: <4AE568EF.8020904@cttc.es> Hi Mirko, >>>> - add a new member variable to WifiRemoteStation: >>>> uint8_t m_tid; > > This doens't work. :( The counter must be mainteined for each access > class. See section 9.9.1.6 in IEEE802.11 standard. > Better a variable like the following: > > AccessClass m_ac. > [...] >>>> - change this member method of WifiRemoteStationManager >>>> WifiRemoteStation *Lookup (Mac48Address address) >>>> to the following: >>>> WifiRemoteStation *Lookup (Mac48Address address, uint8_t tid) > > The same of above: > > WifiRemoteStation *Lookup (Mac48Address address, AccessClass ac) > I think the two solutions (AC vs. TID) are equivalent since there is a one-to-one mapping from a TID of an outgoing frame to an AC. However, after reading section 9.9.1.6 in the standard I agree that using AC is more appropriate, so I am fine with the above changes that you proposed. Nicola From faker.moatamri at sophia.inria.fr Mon Oct 26 02:20:23 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 26 Oct 2009 10:20:23 +0100 Subject: [Ns-developers] Pybindgen error ==> Buildbot errors Message-ID: <4AE569D7.5070309@sophia.inria.fr> Hi Gustavo and all, The builds are breaking because of an error generating the pybindgen version: error: Could not load the tool 'cflags' in ['/home/buildslave/slave/full-rahan-g++-4.4.0/build/.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/ wafadmin/Tools', '/home/buildslave/slave/full-rahan-g++-4.4.0/build/.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/wafadmin', '/home/buildslave/ slave/full-rahan-g++-4.4.0/build/.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/wafadmin/Tools', '/home/buildslave/slave/full-rahan-g++-4.4.0/build', '/usr/lib/python2.5/site-packages/buildbot-0.7.10p1-py2.5.egg', '/usr/lib64/python25.zip', '/usr/lib64/python2.5', '/usr/lib64/python2.5/plat-linux2', '/usr/lib64/python2.5/lib-tk', '/usr/lib64/python2.5/lib-dynload', '/usr/lib64/python2.5/site-packages', '/usr/lib64/python2.5/site-packages/Numeric', '/usr/lib64/python2.5/site-packages/PIL', '/usr/lib64/python2.5/site-packages/gst-0.10', '/usr/lib64/python2.5/site-packages/gtk-2.0', '/usr/lib/python2.5/site-packages'] If I copy the file cflags.py from ns-3-dev/waf-tools to /home/buildslave/slave/full-rahan-g++-4.4.0/build/.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/ wafadmin/Tools this error disappears and another one appears: error: Could not load the tool 'command' in ['.../.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/wafadmin', '.../.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/wafadmin/Tools', '/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev', '/usr/lib/python2.5/site-packages/ReviewBoard-1.0beta2-py2.5.egg', '/usr/lib/python2.5/site-packages/flup-1.0.1-py2.5.egg', '/usr/lib/python2.5/site-packages/Pygments-1.0-py2.5.egg', '/usr/lib/python2.5/site-packages/Djblets-0.5beta1-py2.5.egg', '/usr/lib/python2.5/site-packages/django_evolution-0.0.0-py2.5.egg', '/usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg', '/usr/lib/python2.5/site-packages/buildbot-0.7.10p1-py2.5.egg', '/usr/lib/python2.5/site-packages/Twisted-8.2.0-py2.5-linux-x86_64.egg', '/usr/lib/python2.5/site-packages/zope.interface-3.5.1-py2.5-linux-x86_64.egg', '/usr/lib64/python25.zip', '/usr/lib64/python2.5', '/usr/lib64/python2.5/plat-linux2', '/usr/lib64/python2.5/lib-tk', '/usr/lib64/python2.5/lib-dynload', '/usr/lib64/python2.5/site-packages', '/usr/lib64/python2.5/site-packages/Numeric', '/usr/lib64/python2.5/site-packages/PIL', '/usr/lib64/python2.5/site-packages/gst-0.10', '/usr/lib64/python2.5/site-packages/gtk-2.0', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages'] I guess that the file ns-3-dev/waf-tools/command.py should be copied to some place also but why it doesn't work automatically? Thanks Faker Moatamri From gjcarneiro at gmail.com Mon Oct 26 03:01:30 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 26 Oct 2009 10:01:30 +0000 Subject: [Ns-developers] Pybindgen error ==> Buildbot errors In-Reply-To: <4AE569D7.5070309@sophia.inria.fr> References: <4AE569D7.5070309@sophia.inria.fr> Message-ID: 2009/10/26 Faker Moatamri > Hi Gustavo and all, > The builds are breaking because of an error generating the pybindgen > version: > > error: Could not load the tool 'cflags' in > ['/home/buildslave/slave/full-rahan-g++-4.4.0/build/.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/ > wafadmin/Tools', > '/home/buildslave/slave/full-rahan-g++-4.4.0/build/.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/wafadmin', > '/home/buildslave/ > slave/full-rahan-g++-4.4.0/build/.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/wafadmin/Tools', > '/home/buildslave/slave/full-rahan-g++-4.4.0/build', > '/usr/lib/python2.5/site-packages/buildbot-0.7.10p1-py2.5.egg', > '/usr/lib64/python25.zip', '/usr/lib64/python2.5', > '/usr/lib64/python2.5/plat-linux2', '/usr/lib64/python2.5/lib-tk', > '/usr/lib64/python2.5/lib-dynload', '/usr/lib64/python2.5/site-packages', > '/usr/lib64/python2.5/site-packages/Numeric', > '/usr/lib64/python2.5/site-packages/PIL', > '/usr/lib64/python2.5/site-packages/gst-0.10', > '/usr/lib64/python2.5/site-packages/gtk-2.0', > '/usr/lib/python2.5/site-packages'] > > > If I copy the file cflags.py from ns-3-dev/waf-tools to > > > /home/buildslave/slave/full-rahan-g++-4.4.0/build/.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/ > wafadmin/Tools > > this error disappears and another one appears: > > error: Could not load the tool 'command' in > ['.../.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/wafadmin', > '.../.waf-1.5.9-d1e0349fc8937631a656fb8ea7e99063/wafadmin/Tools', > '/auto/sop-nas2a/u/sop-nas2a/vol/home_planete/fmoatamr/src/ns-3-dev', > '/usr/lib/python2.5/site-packages/ReviewBoard-1.0beta2-py2.5.egg', > '/usr/lib/python2.5/site-packages/flup-1.0.1-py2.5.egg', > '/usr/lib/python2.5/site-packages/Pygments-1.0-py2.5.egg', > '/usr/lib/python2.5/site-packages/Djblets-0.5beta1-py2.5.egg', > '/usr/lib/python2.5/site-packages/django_evolution-0.0.0-py2.5.egg', > '/usr/lib/python2.5/site-packages/Django-1.0.2_final-py2.5.egg', > '/usr/lib/python2.5/site-packages/buildbot-0.7.10p1-py2.5.egg', > '/usr/lib/python2.5/site-packages/Twisted-8.2.0-py2.5-linux-x86_64.egg', > '/usr/lib/python2.5/site-packages/zope.interface-3.5.1-py2.5-linux-x86_64.egg', > '/usr/lib64/python25.zip', '/usr/lib64/python2.5', > '/usr/lib64/python2.5/plat-linux2', '/usr/lib64/python2.5/lib-tk', > '/usr/lib64/python2.5/lib-dynload', '/usr/lib64/python2.5/site-packages', > '/usr/lib64/python2.5/site-packages/Numeric', > '/usr/lib64/python2.5/site-packages/PIL', > '/usr/lib64/python2.5/site-packages/gst-0.10', > '/usr/lib64/python2.5/site-packages/gtk-2.0', > '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages'] > > I guess that the file ns-3-dev/waf-tools/command.py should be copied to > some place also but why it doesn't work automatically? > 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. The way Mathieu tried to work around the lack of waf was to call the ns-3 waf. But the ns-3 waf is no longer self-contained and requires the waf-tools now. Unfortunately these waf tools are discovered by a relative path which no longer works when calling waf from another directory. In ns-3-allinone a similar problem could have existed, but I took a different path: 1. Peek into $ns3_branch/bindings/python/wscript, see what pybindgen version is required 2. Write the required version into $pybindgen/pybindgen/version.py This way you don't even need to invoke waf in pybindgen, since pybindgen does not need to be compiled. I 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 vincent at clarinet.u-strasbg.fr Mon Oct 26 03:51:00 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Mon, 26 Oct 2009 11:51:00 +0100 Subject: [Ns-developers] IPv6 extension support In-Reply-To: <4AE05F85.7040107@clarinet.u-strasbg.fr> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> Message-ID: <4AE57F14.4020205@clarinet.u-strasbg.fr> 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, ...); - 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. - The IPv6 option processing, as suggested by Fabian Mauchle, it should not have an Ipv6OptionDemux class and Ipv6Option process method because of conceptual stuff. Maybe he can say more about it and provide a way to do this. As usual, any feedback is welcome. Best regards, -- Sebastien Sebastien Vincent a ?crit : > Hi all, > > I have found some time to integrate IPv6 extensions contributed last > year by David Gross during a placement and some improvement patch from > Fabian Mauchle. > > I will release source by the end of the week. And I propose this > feature for a merge in ns-3.7. > > Basically it support parsing IPv6 extensions and options. The most > useful stuff is fragmentation and routing type 0 (deprecated and > dangerous extension but we include it for some case studies). Other > extensions can be parsed (hop-by-hop, AH, ESP, ...) but for now there > are no special processing. > IPv6 extension support is the base for an future implementation of > Mobile IPv6. If I remember correctly someone (Fabian Mauchle ?) worked > on a MIPv6 implementation last year. > > Best regards, > -- > Sebastien > > From mk.banchi at gmail.com Mon Oct 26 06:54:10 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Mon, 26 Oct 2009 14:54:10 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <4AE568EF.8020904@cttc.es> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> Message-ID: Il giorno 26/ott/09, alle ore 10:16, Nicola Baldo ha scritto: > Hi Mirko, > > >>>>> - add a new member variable to WifiRemoteStation: >>>>> uint8_t m_tid; >> This doens't work. :( The counter must be mainteined for each >> access class. See section 9.9.1.6 in IEEE802.11 standard. >> Better a variable like the following: >> AccessClass m_ac. > [...] >>>>> - change this member method of WifiRemoteStationManager >>>>> WifiRemoteStation *Lookup (Mac48Address address) >>>>> to the following: >>>>> WifiRemoteStation *Lookup (Mac48Address address, uint8_t tid) >> The same of above: >> WifiRemoteStation *Lookup (Mac48Address address, AccessClass ac) > > I think the two solutions (AC vs. TID) are equivalent since there is > a one-to-one mapping from a TID of an outgoing frame to an AC. > However, after reading section 9.9.1.6 in the standard I agree that > using AC is more appropriate, so I am fine with the above changes > that you proposed. The two solutions aren't equivalent because two instances of WifiRemoteStation with different TIDs that are mapped to the same AC have to share the same counter. 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/20091026/71cd3978/smime-0001.bin From mk.banchi at gmail.com Mon Oct 26 07:41:44 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Mon, 26 Oct 2009 15:41:44 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <4AE568EF.8020904@cttc.es> References: <4AE1E736.6040501@cttc.es> <1256458765.2896.2.camel@localhost.localdomain> <43CE324C-7C37-4D9A-A743-94AFE90ADFEA@gmail.com> <4AE568EF.8020904@cttc.es> Message-ID: <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@gmail.com> Hi Mathieu,Nicola and all, i'm analysing your solution for correction of bug 602. I noticed we have to also change signature of MacLow::GetStation method: MacLow::GetStation (Mac48Address, const WifiMacHeader&) That involves other changes to other functions like: MacLow::GetAckDuration MacLow::GetAckTxModeForData MacLow::GetCtsTxModeForRts .... However all functions that call MacLow::GetStation. What do you think? 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/20091026/ac013f18/smime.bin From jpelkey at gatech.edu Mon Oct 26 09:15:34 2009 From: jpelkey at gatech.edu (Josh Pelkey) Date: Mon, 26 Oct 2009 12:15:34 -0400 (EDT) Subject: [Ns-developers] nsnam server upgrade In-Reply-To: <208336261.962991256322569999.JavaMail.root@mail8.gatech.edu> Message-ID: <1211268333.1321231256573734101.JavaMail.root@mail8.gatech.edu> This is a reminder that the nsnam server, which hosts the ns-3 website, mediawiki, bugzilla, and mercurial repositories will be going offline for an upgrade in approximately 2 hours. I will send out an email when the server is going down and immediately after it is back up, which will hopefully only take a few hours. -- Josh Pelkey ----- Original Message ----- From: jpelkey at gatech.edu To: "ns-developers" Sent: Friday, October 23, 2009 2:29:30 PM GMT -05:00 US/Canada Eastern Subject: nsnam server upgrade Hi all, We will be upgrading the nsnam server, which hosts the ns-3 website and mercurial repositories, on Monday, October 26. There will be several hours of downtime, and hopefully the upgrade process goes smoothly. Note that all directories under "/home" are backed up daily; however, if you have anything very important (that you haven't already backed up!), I recommend you copy it from the server. I plan to start the upgrade around 14:00 EDT (18:00 UTC). I will send out an email after I'm done. Also note that the server will be getting a new IP, so this may cause some extra delay. -- Josh Pelkey From faker.moatamri at sophia.inria.fr Mon Oct 26 09:41:57 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Mon, 26 Oct 2009 17:41:57 +0100 Subject: [Ns-developers] Pybindgen error ==> Buildbot errors In-Reply-To: References: <4AE569D7.5070309@sophia.inria.fr> Message-ID: <4AE5D155.9070805@sophia.inria.fr> > > 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 :-( > The way Mathieu tried to work around the lack of waf was to call the > ns-3 waf. But the ns-3 waf is no longer self-contained and requires > the waf-tools now. Unfortunately these waf tools are discovered by a > relative path which no longer works when calling waf from another > directory. > The third solution would be to use the waf that comes with linux distro. I tried to do that, it worked on my machine but not on the slave machine. It generates an error: Traceback (most recent call last): File "/usr/bin/waf", line 141, in Scripting.prepare() File "/usr/share/waf/wafadmin/Scripting.py", line 236, in prepare Utils.set_main_module(os.path.join(candidate, WSCRIPT_FILE)) File "/usr/share/waf/wafadmin/Utils.py", line 138, in set_main_module g_module = load_module(file_path, 'wscript_main') File "/usr/share/waf/wafadmin/Utils.py", line 127, in load_module exec file in module.__dict__ File "/home/buildslave/slave/full-rahan-g++-4.2.4/pybindgen/wscript", line 10, in import Logs ImportError: No module named Logs I didn't find anything that would solve this error, can you please tell me what package will contain this module Logs? > > In ns-3-allinone a similar problem could have existed, but I took a > different path: > > 1. Peek into $ns3_branch/bindings/python/wscript, see what pybindgen > version is required > > 2. Write the required version into $pybindgen/pybindgen/version.py > > This way you don't even need to invoke waf in pybindgen, since > pybindgen does not need to be compiled. in that case I would need to change the code in ns-3-dev which I think is not proper since the version has to be generated by PyBindgen itself. In fact, when reading the code in ns-3-dev, what we do is to read the version.py file in pybindgen/pybindgen and compare it to the version that we require in ns-3-dev. If the file pybindgen/pybindgen/version.py is itself written from ns-3-dev, than comparing is useless since we write the version by ourselves. So I prefer to change the generate the version file from pybindgen itself. > > I 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 Thanks best regards Faker Moatamri From gjcarneiro at gmail.com Mon Oct 26 11:02:03 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 26 Oct 2009 18:02:03 +0000 Subject: [Ns-developers] Pybindgen error ==> Buildbot errors In-Reply-To: <4AE5D155.9070805@sophia.inria.fr> References: <4AE569D7.5070309@sophia.inria.fr> <4AE5D155.9070805@sophia.inria.fr> Message-ID: 2009/10/26 Faker Moatamri > > >> 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. > > The way Mathieu tried to work around the lack of waf was to call the ns-3 >> waf. But the ns-3 waf is no longer self-contained and requires the >> waf-tools now. Unfortunately these waf tools are discovered by a relative >> path which no longer works when calling waf from another directory. >> >> The third solution would be to use the waf that comes with linux distro. > I tried to do that, it worked on my machine but not on the slave machine. It > generates an error: > Traceback (most recent call last): > File "/usr/bin/waf", line 141, in > Scripting.prepare() > File "/usr/share/waf/wafadmin/Scripting.py", line 236, in prepare > Utils.set_main_module(os.path.join(candidate, WSCRIPT_FILE)) > File "/usr/share/waf/wafadmin/Utils.py", line 138, in set_main_module > g_module = load_module(file_path, 'wscript_main') > File "/usr/share/waf/wafadmin/Utils.py", line 127, in load_module > exec file in module.__dict__ > File "/home/buildslave/slave/full-rahan-g++-4.2.4/pybindgen/wscript", line > 10, in > import Logs > ImportError: No module named Logs > I didn't find anything that would solve this error, can you please tell me > what package will contain this module Logs? The system installed version is not compatible. Just forget about the system installed version, WAF APIs have been very unstable in the past. > > >> In ns-3-allinone a similar problem could have existed, but I took a >> different path: >> >> 1. Peek into $ns3_branch/bindings/python/wscript, see what pybindgen >> version is required >> >> 2. Write the required version into $pybindgen/pybindgen/version.py >> >> This way you don't even need to invoke waf in pybindgen, since pybindgen >> does not need to be compiled. >> > in that case I would need to change the code in ns-3-dev which I think is > not proper since the version has to be generated by PyBindgen itself. In > fact, when reading the code in ns-3-dev, what we do is to read the > version.py file in pybindgen/pybindgen and compare it to the version that we > require in ns-3-dev. If the file pybindgen/pybindgen/version.py is itself > written from ns-3-dev, than comparing is useless since we write the version > by ourselves. So I prefer to change the generate the version file from > pybindgen itself. I was talking about the code in ns-3-allinone/download.py, not in ns-3-dev. I think it is reasonable that we generate the version file ourselves, since we have already downloading (via bzr) that explicit version. If we explicitly download version X.Y.Z.W, it should be safe to manually write that version into pybindgen/version.py. -- 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 Oct 26 11:27:52 2009 From: jpelkey at gatech.edu (Josh Pelkey) Date: Mon, 26 Oct 2009 14:27:52 -0400 (EDT) Subject: [Ns-developers] nsnam server upgrade In-Reply-To: <1211268333.1321231256573734101.JavaMail.root@mail8.gatech.edu> Message-ID: <1925894107.1361881256581672880.JavaMail.root@mail8.gatech.edu> The nsnam server is going offline now. I will send an email when it is back up. -- Josh Pelkey ----- Original Message ----- From: "Josh Pelkey" To: "ns-developers" Sent: Monday, October 26, 2009 12:15:34 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade This is a reminder that the nsnam server, which hosts the ns-3 website, mediawiki, bugzilla, and mercurial repositories will be going offline for an upgrade in approximately 2 hours. I will send out an email when the server is going down and immediately after it is back up, which will hopefully only take a few hours. -- Josh Pelkey ----- Original Message ----- From: jpelkey at gatech.edu To: "ns-developers" Sent: Friday, October 23, 2009 2:29:30 PM GMT -05:00 US/Canada Eastern Subject: nsnam server upgrade Hi all, We will be upgrading the nsnam server, which hosts the ns-3 website and mercurial repositories, on Monday, October 26. There will be several hours of downtime, and hopefully the upgrade process goes smoothly. Note that all directories under "/home" are backed up daily; however, if you have anything very important (that you haven't already backed up!), I recommend you copy it from the server. I plan to start the upgrade around 14:00 EDT (18:00 UTC). I will send out an email after I'm done. Also note that the server will be getting a new IP, so this may cause some extra delay. -- Josh Pelkey From Faker.Moatamri at sophia.inria.fr Mon Oct 26 14:24:37 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Mon, 26 Oct 2009 22:24:37 +0100 (CET) Subject: [Ns-developers] Pybindgen error ==> Buildbot errors In-Reply-To: References: <4AE569D7.5070309@sophia.inria.fr> <4AE5D155.9070805@sophia.inria.fr> Message-ID: <49405.217.128.71.243.1256592277.squirrel@imap-sop.inria.fr> > 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. > I will verify that > >> ImportError: No module named Logs >> I didn't find anything that would solve this error, can you please tell >> me >> what package will contain this module Logs? > > > The system installed version is not compatible. Just forget about the > system installed version, WAF APIs have been very unstable in the past. > > ok >> >> in that case I would need to change the code in ns-3-dev which I think >> is >> not proper since the version has to be generated by PyBindgen itself. In >> fact, when reading the code in ns-3-dev, what we do is to read the >> version.py file in pybindgen/pybindgen and compare it to the version >> that we >> require in ns-3-dev. If the file pybindgen/pybindgen/version.py is >> itself >> written from ns-3-dev, than comparing is useless since we write the >> version >> by ourselves. So I prefer to change the generate the version file from >> pybindgen itself. > > > I was talking about the code in ns-3-allinone/download.py, not in > ns-3-dev. > I think it is reasonable that we generate the version file ourselves, > since > we have already downloading (via bzr) that explicit version. If we > explicitly download version X.Y.Z.W, it should be safe to manually write > that version into pybindgen/version.py. > Actually I need it to work with buildbot which builds from ns-3-dev, yes we can generate the version ourselves but in that case it is useless to check the version against the one in pybindgen. I guess at this point that the easiest solution would be to take a compatible waf from ns-3.6 and install it on the build slave and call it from buildbot just to generate the version. Otherwise the solution will need much more work. I should generate the version.py file from buildbot. Thanks for help Best regards Faker moatamri > -- > 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 Oct 26 15:50:03 2009 From: jpelkey at gatech.edu (jpelkey@gatech.edu) Date: Mon, 26 Oct 2009 18:50:03 -0400 (EDT) Subject: [Ns-developers] nsnam server upgrade In-Reply-To: <1215956604.1427181256596592680.JavaMail.root@mail8.gatech.edu> Message-ID: <1760691974.1428971256597403554.JavaMail.root@mail8.gatech.edu> Hi all, The server is back up, and I think everything is back to normal with the exception of bugzilla. I'll be working on getting that back up later tonight. Please let me know if you notice any issues. Also, we did have to move the server, so the IP changed. You will probably notice this the first time you try to ssh. -- Josh Pelkey ----- Original Message ----- From: "Josh Pelkey" To: "ns-developers" Sent: Monday, October 26, 2009 2:27:52 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade The nsnam server is going offline now. I will send an email when it is back up. -- Josh Pelkey ----- Original Message ----- From: "Josh Pelkey" To: "ns-developers" Sent: Monday, October 26, 2009 12:15:34 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade This is a reminder that the nsnam server, which hosts the ns-3 website, mediawiki, bugzilla, and mercurial repositories will be going offline for an upgrade in approximately 2 hours. I will send out an email when the server is going down and immediately after it is back up, which will hopefully only take a few hours. -- Josh Pelkey ----- Original Message ----- From: jpelkey at gatech.edu To: "ns-developers" Sent: Friday, October 23, 2009 2:29:30 PM GMT -05:00 US/Canada Eastern Subject: nsnam server upgrade Hi all, We will be upgrading the nsnam server, which hosts the ns-3 website and mercurial repositories, on Monday, October 26. There will be several hours of downtime, and hopefully the upgrade process goes smoothly. Note that all directories under "/home" are backed up daily; however, if you have anything very important (that you haven't already backed up!), I recommend you copy it from the server. I plan to start the upgrade around 14:00 EDT (18:00 UTC). I will send out an email after I'm done. Also note that the server will be getting a new IP, so this may cause some extra delay. -- Josh Pelkey From jpelkey at gatech.edu Mon Oct 26 18:35:51 2009 From: jpelkey at gatech.edu (Josh Pelkey) Date: Mon, 26 Oct 2009 21:35:51 -0400 (EDT) Subject: [Ns-developers] nsnam server upgrade In-Reply-To: <1760691974.1428971256597403554.JavaMail.root@mail8.gatech.edu> Message-ID: <389523379.1449271256607351967.JavaMail.root@mail8.gatech.edu> nsnam server update: I found a small issue with the server being unable to access outside connections. This has caused some minor issues, but the most noticeable one is mercurial commits will not be mailed to the mailing list. This should be fixed tomorrow. -- Josh Pelkey ----- Original Message ----- From: jpelkey at gatech.edu To: "ns-developers" Sent: Monday, October 26, 2009 6:50:03 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade Hi all, The server is back up, and I think everything is back to normal with the exception of bugzilla. I'll be working on getting that back up later tonight. Please let me know if you notice any issues. Also, we did have to move the server, so the IP changed. You will probably notice this the first time you try to ssh. -- Josh Pelkey ----- Original Message ----- From: "Josh Pelkey" To: "ns-developers" Sent: Monday, October 26, 2009 2:27:52 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade The nsnam server is going offline now. I will send an email when it is back up. -- Josh Pelkey ----- Original Message ----- From: "Josh Pelkey" To: "ns-developers" Sent: Monday, October 26, 2009 12:15:34 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade This is a reminder that the nsnam server, which hosts the ns-3 website, mediawiki, bugzilla, and mercurial repositories will be going offline for an upgrade in approximately 2 hours. I will send out an email when the server is going down and immediately after it is back up, which will hopefully only take a few hours. -- Josh Pelkey ----- Original Message ----- From: jpelkey at gatech.edu To: "ns-developers" Sent: Friday, October 23, 2009 2:29:30 PM GMT -05:00 US/Canada Eastern Subject: nsnam server upgrade Hi all, We will be upgrading the nsnam server, which hosts the ns-3 website and mercurial repositories, on Monday, October 26. There will be several hours of downtime, and hopefully the upgrade process goes smoothly. Note that all directories under "/home" are backed up daily; however, if you have anything very important (that you haven't already backed up!), I recommend you copy it from the server. I plan to start the upgrade around 14:00 EDT (18:00 UTC). I will send out an email after I'm done. Also note that the server will be getting a new IP, so this may cause some extra delay. -- Josh Pelkey From faker.moatamri at sophia.inria.fr Tue Oct 27 02:16:09 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 27 Oct 2009 10:16:09 +0100 Subject: [Ns-developers] Pybindgen error ==> Buildbot errors In-Reply-To: <49405.217.128.71.243.1256592277.squirrel@imap-sop.inria.fr> References: <4AE569D7.5070309@sophia.inria.fr> <4AE5D155.9070805@sophia.inria.fr> <49405.217.128.71.243.1256592277.squirrel@imap-sop.inria.fr> Message-ID: <4AE6BA59.6080708@sophia.inria.fr> Faker.Moatamri at sophia.inria.fr wrote: > > Actually I need it to work with buildbot which builds from ns-3-dev, yes > we can generate the version ourselves but in that case it is useless to > check the version against the one in pybindgen. I guess at this point that > the easiest solution would be to take a compatible waf from ns-3.6 and > install it on the build slave and call it from buildbot just to generate > the version. This solution worked very well :-) . Thanks Gustavo Best regards Faker Moatamri From Amine.Ismail at sophia.inria.fr Tue Oct 27 03:57:59 2009 From: Amine.Ismail at sophia.inria.fr (Ismail Amine) Date: Tue, 27 Oct 2009 11:57:59 +0100 Subject: [Ns-developers] Merge wimax In-Reply-To: <4AE01FFA.2030801@sophia.inria.fr> References: <4AE01FFA.2030801@sophia.inria.fr> Message-ID: <4AE6D237.8010909@sophia.inria.fr> Hi Faker and all, I have merged the WiMAX module with the latest version of ns-3-dev. The code I available at the same directory (http://code.nsnam.org/iamine/ns-3-wimax-release/). I have tested builds under g++-4.0.4, 4.1.2 and 4.2.4; everything is green! Could you rerun the build for g++-3.4.6, 4.3.3 and 4.4.0? Regarding bug 575 the status is still open, however from my point of view this bug is not critical and should not block an eventual release. Thank you in advance Amine Faker Moatamri wrote: > Hi Amine & all, > We are aiming, to merge wimax module into ns-3-dev before the end of > next week. In order to get the merge go smoothly and to anticipate > eventual problems I tested the builds under g++ 3.4.6, 4.0.4, 4.1.2, > 4.2.4, 4.3.3 and 4.4.0 from the repository > http://code.nsnam.org/iamine/ns-3-wimax-release/. > > Here are the results: > g++ 3.4.6, 4.0.4, 4.1.2: > Building error debug and optimized: > > [698/893] cxx: src/devices/wimax/simple-wimax-channel.cc -> > build/debug/src/devices/wimax/simple-wimax-channel_1.o > ../src/devices/wimax/simple-ofdm-wimax-phy.cc: In member function > `ns3::Ptr > ns3::SimpleOfdmWimaxPhy::ConvertBitsToBurst(itpp::bvec, > ns3::Ptr)': > ../src/devices/wimax/simple-ofdm-wimax-phy.cc:597: warning: converting > to `uint8_t' from `double' > > g++ 4.2.4, 4.3.3 and 4.4.0: everything is green :-) > > Can you please pull ns-3-dev code into your repository and merge it > specially that there are a new testing framework? > This will considerably speed up the merging time since it will be > easier to provide a patch based on ns-3-dev and you will anticipate > eventual small merging problems. > Also what is the status of bug 575 which is the only bug left for wimax? > > Thanks > Best regards > Faker Moatamri > > From faker.moatamri at sophia.inria.fr Tue Oct 27 04:17:06 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 27 Oct 2009 12:17:06 +0100 Subject: [Ns-developers] AODV model review Message-ID: <4AE6D6B2.706@sophia.inria.fr> Hi Tom & Craig, I already reviwed the code for AODV, and Pavel corrected according to my review, can you please take a look at it and tell Pavel if he needs to change anything else: http://codereview.appspot.com/115075/show The code looks pretty nice for me and running tests presented a small problem that Pavel already fixed. If anyone else wants to review the code, please feel free to do so. Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Tue Oct 27 06:02:56 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Tue, 27 Oct 2009 14:02:56 +0100 Subject: [Ns-developers] Merge wimax In-Reply-To: <4AE6D237.8010909@sophia.inria.fr> References: <4AE01FFA.2030801@sophia.inria.fr> <4AE6D237.8010909@sophia.inria.fr> Message-ID: <4AE6EF80.7020305@sophia.inria.fr> Ismail Amine wrote: > Hi Faker and all, > > I have merged the WiMAX module with the latest version of ns-3-dev. > The code I available at the same directory > (http://code.nsnam.org/iamine/ns-3-wimax-release/). > > I have tested builds under g++-4.0.4, 4.1.2 and 4.2.4; everything is > green! Could you rerun the build for g++-3.4.6, 4.3.3 and 4.4.0? > Regarding bug 575 the status is still open, however from my point of > view this bug is not critical and should not block an eventual release. > The following tests have failed on all the g++-s: CRASH: TestSuite ns3-tcp-interoperability FAIL: TestSuite pcap-file-object I tried to test the same thing with ns-3-dev and all the tests passed. Anyone has an idea what the problem could be? Best regards Faker Moatamri From boyko at iitp.ru Tue Oct 27 06:23:46 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Tue, 27 Oct 2009 17:23:46 +0400 Subject: [Ns-developers] Trace based regression tests In-Reply-To: <200910191557.24039.boyko@iitp.ru> References: <200910191557.24039.boyko@iitp.ru> Message-ID: <200910271623.46868.boyko@iitp.ru> Hi, Craig, please review Pcap::Diff implementation I use in trace based regression tests. Pavel On Monday 19 October 2009 03:57:23 pm Pavel Boyko wrote: > Hi, > > I'm trying to write simple pcap based regression (aka system) test using > new framework. The only adequate example I have found is > ns3tcp-interop-test- suite.cc . It can operate in two modes -- write packet > traces ("test vectors") or compare actual transmitted packets (sniffed at > IP level) with given correct traces. I like this. But this behavior is > implemented "by hand", both packet tracing and comparison are implemented > in Ns3TcpInteroperabilityTestCase and can not be reused by other tests. > Also it happens that fancy PcapFile doesn't know about old PcapWriter, used > by my favorite *Helper::EnablePcapAll (). And I want to use device level > sniffer instead of IP level one. > > Does anybody have any plans / ideas how to implement trace based > regression test behavior in reusable way? I can easily implement custom > pcap diff for my WiFi based tests, but problem looks general and deserves > some general solution. > > Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pcap_diff.patch Type: text/x-patch Size: 7946 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091027/0c8bb607/pcap_diff.bin From craigdo at ee.washington.edu Tue Oct 27 10:58:07 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 27 Oct 2009 10:58:07 -0700 Subject: [Ns-developers] Merge wimax In-Reply-To: <4AE6EF80.7020305@sophia.inria.fr> References: <4AE01FFA.2030801@sophia.inria.fr> <4AE6D237.8010909@sophia.inria.fr> <4AE6EF80.7020305@sophia.inria.fr> Message-ID: <001e01ca572f$0a6ee680$1f4cb380$@washington.edu> > > I have merged the WiMAX module with the latest version of ns-3-dev. > > The code I available at the same directory > > (http://code.nsnam.org/iamine/ns-3-wimax-release/). > > > > I have tested builds under g++-4.0.4, 4.1.2 and 4.2.4; everything is > > green! Could you rerun the build for g++-3.4.6, 4.3.3 and 4.4.0? > > Regarding bug 575 the status is still open, however from my point of > > view this bug is not critical and should not block an eventual > release. > > > The following tests have failed on all the g++-s: > CRASH: TestSuite ns3-tcp-interoperability > FAIL: TestSuite pcap-file-object > I tried to test the same thing with ns-3-dev and all the tests passed. > Anyone has an idea what the problem could be? Make sure your test.py and src/test is up to date. ns3-tcp-interoperability: Run ./test.py -s ns3-tcp-interoperability -v And take a look at the standard error. CRASH means the test-runner did not return 0 (success) or 1 (failure). pcap-file-object: Run ./test.py -s pcap-file-object -t results.txt To create an error report. Then look in results.txt for what exactly happened. I noticed last night that there is still a hardcoded location in pcap-file-object (/tmp/.pcap) that I need to fix. If you can't create a file in /tmp the test will fail. I am going to fix this morning. -- Craig From craigdo at ee.washington.edu Tue Oct 27 11:34:47 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 27 Oct 2009 11:34:47 -0700 Subject: [Ns-developers] Trace based regression tests In-Reply-To: <200910271623.46868.boyko@iitp.ru> References: <200910191557.24039.boyko@iitp.ru> <200910271623.46868.boyko@iitp.ru> Message-ID: <004101ca5734$29ec0510$7dc40f30$@washington.edu> > Craig, please review Pcap::Diff implementation I use in trace based > regression tests. I tried keep all ns-3 code (even NS_LOG) out of tools used in the low-level test suites since we don't want to end up with test framework code depending on the code it is testing. NS_LOG is not a big deal, but I looked at it like a camel's nose in the tent; and I avoided putting it in even though it would have been very convenient. Other than that, looks fine. -- Craig [ ... ] From faker.moatamri at sophia.inria.fr Wed Oct 28 02:51:58 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 28 Oct 2009 10:51:58 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE5621A.8040001@sophia.inria.fr> References: <4AE0601D.4050206@sophia.inria.fr> <4AE53860.2020909@tomh.org> <4AE5621A.8040001@sophia.inria.fr> Message-ID: <4AE8143E.2090104@sophia.inria.fr> Faker Moatamri wrote: > Hi Tom and all, > As a first step to cleaning, I will remove the following repositories > which are more that 1 year old on Wednesday October 28th at 10 am > (GMT+1): > > raj/docs/wns2-ns-3-tutorial > > WNS2 2008 Tutorial Files > raj/ns-3-dev-http > > toy http model > gjc/ns-3-wifi-scanning > > ns-3 experimental WiFi > scanning > ns-3.2 > ns-3.2 release > ns-3.2-ref-traces > > reference traces for > ns-3.2 > gjc/ns-3-virtual-netdevice > > unknownunknown > lj/quagga-porting > > quagga porting > lj/ns-3-netlink > > ns3 netlink sockets > fw/ns-3-nsc-old > > ns-3 Network Simulation Cradle > portFlorian Westphal > mathieu/ns-3-nam > unknownunknown > ns-3-sigcomm > Sigcomm demo tree > pfeifer/ns-3-para > > ns-3 parallelized > branch > ns-3.1 > ns-3.1 relese > ns-3.1-ref-traces > > reference traces for > ns-3.1 > pfeifer/ns-3-para-mpi > > MPI infrastructure > docs > s3 Documentation > mathieu/ns-3-yans > > unknownunknown > Hi Tom and All, This has been done today as mentioned. > Next step we will remove RC* repositories and Old repositories. > Here is the new list of repositories to be removed on Friday October 30th at 10am (GMT+1): ns-3.6-RC4 ns-.6-RC3 release 8 days ago ns-3.6-RC4-ref-traces reference traces for ns-3.6-RC3 release 8 days ago ns-3.6-RC3 ns-.6-RC3 release 12 days ago ns-3.6-RC3-ref-traces reference traces for ns-3.6-RC3 release 12 days ago ns-3.6-RC2 ns-.6-RC2 release 13 days ago ns-3.6-RC2-ref-traces reference traces for ns-3.6-RC2 release 13 days ago ns-3.6-RC1 ns-.6-RC1 release 2 weeks ago ns-3.6-RC1-ref-traces reference traces for ns-3.6-RC1 release 2 weeks ago iamine/ns-3-wimax-to_be_released wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-to_be_released_old2 wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-to_be_released_old wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-dev-old unknown unknown 3 months ago ns-3.4-RC3 ns-3.4-RC3 release 7 months ago ns-3.4-RC3-ref-traces reference traces for ns-3.4-RC3 release 7 months ago ns-3.4-RC2 ns-3.4-RC2 release 7 months ago ns-3.4-RC2-ref-traces reference traces for ns-3.4-RC2 release 7 months ago ns-3.4-RC1 ns-3.4-RC1 release 7 months ago ns-3.4-RC1-ref-traces reference traces for ns-3.4-RC1 release 7 months ago craigdo/ns-3-test-patches-old Mercurial Queues patches repository backup for ns-3 testing development 2 months ago ns-3-wimax-old ns-3 wimax development tree 10 months ago mathieu/ns-3-simu-old unknown unknown 10 months ago vincent/ns-3-ipv6-1st NS-3 simulator with IPv6 support (first chunk). unknown 11 months ago *For the vincent/ns-3-ipv6-1st I need green light to remove it, does it need to be archived? *If you have any objection to remove any of the above repositories, please tell me as soon as possible. Best regards Faker Moatamri From vincent at clarinet.u-strasbg.fr Wed Oct 28 03:21:43 2009 From: vincent at clarinet.u-strasbg.fr (Sebastien Vincent) Date: Wed, 28 Oct 2009 11:21:43 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE8143E.2090104@sophia.inria.fr> References: <4AE0601D.4050206@sophia.inria.fr> <4AE53860.2020909@tomh.org> <4AE5621A.8040001@sophia.inria.fr> <4AE8143E.2090104@sophia.inria.fr> Message-ID: <4AE81B37.1010303@clarinet.u-strasbg.fr> Faker Moatamri a ?crit : > Faker Moatamri wrote: >> Hi Tom and all, >> As a first step to cleaning, I will remove the following repositories >> which are more that 1 year old on Wednesday October 28th at 10 am >> (GMT+1): >> >> raj/docs/wns2-ns-3-tutorial >> >> WNS2 2008 Tutorial Files >> raj/ns-3-dev-http >> >> toy http model >> gjc/ns-3-wifi-scanning >> >> ns-3 experimental WiFi >> scanning >> ns-3.2 >> >> ns-3.2 release >> ns-3.2-ref-traces >> >> reference traces for >> ns-3.2 >> gjc/ns-3-virtual-netdevice >> >> unknownunknown >> lj/quagga-porting >> >> quagga porting >> lj/ns-3-netlink >> >> ns3 netlink sockets >> fw/ns-3-nsc-old >> >> ns-3 Network Simulation Cradle >> portFlorian Westphal >> mathieu/ns-3-nam >> unknownunknown >> ns-3-sigcomm >> Sigcomm demo tree >> pfeifer/ns-3-para >> >> ns-3 parallelized >> branch >> ns-3.1 >> ns-3.1 relese >> ns-3.1-ref-traces >> >> reference traces for >> ns-3.1 >> pfeifer/ns-3-para-mpi >> >> MPI infrastructure >> docs >> >> s3 Documentation >> mathieu/ns-3-yans >> >> unknownunknown >> > Hi Tom and All, > This has been done today as mentioned. >> Next step we will remove RC* repositories and Old repositories. >> > Here is the new list of repositories to be removed on Friday October > 30th at 10am (GMT+1): > ns-3.6-RC4 ns-.6-RC3 > release 8 days ago > ns-3.6-RC4-ref-traces reference traces for > ns-3.6-RC3 release 8 days ago > ns-3.6-RC3 ns-.6-RC3 > release 12 days ago > ns-3.6-RC3-ref-traces reference traces for > ns-3.6-RC3 release 12 days ago > ns-3.6-RC2 ns-.6-RC2 > release 13 days ago > ns-3.6-RC2-ref-traces reference traces for > ns-3.6-RC2 release 13 days ago > ns-3.6-RC1 ns-.6-RC1 > release 2 weeks ago > ns-3.6-RC1-ref-traces reference traces for > ns-3.6-RC1 release 2 weeks ago > iamine/ns-3-wimax-to_be_released wimax module for ns-3 to be > merged with the main ns-3-dev tree > 2 months ago > ns-3-wimax-to_be_released_old2 wimax module for ns-3 to be > merged with the main ns-3-dev tree > 2 months ago > ns-3-wimax-to_be_released_old wimax module for ns-3 to be > merged with the main ns-3-dev tree > 2 months ago > ns-3-wimax-dev-old unknown unknown 3 > months ago ns-3.4-RC3 > ns-3.4-RC3 release 7 months ago > ns-3.4-RC3-ref-traces reference traces for > ns-3.4-RC3 release 7 months ago > ns-3.4-RC2 ns-3.4-RC2 > release 7 months ago > ns-3.4-RC2-ref-traces reference traces for > ns-3.4-RC2 release 7 months ago > ns-3.4-RC1 ns-3.4-RC1 > release 7 months ago > ns-3.4-RC1-ref-traces reference traces for > ns-3.4-RC1 release 7 months ago > craigdo/ns-3-test-patches-old Mercurial Queues patches > repository backup for ns-3 testing development > 2 months ago > ns-3-wimax-old ns-3 wimax > development tree 10 months ago > mathieu/ns-3-simu-old unknown unknown > 10 months ago vincent/ns-3-ipv6-1st NS-3 > simulator with IPv6 support (first chunk). unknown 11 months ago > > *For the vincent/ns-3-ipv6-1st I need green light to remove it, does > it need to be archived? You can remove it as code has been merged in ns-3-dev now. > *If you have any objection to remove any of the above repositories, > please tell me as soon as possible. > Best regards > Faker Moatamri > > From mk.banchi at gmail.com Wed Oct 28 03:50:24 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Wed, 28 Oct 2009 11:50:24 +0100 Subject: [Ns-developers] Default behaviour for 802.11n A-MSDU aggregation Message-ID: <8333D462-C4DC-4785-AC37-A68043B3FC2D@gmail.com> Hi Mathieu, i've noticed that default behaviour for 802.11n A-MSDU aggregation is changed. Now aggregation is always performed. So i think that default aggregators in QosWifiMacHelper::Default method should be removed. It's not the correct behaviour. 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/20091028/dccb37cb/smime.bin From faker.moatamri at sophia.inria.fr Wed Oct 28 05:49:13 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 28 Oct 2009 13:49:13 +0100 Subject: [Ns-developers] MacOS PPC buildslave Message-ID: <4AE83DC9.6020108@sophia.inria.fr> Hi all, Since the upgrade of the MacOS X 10.5 PPC buildslave, when I restart buildbot on it, it will work fine for few hours, after which the build will fail at the first step (pulling code from ns-3-dev) saying: abort: error: Temporary failure in name resolution Of course when I connect to the machine directly and do hg clone http://code.nsnam.org/ns-3-dev , it works very well. I have been on some forums and it looks like it is because of MacOS system upgrade (http://buildbot.net/trac/ticket/222). It does not guarantee server daemons to work properly and we have to go through the launchd daemon to ensure that buildbot will work. After few hours trying to fix that, I ended up making the process works. Normally this time Mac will not let us down after few hours. Best regards, Faker Moatamri From faker.moatamri at sophia.inria.fr Wed Oct 28 06:35:58 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 28 Oct 2009 14:35:58 +0100 Subject: [Ns-developers] Buildbot notifications Message-ID: <4AE848BE.20007@sophia.inria.fr> Hi all, The buildbot mail notifications will go from now on to the ns-commits mailing list. Also from now on, the mail will not be sent upon failure in buildbot but in all cases so that we can be notified upon success also. I also thought about having two builds a day. One would be before work in GMT areas and the other will be before work in US area. The builds are scheduled at 3 am and 5 pm GMT-7 time (west coast US). The first one would be before work in US and the second will be before work in the GMT area. What do you guys think? Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Wed Oct 28 07:02:00 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 28 Oct 2009 15:02:00 +0100 Subject: [Ns-developers] Mac OS testing problem Message-ID: <4AE84ED8.8070005@sophia.inria.fr> Hi Craig, Gustavo and all, Finally the buildbot on Mac OS X is working, and of course it brought some more work for developers. Actually the building is gone fine and it is only in testing that it didn't work: bash -c ./test.py --verbose --html=results.html in dir /Users/buildslave/slave/full-darwin-ppc-g++-4.2/build (timeout 1200 secs) watching logfiles {} argv: ['bash', '-c', './test.py --verbose --html=results.html'] environment: HOME=/Users/buildslave LOGNAME=buildslave PATH=/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin:/usr/X11R6/bin PWD=/Users/buildslave/slave/full-darwin-ppc-g++-4.2/build PYTHONPATH=/usr/local/lib/python2.5/site-packages SHELL=/bin/tcsh TMPDIR=/var/folders/Ck/CkfBWkRNEeCjYWdNfAfSZk+++TM/-Tmp-/ USER=buildslave closing stdin using PTY: False /bin/sh: waf: command not found Traceback (most recent call last): File "./test.py", line 1351, in sys.exit(main(sys.argv)) File "./test.py", line 1348, in main return run_tests() File "./test.py", line 822, in run_tests make_library_path() File "./test.py", line 563, in make_library_path print "os.environ[\"DYLD_LIBRARY_PATH\"] == %s" % os.environ["DY_LIBRARY_PATH"] File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/UserDict.py", line 22, in __getitem__ NS3_ACTIVE_VARIANT == debug NS3_BUILDDIR == /Users/buildslave/slave/full-darwin-ppc-g++-4.2/build/build NS3_MODULE_PATH == ['/Users/buildslave/slave/full-darwin-ppc-g++-4.2/build/build/debug'] ENABLE_NSC == False ENABLE_REAL_TIME == False ENABLE_EXAMPLES == True raise KeyError(key) KeyError: 'DY_LIBRARY_PATH' program finished with exit code 1 elapsedTime=0.664181 It looks like it is not able to find the waf command, which is used already for building (very weird error) Also it doesn't find the key 'DY_LIBRARY_PATH' and I'm wondering why the key is not DYLD_LIBRARY_PATH? Thanks Best regards, Faker Moatamri From faker.moatamri at sophia.inria.fr Wed Oct 28 08:17:15 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Wed, 28 Oct 2009 16:17:15 +0100 Subject: [Ns-developers] Mac OS testing problem In-Reply-To: <4AE84ED8.8070005@sophia.inria.fr> References: <4AE84ED8.8070005@sophia.inria.fr> Message-ID: <4AE8607B.3000007@sophia.inria.fr> Faker Moatamri wrote: > Hi Craig, Gustavo and all, > > [....] > using PTY: False > /bin/sh: waf: command not found Still there > [....] > It looks like it is not able to find the waf command, which is used > already for building (very weird error) > Also it doesn't find the key 'DY_LIBRARY_PATH' and I'm wondering why > the key is not DYLD_LIBRARY_PATH? > Replacing 'DY_LIBRARY_PATH' by DYLD_LIBRARY_PATH fixed this error. > Thanks > > Best regards, > > Faker Moatamri Best regards Faker From f1mauchl at hsr.ch Wed Oct 28 09:54:12 2009 From: f1mauchl at hsr.ch (Fabian Mauchle) Date: Wed, 28 Oct 2009 17:54:12 +0100 Subject: [Ns-developers] UDPv6 In-Reply-To: <4AE05F85.7040107@clarinet.u-strasbg.fr> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> Message-ID: <000301ca57ef$46c5d150$d45173f0$@ch> Hi Sebastien, Hi all, As we are heading on with merging more of Ipv6, I just wondered about UDPv6. What is the current state of this, and will it be included in ns3.7? Regards, Fabian From Faker.Moatamri at sophia.inria.fr Wed Oct 28 10:50:33 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Wed, 28 Oct 2009 18:50:33 +0100 (CET) Subject: [Ns-developers] MPI merging in ns-3.7 Message-ID: <49497.217.128.71.243.1256752233.squirrel@imap-sop.inria.fr> Hi Josh and George, What is the status of MPI development? are you planning to merge soon? Do you have ready to review code? Please remember that in order to merge your code to ns-3.7, you have less than 3 weeks left to go through at least 2 reviews, corrections and tests. Best regards Faker Moatamri From Faker.Moatamri at sophia.inria.fr Wed Oct 28 11:03:00 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Wed, 28 Oct 2009 19:03:00 +0100 (CET) Subject: [Ns-developers] Spectrum modeling merge Message-ID: <49532.217.128.71.243.1256752980.squirrel@imap-sop.inria.fr> Hi Nicolas, What is the status of spectrum modeling development? are you planning to merge soon? Do you have ready to review code? Please remember that in order to merge your code to ns-3.7, you have less than 3 weeks left to go through at least 2 reviews, corrections and tests. Best regards Faker Moatamri From Faker.Moatamri at sophia.inria.fr Wed Oct 28 11:08:00 2009 From: Faker.Moatamri at sophia.inria.fr (Faker.Moatamri@sophia.inria.fr) Date: Wed, 28 Oct 2009 19:08:00 +0100 (CET) Subject: [Ns-developers] NHDP merging in ns-3.7 Message-ID: <49568.217.128.71.243.1256753280.squirrel@imap-sop.inria.fr> Hi Tom, What is the status of NHDP development? are you planning to merge soon? Do you have ready to review code? Please remember that in order to merge your code to ns-3.7, you have less than 3 weeks left to go through at least 2 reviews, corrections and tests. Best regards Faker Moatamri From tom5760 at gmail.com Wed Oct 28 11:51:06 2009 From: tom5760 at gmail.com (Tom Wambold) Date: Wed, 28 Oct 2009 14:51:06 -0400 Subject: [Ns-developers] NHDP merging in ns-3.7 In-Reply-To: <49568.217.128.71.243.1256753280.squirrel@imap-sop.inria.fr> References: <49568.217.128.71.243.1256753280.squirrel@imap-sop.inria.fr> Message-ID: On Wed, Oct 28, 2009 at 2:08 PM, wrote: > What is the status of NHDP development? are you planning to merge > soon? Do you have ready to review code? I don't have too much ready yet. I hope to have something working pretty soon, hopefully next week. > Please remember that in order to merge your code to ns-3.7, you have > less than 3 weeks left to go through at least 2 reviews, corrections > and tests. Thanks for letting me know, I'll make sure to keep this in mind. I'll send another mail to the list when I make some more progress. Thanks! -Tom Wambold From bosawt at gmail.com Wed Oct 28 16:41:15 2009 From: bosawt at gmail.com (Trevor Bosaw) Date: Wed, 28 Oct 2009 16:41:15 -0700 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo Message-ID: <49A67C4E-72F9-49EA-8C9C-4E5BE74E7446@gmail.com> 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. Most of the improvements in the wifiex project are located in the 'ns2ext-wifi-phy.cc' file, under the 'StartReceivePacket' function. The code here is not too complicated, especially with anyone already familiar with the yans phy state machine, so I definitely recommend a quick perusal through the wifiex code. If I get some agreement on this, I'll go ahead and prepare a patch to merge these two models. -Trevor From tomh at tomh.org Wed Oct 28 21:36:56 2009 From: tomh at tomh.org (Tom Henderson) Date: Wed, 28 Oct 2009 21:36:56 -0700 Subject: [Ns-developers] UDPv6 In-Reply-To: <000301ca57ef$46c5d150$d45173f0$@ch> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <000301ca57ef$46c5d150$d45173f0$@ch> Message-ID: <4AE91BE8.9090900@tomh.org> Fabian Mauchle wrote: > Hi Sebastien, Hi all, > > As we are heading on with merging more of Ipv6, I just wondered about UDPv6. > What is the current state of this, and will it be included in ns3.7? Fabian, this is the most recent update that has been on the list, and I'm not aware of any recent change: http://mailman.isi.edu/pipermail/ns-developers/2009-July/006211.html By the way, I have started a wiki page to track open issues with the internet stack and routing (comments welcome), and linked this page from the ns-3.7 roadmap. I will probably next try to look at the NSC multiple interface problem and the code that Florian posted a while back. http://www.nsnam.org/wiki/index.php/Internet-stack-maintenance - Tom From vincent at clarinet.u-strasbg.fr Wed Oct 28 23:52:02 2009 From: vincent at clarinet.u-strasbg.fr (=?ISO-8859-1?Q?S=E9bastien_Vincent?=) Date: Thu, 29 Oct 2009 07:52:02 +0100 Subject: [Ns-developers] UDPv6 In-Reply-To: <4AE91BE8.9090900@tomh.org> References: <4AE05F85.7040107@clarinet.u-strasbg.fr> <000301ca57ef$46c5d150$d45173f0$@ch> <4AE91BE8.9090900@tomh.org> Message-ID: <4AE93B92.6000809@clarinet.u-strasbg.fr> Hi, Tom Henderson a ?crit : > Fabian Mauchle wrote: >> Hi Sebastien, Hi all, >> >> As we are heading on with merging more of Ipv6, I just wondered about >> UDPv6. >> What is the current state of this, and will it be included in ns3.7? > > Fabian, this is the most recent update that has been on the list, and > I'm not aware of any recent change: > http://mailman.isi.edu/pipermail/ns-developers/2009-July/006211.html > I have not started anything on UDP/TCP refactoring and I'm affraid I will not have time to work on it until december/january. I prefer to take my little free time for merge IPv6 extension in ns-3.7 (available at https://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext). Fabian has proposed to remove "IPv6 option demux" design from above source tree. His repository is located at http://sinv-56031.edu.hsr.ch/hg/ns-3-ipv6-ext. So feel free to review these repositories and give feedback about the two solutions. Best regards, -- Sebastien > By the way, I have started a wiki page to track open issues with the > internet stack and routing (comments welcome), and linked this page > from the ns-3.7 roadmap. I will probably next try to look at the NSC > multiple interface problem and the code that Florian posted a while back. > http://www.nsnam.org/wiki/index.php/Internet-stack-maintenance > > - Tom > From mathieu.lacage at sophia.inria.fr Thu Oct 29 02:19:32 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 29 Oct 2009 10:19:32 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE8143E.2090104@sophia.inria.fr> References: <4AE0601D.4050206@sophia.inria.fr> <4AE53860.2020909@tomh.org> <4AE5621A.8040001@sophia.inria.fr> <4AE8143E.2090104@sophia.inria.fr> Message-ID: <1256807972.13830.3.camel@localhost.localdomain> On Wed, 2009-10-28 at 10:51 +0100, Faker Moatamri wrote: > mathieu/ns-3-simu-old unknown unknown > 10 months ago > If you have any objection to remove any of the above repositories, > please tell me as soon as possible. I am pretty careful in removing uneeded repositories from mathieu/* so, if something is still in there, it means that it has not been merged in another repository yet which means that I would prefer to leave it there. Mathieu From faker.moatamri at sophia.inria.fr Thu Oct 29 02:20:00 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 29 Oct 2009 10:20:00 +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: <4AE95E40.1030203@sophia.inria.fr> Hi Trevor, Trevor Bosaw wrote: > I've looked over the code located at: > > http://code.nsnam.org/timob/ns-3-wifiex/ I tried to run the code from this repository and it give me an error (Linux Fedora 10 with g++-4.3.2 and it fails with the following message: ../src/internet-stack/nsc-tcp-socket-impl.cc: In member function ?virtual ns3::Ptr ns3::NscTcpSocketImpl::RecvFrom(uint32_t, uint32_t, ns3::Address&)?: ../src/internet-stack/nsc-tcp-socket-impl.cc:451: error: ?class ns3::Packet? has no member named ?FindFirstMatchingTag? ../src/internet-stack/nsc-tcp-socket-impl.cc: In member function ?bool ns3::NscTcpSocketImpl::ReadPendingData()?: ../src/internet-stack/nsc-tcp-socket-impl.cc:603: error: ?class ns3::Packet? has no member named ?AddTag? I guess that it is easy to fix... I also noticed that the code was merged with revision 4571 and we currentely are in revision 5467, we need a patch for wifiex based on the latest revision which included a lot of changes compared to revision 4571. > 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. Sounds very interesting, if the code is good I will give it +1 to be merged. > > Most of the improvements in the wifiex project are located in the > 'ns2ext-wifi-phy.cc' file, under the 'StartReceivePacket' function. > The code here is not too complicated, especially with anyone already > familiar with the yans phy state machine, so I definitely recommend a > quick perusal through the wifiex code. > > If I get some agreement on this, I'll go ahead and prepare a patch to > merge these two models. I encourage you to produce a patch for these models based on the latest ns-3-dev tree as soon as possible. Please remember that we have less than three weeks left for the open phase, the fastest you provide us with a patch, the more chances you have to include the models into NS-3.7 release. > > -Trevor Best regards, Faker Moatamri From mathieu.lacage at sophia.inria.fr Thu Oct 29 02:24:33 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 29 Oct 2009 10:24:33 +0100 Subject: [Ns-developers] Default behaviour for 802.11n A-MSDU aggregation In-Reply-To: <8333D462-C4DC-4785-AC37-A68043B3FC2D@gmail.com> References: <8333D462-C4DC-4785-AC37-A68043B3FC2D@gmail.com> Message-ID: <1256808273.13830.6.camel@localhost.localdomain> On Wed, 2009-10-28 at 11:50 +0100, Mirko Banchi wrote: > Hi Mathieu, > > i've noticed that default behaviour for 802.11n A-MSDU aggregation is > changed. Now aggregation is always performed. So i think that default > aggregators in QosWifiMacHelper::Default method should be removed. > It's not the correct behaviour. I don' know what has changed, when, how, and who did it but if you believe that the 802.11n defaults should be changed, I trust you because, after all, you are the one who wrote the relevant code. As usual, patch + review request + ack from nicola, pavel or me, but it should be pretty straightforward. Mathieu From mathieu.lacage at sophia.inria.fr Thu Oct 29 02:27:06 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 29 Oct 2009 10:27:06 +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: <1256808426.13830.7.camel@localhost.localdomain> is timo officially not going to work on this anymore ? Mathieu On Wed, 2009-10-28 at 16:41 -0700, 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. > > Most of the improvements in the wifiex project are located in the > 'ns2ext-wifi-phy.cc' file, under the 'StartReceivePacket' function. > The code here is not too complicated, especially with anyone already > familiar with the yans phy state machine, so I definitely recommend a > quick perusal through the wifiex code. > > If I get some agreement on this, I'll go ahead and prepare a patch to > merge these two models. > > -Trevor From faker.moatamri at sophia.inria.fr Thu Oct 29 02:27:56 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 29 Oct 2009 10:27:56 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: <1256807972.13830.3.camel@localhost.localdomain> 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> Message-ID: <4AE9601C.108@sophia.inria.fr> Mathieu Lacage wrote: > On Wed, 2009-10-28 at 10:51 +0100, Faker Moatamri wrote: > >> mathieu/ns-3-simu-old unknown unknown >> 10 months ago >> If you have any objection to remove any of the above repositories, >> please tell me as soon as possible. >> > > I am pretty careful in removing uneeded repositories from mathieu/* so, > if something is still in there, it means that it has not been merged in > another repository yet which means that I would prefer to leave it > there. > > Ok we will keep your repository. Should we archive it? It remained untouched for nearly one year... Anyone else has any objection on the removal of repositories from this list: ns-3.6-RC4 ns-.6-RC3 release 8 days ago ns-3.6-RC4-ref-traces reference traces for ns-3.6-RC3 release 8 days ago ns-3.6-RC3 ns-.6-RC3 release 12 days ago ns-3.6-RC3-ref-traces reference traces for ns-3.6-RC3 release 12 days ago ns-3.6-RC2 ns-.6-RC2 release 13 days ago ns-3.6-RC2-ref-traces reference traces for ns-3.6-RC2 release 13 days ago ns-3.6-RC1 ns-.6-RC1 release 2 weeks ago ns-3.6-RC1-ref-traces reference traces for ns-3.6-RC1 release 2 weeks ago iamine/ns-3-wimax-to_be_released wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-to_be_released_old2 wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-to_be_released_old wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-dev-old unknown unknown 3 months ago ns-3.4-RC3 ns-3.4-RC3 release 7 months ago ns-3.4-RC3-ref-traces reference traces for ns-3.4-RC3 release 7 months ago ns-3.4-RC2 ns-3.4-RC2 release 7 months ago ns-3.4-RC2-ref-traces reference traces for ns-3.4-RC2 release 7 months ago ns-3.4-RC1 ns-3.4-RC1 release 7 months ago ns-3.4-RC1-ref-traces reference traces for ns-3.4-RC1 release 7 months ago craigdo/ns-3-test-patches-old Mercurial Queues patches repository backup for ns-3 testing development 2 months ago ns-3-wimax-old ns-3 wimax development tree 10 months ago vincent/ns-3-ipv6-1st NS-3 simulator with IPv6 support (first chunk). unknown 11 months ago > Mathieu > > Best regards Faker Moatamri From faker.moatamri at sophia.inria.fr Thu Oct 29 03:35:44 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 29 Oct 2009 11:35:44 +0100 Subject: [Ns-developers] UDPv6 In-Reply-To: <4AE93B92.6000809@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> Message-ID: <4AE97000.1090900@sophia.inria.fr> S?bastien Vincent wrote: > Hi, > > Tom Henderson a ?crit : >> Fabian Mauchle wrote: >>> Hi Sebastien, Hi all, >>> >>> As we are heading on with merging more of Ipv6, I just wondered >>> about UDPv6. >>> What is the current state of this, and will it be included in ns3.7? >> >> Fabian, this is the most recent update that has been on the list, and >> I'm not aware of any recent change: >> http://mailman.isi.edu/pipermail/ns-developers/2009-July/006211.html >> > > I have not started anything on UDP/TCP refactoring and I'm affraid I > will not have time to work on it until december/january. > I prefer to take my little free time for merge IPv6 extension in > ns-3.7 (available at https://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext). > I prepared a patch based on the above repository which is included in the mail. I also uploaded the code change in Rietveld so it is easier to review: http://codereview.appspot.com/144048 I will be reviewing the code very soon. Tom, Craig, can you give a quick review to the code? Anyone else can review the code? > Fabian has proposed to remove "IPv6 option demux" design from above > source tree. His repository is located at > http://sinv-56031.edu.hsr.ch/hg/ns-3-ipv6-ext. So feel free to review > these repositories and give feedback about the two solutions. Is there any reason why he did that? reviewing the first code is enough right? Best regards Faker Moatamri -------------- next part -------------- A non-text attachment was scrubbed... Name: ipv6Ns3.patch Type: text/x-patch Size: 154482 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091029/62da9052/ipv6Ns3-0001.bin From gjcarneiro at gmail.com Thu Oct 29 04:09:45 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 29 Oct 2009 11:09:45 +0000 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE9601C.108@sophia.inria.fr> 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> Message-ID: 2009/10/29 Faker Moatamri > Mathieu Lacage wrote: > >> On Wed, 2009-10-28 at 10:51 +0100, Faker Moatamri wrote: >> >> >>> mathieu/ns-3-simu-old unknown unknown >>> 10 months ago If you have any objection to remove any of the above >>> repositories, >>> please tell me as soon as possible. >>> >>> >> >> I am pretty careful in removing uneeded repositories from mathieu/* so, >> if something is still in there, it means that it has not been merged in >> another repository yet which means that I would prefer to leave it >> there. >> >> >> > Ok we will keep your repository. Should we archive it? It remained > untouched for nearly one year... > > Anyone else has any objection on the removal of repositories from this > list: If by remove you mean archive (the way I see now, with a tar.bzw download option, is ok), then fine by me. Just don't delete the repository files forever! > > ns-3.6-RC4 ns-.6-RC3 release > 8 days ago ns-3.6-RC4-ref-traces > reference traces for ns-3.6-RC3 release < > ns-developers at isi.edu> 8 days ago ns-3.6-RC3 > ns-.6-RC3 release 12 days > ago ns-3.6-RC3-ref-traces reference traces for > ns-3.6-RC3 release 12 days ago ns-3.6-RC2 > ns-.6-RC2 release < > ns-developers at isi.edu> 13 days ago ns-3.6-RC2-ref-traces > reference traces for ns-3.6-RC2 release < > ns-developers at isi.edu> 13 days ago ns-3.6-RC1 > ns-.6-RC1 release 2 weeks > ago ns-3.6-RC1-ref-traces reference traces for > ns-3.6-RC1 release 2 weeks ago > iamine/ns-3-wimax-to_be_released wimax module for ns-3 to be merged with > the main ns-3-dev tree 2 months ago > ns-3-wimax-to_be_released_old2 wimax module for ns-3 to be merged > with the main ns-3-dev tree 2 months > ago ns-3-wimax-to_be_released_old wimax module for ns-3 to be > merged with the main ns-3-dev tree 2 > months ago ns-3-wimax-dev-old unknown > unknown 3 months ago ns-3.4-RC3 > ns-3.4-RC3 release 7 months ago > ns-3.4-RC3-ref-traces reference traces for > ns-3.4-RC3 release 7 months ago ns-3.4-RC2 > ns-3.4-RC2 release < > ns-developers at isi.edu> 7 months ago ns-3.4-RC2-ref-traces > reference traces for ns-3.4-RC2 release < > ns-developers at isi.edu> 7 months ago ns-3.4-RC1 > ns-3.4-RC1 release 7 > months ago ns-3.4-RC1-ref-traces reference > traces for ns-3.4-RC1 release 7 months ago > craigdo/ns-3-test-patches-old Mercurial Queues patches > repository backup for ns-3 testing development < > craigdo at ee.washington.edu> 2 months ago > ns-3-wimax-old ns-3 wimax development > tree 10 months ago > vincent/ns-3-ipv6-1st NS-3 simulator with IPv6 > support (first chunk). unknown 11 months ago > >> Mathieu >> >> >> > Best regards > Faker Moatamri > > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mk.banchi at gmail.com Thu Oct 29 04:34:03 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Thu, 29 Oct 2009 12:34:03 +0100 Subject: [Ns-developers] 802.11n Block ack review Message-ID: <12BAD9BC-9D70-4B62-A3F3-44C89527504C@gmail.com> 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. 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. 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 -------------- 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/20091029/85bedaae/smime.bin From jpelkey at gatech.edu Thu Oct 29 06:45:36 2009 From: jpelkey at gatech.edu (Josh Pelkey) Date: Thu, 29 Oct 2009 09:45:36 -0400 Subject: [Ns-developers] MPI merging in ns-3.7 In-Reply-To: <49497.217.128.71.243.1256752233.squirrel@imap-sop.inria.fr> References: <49497.217.128.71.243.1256752233.squirrel@imap-sop.inria.fr> Message-ID: <688a18330910290645n5ab41fabq8d01236f71ea6f8f@mail.gmail.com> Hi Faker, The MPI development is going well. We will have it up on appspot after a merge with the latest ns-3-dev and a few minor changes. I would estimate the possibility for review within a week. Thanks, Josh Pelkey On Wed, Oct 28, 2009 at 1:50 PM, wrote: > Hi Josh and George, > > What is the status of MPI development? are you planning to merge soon? Do > you have ready to review code? > > Please remember that in order to merge your code to ns-3.7, you have less > than 3 weeks left to go through at least 2 reviews, corrections and tests. > > Best regards > Faker Moatamri > From faker.moatamri at sophia.inria.fr Thu Oct 29 08:20:57 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 29 Oct 2009 16:20:57 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: 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> Message-ID: <4AE9B2D9.9030806@sophia.inria.fr> Gustavo Carneiro wrote: > > > 2009/10/29 Faker Moatamri > > > Mathieu Lacage wrote: > > On Wed, 2009-10-28 at 10:51 +0100, Faker Moatamri wrote: > > > mathieu/ns-3-simu-old unknown > unknown > 10 months ago If you have any objection to remove any > of the above repositories, > please tell me as soon as possible. > > > > I am pretty careful in removing uneeded repositories from > mathieu/* so, > if something is still in there, it means that it has not been > merged in > another repository yet which means that I would prefer to leave it > there. > > > > Ok we will keep your repository. Should we archive it? It remained > untouched for nearly one year... > > Anyone else has any objection on the removal of repositories from > this list: > > > If by remove you mean archive (the way I see now, with a tar.bzw > download option, is ok), then fine by me. Just don't delete the > repository files forever! I mean delete delete, forever, a lot of repositories are just duplicates and some have been already merged. Also there is no point of keeping 4 release candidates if we have the release itself, right? Tom archived the ones that he thought might be of interest in the future and that were never merged. We currently have 89 repos 51 of which remained untouched for more than 4 months (including RCs). From gjcarneiro at gmail.com Thu Oct 29 08:39:14 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 29 Oct 2009 15:39:14 +0000 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE9B2D9.9030806@sophia.inria.fr> 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> Message-ID: 2009/10/29 Faker Moatamri > Gustavo Carneiro wrote: > >> >> >> 2009/10/29 Faker Moatamri > faker.moatamri at sophia.inria.fr>> >> >> >> Mathieu Lacage wrote: >> >> On Wed, 2009-10-28 at 10:51 +0100, Faker Moatamri wrote: >> >> mathieu/ns-3-simu-old unknown >> unknown >> 10 months ago If you have any objection to remove any >> of the above repositories, >> please tell me as soon as possible. >> >> >> I am pretty careful in removing uneeded repositories from >> mathieu/* so, >> if something is still in there, it means that it has not been >> merged in >> another repository yet which means that I would prefer to leave it >> there. >> >> >> Ok we will keep your repository. Should we archive it? It remained >> untouched for nearly one year... >> >> Anyone else has any objection on the removal of repositories from >> this list: >> >> >> If by remove you mean archive (the way I see now, with a tar.bzw download >> option, is ok), then fine by me. Just don't delete the repository files >> forever! >> > I mean delete delete, forever, a lot of repositories are just duplicates > and some have been already merged. Also there is no point of keeping 4 > release candidates if we have the release itself, right? > Tom archived the ones that he thought might be of interest in the future > and that were never merged. We currently have 89 repos 51 of which remained > untouched for more than 4 months (including RCs). > Some of the repos have not been merged and contain the start of some useful work. For instance, gjc/ns-3-wifi-scanning is incomplete, but if someone had time and inclination to finish the work, they could conceivably learn something from my old repository, maybe even copy some code. It's a pity to just obliterate it forever. If you keep around 100 repos in tar.bz2 format, at 10 MB each, that adds to 1GB. Hardly difficult with today's hard disk capacities. So I don't understand why so anxious to delete everything... If a branch was not merged into ns-3-dev, I think you should keep it around somehow, for at least a few years. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From faker.moatamri at sophia.inria.fr Thu Oct 29 08:58:58 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 29 Oct 2009 16:58:58 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: 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> Message-ID: <4AE9BBC2.5050302@sophia.inria.fr> Gustavo Carneiro wrote: > > > 2009/10/29 Faker Moatamri > > > > > If by remove you mean archive (the way I see now, with a > tar.bzw download option, is ok), then fine by me. Just don't > delete the repository files forever! > > I mean delete delete, forever, a lot of repositories are just > duplicates and some have been already merged. Also there is no > point of keeping 4 release candidates if we have the release > itself, right? > Tom archived the ones that he thought might be of interest in the > future and that were never merged. We currently have 89 repos 51 > of which remained untouched for more than 4 months (including RCs). > > > Some of the repos have not been merged and contain the start of some > useful work. For instance, gjc/ns-3-wifi-scanning is incomplete, but > if someone had time and inclination to finish the work, they could > conceivably learn something from my old repository, maybe even copy > some code. It's a pity to just obliterate it forever. Those won't be deleted or at least they will be archived. That's why I'm asking permission from the owners of the repos before deleting. I need to make sure it is really useless. > > If you keep around 100 repos in tar.bz2 format, at 10 MB each, that > adds to 1GB. Hardly difficult with today's hard disk capacities. So > I don't understand why so anxious to delete everything... Yes of course, it never has been a matter of disk space. Actually, I'm not planning to delete everything, and that's why I'm asking people if I can delete before actually deleting. I will delete *only 100% useless repos*, the others we will archive them or we will keep them in the repo. Is that ok with you? If you still think that we should systematically archive all the deleted repos, I have no problem with that. It's just that I find it useless in the only case that we are 100% that the repo has no interest. > > If a branch was not merged into ns-3-dev, I think you should keep it > around somehow, for at least a few years. Yes sure, that's what Tom did and what I will do. Actually I think that if it is less than one year old, I will leave it in the repo, if it is older that that, it will go to Tom's archive in the wiki page. > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert Best regard, Faker Moatamri From gjcarneiro at gmail.com Thu Oct 29 09:15:34 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 29 Oct 2009 16:15:34 +0000 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE9BBC2.5050302@sophia.inria.fr> 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> Message-ID: 2009/10/29 Faker Moatamri > Gustavo Carneiro wrote: > >> >> >> 2009/10/29 Faker Moatamri > faker.moatamri at sophia.inria.fr>> >> >> >> >> If by remove you mean archive (the way I see now, with a >> tar.bzw download option, is ok), then fine by me. Just don't >> delete the repository files forever! >> >> I mean delete delete, forever, a lot of repositories are just >> duplicates and some have been already merged. Also there is no >> point of keeping 4 release candidates if we have the release >> itself, right? >> Tom archived the ones that he thought might be of interest in the >> future and that were never merged. We currently have 89 repos 51 >> of which remained untouched for more than 4 months (including RCs). >> >> >> Some of the repos have not been merged and contain the start of some >> useful work. For instance, gjc/ns-3-wifi-scanning is incomplete, but if >> someone had time and inclination to finish the work, they could conceivably >> learn something from my old repository, maybe even copy some code. It's a >> pity to just obliterate it forever. >> > Those won't be deleted or at least they will be archived. That's why I'm > asking permission from the owners of the repos before deleting. I need to > make sure it is really useless. OK, in that case. from my repos you can really delete (since wifi-scanning seems to be already moved to the wiki as tar.bz2): gjc/ns-3-allinone gjc/ns-3-tap-netdevice gjc/ns-3-waf1.5 gjc/ns-3-waf154 gjc/ns-3-dev-flowmon You should keep for a long time: gjc/ns-3-flowmon (some benchmark scripts in there that are not ported to ns-3-dev, so it's not really 100% merged) You should definitely keep, forever until further notice: gjc/ns-3-pyviz (lack of time to work on this, but I think this is a cool project) Thanks, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From craigdo at ee.washington.edu Thu Oct 29 09:51:04 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Thu, 29 Oct 2009 09:51:04 -0700 Subject: [Ns-developers] Very old repositories In-Reply-To: <4AE9B2D9.9030806@sophia.inria.fr> 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> Message-ID: <01ac01ca58b8$01e370f0$05aa52d0$@washington.edu> Hi Faker, Please do not delete any repos under craigdo. It is clean with the exception of a branch useful to folks running ns-3 on ORBIT (and required by a HOWTO). Regards, -- Craig From dnlove at gmail.com Thu Oct 29 10:06:44 2009 From: dnlove at gmail.com (Duy Nguyen) Date: Thu, 29 Oct 2009 10:06:44 -0700 Subject: [Ns-developers] other types of queueing disciplines for ns-3 Message-ID: <70f6a1ed0910291006gd4f2608uf5a804417c7d5276@mail.gmail.com> Hi everyone, I thought it'll be nice if we could have all the standard linux queueing disciplines supported in ns-3. If you're currently working on any other queues for ns-3, please let us know, so we won't duplicate our efforts. My priority is to have RED available in ns-3, please let me know if you're currently working on it or like to work together on this one. Duy From Amine.Ismail at sophia.inria.fr Thu Oct 29 10:30:22 2009 From: Amine.Ismail at sophia.inria.fr (Ismail Amine) Date: Thu, 29 Oct 2009 18:30:22 +0100 Subject: [Ns-developers] Merge wimax In-Reply-To: <001e01ca572f$0a6ee680$1f4cb380$@washington.edu> References: <4AE01FFA.2030801@sophia.inria.fr> <4AE6D237.8010909@sophia.inria.fr> <4AE6EF80.7020305@sophia.inria.fr> <001e01ca572f$0a6ee680$1f4cb380$@washington.edu> Message-ID: <4AE9D12E.9070306@sophia.inria.fr> Hi All, Thank you Caig and Faker. Everything is green now under g++-4.0.4, 4.1.2, 4.2.4, 3.4.6, 4.3.3 and 4.4.0 in debug and optimized modes. And all the tests return the status passed. Faker, you can check this on http://mimas:8010/waterfall Regards Amine craigdo at ee.washington.edu wrote: >>> I have merged the WiMAX module with the latest version of ns-3-dev. >>> The code I available at the same directory >>> (http://code.nsnam.org/iamine/ns-3-wimax-release/). >>> >>> I have tested builds under g++-4.0.4, 4.1.2 and 4.2.4; everything is >>> green! Could you rerun the build for g++-3.4.6, 4.3.3 and 4.4.0? >>> Regarding bug 575 the status is still open, however from my point of >>> view this bug is not critical and should not block an eventual >>> >> release. >> >> The following tests have failed on all the g++-s: >> CRASH: TestSuite ns3-tcp-interoperability >> FAIL: TestSuite pcap-file-object >> I tried to test the same thing with ns-3-dev and all the tests passed. >> Anyone has an idea what the problem could be? >> > > Make sure your test.py and src/test is up to date. > > ns3-tcp-interoperability: Run > > ./test.py -s ns3-tcp-interoperability -v > > And take a look at the standard error. CRASH means the test-runner did not > return 0 (success) or 1 (failure). > > pcap-file-object: Run > > ./test.py -s pcap-file-object -t results.txt > > To create an error report. Then look in results.txt for what exactly > happened. I noticed last night that there is still a hardcoded location in > pcap-file-object (/tmp/.pcap) that I need to fix. If you > can't create a file in /tmp the test will fail. I am going to fix this > morning. > > -- Craig > > > > > > From faker.moatamri at sophia.inria.fr Thu Oct 29 10:52:32 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Thu, 29 Oct 2009 18:52:32 +0100 Subject: [Ns-developers] Merge wimax In-Reply-To: <4AE9D12E.9070306@sophia.inria.fr> References: <4AE01FFA.2030801@sophia.inria.fr> <4AE6D237.8010909@sophia.inria.fr> <4AE6EF80.7020305@sophia.inria.fr> <001e01ca572f$0a6ee680$1f4cb380$@washington.edu> <4AE9D12E.9070306@sophia.inria.fr> Message-ID: <4AE9D660.6010005@sophia.inria.fr> Ismail Amine wrote: > Hi All, > > Thank you Caig and Faker. Everything is green now under g++-4.0.4, > 4.1.2, 4.2.4, 3.4.6, 4.3.3 and 4.4.0 in debug and optimized modes. And > all the tests return the status passed. Ok cool, just curious, what was the problem? > > Faker, you can check this on http://mimas:8010/waterfall > Do you have a ready tested patch to apply to ns-3-dev? If so +1 for merge tomorrow in ns-3dev. Tom? Craig? others? what do you think? > From bosawt at gmail.com Thu Oct 29 21:24:17 2009 From: bosawt at gmail.com (Trevor Bosaw) Date: Thu, 29 Oct 2009 21:24:17 -0700 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo Message-ID: <594D5AD5-660E-44D5-A00D-F8A7A784F08F@gmail.com> 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 tomh at tomh.org Thu Oct 29 23:35:33 2009 From: tomh at tomh.org (Tom Henderson) Date: Thu, 29 Oct 2009 23:35:33 -0700 Subject: [Ns-developers] Merge wimax In-Reply-To: <4AE9D660.6010005@sophia.inria.fr> References: <4AE01FFA.2030801@sophia.inria.fr> <4AE6D237.8010909@sophia.inria.fr> <4AE6EF80.7020305@sophia.inria.fr> <001e01ca572f$0a6ee680$1f4cb380$@washington.edu> <4AE9D12E.9070306@sophia.inria.fr> <4AE9D660.6010005@sophia.inria.fr> Message-ID: <4AEA8935.30802@tomh.org> Faker Moatamri wrote: > If so +1 for merge tomorrow in ns-3dev. Tom? Craig? others? what do you > think? I've been holding off a review of this since Craig posted his 40-point review last month. I have been looking at it tonight; unfortunately, I think it needs more work and another review before merging, or some commitments to fix these things before release if not all of it is done prior to merging. This is an impressive amount of code (40,000+ lines according to wc) but my main concerns are: - very little test code - very little doxygen outside of the helper class - very few attributes - coding style of function declarations There is no test code right now, AFAICS, that test.py would execute. There are two regression tests that are in the examples/wimax directory, and Craig pointed out previously that these should be converted to the new framework (probably moved to src/test/wimax and new, simpler examples added). It is hard to go back after a model like this is done and try to add unit tests and other test code, but I would like to ask the authors what they feel are the main concerns for possible regressions down the road and how we could write tests for them now? Do we even know (how?) that the current code is functioning correctly? Classes missing doxygen-- I started to enumerate these but stopped as the list grew too long-- consider that there are 57 header files and it seems that most classes are missing doxygen. I would start by doxygenating the key classes such as WimaxNetDevice and its variants, things like WimaxMacHeader, etc. Maybe not every class and member needs doxygen (we aren't 100% throughout ns-3 as is right now) but looking at wscript, most headers are publicly exported so I think the general rule should be to doxygenate all public headers. Also, I don't think blocks such as the below are valid doxygen blocks (this is pretty common throughout the proposed new code) because first line is not "/**"-- have you checked whether doxygen picks these up? /* * set the destination IP address and port * \param ip the destination ip address to which the stream will be sent * \param port the destination udp port to which the stream will be sent */ I counted 28 calls to AddAttribute. Many of these seem to involve pointer accessors, outside of some propagation parameters. This means that most of the variables, parameters, and constants are not accessible via the attribute and default value system. Many values seem to be initialized in constructors to magic numbers; for instance, see QoSParameterSet. Again, I would ask the authors to review all of these constructors and, where there is a potential for future users to want to change the value (note: I counted hundreds of "setter" functions), make it an attribute, and for other hard coded magic numbers, consider the use of const integers. I counted 12 trace sources and it didn't seem to me that the trace sources were aligned with the ones that Craig tried to standardize across devices a few months ago (for instance, the use of PromiscSniffer as the pcap trace source). From Craig's previous comments, please revisit the following still unaddressed comments, aside from the "lacks doxygen" comments: 3, 4 (already mentioned above), 20, 23, and 26. From a coding style standpoint, a major difference that was visibly apparent to me with respect to the rest of ns-3 is that the class member function declarations do not have the return type on the same line as the function name. Since most of these functions are also missing Doxygen, this could probably be cleaned up at the same time. Other comments: Regarding logging, I do not think that this is a blocker for merging because there is no required style for logging but there are only two instances of NS_LOG_FUNCTION which makes it harder to trace control flow via logging (something I do when working with with WiFi code, for example). I care much less about addressing this issue than all of the above other concerns (tests, doxygen, attributes), however. address is misspelled "adress" in several variable names (grep on adress) Why is trace-based streamer going to the trouble of allocating and copying zero-filled payloads into packets? Couldn't you use the "fake data" version of application packets here? People may not be aware that there are two new applications (not specific to WiMAX) being merged as well: src/applications/trace-based-streamer, and src/applications/udp-client-server This wasn't apparent to me until I reviewed Craig's previous comments. Maybe this will be a surprise to others unless called out somehow or split out separately of this repo. Given the size of this module, I think that trying to address all of my comments to the fullest extent possible will be a mountain of work, so I would like to hear other opinions about whether, and to what extent, these comments should be addressed before merging. - Tom From mathieu.lacage at sophia.inria.fr Fri Oct 30 01:01:34 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 30 Oct 2009 09:01:34 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <5A3A5B17-650E-4460-A36C-52DAC13B1EA7@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> Message-ID: <1256889694.17577.16.camel@localhost.localdomain> On Mon, 2009-10-26 at 15:41 +0100, Mirko Banchi wrote: > That involves other changes to other functions like: > > MacLow::GetAckDuration > MacLow::GetAckTxModeForData > MacLow::GetCtsTxModeForRts > .... > > However all functions that call MacLow::GetStation. > > What do you think? It's not clear to me what the best solution is but it seems to me that if you did what nicola suggested first, that is, use the tid instead of the AC within the Lookup method signature, you could perform the necessary conversion from tid to AC within Lookup itself instead of requiring the caller to do it and make MacLow::GetStation take a tid as second argument which should not be too hard. Mathieu From f1mauchl at hsr.ch Fri Oct 30 01:07:56 2009 From: f1mauchl at hsr.ch (Fabian Mauchle) Date: Fri, 30 Oct 2009 09:07:56 +0100 Subject: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) In-Reply-To: <4AE97000.1090900@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> Message-ID: <001b01ca5938$16e382d0$44aa8870$@ch> 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). Regards, Fabian -----Urspr?ngliche Nachricht----- Von: ns-developers-bounces at ISI.EDU [mailto:ns-developers-bounces at ISI.EDU] Im Auftrag von Faker Moatamri Gesendet: Donnerstag, 29. Oktober 2009 11:36 An: vincent at clarinet.u-strasbg.fr Cc: ns-developers at ISI.EDU; ns-3-reviews at googlegroups.com Betreff: Re: [Ns-developers] UDPv6 S?bastien Vincent wrote: > Hi, > > Tom Henderson a ?crit : >> Fabian Mauchle wrote: >>> Hi Sebastien, Hi all, >>> >>> As we are heading on with merging more of Ipv6, I just wondered >>> about UDPv6. >>> What is the current state of this, and will it be included in ns3.7? >> >> Fabian, this is the most recent update that has been on the list, and >> I'm not aware of any recent change: >> http://mailman.isi.edu/pipermail/ns-developers/2009-July/006211.html >> > > I have not started anything on UDP/TCP refactoring and I'm affraid I > will not have time to work on it until december/january. > I prefer to take my little free time for merge IPv6 extension in > ns-3.7 (available at https://svnet.u-strasbg.fr/hg/ns-3-ipv6-ext). > I prepared a patch based on the above repository which is included in the mail. I also uploaded the code change in Rietveld so it is easier to review: http://codereview.appspot.com/144048 I will be reviewing the code very soon. Tom, Craig, can you give a quick review to the code? Anyone else can review the code? > Fabian has proposed to remove "IPv6 option demux" design from above > source tree. His repository is located at > http://sinv-56031.edu.hsr.ch/hg/ns-3-ipv6-ext. So feel free to review > these repositories and give feedback about the two solutions. Is there any reason why he did that? reviewing the first code is enough right? Best regards Faker Moatamri From boyko at iitp.ru Fri Oct 30 02:04:47 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Fri, 30 Oct 2009 12:04:47 +0300 Subject: [Ns-developers] Request to merge the timob wifiex project into main ns-3 repo In-Reply-To: <594D5AD5-660E-44D5-A00D-F8A7A784F08F@gmail.com> References: <594D5AD5-660E-44D5-A00D-F8A7A784F08F@gmail.com> Message-ID: <200910301204.47152.boyko@iitp.ru> 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 faker.moatamri at sophia.inria.fr Fri Oct 30 02:12:17 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 30 Oct 2009 10:12:17 +0100 Subject: [Ns-developers] Very old repositories In-Reply-To: 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> Message-ID: <4AEAADF1.5040508@sophia.inria.fr> ns-3.6-RC4 ns-.6-RC3 release 8 days ago ns-3.6-RC4-ref-traces reference traces for ns-3.6-RC3 release 8 days ago ns-3.6-RC3 ns-.6-RC3 release 12 days ago ns-3.6-RC3-ref-traces reference traces for ns-3.6-RC3 release 12 days ago ns-3.6-RC2 ns-.6-RC2 release 13 days ago ns-3.6-RC2-ref-traces reference traces for ns-3.6-RC2 release 13 days ago ns-3.6-RC1 ns-.6-RC1 release 2 weeks ago ns-3.6-RC1-ref-traces reference traces for ns-3.6-RC1 release 2 weeks ago iamine/ns-3-wimax-to_be_released wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-to_be_released_old2 wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-to_be_released_old wimax module for ns-3 to be merged with the main ns-3-dev tree 2 months ago ns-3-wimax-dev-old unknown unknown 3 months ago ns-3.4-RC3 ns-3.4-RC3 release 7 months ago ns-3.4-RC3-ref-traces reference traces for ns-3.4-RC3 release 7 months ago ns-3.4-RC2 ns-3.4-RC2 release 7 months ago ns-3.4-RC2-ref-traces reference traces for ns-3.4-RC2 release 7 months ago ns-3.4-RC1 ns-3.4-RC1 release 7 months ago ns-3.4-RC1-ref-traces reference traces for ns-3.4-RC1 release 7 months ago ns-3-wimax-old ns-3 wimax development tree 10 months ago vincent/ns-3-ipv6-1st NS-3 simulator with IPv6 support (first chunk). unknown 11 months ago > gjc/ns-3-allinone > gjc/ns-3-tap-netdevice > gjc/ns-3-waf1.5 > gjc/ns-3-waf154 > gjc/ns-3-dev-flowmon > Ok done. Now we need to know about those repos, which ones we should keep/archive/delete: guillaume/ns-3-multithreading unknown unknown 2 months ago guillaume/ns-3-multithreading-new unknown unknown 2 months ago guillaume/ns-3-multithreading-new/.hg/patches unknown unknown 2 months ago guillaume/ns-3-multithreading-old ns-3 multithreaded simulator implementation Guillaume Seguin 3 months ago guillaume/ns-3-multithreading/.hg/patches unknown unknown 2 months ago raj/ns-3-dev unknown unknown 7 months ago raj/ns-3-netanim unknown unknown 7 months ago raj/ns-3-rng-changes unknown unknown 8 months ago raj/ns-3-rng-changes-ref-traces unknown unknown 8 months ago raj/ns-3-tcp unknown unknown 7 months ago raj/ns-3-tcp-ref-traces unknown unknown 7 months ago Thanks for your cooperation :-) Faker Moatamri From nbaldo at cttc.es Fri Oct 30 02:43:42 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 30 Oct 2009 10:43:42 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <1256889694.17577.16.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> Message-ID: <4AEAB54E.8000708@cttc.es> Hi Mirko & Mathieu, Mathieu Lacage wrote: > On Mon, 2009-10-26 at 15:41 +0100, Mirko Banchi wrote: > >> That involves other changes to other functions like: >> >> MacLow::GetAckDuration >> MacLow::GetAckTxModeForData >> MacLow::GetCtsTxModeForRts >> .... >> >> However all functions that call MacLow::GetStation. >> >> What do you think? > > It's not clear to me what the best solution is but it seems to me that > if you did what nicola suggested first, that is, use the tid instead of > the AC within the Lookup method signature, you could perform the > necessary conversion from tid to AC within Lookup itself instead of > requiring the caller to do it and make MacLow::GetStation take a tid as > second argument which should not be too hard. > Sorry I forgot to state clearly that I agree with Mirko's last argument on TID vs AC, i.e., that since different TIDs can be mapped to the same AC the two solutions are not always equivalent, and we need to use AC to comply with Section 9.9.1.6 in the standard in all possible cases. So the current "most agreed" modification is this one: WifiRemoteStation * WifiRemoteStationManager::Lookup (Mac48Address address, AccessClass ac); As for the changes in the signature of MacLow::GetStation, what about doing the following? WifiRemoteStation * MacLow::GetStation (const WifiMacHeader& hdr) const { return m_stationManager->Lookup (hdr.GetAddr2 (), QosUtilsMapTidToAc (hdr.GetQosTid ())); } this means that in mac-low.cc all current calls of the type GetStation (m_currentHdr.GetAddr1 ()); would be simply changed into GetStation (m_currentHdr); Regards, Nicola From mk.banchi at gmail.com Fri Oct 30 03:59:43 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 30 Oct 2009 11:59:43 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <4AEAB54E.8000708@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> Message-ID: Il giorno 30/ott/09, alle ore 10:43, Nicola Baldo ha scritto: > Hi Mirko & Mathieu, > > Mathieu Lacage wrote: >> On Mon, 2009-10-26 at 15:41 +0100, Mirko Banchi wrote: >>> That involves other changes to other functions like: >>> >>> MacLow::GetAckDuration >>> MacLow::GetAckTxModeForData >>> MacLow::GetCtsTxModeForRts >>> .... >>> >>> However all functions that call MacLow::GetStation. >>> >>> What do you think? >> It's not clear to me what the best solution is but it seems to me >> that >> if you did what nicola suggested first, that is, use the tid >> instead of >> the AC within the Lookup method signature, you could perform the >> necessary conversion from tid to AC within Lookup itself instead of >> requiring the caller to do it and make MacLow::GetStation take a >> tid as >> second argument which should not be too hard. > > Sorry I forgot to state clearly that I agree with Mirko's last > argument on TID vs AC, i.e., that since different TIDs can be mapped > to the same AC the two solutions are not always equivalent, and we > need to use AC to comply with Section 9.9.1.6 in the standard in all > possible cases. > > So the current "most agreed" modification is this one: > > WifiRemoteStation * > WifiRemoteStationManager::Lookup (Mac48Address address, AccessClass > ac); > It could be. > > As for the changes in the signature of MacLow::GetStation, what > about doing the following? > > WifiRemoteStation * > MacLow::GetStation (const WifiMacHeader& hdr) const > { > return m_stationManager->Lookup (hdr.GetAddr2 (), > QosUtilsMapTidToAc (hdr.GetQosTid ())); > } > > this means that in mac-low.cc all current calls of the type > GetStation (m_currentHdr.GetAddr1 ()); > would be simply changed into > GetStation (m_currentHdr); > I think taht with this change it''s not possible to choose address type (addr1 or addr2) for GetStation method. However the problems are in MacLow. For instance, how would you call GetStation in MacLow::GetCtsTxModeForRts? I think that in some cases this solution is not applicable. In addiction, i think that there is also another bug in MacLow. Function 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. What do you think? 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 -------------- 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/20091030/0d12f1d2/smime.bin From nbaldo at cttc.es Fri Oct 30 04:31:14 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Fri, 30 Oct 2009 12:31:14 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: 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> Message-ID: <4AEACE82.9010309@cttc.es> Hi, >> this means that in mac-low.cc all current calls of the type >> GetStation (m_currentHdr.GetAddr1 ()); >> would be simply changed into >> GetStation (m_currentHdr); >> > > I think taht with this change it''s not possible to choose address type > (addr1 or addr2) for GetStation method. Ok so that was just a stupid idea, let's forget it. Sorry for the noise. However the problems are in MacLow. > For instance, how would you call GetStation in > MacLow::GetCtsTxModeForRts? I think that in some cases this solution is > not applicable. So what you say is that when a STA receives a RTS it needs to call GetStation (), but since the TID is not provided within the RTS we cannot determine the AC and pass it to GetStation (). I agree that's a problem. I think that more in general the issue is that WifiRemoteStation handles many different functionalities which are related to a connection (a tx-rx pair), however the exact definition of connection varies slightly for each functionality considered. Examples: retx count -> connection identified by remote address and AC STA Association -> connection identified by desination address only? Rate Adaptation -> standard doesn't define it, but it would be a nice feature if a connection were identified by remote address and AC or TID At this point I don't know what could be a good solution to this problem. Any ideas? Nicola From faker.moatamri at sophia.inria.fr Fri Oct 30 04:40:40 2009 From: faker.moatamri at sophia.inria.fr (Faker Moatamri) Date: Fri, 30 Oct 2009 12:40:40 +0100 Subject: [Ns-developers] Ipv6Extension (was UDPv6, missleading subject) In-Reply-To: <001b01ca5938$16e382d0$44aa8870$@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> Message-ID: <4AEAD0B8.8070202@sophia.inria.fr> 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 mk.banchi at gmail.com Fri Oct 30 04:51:09 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 30 Oct 2009 12:51:09 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <4AEACE82.9010309@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> <4AEACE82.9010309@cttc.es> Message-ID: <02BF417E-C048-4378-B0CB-8726CEA45C7F@gmail.com> Il giorno 30/ott/09, alle ore 12:31, Nicola Baldo ha scritto: > Hi, > >>> this means that in mac-low.cc all current calls of the type >>> GetStation (m_currentHdr.GetAddr1 ()); >>> would be simply changed into >>> GetStation (m_currentHdr); >>> >> I think taht with this change it''s not possible to choose address >> type (addr1 or addr2) for GetStation method. > > Ok so that was just a stupid idea, let's forget it. Sorry for the > noise. No problems :) > > However the problems are in MacLow. >> For instance, how would you call GetStation in >> MacLow::GetCtsTxModeForRts? I think that in some cases this >> solution is not applicable. > > > So what you say is that when a STA receives a RTS it needs to call > GetStation (), but since the TID is not provided within the RTS we > cannot determine the AC and pass it to GetStation (). I agree that's > a problem. > > I think that more in general the issue is that WifiRemoteStation > handles many different functionalities which are related to a > connection (a tx-rx pair), however the exact definition of > connection varies slightly for each functionality considered. > Examples: > > retx count -> connection identified by remote address and AC > STA Association -> connection identified by desination address only? > Rate Adaptation -> standard doesn't define it, but it would be a > nice feature if a connection were identified by remote address and > AC or TID > > At this point I don't know what could be a good solution to this > problem. Any ideas? > I think the first patch i created it's the best solution because access class information is passed to methods WifiRemoteStation::ReportDataFailed, WifiRemoteStation::ReportRtsFailed... directly with the call. The patch is in attachment. Please take a look at it. -------------- next part -------------- A non-text attachment was scrubbed... Name: QosRetryCounters.patch Type: application/octet-stream Size: 34812 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091030/01c82532/QosRetryCounters-0001.obj -------------- next part -------------- . What do you think about above-mentioned bug in MacLow::NormalAckTimeout, MacLow::FastAckTimeout ...? Thank you, 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/20091030/01c82532/smime-0001.bin From phillip.sitbon at gmail.com Thu Oct 29 13:32:06 2009 From: phillip.sitbon at gmail.com (Phillip Sitbon) Date: Thu, 29 Oct 2009 13:32:06 -0700 Subject: [Ns-developers] Submission for Review: Waypoint Mobility Model Message-ID: <536685ea0910291332v1bf4322cp7e1a58f1db0f56e4@mail.gmail.com> Hi folks, This is my first time submitting code to ns-3, so I'm doing my best to go by the book but please let me know if I miss something. The code submitted here implements a new Object type, "Waypoint", and a new mobility model "WaypointMobilityModel". Discussion on the feature can be found here: http://groups.google.com/group/ns-3-users/browse_thread/thread/f78de8c92bf43e49 In a nutshell, it provides a method to add mobility as a set of (time, position) pairs. The same functionality is achievable with a ConstantVelocityMobilityModel by scheduling velocity changes at each waypoint; however, the specialization here reduces mobility-related memory usage (by 50%-ish) and provides a very small performance boost in average use scenarios (the performance benefit is directly proportional to the number of waypoints). Files added: src/mobility/waypoint.h src/mobility/waypoint.cc src/mobility/waypoint-mobility-model.h src/mobility/waypoint-mobility-model.cc Files modified: src/mobility/wscript: added relevant file names src/mobility/mobility.h: added new class description I'm not sure if including changes to wscript files is proper, but it allows this patch to compile right out of the box. I'll write up some tests and examples after the code review is done. Looking forward to your feedback! Cheers, Phillip P.S. Applying the patch to ns-3-dev: patch -p2 -d ./ns-3-dev/src/ < waypoint-mobility.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: waypoint-mobility.patch Type: text/x-patch Size: 13572 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20091029/fa4f6b3e/waypoint-mobility.bin From mathieu.lacage at sophia.inria.fr Fri Oct 30 08:49:26 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 30 Oct 2009 16:49:26 +0100 Subject: [Ns-developers] Bug 602 status (patch) In-Reply-To: <4AEAB54E.8000708@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> Message-ID: <1256917766.21755.13.camel@localhost.localdomain> On Fri, 2009-10-30 at 10:43 +0100, Nicola Baldo wrote: > > It's not clear to me what the best solution is but it seems to me that > > if you did what nicola suggested first, that is, use the tid instead of > > the AC within the Lookup method signature, you could perform the > > necessary conversion from tid to AC within Lookup itself instead of > > requiring the caller to do it and make MacLow::GetStation take a tid as > > second argument which should not be too hard. > > > > Sorry I forgot to state clearly that I agree with Mirko's last argument > on TID vs AC, i.e., that since different TIDs can be mapped to the same > AC the two solutions are not always equivalent, and we need to use AC to > comply with Section 9.9.1.6 in the standard in all possible cases. Yes, this is why I suggested just giving the tid to Lookup and make Lookup call TidToAc and use the calculated AC to perform the lookup internally. If you give the tid to lookup, the callers don't need to call the TidToAc function. To be clear: WifiRemoteStationManager::Lookup (Mac48Address ad, uint8_t tid) { ac = TidToAc (tid); return RealLookup (ad, ac); } The above would make the below call to TidToAc unecessary: > WifiRemoteStation * > MacLow::GetStation (const WifiMacHeader& hdr) const > { > return m_stationManager->Lookup (hdr.GetAddr2 (), > QosUtilsMapTidToAc (hdr.GetQosTid ())); > } > > this means that in mac-low.cc all current calls of the type > GetStation (m_currentHdr.GetAddr1 ()); > would be simply changed into > GetStation (m_currentHdr); Which, as mirko pointed out, is not ok: GetStation must take the tid as argument because the header from which the tid must be taken from is different for each call location. Mathieu From jpelkey at gatech.edu Fri Oct 30 09:39:33 2009 From: jpelkey at gatech.edu (Josh Pelkey) Date: Fri, 30 Oct 2009 12:39:33 -0400 (EDT) Subject: [Ns-developers] nsnam server upgrade In-Reply-To: <389523379.1449271256607351967.JavaMail.root@mail8.gatech.edu> Message-ID: <1306950849.78241256920773962.JavaMail.root@mail8.gatech.edu> Hi all, Bugzilla is back up. Sorry for the downtime. Please let me know if you have any issues with any of the services on the nsnam server. -- Josh Pelkey ----- Original Message ----- From: "Josh Pelkey" To: "ns-developers" Sent: Monday, October 26, 2009 9:35:51 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade nsnam server update: I found a small issue with the server being unable to access outside connections. This has caused some minor issues, but the most noticeable one is mercurial commits will not be mailed to the mailing list. This should be fixed tomorrow. -- Josh Pelkey ----- Original Message ----- From: jpelkey at gatech.edu To: "ns-developers" Sent: Monday, October 26, 2009 6:50:03 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade Hi all, The server is back up, and I think everything is back to normal with the exception of bugzilla. I'll be working on getting that back up later tonight. Please let me know if you notice any issues. Also, we did have to move the server, so the IP changed. You will probably notice this the first time you try to ssh. -- Josh Pelkey ----- Original Message ----- From: "Josh Pelkey" To: "ns-developers" Sent: Monday, October 26, 2009 2:27:52 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade The nsnam server is going offline now. I will send an email when it is back up. -- Josh Pelkey ----- Original Message ----- From: "Josh Pelkey" To: "ns-developers" Sent: Monday, October 26, 2009 12:15:34 PM GMT -05:00 US/Canada Eastern Subject: Re: nsnam server upgrade This is a reminder that the nsnam server, which hosts the ns-3 website, mediawiki, bugzilla, and mercurial repositories will be going offline for an upgrade in approximately 2 hours. I will send out an email when the server is going down and immediately after it is back up, which will hopefully only take a few hours. -- Josh Pelkey ----- Original Message ----- From: jpelkey at gatech.edu To: "ns-developers" Sent: Friday, October 23, 2009 2:29:30 PM GMT -05:00 US/Canada Eastern Subject: nsnam server upgrade Hi all, We will be upgrading the nsnam server, which hosts the ns-3 website and mercurial repositories, on Monday, October 26. There will be several hours of downtime, and hopefully the upgrade process goes smoothly. Note that all directories under "/home" are backed up daily; however, if you have anything very important (that you haven't already backed up!), I recommend you copy it from the server. I plan to start the upgrade around 14:00 EDT (18:00 UTC). I will send out an email after I'm done. Also note that the server will be getting a new IP, so this may cause some extra delay. -- Josh Pelkey From tomh at tomh.org Fri Oct 30 18:05:14 2009 From: tomh at tomh.org (Tom Henderson) Date: Fri, 30 Oct 2009 18:05:14 -0700 Subject: [Ns-developers] Submission for Review: Waypoint Mobility Model In-Reply-To: <536685ea0910291332v1bf4322cp7e1a58f1db0f56e4@mail.gmail.com> References: <536685ea0910291332v1bf4322cp7e1a58f1db0f56e4@mail.gmail.com> Message-ID: <4AEB8D4A.9060604@tomh.org> Phillip Sitbon wrote: > Hi folks, > > This is my first time submitting code to ns-3, so I'm doing my best to > go by the book but please let me know if I miss something. Thanks for submitting it, I think you followed the book well. I left comments in Rietveld and added it to the ns-3.7 roadmap wiki page for possible merge. - Tom