From Mathieu.Lacage at sophia.inria.fr Tue Oct 4 23:33:06 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 05 Oct 2005 08:33:06 +0200 Subject: [Ns-developers] [ns] ns2.28 & gcc4.0.1 In-Reply-To: <8f15bed40510041601t70731064g9fd6b138b2b52047@mail.gmail.com> References: <5e11ed6b05092104054ea5164@mail.gmail.com> <1127302955.4311.203.camel@chronos> <8f15bed4050921103461cd8b6@mail.gmail.com> <1127380236.4311.285.camel@chronos> <8f15bed405092212511452c6d2@mail.gmail.com> <1127456545.4311.323.camel@chronos> <8f15bed40510041601t70731064g9fd6b138b2b52047@mail.gmail.com> Message-ID: <1128493986.5166.71.camel@chronos> hi On Wed, 2005-10-05 at 01:01 +0200, Guillermo Alberdi wrote: > Thanks a lot for your help and your time. Your include suggestions > helped a lot and I finally got it to compile. I'm using an Ubuntu > distribution with a gcc version (GCC) 3.3.5 (Debian 1:3.3.5-8ubuntu2). > I tryed to understand your new example tests and run some simulations, > but I couldn't. > When I call the executable "ns-80211" it starts something, but I don't > know what and when its finished displays the % simbol and waits for > tcl code. I've copied the last lines: Ah, yes, I think you could run something like ./ns-80211 empty.tcl with an empty tcl file. ns-80211 is not supposed to be used. It is a prototype. ./ns 80211/test-80211.tcl should do what you want. > DCA TXOP 3 got cts > MAC LOW 3 4.999644 tx tcp to 1 with mode 7 seq=0x4a10 tid=0 > MAC LOW 1 4.999891 duration/id: 0.000089 > MAC LOW 1 4.999891 rx unicast/send_ack from 3 > MAC LOW 2 4.999891 duration/id: 0.000089 > MAC LOW 1 4.999907 tx ACK to 3 with mode 0 > MAC LOW 2 4.999980 duration/id: 0.000000 > MAC LOW 2 4.999980 rx drop CTL_ACK > MAC LOW 3 4.999980 duration/id: 0.000000 > MAC LOW 3 4.999980 rx ACK from 1 > DCA TXOP 3 got ack > DCA TXOP 3 no access needed here -- 1/(nil) > DCA TXOP 3 no access needed here -- 1/(nil) > % > > > If I run "ns-80211 test.tcl" it seems to do the same thing and at the I need to remove that test.tcl file. It is dead. [snip] > Another and last question: is it possible to make two wireless nodes > invisible one to another, like if there was an obstacle between them? In AP mode, you could create two APs with different bssids. Of course, this would isolate them only at the MAC level and I guess you want to isolate them at the PHY level which is not possible in the current code. > As there is no way to use directive antennas I think that maybe Not in the current code but I would happily accept: - a detailed explanation of how this sort of stuff is modelized - patches > something like that could help by using omni antennas while making > nodes only capable of seeing the base station. The behaviour would be > similar to the one using directive antennas. regards, Mathieu -- From ehlert at fokus.fraunhofer.de Wed Oct 5 07:18:09 2005 From: ehlert at fokus.fraunhofer.de (Sven Ehlert) Date: Wed, 05 Oct 2005 16:18:09 +0200 Subject: [Ns-developers] licensing update In-Reply-To: References: <432AC9AD.2070403@tomh.org> <432C1DD2.6060501@tomh.org> Message-ID: <4343E0A1.6040804@fokus.fraunhofer.de> Hi, In my knowledge, the MFTP Code from StarBurst seems to be an old multicast protocol that is not in use anymore. When I did reasearch on multicast 2 years ago, there was already nothing to be found about MFTP and Starburst. I think it's safe to remove this - it's unlikly that anybody will ever notice it ... Greetings /Sven Richard M. Stallman wrote: > The StarBurst and DEC licenses are non-free software. So if you > include those files, the package as a whole will be non-free. > > What needs to be done is delete them entirely. If people want that > functionality, someone else will eventually write it again from > scratch. That is the right outcome. From ehlert at fokus.fraunhofer.de Wed Oct 5 07:29:54 2005 From: ehlert at fokus.fraunhofer.de (Sven Ehlert) Date: Wed, 05 Oct 2005 16:29:54 +0200 Subject: [Ns-developers] Otcl snapshot compilation under Cygwin -- X problem? Message-ID: <4343E362.7050504@fokus.fraunhofer.de> Hi, I'm trying to get the last CVS release of ns running under Cygwin to validate for the next release. However, I've alredy problems to install the newest CVS version of OTcl under Cygwin. It's seems (there's no remark in the CHANGES file) that the inclusion of X was dropped from the configure file (I read something in the mailinglist that this was intended). So, OTcl doesn't build anymore, because for the owish executable X is of course mandatory. I'd judge, that X dependency should be enabled again in OTcl or at least the compilation of owish should be dropped in case no X was detected on the system. If this was really the only modification (X dependency) on the new Otcl, shouldn't we just revert to the old 1.9 version (which compiles just fine under Cygwin)? Or, maybe someone is willing to fix this issue. Below is the error output under Cygwin 1.5.18: No .configure file found in current directory Continuing with default options... checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for string.h... (cached) yes checking for main in -lXbsd... no checking for socket in -lsocket... no checking for gethostbyname in -lnsl... no checking for dcgettext in -lintl... yes checking for getnodebyname in -ldnet_stub... no checking that g++ can handle -O2... no checking standard STL is available... no checking for tcl.h... -I../include checking for tclInt.h... -I../include checking for libtcl8.4... -L../lib -ltcl8.4 checking for init.tcl... ../lib/tcl8.4 checking for http.tcl... ../lib/tcl8.4/http2.4 checking Tcl http.tcl library... yes checking for tclsh8.4.11... no checking for tclsh8.4... ../bin/tclsh8.4 checking for tk.h... -I../include checking for libtk8.4... -L../lib -ltk8.4 checking for tk.tcl... ../lib/tk8.4 checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking system version (for dynamic loading)... CYGWIN_NT-5.1-1.5.18(0.132/4/2) Can't figure out how to do dynamic loading or shared libraries on this system. No explicit static compilation flag; setting V_STATIC to "" no dynamic load lib checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating Makefile creating ./gen creating ./bin rm -f libotcl.a otcl.o gcc -c -g -O2 -DNDEBUG -DUSE_SHM -I. -I/home/ehlert/coding/ns-allinone-2.28-new/ include -I/home/ehlert/coding/ns-allinone-2.28-new/include -I/home/ehlert/coding /ns-allinone-2.28-new/include -I/include otcl.c ar cq libotcl.a otcl.o ranlib libotcl.a rm -f libotcl.so otcl.o so_locations gcc -c -g -O2 -DNDEBUG -DUSE_SHM -fpic -I. -I/home/ehlert/coding/ns-allinone-2.2 8-new/include -I/home/ehlert/coding/ns-allinone-2.28-new/include -I/home/ehlert/ coding/ns-allinone-2.28-new/include -I/include otcl.c otcl.c:1: warning: -fpic ignored for target (all code is position independent) : Skipping shared libaries -o libotcl.so otcl.o rm -f libotcl.so gcc -o otclsh -g -O2 -I. -I/home/ehlert/coding/ns-allinone-2.28-new/include -I/ home/ehlert/coding/ns-allinone-2.28-new/include -I/home/ehlert/coding/ns-allinon e-2.28-new/include -I/include otclAppInit.c \ -L. -lotcl -L/home/ehlert/coding/ns-allinone-2.28-new/lib -ltk8.4 -L/home/ehlert /coding/ns-allinone-2.28-new/lib -ltcl8.4 -lintl -lm rm -f libotcl.so gcc -o owish -g -O2 -I. -I/home/ehlert/coding/ns-allinone-2.28-new/include -I/h ome/ehlert/coding/ns-allinone-2.28-new/include -I/home/ehlert/coding/ns-allinone -2.28-new/include -I/include otkAppInit.c \ -L. -lotcl -L/home/ehlert/coding/ns-allinone-2.28-new/lib -ltk8.4 -L/home/ehlert /coding/ns-allinone-2.28-new/lib -ltcl8.4 -lintl -lm /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x1139): undefined reference to `_XDestroyWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x11ad): undefined reference to `_XDestroyIC' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x1341): undefined reference to `_XSync' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x13b3): undefined reference to `_XMapWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x1426): undefined reference to `_XRootWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x14a6): undefined reference to `_XConfigureWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x15a8): undefined reference to `_XUnmapWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x167b): undefined reference to `_XConfigureWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x16d1): undefined reference to `_XMoveWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x1721): undefined reference to `_XResizeWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x178a): undefined reference to `_XMoveResizeWindow' /home/ehlert/coding/ns-allinone-2.28-new/lib/libtk8.4.a(tkWindow.o):tkWindow.c:( .text+0x17d4): undefined reference to `_XSetWindowBorderWidth' [... lot's more to come ...] From ehlert at fokus.fraunhofer.de Wed Oct 5 07:32:22 2005 From: ehlert at fokus.fraunhofer.de (Sven Ehlert) Date: Wed, 05 Oct 2005 16:32:22 +0200 Subject: [Ns-developers] Which Tcl/Tk version for new allinone? Message-ID: <4343E3F6.1030106@fokus.fraunhofer.de> Hi, Which version of Tcl/Tk will be included for the new 2.29 allinone? Currently it's 8.4.5, and there doesn't seem to be any problems here under Cygwin, but I read here somwhere that for OS X support you need at least 8.4.9? Would be good to know for validation reasons ... Greetings /Sven From floyd at icir.org Wed Oct 5 08:28:44 2005 From: floyd at icir.org (Sally Floyd) Date: Wed, 05 Oct 2005 08:28:44 -0700 Subject: [Ns-developers] fixing a problem so that NS makes on FreeBSD again Message-ID: <200510051528.j95FSiu8029259@cougar.icir.org> Tom reported to me that NS wasn't making on FreeBSD, so I checked it out, and made the following change in diffusion3/lib/main/tools.cc: < sec = lrint (time); < usec = lrint ((time - sec) * 1000000); --- > // sec = lrint (time); > sec = (long) rint (time); > // usec = lrint ((time - sec) * 1000000); > usec = (long) rint ((time - sec) * 1000000); The problem was that FreeBSD (my version, anyway) doesn't have "lrint" in math.h. The author of the code said that the change is ok. - Sally lrint: round from double to long, to nearest integer, using current rounding direction. From francesco.gringoli at ing.unibs.it Wed Oct 5 08:49:27 2005 From: francesco.gringoli at ing.unibs.it (Francesco Gringoli) Date: Wed, 5 Oct 2005 17:49:27 +0200 Subject: [Ns-developers] Which Tcl/Tk version for new allinone? In-Reply-To: References: <4343E3F6.1030106@fokus.fraunhofer.de> Message-ID: Hi, On Oct 5, 2005, at 5:13 PM, Lloyd Wood wrote: > On Wed, 5 Oct 2005, Sven Ehlert wrote: > > >> Which version of Tcl/Tk will be included for the new 2.29 allinone? >> Currently it's 8.4.5, and there doesn't seem to be any problems here >> under Cygwin, but I read here somwhere that for OS X support you >> need at >> least 8.4.9? Would be good to know for validation reasons ... >> > > There are effectively two versions of Tcl/Tk for OS X. There's the > native Aqua Carbon version, and there's the X11 stuff. Given the > various ns X library dependencies, I presume you would want the > latter, and that true OS X support refers to the former. > ns does successfully link to the Aqua Tcl/Tk shipped by Apple. There is no need to link with fink or DarwinPorts tcl/tk. To my knowledge only nam needs a special static tcl/tk library, as Apple include just dynamic libs you need to build tcl/tk from sources. Regards, FG > The official cygwin Tcl/Tk (a weird non-X hybrid that draws Windows > windows and crashes if you do an X call for a canvas) hasn't been > updated since September 2003; I doubt you would want to use that, and > that any later version of Tcl/Tk in the allinone is preferable. > > L. > > > From Mathieu.Lacage at sophia.inria.fr Wed Oct 5 23:36:13 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Thu, 06 Oct 2005 08:36:13 +0200 Subject: [Ns-developers] Otcl snapshot compilation under Cygwin -- X problem? In-Reply-To: <4343E362.7050504@fokus.fraunhofer.de> References: <4343E362.7050504@fokus.fraunhofer.de> Message-ID: <1128580573.5166.104.camel@chronos> hi sven, On Wed, 2005-10-05 at 16:29 +0200, Sven Ehlert wrote: > I'm trying to get the last CVS release of ns running under Cygwin to > validate for the next release. > However, I've alredy problems to install the newest CVS version of OTcl > under Cygwin. It's seems (there's no remark in the CHANGES file) that > the inclusion of X was dropped from the configure file (I read something > in the mailinglist that this was intended). Yes, I think I was the one to ask for this. > So, OTcl doesn't build anymore, because for the owish executable X is of > course mandatory. What is this executable supposed to do ? Looking at your log below, I see that this executable is actually doing a static link against libtk. Do you have any idea why it would not do a dynamic link ? Is this related to the ns-allinone setup ? > I'd judge, that X dependency should be enabled again in OTcl or at least > the compilation of owish should be dropped in case no X was detected > on the system. The second alternative is likely to be the most appealing although it would be nice to understand exactly why this dependency exists. > If this was really the only modification (X dependency) on the new Otcl, > shouldn't we just revert to the old 1.9 version (which compiles just > fine under Cygwin)? Or, maybe someone is willing to fix this issue. I am willing to spend time to find a solution to your problem and apply it to the otcl cvs tree. Mathieu -- From lars.eggert at netlab.nec.de Wed Oct 5 12:29:09 2005 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Wed, 5 Oct 2005 21:29:09 +0200 Subject: [Ns-developers] Which Tcl/Tk version for new allinone? In-Reply-To: References: <4343E3F6.1030106@fokus.fraunhofer.de> Message-ID: On Oct 5, 2005, at 17:49, Francesco Gringoli wrote: > ns does successfully link to the Aqua Tcl/Tk shipped by Apple. > There is no need to link with fink or DarwinPorts tcl/tk. > To my knowledge only nam needs a special static tcl/tk library, as > Apple include just dynamic libs you need to build tcl/tk from sources. I can second that, ns works. I also tried to pull in various pieces from Darwin that are missing in Tiger to make nam link cleanly against the Aqua Tcl/Tk, but quickly got nowhere. Lars -- Lars Eggert NEC Network Laboratories From ehlert at fokus.fraunhofer.de Thu Oct 6 02:51:32 2005 From: ehlert at fokus.fraunhofer.de (Sven Ehlert) Date: Thu, 06 Oct 2005 11:51:32 +0200 Subject: [Ns-developers] Otcl snapshot compilation under Cygwin -- X problem? In-Reply-To: <1128580573.5166.104.camel@chronos> References: <4343E362.7050504@fokus.fraunhofer.de> <1128580573.5166.104.camel@chronos> Message-ID: <4344F3A4.10000@fokus.fraunhofer.de> Hello, Mathieu Lacage wrote: > hi sven, > [...] >>So, OTcl doesn't build anymore, because for the owish executable X is of >>course mandatory. > > What is this executable supposed to do ? Looking at your log below, I > see that this executable is actually doing a static link against libtk. > Do you have any idea why it would not do a dynamic link ? Is this > related to the ns-allinone setup ? I'd guess that owish is just another graphical shell like the standard Tk shell wish, although with OTcl capabilities. I guess that there isn't much need for this (clearly not for ns support), but it's included, so it should also work. As far as I know Cygwin only does static linking. I never searched for an option to do dynamic linking, as the previous allinone setups just worked fine with static linking. [,,,] >>If this was really the only modification (X dependency) on the new Otcl, >> shouldn't we just revert to the old 1.9 version (which compiles just >>fine under Cygwin)? Or, maybe someone is willing to fix this issue. > > I am willing to spend time to find a solution to your problem and apply > it to the otcl cvs tree. Thanks a lot! Greetings /Sven From tomh at tomh.org Thu Oct 6 06:46:47 2005 From: tomh at tomh.org (Tom Henderson) Date: Thu, 06 Oct 2005 06:46:47 -0700 Subject: [Ns-developers] Which Tcl/Tk version for new allinone? In-Reply-To: <4343E3F6.1030106@fokus.fraunhofer.de> References: <4343E3F6.1030106@fokus.fraunhofer.de> Message-ID: <43452AC7.3090909@tomh.org> Sven Ehlert wrote: > Hi, > > Which version of Tcl/Tk will be included for the new 2.29 allinone? > Currently it's 8.4.5, and there doesn't seem to be any problems here > under Cygwin, but I read here somwhere that for OS X support you need at > least 8.4.9? Would be good to know for validation reasons ... > > Greetings > /Sven > I was planning on 8.4.11, which is described as the latest stable release: http://www.tcl.tk/software/tcltk/roadmap.html Tom From pedro.estrela at inesc.pt Thu Oct 6 08:00:16 2005 From: pedro.estrela at inesc.pt (Pedro Estrela) Date: Thu, 6 Oct 2005 16:00:16 +0100 Subject: [Ns-developers] Otcl snapshot compilation under Cygwin -- X problem? In-Reply-To: Message-ID: <010e01c5ca86$a9616d10$172914ac@tagus.ist.utl.pt> hi Concerning this subject, I've already done a patch for enabling TK support on ns2.28 http://mailman.isi.edu/pipermail/ns-developers/2005-July/001769.html For this, I've heavily modified common/tkAppinit.cc based on ns-2.28's common/tclAppinit.cc tk8.4.5's wish.c (v 1.7 2002/06/21 20:24:29 dgp Exp) It is part of my otcl debugging guide, namely step 2: http://inesc-0.tagus.ist.utl.pt/~pmsrve/ns2/ns2_debugging2.html regards Pedro Vale Estrela http://inesc-0.tagus.ist.utl.pt/~pmsrve/timip > -----Original Message----- > From: ns-developers-bounces at ISI.EDU [mailto:ns-developers-bounces at ISI.EDU] On Behalf Of Lloyd Wood > Sent: quinta-feira, 6 de Outubro de 2005 14:04 > To: Sven Ehlert > Cc: ns-developers > Subject: Re: [Ns-developers] Otcl snapshot compilation under Cygwin -- X problem? > > On Thu, 6 Oct 2005, Sven Ehlert wrote: > > > >>So, OTcl doesn't build anymore, because for the owish executable X is of > > >>course mandatory. > > > > > > What is this executable supposed to do ? Looking at your log below, I > > > see that this executable is actually doing a static link against libtk. > > > Do you have any idea why it would not do a dynamic link ? Is this > > > related to the ns-allinone setup ? > > > > I'd guess that owish is just another graphical shell like the standard > > Tk shell wish, although with OTcl capabilities. I guess that there isn't > > much need for this (clearly not for ns support), but it's included, so > > it should also work. > > I was arguing back in 1999 (p3): > http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/vint-lloyd.pdf > > that since OTcl had graphical capabilities and needed X to build, it > should be possible to get Tk commands working in OTcl and thus in ns > scripts. > > Students of mine were wasting their time building Tk GUIs, > discovering they didn't work with ns, building Tcl/Tk scripts that > controlled ns scripts in a complete lashup... > > getting key bindings working right so that OTcl delete/cursor keys > work when you run ns as an interactive shell would be nice too. > > L. > > From tomh at tomh.org Sun Oct 9 12:08:18 2005 From: tomh at tomh.org (Tom Henderson) Date: Sun, 09 Oct 2005 12:08:18 -0700 Subject: [Ns-developers] licensing update In-Reply-To: References: <432AC9AD.2070403@tomh.org> <432C1DD2.6060501@tomh.org> <4343E0A1.6040804@fokus.fraunhofer.de> Message-ID: <43496AA2.4080208@tomh.org> Lloyd Wood wrote: > I asked Alex, who says: > > "a lengthy meander through Google led me to > http://www.streamingmedia.com/article.asp?id=7497 > from which it appears that a company called "The Fantastic > Corporation" acquired all of Starburst's IP from adero.com > > Adero seem to have failed - but "The Fantastic Corporation" appears to > be (just about) still around, so they may be the right ones to > contact. > > Alternatively, Ken Miller (ex CEO of Starburst and the primary author > of the protocol) had a book published by Addison Wesley, so they may > still have contact info for him (probably under his formal name of C. > Kenneth Miller)." > > hope this helps, > > L. Thanks for the contact information. So as to avoid holding up the release process, I will remove the problematic files for now and try to track down the rights-holder of these files to ask whether a change can be made. Tom From tomh at tomh.org Sun Oct 9 19:27:15 2005 From: tomh at tomh.org (Tom Henderson) Date: Sun, 09 Oct 2005 19:27:15 -0700 Subject: [Ns-developers] ns-2.29 release candidate Message-ID: <4349D183.30305@tomh.org> I put together an ns-2.29 release candidate at: http://www.isi.edu/nsnam/dist/ns-2.29-rc1.tgz Unless there are major comments, I plan to make a release of this later in the week, and then allinone shortly after that. The autoconf stuff is designed to work with OTcl 1.10 and TclCL 1.17, although the older releases of those packages probably work fine. I understand that Mathieu and Sven are looking for a solution for building OTcl 1.10 under cygwin. Tom From Mathieu.Lacage at sophia.inria.fr Mon Oct 10 00:35:05 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 10 Oct 2005 09:35:05 +0200 Subject: [Ns-developers] Otcl snapshot compilation under Cygwin -- X problem? In-Reply-To: <4344F3A4.10000@fokus.fraunhofer.de> References: <4343E362.7050504@fokus.fraunhofer.de> <1128580573.5166.104.camel@chronos> <4344F3A4.10000@fokus.fraunhofer.de> Message-ID: <1128929705.5166.146.camel@chronos> hi sven, On Thu, 2005-10-06 at 11:51 +0200, Sven Ehlert wrote: > > What is this executable supposed to do ? Looking at your log below, I > > see that this executable is actually doing a static link against libtk. > > Do you have any idea why it would not do a dynamic link ? Is this > > related to the ns-allinone setup ? > > I'd guess that owish is just another graphical shell like the standard > Tk shell wish, although with OTcl capabilities. I guess that there isn't > much need for this (clearly not for ns support), but it's included, so > it should also work. > > As far as I know Cygwin only does static linking. I never searched for > an option to do dynamic linking, as the previous allinone setups just > worked fine with static linking. I had the strange memory cygwin was supposed to support shared libraries. Clearly, the way this autoconf file deals with shared libraries is a major component of this problem. > >>If this was really the only modification (X dependency) on the new Otcl, > >> shouldn't we just revert to the old 1.9 version (which compiles just > >>fine under Cygwin)? Or, maybe someone is willing to fix this issue. I think the fix for now should be to revert this patch. Looking around in the autoconf magic, I am starting to grasp the scope of the problem and I have zero interest in fixing it, this being dead code as far as I am concerned. Here is a quick and dirty RC with this patch reverted. Can you tell me if it fixes your problem ? ftp://ftp-sop.inria.fr/dream/ns-80211/otcl-sven.tar.gz Clearly, the right fix here would be to throw away 99% of that autoconf crap and move to the evil trio libtool/automake/autoconf rather than try to do stupidly smart things with shared libraries. Using pkg-config would help to solve the problem too. However, it is too late for such a drastic change and I can't figure out a proper fix within the current code so it is easier to revert this. regards, Mathieu -- From Mathieu.Lacage at sophia.inria.fr Mon Oct 10 07:19:51 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 10 Oct 2005 16:19:51 +0200 Subject: [Ns-developers] ns-2.29 release candidate In-Reply-To: <4349D183.30305@tomh.org> References: <4349D183.30305@tomh.org> Message-ID: <1128953991.5166.200.camel@chronos> On Sun, 2005-10-09 at 19:27 -0700, Tom Henderson wrote: > I put together an ns-2.29 release candidate at: > http://www.isi.edu/nsnam/dist/ns-2.29-rc1.tgz builds on ia32 FC3 with gcc 3.4.4, gcc 4.0.1, "-Wall -Werror -O0". -Wall -Werror and -O1, -O2, -O3 fail with both gcc 3.4.4 and gcc 4.0.1 (with a few more warnings with gcc-4.0.1) as reported in earlier messages on this ML. Here is, again, the complete list: sctp/sctp.cc: In member function ?void SctpAgent::InsertDuplicateTsn(u_int)?: sctp/sctp.cc:2727: warning: ?uiCurrTsn? may be used uninitialized in this function trace/cmu-trace.cc: In member function ?void CMUTrace::format_mac_common(Packet*, const char*, int)?: trace/cmu-trace.cc:127: warning: ?mh? may be used uninitialized in this function trace/cmu-trace.cc:128: warning: ?sh? may be used uninitialized in this function pushback/ident-tree.cc: In member function ?AggReturn* PrefixTree::identifyAggregate(double, double)?: pushback/ident-tree.cc:170: warning: ?requiredBottom? may be used uninitialized in this function wpan/p802_15_4mac.cc: In member function ?double Mac802_15_4::getCAP(bool)?: wpan/p802_15_4mac.cc:4387: warning: ?t_CAP? may be used uninitialized in this function wpan/p802_15_4mac.cc:4387: warning: ?t_CAP2? may be used uninitialized in this function wpan/p802_15_4mac.cc:4387: warning: ?t_CAP3? may be used uninitialized in this function wpan/p802_15_4sscs.cc: In member function ?void SSCS802_15_4::startDevice(bool, bool, bool, bool, UINT_8, UINT_8, bool, MACenum)?: wpan/p802_15_4sscs.cc:496: warning: ?k? may be used uninitialized in this function wpan/p802_15_4sscs.cc:496: warning: ?l? may be used uninitialized in this function diffusion3/filters/rmst/rmst_filter.cc: In member function ?bool RmstFilter::processMessage(Message*)?: diffusion3/filters/rmst/rmst_filter.cc:127: warning: ?rmst_ptr? may be used uninitialized in this function Validation succeeds with -O0 and -O3/gcc 3.4.4 and fails with -O3/gcc 4.0.1 in webcache: Running test Mcast-PBtr: ../../ns test-suite-webcache.tcl Mcast-PBtr QUIET Test output differs from reference output Diagnose with: diff test-output-webcache/Mcast-PBtr.test test-output- webcache/Mcast-PBtr Or see URL "http://www.isi.edu/nsnam/ns/ns-problems.html". Running test Mcast-PBPtr: ../../ns test-suite-webcache.tcl Mcast-PBPtr QUIET Test output differs from reference output Diagnose with: diff test-output-webcache/Mcast-PBPtr.test test-output- webcache/Mcast-PBPtr Or see URL "http://www.isi.edu/nsnam/ns/ns-problems.html". Running test Mcast-PBUtr: ../../ns test-suite-webcache.tcl Mcast-PBUtr QUIET Test output differs from reference output Diagnose with: diff test-output-webcache/Mcast-PBUtr.test test-output- webcache/Mcast-PBUtr Or see URL "http://www.isi.edu/nsnam/ns/ns-problems.html". Running test ttl-PBtr: ../../ns test-suite-webcache.tcl ttl-PBtr QUIET Test output differs from reference output Diagnose with: diff test-output-webcache/ttl-PBtr.test test-output- webcache/ttl-PBtr Or see URL "http://www.isi.edu/nsnam/ns/ns-problems.html". Running test ottl-PBtr: ../../ns test-suite-webcache.tcl ottl-PBtr QUIET Test output differs from reference output Diagnose with: diff test-output-webcache/ottl-PBtr.test test-output- webcache/ottl-PBtr Or see URL "http://www.isi.edu/nsnam/ns/ns-problems.html". regards, Mathieu -- From ehlert at fokus.fraunhofer.de Mon Oct 10 08:38:44 2005 From: ehlert at fokus.fraunhofer.de (Sven Ehlert) Date: Mon, 10 Oct 2005 17:38:44 +0200 Subject: [Ns-developers] Otcl snapshot compilation under Cygwin -- X problem? In-Reply-To: <1128929705.5166.146.camel@chronos> References: <4343E362.7050504@fokus.fraunhofer.de> <1128580573.5166.104.camel@chronos> <4344F3A4.10000@fokus.fraunhofer.de> <1128929705.5166.146.camel@chronos> Message-ID: <434A8B04.9050403@fokus.fraunhofer.de> Hi Mathieu Mathieu Lacage wrote: > I had the strange memory cygwin was supposed to support shared > libraries. Clearly, the way this autoconf file deals with shared > libraries is a major component of this problem. maybe it does support it ;-) I just haven't found it! > I think the fix for now should be to revert this patch. Looking around > in the autoconf magic, I am starting to grasp the scope of the problem > and I have zero interest in fixing it, this being dead code as far as I > am concerned. Here is a quick and dirty RC with this patch reverted. Can > you tell me if it fixes your problem ? > ftp://ftp-sop.inria.fr/dream/ns-80211/otcl-sven.tar.gz Thanks, with this version it compiles just fine. Did you just revert to 1.9? Then maybe there shouldn't be an Otcl 1.10 ... Btw, TclCl-1.17 compiled just fine under Cygwin. Thanks for your help! Greetings /Sven From Mathieu.Lacage at sophia.inria.fr Mon Oct 10 12:52:40 2005 From: Mathieu.Lacage at sophia.inria.fr (mathieu lacage) Date: Mon, 10 Oct 2005 21:52:40 +0200 Subject: [Ns-developers] Otcl snapshot compilation under Cygwin -- X problem? In-Reply-To: <434A8B04.9050403@fokus.fraunhofer.de> References: <4343E362.7050504@fokus.fraunhofer.de> <1128580573.5166.104.camel@chronos> <4344F3A4.10000@fokus.fraunhofer.de> <1128929705.5166.146.camel@chronos> <434A8B04.9050403@fokus.fraunhofer.de> Message-ID: <434AC688.407@sophia.inria.fr> >> I think the fix for now should be to revert this patch. Looking around >> in the autoconf magic, I am starting to grasp the scope of the problem >> and I have zero interest in fixing it, this being dead code as far as I >> am concerned. Here is a quick and dirty RC with this patch reverted. Can >> you tell me if it fixes your problem ? >> ftp://ftp-sop.inria.fr/dream/ns-80211/otcl-sven.tar.gz > > > Thanks, with this version it compiles just fine. Did you just revert > to 1.9? Then maybe there shouldn't be an Otcl 1.10 ... I think there are other changes in the code so I just reverted this specific patch. I will probably check it in soon. It would be nice to have more testers for this change. > Btw, TclCl-1.17 compiled just fine under Cygwin. cool Mathieu From tomh at tomh.org Tue Oct 11 00:30:46 2005 From: tomh at tomh.org (Tom Henderson) Date: Tue, 11 Oct 2005 07:30:46 +0000 Subject: [Ns-developers] ns-2.29 release candidate Message-ID: > >Validation succeeds with -O0 and -O3/gcc 3.4.4 and fails with -O3/gcc >4.0.1 in webcache: this one I'm more concerned about for the moment. Have you looked into this failure mode-- is it limited to -O3? Thanks for the detailed testing-- we could use some more platforms. Tom From Mathieu.Lacage at sophia.inria.fr Tue Oct 11 01:53:20 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 11 Oct 2005 10:53:20 +0200 Subject: [Ns-developers] ns-2.29 release candidate In-Reply-To: References: Message-ID: <1129020800.5166.209.camel@chronos> On Tue, 2005-10-11 at 07:30 +0000, Tom Henderson wrote: > > > > >Validation succeeds with -O0 and -O3/gcc 3.4.4 and fails with -O3/gcc > >4.0.1 in webcache: > > this one I'm more concerned about for the moment. Have you looked > into this failure mode-- is it limited to -O3? It is present with -O1 and -O3 at least. Mathieu -- From ehlert at fokus.fraunhofer.de Tue Oct 11 03:14:38 2005 From: ehlert at fokus.fraunhofer.de (Sven Ehlert) Date: Tue, 11 Oct 2005 12:14:38 +0200 Subject: [Ns-developers] ns-2.29 release candidate In-Reply-To: <4349D183.30305@tomh.org> References: <4349D183.30305@tomh.org> Message-ID: <434B908E.9050408@fokus.fraunhofer.de> Hello, I was able to compile the RC under Cygwin 1.5.18. However, it needed a patch from Mathieu Lacage for Otcl, see the discusion on Otcl / X problems here on the mailinglist. I still used the old 8.4.5 Tcl/Tk version. There were a lot of warnings (coversion from nsaddr_t to int, and that stuff), but no errors. The Testsuite runs fine, except test-all-tcp-init-win-full with the following parameters: tahoe4, reno4, newreno4, slowLink2. I haven't had the time to investigate the failures. Greetings /Sven Tom Henderson wrote: > I put together an ns-2.29 release candidate at: > http://www.isi.edu/nsnam/dist/ns-2.29-rc1.tgz > > Unless there are major comments, I plan to make a release of this later > in the week, and then allinone shortly after that. > > The autoconf stuff is designed to work with OTcl 1.10 and TclCL 1.17, > although the older releases of those packages probably work fine. I > understand that Mathieu and Sven are looking for a solution for building > OTcl 1.10 under cygwin. > > Tom From Mathieu.Lacage at sophia.inria.fr Tue Oct 11 03:24:18 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 11 Oct 2005 12:24:18 +0200 Subject: [Ns-developers] ns-2.29 release candidate In-Reply-To: <434B908E.9050408@fokus.fraunhofer.de> References: <4349D183.30305@tomh.org> <434B908E.9050408@fokus.fraunhofer.de> Message-ID: <1129026258.5166.212.camel@chronos> On Tue, 2005-10-11 at 12:14 +0200, Sven Ehlert wrote: > Hello, > > I was able to compile the RC under Cygwin 1.5.18. However, it needed a > patch from Mathieu Lacage for Otcl, see the discusion on Otcl / X > problems here on the mailinglist. I still used the old 8.4.5 Tcl/Tk version. > There were a lot of warnings (coversion from nsaddr_t to int, and that > stuff), but no errors. > > The Testsuite runs fine, except test-all-tcp-init-win-full with the > following parameters: tahoe4, reno4, newreno4, slowLink2. I haven't had > the time to investigate the failures. It would be nice to rebuild with the latest tcl/tk and send the diff -u (don't forget the -u: the output is horrible to read otherwise) output of the failed tests. Mathieu -- From enrico-minack at gmx.de Tue Oct 11 13:59:13 2005 From: enrico-minack at gmx.de (Enrico Minack) Date: Tue, 11 Oct 2005 22:59:13 +0200 Subject: [Ns-developers] Mac802_11 random backoff patch Message-ID: <434C27A1.3050701@gmx.de> Dear ns-developers, as announced on the ns-users mailing list some months ago there is an inaccuracy between the IEEE 802.11 code and the specification. The random backoff is selected out of [0, cw_), but the specification _includes_ cw_, thus it should be [0, cw_]. This bug leads to a better throughput than actually possible. I'd highly appreciate any comment on that. See attached a patch that modifies all random backoff selection of Mac802_11. regards, Enrico M. ieee 802.11 random backoff patch: http://www.maniac-site.de/download/ns-2.28-ieee802_11_random_backoff.patch From pedro.estrela at inesc.pt Tue Oct 11 17:47:32 2005 From: pedro.estrela at inesc.pt (Pedro Estrela) Date: Wed, 12 Oct 2005 01:47:32 +0100 Subject: [Ns-developers] PATCH - Hierarchical routing hier-reset - (unallocated memory being accessed) Message-ID: <000a01c5cec6$87dc10c0$172914ac@tagus.ist.utl.pt> Hello, I've found another problem with the hierarchical routing module. In some tricky situations, during the reset operations triggered by "link down" instructions, at Simulator::compute-routes, there seems to be a bug that causes unallocated memory to be access, causing a segfault, I've corrected the problem by calling hier_check(i) before each memory access, that makes sure that memory is properly allocated before-hand. This behaviour is now equal to the Hier-insert function, below the hier-reset in routing/route.cc. regards Pedro Estrela http://inesc-0.tagus.ist.utl.pt/~pmsrve/ns2 ---------- Index: route.cc =================================================================== RCS file: /home/pmsrve/.cvsroot/ns_cims/routing/route.cc,v retrieving revision 1.3 diff -C2 -r1.3 route.cc *** route.cc 20 Sep 2005 18:23:20 -0000 1.3 --- route.cc 12 Oct 2005 00:45:10 -0000 *************** *** 614,617 **** --- 614,618 ---- i = INDEX(src[0], src[1], Cmax_); n = cluster_size_[i]; + hier_check(i); // pmsrve 11/october/05 - makes sure that memory is allocated hadj_[i][N_N_INDEX(src[2], dst[2], n, C_[d], D_)] = INFINITY; } else { *************** *** 619,622 **** --- 620,624 ---- i = INDEX(src[0], y, Cmax_); n = cluster_size_[i]; + hier_check(i); // pmsrve 11/october/05 - makes sure that memory is allocated hadj_[i][C_C_INDEX(src[1], dst[1], n, C_[d], D_)] = INFINITY; if (y == src[1]) *************** *** 629,632 **** --- 631,635 ---- i = INDEX(x, y, Cmax_); n = cluster_size_[i]; + hier_check(i); // pmsrve 11/october/05 - makes sure that memory is allocated hadj_[i][D_D_INDEX(src[0], dst[0], n, C_[x], D_)] = INFINITY; if ( x == src[0] ){ From jainim at gist.ac.kr Thu Oct 13 00:17:20 2005 From: jainim at gist.ac.kr (=?EUC-KR?B?wK/A57/r?=) Date: Thu, 13 Oct 2005 16:17:20 +0900 (KST) Subject: [Ns-developers] Segmentation fault at MAC layer Message-ID: <29789592.1129187840435.JavaMail.root@eunhasu.gist.ac.kr> hello I have serious problem with ns-2. When running ns-2 I accidently meet segmentation fault. I do not know the exact position of seg. fault. But there is a clue at MAC layer. I wrote "fp = fopen( "MAC.log", "wr" );" at mac802_11 constructor then the seg. fault occurs. But the segmentation fault is NOT occurred that point. If I delete that code, no segmentation fault occurs. Here is detailed situation. I added new routing protocol in ns-2. The modified parts are listed below. NS-2 code modification (1) Modification File: ?common\packet.h? Add ?PT_PFGR? below ?PT_AODV? at ?enum packet_t? Add ?name_[PT_PFGR] = "PFGR";? below ?name_[PT_AODV]= "AODV";? at p_info() constructor Add ? double timestamp__;? below ?// Monarch extn end? at ?struct hdr_cmn? Add ? inline double& timestamp_() { return (timestamp__); }? below ?// Monarch_end? at struct hdr_cmn? (2) Modification File: ?mac\ll.h? Add ?NsObject* pfgr_agent_;? into class LL Add ?Mac* getMAC() { return mac_; }" into class LL Add ?Queue* getIFQ() { return Queue*(downtarget_); }" into class LL (3) Modification File: ?mac\ll.c? Add ?#include ? Add ? if( pfgr_agent_ && pfgr_agent_ != (NsObject*)1 ) { FromLinkLayer( p ); }? at the end of function ?void LL::sendUp(Packet* p)? (4) Modification File: ?ns-mobilenode.tcl? Add ?$agent ll-layer [$self set ll_(0)]? below ?#send target? at function ?Node/MobileNode instproc add-target-rtagent { agent port } {? (5) Modification file: ?ns-lib.tcl? Add Function ?Simulator instproc create-PFGR-agent { node } { set ragent [new Agent/PFGR] set addr [$node node-addr] $ragent addr $addr $ragent node $node if [Simulator set mobile_ip_] { $ragent port-dmux [$node demux] } $node addr $addr $node set ragent_ $ragent $self at 0.0 "$ragent start-PFGR" return $ragent }? Add ?PFGR { set ragent [$self create-PFGR-agent $node] }? below ?switch -exact $routingAgent_ {? at ?Simulator instproc create-wireless-node args {? Add ?source simpleroute.tcl? below ?source dsdv.tcl? (6) Modification file: ?agent.cc? Add ?else if (strcmp(argv[1], "ll-layer") == 0) { // for only pfgr return (TCL_OK); } else if (strcmp(argv[1], "mac-layer") == 0) { // for only pfgr return (TCL_OK); }? below ?else if(strcmp(argv[1], "set_pkttype") == 0){ set_pkttype(packet_t(atoi(argv[2]))); return (TCL_OK); }? (7) Modification file: ?ns-packet.tcl? Add ?PFGR? below ?AODV? at ?foreach prot? My routing protocol name (PFGR) works properly. But when I try to test DSDV, there is a segmentation fault error. When I delete "fp = fopen( "MAC.log", "wr" );", then try DSDV, no error is occurred. If there is a wrong point of adding new routing protocol, please comment about that. Would anybody has any clue about seg. fault? Any comment is appreciated. Thanks in advance. With regards Jaeyong Yoo From Mathieu.Lacage at sophia.inria.fr Thu Oct 13 00:49:44 2005 From: Mathieu.Lacage at sophia.inria.fr (mathieu lacage) Date: Thu, 13 Oct 2005 09:49:44 +0200 Subject: [Ns-developers] Segmentation fault at MAC layer In-Reply-To: <29789592.1129187840435.JavaMail.root@eunhasu.gist.ac.kr> References: <29789592.1129187840435.JavaMail.root@eunhasu.gist.ac.kr> Message-ID: <434E1198.9070101@sophia.inria.fr> hi, >I have serious problem with ns-2. When running ns-2 I accidently meet >segmentation fault. >I do not know the exact position of seg. fault. But there is a clue > If you do not know where it comes from, there is little chance anyone else would know. You should use a debugger for this kind of problem. For example, run ns under gdb and, when the crash happens, type "bt" to get a backtrace. It will tell you exactly where the segfault happened. However, it looks like you get this with a modified ns-2. If you cannot reproduce this problem with an unmodified ns-2, there is zero chance anyone will try to find the bug. If it only happens in your version of ns-2, there is a great chance this is a bug of yours and not of ns-2. regards, Mathieu From jainim at gist.ac.kr Thu Oct 13 02:16:29 2005 From: jainim at gist.ac.kr (=?EUC-KR?B?wK/A57/r?=) Date: Thu, 13 Oct 2005 18:16:29 +0900 (KST) Subject: [Ns-developers] Segmentation fault at MAC layer Message-ID: <31527641.1129194989856.JavaMail.root@eunhasu.gist.ac.kr> Thank you for your comment. But still there is a wierd thing. When I run gdb and running ns-2, there is no error but when I run ns-2 only, there is segmentation fault. It is really strange... Any comment is really appreciate. with regards Jaeyong --- Original Message --- From : "mathieu lacage" To : Date : 2005/10/13 ??? ?? 4:49:44 Subject : If you do not know where it comes from, there is little chance anyone else would know. You should use a debugger for this kind of problem. For example, run ns under gdb and, when the crash happens, type "bt" to get a backtrace. It will tell you exactly where the segfault happened. However, it looks like you get this with a modified ns-2. If you cannot reproduce this problem with an unmodified ns-2, there is zero chance anyone will try to find the bug. If it only happens in your version of ns-2, there is a great chance this is a bug of yours and not of ns-2. regards, Mathieu From francesco.gringoli at ing.unibs.it Thu Oct 13 02:35:04 2005 From: francesco.gringoli at ing.unibs.it (Francesco Gringoli) Date: Thu, 13 Oct 2005 11:35:04 +0200 Subject: [Ns-developers] Segmentation fault at MAC layer In-Reply-To: <31527641.1129194989856.JavaMail.root@eunhasu.gist.ac.kr> References: <31527641.1129194989856.JavaMail.root@eunhasu.gist.ac.kr> Message-ID: <16E52CB3-4DFE-4482-8DCE-A32E4E5E5856@ing.unibs.it> The same binary? Or the gdb ready is compiled as a different one? What about compiler optimization? Try to switch off all -O... Regards, FG On Oct 13, 2005, at 11:16 AM, ??? wrote: > > > Thank you for your comment. > > But still there is a wierd thing. > > When I run gdb and running ns-2, there is no error but > when I run ns-2 only, there is segmentation fault. > It is really strange... > > Any comment is really appreciate. > > with regards > Jaeyong > > --- Original Message --- > From : "mathieu lacage" > To : > Date : 2005/10/13 ??? ?? 4:49:44 > Subject : > > If you do not know where it comes from, there is little chance anyone > > else would know. You should use a debugger for this kind of > problem. For > > example, run ns under gdb and, when the crash happens, type "bt" to > get > > a backtrace. It will tell you exactly where the segfault happened. > > > > However, it looks like you get this with a modified ns-2. If you > cannot > > reproduce this problem with an unmodified ns-2, there is zero chance > > anyone will try to find the bug. If it only happens in your version of > > ns-2, there is a great chance this is a bug of yours and not of ns-2. > > > > regards, > > Mathieu > > > > > > From lars.eggert at netlab.nec.de Thu Oct 13 02:35:43 2005 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Thu, 13 Oct 2005 11:35:43 +0200 Subject: [Ns-developers] Fwd: [e2e] A patch that speeds up the NS-2 simulation References: <02d601c5cfc9$13508f70$f5f2010a@seashadow> Message-ID: <9B495D8E-28C1-4E19-B7AE-160139BF12AA@netlab.nec.de> Just saw this on end2end and couldn't recall seeing it here. Begin forwarded message: > From: "Xiaoliang (David) Wei" > Date: October 13, 2005 9:38:16 AM GMT+02:00 > To: > Subject: [e2e] A patch that speeds up the NS-2 simulation > > > I guess this may help some colleagues in e2e, especially those > who are using NS-2 to simulate high speed long distance network. If > you find that your NS-2 simulation runs on a 200-second simulation > for a day, the patch may probably help. You can download the patch > and see detailed explanation from: > > http://www.cs.caltech.edu/~weixl/technical/ns2patch/ns2patch.htm > > In the patch, I only changed the event scheduler of NS2. So, > the patched NS-2 will give the same results as the original one. > Depending on different scenarios, the patched NS2 runs faster in > most the cases I tested, sometimes 50 times faster. If you find any > problem, please let me know.:) > > > > A little bit more details (See the link above for more details): > > The original NS2 scheduler is implemented by Calendar Queue. > Its performance is expected to be O(1) on average but the real > results may be much longer, especially when the events are not > evenly distributed and the bucket-width is not "correct" for the > event distribution. This is unfortunately more common in > simulations of high speed long distance network, where the events > are clustered in bursts. > > I add three changes: > > 1. Use the gaps between dequeued events, instead the gaps between > the events in the most crowded bucket, to estimate the bucket-width. > > 2. Apply a scheme similar to SNOOPy Calendar Queue that tunes the > bucket-width dynamically > > 3. Inside a bucket, I changed the search of event insertion point > from forward-search to backward-search. > > > > > -David > > Xiaoliang (David) Wei Graduate Student in CS at Caltech > http://www.davidwei.org > ==================================================== > > Lars -- Lars Eggert NEC Network Laboratories From pedro.estrela at inesc.pt Thu Oct 13 03:50:58 2005 From: pedro.estrela at inesc.pt (Pedro Estrela) Date: Thu, 13 Oct 2005 11:50:58 +0100 Subject: [Ns-developers] Segmentation fault at MAC layer In-Reply-To: <31527641.1129194989856.JavaMail.root@eunhasu.gist.ac.kr> Message-ID: <000001c5cfe4$00b93cc0$172914ac@tagus.ist.utl.pt> I agree with Mathieu; Its most probably a bug of our own code; if not, then its most probably a bug from the specific NS2 modification that you are using; only if these are not valid, then it might be a bug from core NS2. >From my own experience, I'm using ns-2.26 with the CIMS micro-mobility suite of protocols, and I've modified the simulator in various ways to model the TIMIP protocol (my research work); In this scenario, for each non-trivial bug on core NS that I've found and fixed, there were around 10 bugs from CIMS, and around 100 from my own modifications! Thus, it is most important to try to isolate the bug with the least modifications from base NS. In that process, you should use a good debugger to carefully check what is happening. For this I suggest ddd, which is a graphical front-end to gdb with very powerful data inspection capabilities. Check this page on the topic "C++ debugging" for the link to a good tutorial http://inesc-0.tagus.ist.utl.pt/~pmsrve/ns2/ns2_debugging.html also, check valgrind, a run-time checker for unitialized variables, wrong memory allocations. Etc. ------- regarding your doubt, this as also happened to me, where a program runs fine inside the debugger, but wrong without it. Normally is related to major memory corruption (inside the debugger it may be more permissible to mem corruption). Also common syntom is changing a .h file and not compiling all involved files automatically again (caused by wrong dependencies in "make dep"). I suggest: - make clean; make - checking mem alloctions with ddd Pedro Vale Estrela http://inesc-0.tagus.ist.utl.pt/~pmsrve/timip/ > -----Original Message----- > From: ns-developers-bounces at ISI.EDU [mailto:ns-developers-bounces at ISI.EDU] On Behalf Of ?????? > Sent: quinta-feira, 13 de Outubro de 2005 10:16 > To: mathieu lacage; jainim at gist.ac.kr; ns-developers > Subject: Re: [Ns-developers] Segmentation fault at MAC layer > > > > Thank you for your comment. > > But still there is a wierd thing. > > When I run gdb and running ns-2, there is no error but > when I run ns-2 only, there is segmentation fault. > It is really strange... > > Any comment is really appreciate. > > with regards > Jaeyong > > --- Original Message --- > From : "mathieu lacage" > To : > Date : 2005/10/13 ??? ?? 4:49:44 > Subject : > > If you do not know where it comes from, there is little chance anyone > > else would know. You should use a debugger for this kind of problem. For > > example, run ns under gdb and, when the crash happens, type "bt" to get > > a backtrace. It will tell you exactly where the segfault happened. > > > > However, it looks like you get this with a modified ns-2. If you cannot > > reproduce this problem with an unmodified ns-2, there is zero chance > > anyone will try to find the bug. If it only happens in your version of > > ns-2, there is a great chance this is a bug of yours and not of ns-2. > > > > regards, > > Mathieu > > > > From Mathieu.Lacage at sophia.inria.fr Thu Oct 13 04:53:49 2005 From: Mathieu.Lacage at sophia.inria.fr (mathieu lacage) Date: Thu, 13 Oct 2005 13:53:49 +0200 Subject: [Ns-developers] Segmentation fault at MAC layer In-Reply-To: <31527641.1129194989856.JavaMail.root@eunhasu.gist.ac.kr> References: <31527641.1129194989856.JavaMail.root@eunhasu.gist.ac.kr> Message-ID: <434E4ACD.6010509@sophia.inria.fr> You should consider using valgrind. It can be very very slow but if you can ignore all the error reports from various tcp monitoring variables, you might find it useful. http://valgrind.org Memory corruption problems which happen a lot during developement are best found with valgrind (or more fancy tools if you can pay for them) but the fact that the ns-2 tcp code uses a lot of uninitialized variables makes it really hard to focus on your own bugs. A complete list of these uninitialized variables is in one of my previous emails to this ML so, if you feel like doing something great today, you can try to find reasonable default values for these uninitialized variables. regards, Mathieu ??? wrote: >Thank you for your comment. > >But still there is a wierd thing. > >When I run gdb and running ns-2, there is no error but >when I run ns-2 only, there is segmentation fault. >It is really strange... > >Any comment is really appreciate. > >with regards >Jaeyong > >--- Original Message --- >From : "mathieu lacage" >To : >Date : 2005/10/13 ??? ?? 4:49:44 >Subject : > >If you do not know where it comes from, there is little chance anyone > >else would know. You should use a debugger for this kind of problem. For > >example, run ns under gdb and, when the crash happens, type "bt" to get > >a backtrace. It will tell you exactly where the segfault happened. > > > >However, it looks like you get this with a modified ns-2. If you cannot > >reproduce this problem with an unmodified ns-2, there is zero chance > >anyone will try to find the bug. If it only happens in your version of > >ns-2, there is a great chance this is a bug of yours and not of ns-2. > > > >regards, > >Mathieu > > > > > > > From Mathieu.Lacage at sophia.inria.fr Thu Oct 13 04:56:43 2005 From: Mathieu.Lacage at sophia.inria.fr (mathieu lacage) Date: Thu, 13 Oct 2005 13:56:43 +0200 Subject: [Ns-developers] Fwd: [e2e] A patch that speeds up the NS-2 simulation In-Reply-To: <9B495D8E-28C1-4E19-B7AE-160139BF12AA@netlab.nec.de> References: <02d601c5cfc9$13508f70$f5f2010a@seashadow> <9B495D8E-28C1-4E19-B7AE-160139BF12AA@netlab.nec.de> Message-ID: <434E4B7B.3080100@sophia.inria.fr> Nice. Being better than Heap is hard... Mathieu Lars Eggert wrote: > Just saw this on end2end and couldn't recall seeing it here. > > Begin forwarded message: > >> From: "Xiaoliang (David) Wei" >> Date: October 13, 2005 9:38:16 AM GMT+02:00 >> To: >> Subject: [e2e] A patch that speeds up the NS-2 simulation >> >> >> I guess this may help some colleagues in e2e, especially those >> who are using NS-2 to simulate high speed long distance network. If >> you find that your NS-2 simulation runs on a 200-second simulation >> for a day, the patch may probably help. You can download the patch >> and see detailed explanation from: >> >> http://www.cs.caltech.edu/~weixl/technical/ns2patch/ns2patch.htm >> >> In the patch, I only changed the event scheduler of NS2. So, the >> patched NS-2 will give the same results as the original one. >> Depending on different scenarios, the patched NS2 runs faster in >> most the cases I tested, sometimes 50 times faster. If you find any >> problem, please let me know.:) >> >> >> >> A little bit more details (See the link above for more details): >> >> The original NS2 scheduler is implemented by Calendar Queue. Its >> performance is expected to be O(1) on average but the real results >> may be much longer, especially when the events are not evenly >> distributed and the bucket-width is not "correct" for the event >> distribution. This is unfortunately more common in simulations of >> high speed long distance network, where the events are clustered in >> bursts. >> >> I add three changes: >> >> 1. Use the gaps between dequeued events, instead the gaps between >> the events in the most crowded bucket, to estimate the bucket-width. >> >> 2. Apply a scheme similar to SNOOPy Calendar Queue that tunes the >> bucket-width dynamically >> >> 3. Inside a bucket, I changed the search of event insertion point >> from forward-search to backward-search. >> >> >> >> >> -David >> >> Xiaoliang (David) Wei Graduate Student in CS at Caltech >> http://www.davidwei.org >> ==================================================== >> >> > > Lars > -- > Lars Eggert NEC Network Laboratories > From tomh at tomh.org Thu Oct 13 22:14:02 2005 From: tomh at tomh.org (Tom Henderson) Date: Thu, 13 Oct 2005 22:14:02 -0700 Subject: [Ns-developers] ns-2.29 release candidate In-Reply-To: <1129020800.5166.209.camel@chronos> References: <1129020800.5166.209.camel@chronos> Message-ID: <434F3E9A.90609@tomh.org> Mathieu Lacage wrote: > On Tue, 2005-10-11 at 07:30 +0000, Tom Henderson wrote: > >>>Validation succeeds with -O0 and -O3/gcc 3.4.4 and fails with -O3/gcc >>>4.0.1 in webcache: >> >>this one I'm more concerned about for the moment. Have you looked >>into this failure mode-- is it limited to -O3? > > > It is present with -O1 and -O3 at least. > > Mathieu Testing with optimizations on gcc-3.3.4, -Wall -Werror works, but anything above -O0 fails the build. I am afraid that chasing down all these problems with optimizations turned on will really delay things. I'd like to suggest that we try to clear problems with the following flags "-Wall -Werror -O0" on gcc 3.3.4, gcc 3.4.4, gcc 4.0.1 (including OS X), and Cygwin, and leave the rest for future release. Tom From Mathieu.Lacage at sophia.inria.fr Thu Oct 13 23:19:34 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 14 Oct 2005 08:19:34 +0200 Subject: [Ns-developers] ns-2.29 release candidate In-Reply-To: <434F3E9A.90609@tomh.org> References: <1129020800.5166.209.camel@chronos> <434F3E9A.90609@tomh.org> Message-ID: <1129270774.5166.255.camel@chronos> On Thu, 2005-10-13 at 22:14 -0700, Tom Henderson wrote: > Mathieu Lacage wrote: > > On Tue, 2005-10-11 at 07:30 +0000, Tom Henderson wrote: > > > >>>Validation succeeds with -O0 and -O3/gcc 3.4.4 and fails with -O3/gcc > >>>4.0.1 in webcache: > >> > >>this one I'm more concerned about for the moment. Have you looked > >>into this failure mode-- is it limited to -O3? > > > > > > It is present with -O1 and -O3 at least. > > > > Mathieu > > Testing with optimizations on gcc-3.3.4, -Wall -Werror works, but > anything above -O0 fails the build. > > I am afraid that chasing down all these problems with optimizations > turned on will really delay things. I'd like to suggest that we try to > clear problems with the following flags "-Wall -Werror -O0" on gcc > 3.3.4, gcc 3.4.4, gcc 4.0.1 (including OS X), and Cygwin, and leave the > rest for future release. If you create a cvs tag/branch, make sure nothing but fixes get committed there and make the next release out of that tag/branch, I am okay with this. Otherwise, you will just never converge towards something stable. Mathieu -- From pedro.estrela at inesc.pt Fri Oct 14 10:54:40 2005 From: pedro.estrela at inesc.pt (Pedro Estrela) Date: Fri, 14 Oct 2005 18:54:40 +0100 Subject: [Ns-developers] NS hierarchical addresses guide Message-ID: <000601c5d0e8$5ae84a10$172914ac@tagus.ist.utl.pt> Hi I've made a complete guide concerning the usage of hierarchical addresses in NS2. This guide covers: - Flat addresses usage in pure Wired networks - Flat addresses usage in pure Wireless networks - Hierarchical addresses usage in pure Wired networks - Hierarchical Addresses in Wired + Wireless Mobile Networks - tips for Wired-cum-Wireless and IP Mobility Simulations - Type of Addresses (haddr, Id, Iaddr, handle) http://inesc-0.tagus.ist.utl.pt/~pmsrve/ns2/ns2_haddr_tips.html At the end of this guide, I propose the following nomenclature for the multiple ways of identifying node in NS: ## the "handle" is the otcl name; it refers to an object of the form "_oXXX", and ## because of this, it is the only form can be used to directly call internal ## instprocs and variables. ## the "haddr" is the Hierarquical address, on the form "X.Y.Z" ## the "iaddr" is the INTEGER hieralquical address, where the haddr string is simply ## ENCODED in a 32 bit integer. ## the "id" is the sequential Node ID of the simulator. ## ## Type | VarNames | C++ type | TCL | Example | Error / UNK ## -----------------------|-------------|-----------|----------------|-------------|-------------- ## Node's handle | N_handle | char * | string | "_o89" | "-1" ## String HierAddress | N_haddr | char * | string | "1.2.3" | "-1" ## 32 bit Address | N_iaddr | int | int in string | 6144 | -1 ## Sequential ID | N_id | int | int in string | 4 | -1 ## and I also introduce the conversion procs "handle2iaddr", "handle2haddr", "handle2id", etc. Pedro Vale Estrela http://inesc-0.tagus.ist.utl.pt/~pmsrve/ns2/ From pedro.estrela at inesc.pt Fri Oct 14 11:01:57 2005 From: pedro.estrela at inesc.pt (Pedro Estrela) Date: Fri, 14 Oct 2005 19:01:57 +0100 Subject: [Ns-developers] patch: tcl/ex/hier-rtg-100.tcl with colors Message-ID: <000901c5d0e9$5e458960$172914ac@tagus.ist.utl.pt> Hi I've modified the tcl/ex/hier-rtg-100.tcl example for my hierarchical addresses guide. http://inesc-0.tagus.ist.utl.pt/~pmsrve/ns2/ns2_haddr_tips.html For this, the example now color-codes the nodes based on cluster and domain addresses: Domain 0: each cluster as a different shade of Red Domain 1: each cluster as a different shade of Blue Domain 2: each cluster as a different shade of Green Domain 3: each cluster as a different shade of Magenta The patch below enables one to generate this pretty picture (warning: very large file) http://inesc-0.tagus.ist.utl.pt/~pmsrve/ns2/files/haddr_all_nodes_zoom.PNG regards Pedro Vale Estrela http://inesc-0.tagus.ist.utl.pt/~pmsrve/ns2 ------- Index: hier-rtg-100.tcl =================================================================== RCS file: /home/pmsrve/.cvsroot/ns_cims/tcl/ex/hier-rtg-100.tcl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- hier-rtg-100.tcl 9 Oct 2003 18:59:11 -0000 1.1 +++ hier-rtg-100.tcl 21 Sep 2005 16:23:31 -0000 1.2 @@ -61,6 +61,46 @@ exit 0 } + + + +######## start pmsrve - pedro.estrela at gmail.com - 21/september/2005 +# this code will assign colors to the hierarchical nodes, based on the domain and cluster addresses. +# each domain will have a distinct color (red, blue, green, magenta) and each cluster will have a certain shade of +# the domain's color +# +# this way, it will be easier to inspect in NAM the correct usage of hierarchical addresses. +# +# NOTE: if you want to change the colors, check this simple TK program: http://wiki.tcl.tk/8606 +# + +set color_array { + red red4 maroon tomato + blue blue4 SteelBlue cyan + green green4 SpringGreen4 seagreen2 + magenta magenta3 orchid2 pink3 +} + + +for {set i 0} { $i < [Node set nn_] } { incr i } { + + set haddr [$n($i) set address_] + set L [AddrParams split-addrstr $haddr] + set domain [ lindex $L 0 ] + set cluster [ lindex $L 1 ] + + + set c [ lindex $color_array [ expr $domain * 4 + $cluster ] ] + puts "Node $haddr -> $c" + + $n($i) color $c + $n($i) label "$haddr" +} +####### end pmsrve + + + + $ns run From tomh at tomh.org Sun Oct 16 20:56:38 2005 From: tomh at tomh.org (Tom Henderson) Date: Sun, 16 Oct 2005 20:56:38 -0700 Subject: [Ns-developers] ns-2.29 release candidate In-Reply-To: <4349D183.30305@tomh.org> References: <4349D183.30305@tomh.org> Message-ID: <435320F6.8060602@tomh.org> Tom Henderson wrote: > I put together an ns-2.29 release candidate at: > http://www.isi.edu/nsnam/dist/ns-2.29-rc1.tgz > > Unless there are major comments, I plan to make a release of this later > in the week, and then allinone shortly after that. I received feedback from several people on the above snapshot. Mathieu built with FC3 and FC4 (gcc 3.4.4 and gcc 4.0.1)-- builds with -Wall -Werror -O0, but -O1 and above cause failures in various places. I previously built on gcc 3.3.4 and found that it builds/validates with -Wall -Werror -O0, but not with -O1 or above. Sven Ehlert reported that otcl-1.10 does not build on cygwin because of the X dependencies removed between 1.9 and 1.10. Mathieu committed a patch to revert this, and the proposed otcl-1.11 can be found at: http://www.isi.edu/nsnam/dist/otcl-1.11-rc1.tgz Sven also reported that there were lots of warnings in building the ns-2 rc, but no show stoppers, and that validation failed in test-all-tcp-init-win-full. I tried on my own local copy and found that smac-multihop and wireless-tdma failed but not test-all-tcp-init-win-full. Sally Floyd tested and did not report any problems with FreeBSD (don't know which version). I built it on my OS X (10.4) machine and found that it builds with a lot of warnings (especially "rcsid defined but not used" and "MIN/MAX redefined" warnings), but builds OK with -Wall -O0. However, two subtests in test-all-adaptive-red fail: red1AdaptFeng and red2-AdaptFeng. Sally tells me that these are not important variants and could be left out of the tests if needed. In summary, for recent Linux and FreeBSD, we seem to be OK with building and validating "-Wall -Werror -O0" with the above snapshot. With Cygwin, we take a lot of warnings and are getting a handful of regression tests to fail (Sven and I encountered different failures). With OS X, we similary can build with warnings and all but two individual regression tests pass. In light of this, I propose we should move forward with the above ns-2.29 release, since I don't know how long it will take to drive out all of these nits on the various platforms. I noticed that there were similar problems in the 2.28 release. I agree with Mathieu's suggestion to carry these problems forward in the main branch so that they get fixed in the next release or two. (Note: there is a compile farm at Sourceforge that seems to be usable for this purpose: http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1) Any different opinions? Tom From tomh at tomh.org Sun Oct 16 21:03:13 2005 From: tomh at tomh.org (Tom Henderson) Date: Sun, 16 Oct 2005 21:03:13 -0700 Subject: [Ns-developers] Mac802_11 random backoff patch In-Reply-To: <434C27A1.3050701@gmx.de> References: <434C27A1.3050701@gmx.de> Message-ID: <43532281.6060406@tomh.org> Enrico Minack wrote: > Dear ns-developers, > > as announced on the ns-users mailing list some months ago there is an > inaccuracy between the IEEE 802.11 code and the specification. The > random backoff is selected out of [0, cw_), but the specification > _includes_ cw_, thus it should be [0, cw_]. This bug leads to a better > throughput than actually possible. I'd highly appreciate any comment on > that. See attached a patch that modifies all random backoff selection of > Mac802_11. > > regards, > Enrico M. > > ieee 802.11 random backoff patch: > http://www.maniac-site.de/download/ns-2.28-ieee802_11_random_backoff.patch Enrico, Mathieu Lacage is writing a new 802.11 model that you might be interested in: http://mailman.isi.edu/pipermail/ns-developers/2005-September/001898.html As for the existing code, I am aware that there are some problems with it-- I've passed your patch on to someone who was trying to fix the existing code, to see if he agrees. We can try to pick that change up for the next release, as the release of ns-2.29 is imminent. I'll add it to the new tracker. Thanks, Tom From tomh at tomh.org Wed Oct 19 21:21:43 2005 From: tomh at tomh.org (Tom Henderson) Date: Wed, 19 Oct 2005 21:21:43 -0700 Subject: [Ns-developers] code freeze Message-ID: <43571B57.5060909@tomh.org> I haven't had any comments on the release candidate, so I plan to make the release and John will tar up the cvsroot directory to move to sourceforge. So please do not check anything into CVS in this interim. Next, I will make a new allinone release. we have a new project at sourceforge: http://sourceforge.net/projects/nsnam/ (nothing there yet) From kamal.ns2 at gmail.com Wed Oct 19 22:19:26 2005 From: kamal.ns2 at gmail.com (Kamal Gakhar) Date: Thu, 20 Oct 2005 10:49:26 +0530 Subject: [Ns-developers] NS+ 802.16 In-Reply-To: <20051018083849.49789.qmail@web32801.mail.mud.yahoo.com> References: <20051018083849.49789.qmail@web32801.mail.mud.yahoo.com> Message-ID: <7f7cdc120510192219l401643f6i30f4d91ec29757e0@mail.gmail.com> I am visting India nowadays and dont have it with me you can find it as an attachment file in mailing-list discussions of July (I think ). thanks Kamal On 10/18/05, Bogdan Hosu wrote: > > > Hello, > > I'm a student in the last year at UTCN, Romania, and > for my diploma I have to make a study between 802.16 > and 802.11 using NS. Because NS doesn't have support > for 802.16 I've decided to write a patch. > I've seen on the ns-developers mailing lists that you > have writen a small description of 802.16. Can you > mail it to me. > > Thanks in advance, > Bogdan > > > > __________________________________ > Yahoo! Music Unlimited > Access over 1 million songs. Try it free. > http://music.yahoo.com/unlimited/ > -- regards, Kamal (http://www-info.enst-bretagne.fr/~kgakhar) From tomh at tomh.org Wed Oct 19 22:22:19 2005 From: tomh at tomh.org (Tom Henderson) Date: Wed, 19 Oct 2005 22:22:19 -0700 Subject: [Ns-developers] announcing ns-2.29 release Message-ID: <4357298B.2060106@tomh.org> This is to announce that ns-2.29 is available from http://www.isi.edu/nsnam/dist/ns-src-2.29.tar.gz This release is primarily a maintenance release to address newer compilers and operating systems, including OS X and gcc-4.0.1. There are a few new things, however: - Upgrade of SCTP implementation (extensions and bug fixes) - Additions to the XCP codebase, including new error models, an HDLC/ARQ model, and addition of XCP to mobilenode to allow wireless simulations with XCP - Extension of energy model for SMAC - full-duplex mode for simple mac A full change log is available at: http://www.isi.edu/nsnam/ns/CHANGES.html A new version of the corresponding "allinone" package will be released in the next day or two. Tom From kamal.ns2 at gmail.com Wed Oct 19 22:25:01 2005 From: kamal.ns2 at gmail.com (Kamal Gakhar) Date: Thu, 20 Oct 2005 10:55:01 +0530 Subject: [Ns-developers] discussion 802.16 MAC In-Reply-To: <02c301c5d4b7$6e1571d0$219c738c@lovebyrj4txjm3> References: <02c301c5d4b7$6e1571d0$219c738c@lovebyrj4txjm3> Message-ID: <7f7cdc120510192225w1d6bcc52ic31dc0e81bed328e@mail.gmail.com> Just want to confirm again what I have said earlier that because of time constraints and work necessities in my thesis I have stopped developing ns2 code for 802.16 but I remain at disposal for any technical discussions if any advice is needed for this code development. Good luck to all who are trying to develop the ONE.!! thanks On 10/19/05, aqws wrote: > > Dear karmal: > I have read your articles related to 802.16 MAC simulation at isi > website. > It seems that you were writing for the 802.16 MAC simulation. > I am interesting in Wimax and try to write some simple ns2 code. > But I found many problems and difficulties. > May I ask you about some ns2 code proplems and if you have made it ? > Good luck :) > Many thanks and Best Regards, Yuting. > -- regards, Kamal (http://www-info.enst-bretagne.fr/~kgakhar) From tomh at tomh.org Sat Oct 22 21:15:12 2005 From: tomh at tomh.org (Tom Henderson) Date: Sat, 22 Oct 2005 21:15:12 -0700 Subject: [Ns-developers] announcing ns-allinone-2.29 Message-ID: <435B0E50.9020202@tomh.org> A new version of ns-allinone package is available at: http://www.isi.edu/nsnam/dist/ns-allinone-2.29.tar.gz This version includes the following packages: * Tcl release 8.4.11 (required component) * Tk release 8.4.11 (required component) * Otcl release 1.11 (required component) * TclCL release 1.17 (required component) * Ns release 2.29 (required component) * Nam release 1.11 (optional component) and some additional supporting packages, and an install script. More information can be found at: http://www.isi.edu/nsnam/ns/ns-build.html#allinone I have tested it on linux (gcc 3.3.4), OS X (10.4 with Xcode), and Cygwin 1.5.12. For OS X (gcc-4.0.1) and Cygwin, nam will not build successfully, but ns-2 will. nam has not been updated recently. Tom From Mathieu.Lacage at sophia.inria.fr Wed Oct 26 04:48:23 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 26 Oct 2005 13:48:23 +0200 Subject: [Ns-developers] ns-2-snapshot-20050907-13 AP to node In-Reply-To: <48a4d13c0510260431j518f32fbj1b3c86866aa926dd@mail.gmail.com> References: <48a4d13c0510251055r1cb5c5bt3f5a123cc5e037e4@mail.gmail.com> <1130308782.26376.39.camel@chronos> <48a4d13c0510260431j518f32fbj1b3c86866aa926dd@mail.gmail.com> Message-ID: <1130327303.26376.66.camel@chronos> On Wed, 2005-10-26 at 17:01 +0530, Anand SVR wrote: > 1. The tsid returned by the callback is 1 when addts is done from AP > whereas it is 9 when done by qsta. The reason could be that in > MacHighQap::addTsRequest (TSpecRequest *request), the following code > segment > that was there in the corresponding function in > MacHighQsta::addTsRequest (TSpecRequest *request) is missing. > > /****************/ > > TSpec *tspec = request->getTSpec (); > bool found = false; > for (int i = 8; i < 16; i++) { > if (m_ts.find (i) == m_ts.end ()) { > /* this is an available tsid. */ > tspec->setTsid (i); > found = true; > break; > } > } > if (!found) { > TRACE ("no tsids available"); > request->notifyRefused (); > return; > } > > /***************/ > > As a result the base tsid value is zero, which gets incremented to 1 > before the callback. So, the UP is 1, which is less than 8 and the > corresponding rules given in > enqueueToLow seem to apply. Basically the code doesn't enter > queueTS (requestedTID, packet); in this case. > > After adding the above code segment in MacHighQap::addTsRequest, the > tsid returned is 9 and not 1. Yes, it sounds right. I need to double-check this with the code but your approach sounds like the right fix. > Starting Simulation... > create node > create node > SCHED TRACE 1 0.000000 Admitted new stream. Service interval: > 0.150000, capTime: 0.007015 > SCHED TRACE 1 1.000000 sending beacon > MAC LOW 1 1.000000 startTx 340 to -1 id: 0 > MAC LOW 1 1.000000 tx MGT_BEACON to -1 with mode 0 id: 0 from 1 > MAC LOW 2 1.000942 duration/id: 0.000126 id:0 > MAC LOW 2 1.000942 rx broadcast from 1 > QSTA TRACE 2 1.000942 requested tid 0 > QSTA TRACE 2 1.000942 queue "MGT_ASSOCIATION_REQUEST" to 1 thru AC_VO id: 0 > SCHED TRACE 1 1.000958 start CAP until 1.007973 > SCHED TRACE 1 1.000958 start txop for 1 until 1.007973 > MAC LOW 1 1.000958 startTx 28 to 1 id: 0 > MAC LOW 1 1.000958 tx MGT_CFPOLL to 1 with mode 0 id: 0 from 1 AP scheduler sends CFPOLL to itself to notify everyone that a CAP for itself is starting. > MAC LOW 2 1.001068 duration/id: 0.007015 id:0 > MAC LOW 2 1.001068 rx not-for-me from 1 rx CFPOLL at 2: not for me so drop it. > MAC LOW 1 1.001093 super fast Ack failed Here, we have a problem because 1 (AP) does not rx the CFPOLL for itself so it cannot answer the CFPOLL so the scheduler assumes that the CFPOLL was ignored and it tries to perform another TXOP but since you have no other TXOP scheduled, nothing happens until the start of next CAP. Generally speaking, I think that what you are trying to do (get AP to create and use CFPOLL TXOPs for itself) has never been tested before and, well, it does not work right. It is not clear to me how it should work. Maybe this sort of thing should be done with TCLAS which are not implemented yet. thanks for your insightful feedback, Mathieu -- From jeanmichel.sanner at francetelecom.com Wed Oct 26 06:33:53 2005 From: jeanmichel.sanner at francetelecom.com (SANNER Jean-Michel RD-RESA-REN) Date: Wed, 26 Oct 2005 15:33:53 +0200 Subject: [Ns-developers] new 802.11 release Message-ID: Hello Mathieu, We tried to compile your 802.11 release, and we found some trouble with the gsl library: Hereafter the error message: "802.11/rng-uniform.h:46:25: gsl/gsl_rng.h: No such file or directory" Could you please help us (what gsl version do you use ?) Regards Jean Michel Sanner -----Message d'origine----- De : ns-developers-bounces at ISI.EDU [mailto:ns-developers-bounces at ISI.EDU] De la part de Mathieu Lacage Envoy? : mercredi 14 septembre 2005 09:17 ? : ns-developers Objet : [Ns-developers] new 802.11 release hi, A new release of my 802.11 code based on a recent ns-2 snapshot is available at: http://www-sop.inria.fr/dream/personnel/Mathieu.Lacage/ns2/ or ftp://ftp-sop.inria.fr/dream/ns-80211/ns-2-snapshot-20050907-13.tar.gz This release changes the code layout: there are now 3 new directories in the ns-2 root directory: - 80211: all of the 802.11 code. This includes normal 802.11, EDCA and HCCA support. The test-80211.tcl and test-80211e.tcl scripts can be used to play with this code. - node-common: the files which can be used to integrate various types of network interfaces in ns-2. Right now, there is the 802.11 network interface and a simple demo interface in simple-interface. This directory also contains various components which can be re-used in other network-interface implementations (such as, an ARP LL layer) - simple-interface: a very simple demo of how to integrate a new type of network interface in ns-2 using the node-common infrastructure. Try the test-simple.tcl script to play with it. Every directory contains a bunch of tcl-*.cc/h files which act as wrappers for the tcl scripts to the real C++ objects. This new release is quite important because it is the first release where the number of "hacks" to integrate the 802.11 layer in ns-2 is zero. I have had to make a few modifications to ns-2 (they are detailed below) but these modifications are clean and it should be possible to commit them without too much trouble. Modifications to ns-2 core: - classifier.patch: this makes the port classifier functionality (allocPort) available from C++. It was previously only available from tcl. http://www- sop.inria.fr/dream/personnel/Mathieu.Lacage/ns2/classifier.patch - connector.patch: this adds missing API for the C++ code. http://www- sop.inria.fr/dream/personnel/Mathieu.Lacage/ns2/connector.patch - net-interface.patch: rename common/net-interface.h to common/network-interface.h. This is to avoid conflicts with my own code which also has a net-interface.h header (I cannot really use network- interface.h myself because the ns-2 code uses the net-interface.h header to define the NetworkInterface class). http://www- sop.inria.fr/dream/personnel/Mathieu.Lacage/ns2/net-interface.patch - dependency on gsl: the Gnu Scientific Library is used by my 802.11 layer to deal with random numbers (I could switch to the internal random number generator if there is a neeed for this) and to implement the PHY models of the various modulation modes used in 802.11a. It is not clear to me if it is acceptable to add a new dependency to ns-2 as a whole. Maybe adding a configure check for gsl and build the 802.11 code conditionally to this check would be acceptable ? My current work is focused on trying to write a simulation entirely in C ++ without any tcl script to show the feasability of such a thing so I don't expect new 802.11 features to creep in soon. regards, Mathieu -- From Mathieu.Lacage at sophia.inria.fr Wed Oct 26 08:40:30 2005 From: Mathieu.Lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 26 Oct 2005 17:40:30 +0200 Subject: [Ns-developers] new 802.11 release In-Reply-To: References: Message-ID: <1130341230.29903.11.camel@chronos> hi, On Wed, 2005-10-26 at 15:33 +0200, SANNER Jean-Michel RD-RESA-REN wrote: > We tried to compile your 802.11 release, and we found some trouble with the gsl library: > Hereafter the error message: > "802.11/rng-uniform.h:46:25: gsl/gsl_rng.h: No such file or directory" > > Could you please help us (what gsl version do you use ?) I use gsl 1.4 but any other later version should work. Did you find a later version which does not work ? regards, Mathieu -- From johnh at ISI.EDU Thu Oct 27 14:28:06 2005 From: johnh at ISI.EDU (John Heidemann) Date: Thu, 27 Oct 2005 14:28:06 -0700 Subject: [Ns-developers] snapshot of source handed off Message-ID: <200510272128.j9RLS6g7024478@dash.isi.edu> I made a snapshot of all the ns source as of today. (This includes Padma's changes yesterday.) This tar includes the following software: conf javis nam-1 ns-2 topoconverter xgraph which is, I believe, all the public ns-related code. I've sent it to Tom H. to install at sourceforge. My experience is that this will take a couple of days. Changes to the source during that time will have to be ported manually to the new cvs repository. (A big thanks to Tom for normalizing the ns license and taking this overall task on.) For now we plan to continue hosting the ns website at ISI, and to set up (soon) a new wiki for ns use. -John