From YYFINPTV at it.com.pl Sat May 1 19:47:30 2004 From: YYFINPTV at it.com.pl (Katrina Cline) Date: Sat May 1 18:52:37 2004 Subject: [nsclick-users] get the better job * buy a university degree today Message-ID: An HTML attachment was scrubbed... URL: http://cs-lists.cs.colorado.edu/pipermail/nsclick-users/attachments/20040502/f62ec1df/attachment.htm From Antonio.Gonzalez1 at pandora.be Tue May 11 15:42:47 2004 From: Antonio.Gonzalez1 at pandora.be (=?iso-8859-1?Q?Antonio_Gonz=E1lez_Kirchenmayer?=) Date: Tue May 11 15:43:05 2004 Subject: [nsclick-users] Timer under nsclick Message-ID: <001201c437a0$e6b01150$772d5351@Antwerp> Hello, I'm having difficulties using timers in nsclick. My element is using a timer for scheduled task. But the methods handling the timer are never called. But if I use click to run the configuration all it's ok. I'm using ns-2.26 with the nsclick-2.26.patch. And the lastest cvs version of click. Whats going on? Thankl you very much. Antonio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cs-lists.cs.colorado.edu/pipermail/nsclick-users/attachments/20040511/09c1d09e/attachment.htm From Antonio.Gonzalez1 at pandora.be Wed May 12 09:31:09 2004 From: Antonio.Gonzalez1 at pandora.be (=?iso-8859-1?Q?Antonio_Gonz=E1lez_Kirchenmayer?=) Date: Wed May 12 09:31:18 2004 Subject: [nsclick-users] Timer under nsclick : recall References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> Message-ID: <002801c43836$2642fbd0$772d5351@Antwerp> Hi Michael, Hi list I forwarded my question to a friend and he told me that, for him, the timers are working. The issue is the same: TimedSource(INTERVAL 0.333) -> Print ("Packet") -> ToSimDevice(eth0,IP); So I thougth that my nsclick was not well installed. But I reinstalled it and the timers don't work. What could be wrong? I have installed: ns2-2.26 (all-in-one) the ns2-2.26 patch from the nsclick site click is a last CVS version based on 1.3.1. and also the libnet-1.0.2a. Thank you. Antonio. From Michael.Neufeld at Colorado.EDU Wed May 12 09:42:41 2004 From: Michael.Neufeld at Colorado.EDU (Michael Neufeld) Date: Wed May 12 09:43:03 2004 Subject: [nsclick-users] Timer under nsclick : recall In-Reply-To: <002801c43836$2642fbd0$772d5351@Antwerp> References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> <002801c43836$2642fbd0$772d5351@Antwerp> Message-ID: <40A245F1.7040502@cs.colorado.edu> The timers are working fine for me, too, so I'm not certain what's going on. The usual timing problems I've seen with nsclick are with elements which don't use timers, but instead check the time whenever they get run and use that for doing periodic tasks. That shouldn't be happening in this case. Of course, I'm not using the absolute latest CVS version, so that might be part of the issue. Is your friend using the exact same CVS version of Click as you are? From time to time something changes in the Click scheduling core which requires modifications to nsclick. I'll look into things in more detail as I have time and let you know what I find out. -Mike Antonio Gonz?lez Kirchenmayer wrote: > Hi Michael, Hi list > > I forwarded my question to a friend and he told me that, > for him, the timers are working. > > The issue is the same: > > TimedSource(INTERVAL 0.333) > -> Print ("Packet") > -> ToSimDevice(eth0,IP); > > So I thougth that my nsclick was not well installed. > But I reinstalled it and the timers don't work. > > What could be wrong? > > I have installed: > ns2-2.26 (all-in-one) > the ns2-2.26 patch from the nsclick site > click is a last CVS version based on 1.3.1. > and also the libnet-1.0.2a. > > Thank you. Antonio. > > > > > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs-lists.cs.colorado.edu > http://cs-lists.cs.colorado.edu/mailman/listinfo/nsclick-users From Antonio.Gonzalez1 at pandora.be Wed May 12 16:44:58 2004 From: Antonio.Gonzalez1 at pandora.be (=?iso-8859-1?Q?Antonio_Gonz=E1lez_Kirchenmayer?=) Date: Wed May 12 16:48:59 2004 Subject: [nsclick-users] Timer under nsclick : simclick_gettimeofday References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> <002801c43836$2642fbd0$772d5351@Antwerp> <40A245F1.7040502@cs.colorado.edu> Message-ID: <000b01c43872$c11bac60$772d5351@Antwerp> Hi Michael, hi list, I have seen some posted messages about the issue of timers. (May 2003 threads I think). There is one who says that the simclick_gettimeofday() is never called. That's my case. I used gdb and indeed it's never called. I'm very confused about this, because is this bug was fixed, why I'm suffering it? Maybe my version of click? But I got it by cvs, following the click webpage instruccions..... Could be any problem with the cvs server, so I'm getting an old version of click? Can you tell me what version of click are you using, and how to get it? So I can try with that version... Thank you. Antonio. ----- Original Message ----- From: "Michael Neufeld" To: "Antonio Gonz?lez Kirchenmayer" Cc: "Michael Neufeld" ; Sent: Wednesday, May 12, 2004 5:42 PM Subject: Re: [nsclick-users] Timer under nsclick : recall > The timers are working fine for me, too, so I'm not certain what's going > on. The usual timing problems I've seen with nsclick are with elements > which don't use timers, but instead check the time whenever they get run > and use that for doing periodic tasks. That shouldn't be happening in > this case. Of course, I'm not using the absolute latest CVS version, so > that might be part of the issue. Is your friend using the exact same CVS > version of Click as you are? From time to time something changes in the > Click scheduling core which requires modifications to nsclick. I'll look > into things in more detail as I have time and let you know what I find out. > > -Mike > > Antonio Gonz?lez Kirchenmayer wrote: > > Hi Michael, Hi list > > > > I forwarded my question to a friend and he told me that, > > for him, the timers are working. > > > > The issue is the same: > > > > TimedSource(INTERVAL 0.333) > > -> Print ("Packet") > > -> ToSimDevice(eth0,IP); > > > > So I thougth that my nsclick was not well installed. > > But I reinstalled it and the timers don't work. > > > > What could be wrong? > > > > I have installed: > > ns2-2.26 (all-in-one) > > the ns2-2.26 patch from the nsclick site > > click is a last CVS version based on 1.3.1. > > and also the libnet-1.0.2a. > > > > Thank you. Antonio. > > > > > > > > > > _______________________________________________ > > nsclick-users mailing list > > nsclick-users@cs-lists.cs.colorado.edu > > http://cs-lists.cs.colorado.edu/mailman/listinfo/nsclick-users > From Antonio.Gonzalez1 at pandora.be Wed May 12 17:39:38 2004 From: Antonio.Gonzalez1 at pandora.be (=?iso-8859-1?Q?Antonio_Gonz=E1lez_Kirchenmayer?=) Date: Wed May 12 17:39:45 2004 Subject: [nsclick-users] Timer under nsclick : simclick_gettimeofday() more References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> <002801c43836$2642fbd0$772d5351@Antwerp> <40A245F1.7040502@cs.colorado.edu> Message-ID: <000b01c4387a$6402b0c0$772d5351@Antwerp> Hi Michael, hi list Sorry, I was wrong in my last message. The function simclick_gettiemofday is called. And I have findout that I have the last version of click. So now I'm very lost about this, I can't get what is wrong here. So I still need help. Thank you. Antonio. From Antonio.Gonzalez1 at pandora.be Mon May 17 07:10:48 2004 From: Antonio.Gonzalez1 at pandora.be (=?iso-8859-1?Q?Antonio_Gonz=E1lez_Kirchenmayer?=) Date: Mon May 17 07:10:59 2004 Subject: [nsclick-users] Timer under nsclick : the problem remains References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> <002801c43836$2642fbd0$772d5351@Antwerp> <40A245F1.7040502@cs.colorado.edu> Message-ID: <002e01c43c10$5eef9780$8ee4a551@Antwerp> Hi Michael, I'm still having the problem with timers. Since the timers are working ok also for Michael Voorhaen, I got the click version from him. We tried to guess what's the problem but without results. I have reinstalled linux, and nsclick ussing the click version I got, and I'm still having the problem. Please I need help, I have to prove my mobile ip implementation, and it has many timers as you can guess. If you need some information please ask me. Thank you. Antonio. From Michael.Neufeld at Colorado.EDU Mon May 17 08:00:08 2004 From: Michael.Neufeld at Colorado.EDU (Michael Neufeld) Date: Mon May 17 08:00:43 2004 Subject: [nsclick-users] Timer under nsclick : the problem remains In-Reply-To: <002e01c43c10$5eef9780$8ee4a551@Antwerp> References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> <002801c43836$2642fbd0$772d5351@Antwerp> <40A245F1.7040502@cs.colorado.edu> <002e01c43c10$5eef9780$8ee4a551@Antwerp> Message-ID: <40A8C568.6040400@cs.colorado.edu> I take it you can still reproduce the problem with the very simple traffic generator case you sent out last week? Have you tried tracing through the code which sets the timers in the debugger? It should be making a call to the function "simclick_sim_schedule" over in the ns-2 half of nsclick, in the file classifier/classifier-click.cc. You can also set a breakpoint at the method (in that same file) ClickEventHandler::handle and see if that gets called when the event is supposed to fire. I'd reccommend doing both of these tests with the simplest possible case which exhibits the problem -- should make isolating the problem easier. If both of these things are happening correctly, then the problem is most likely over in the click part of nsclick, and we can do further tracing in the debugger to figure out exactly where. -Mike Antonio Gonz?lez Kirchenmayer wrote: > Hi Michael, > > I'm still having the problem with timers. > > Since the timers are working ok also for > Michael Voorhaen, I got the click version from him. > We tried to guess what's the problem but without > results. > > I have reinstalled linux, and nsclick ussing the click > version I got, and I'm still having the problem. > > Please I need help, I have to prove my mobile ip implementation, > and it has many timers as you can guess. > > If you need some information please ask me. > > Thank you. Antonio. > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs-lists.cs.colorado.edu > http://cs-lists.cs.colorado.edu/mailman/listinfo/nsclick-users From Antonio.Gonzalez1 at pandora.be Mon May 17 10:32:03 2004 From: Antonio.Gonzalez1 at pandora.be (Antonio Gonzalez Kirchenmayer) Date: Mon May 17 10:32:14 2004 Subject: [nsclick-users] ns build error.... libnet.h BIGENDIAN ... not defined Message-ID: <40A8E903.1070409@pandora.be> Hi, I was building nsclick in another machine and I got: >> c++ -c -DTCP_DELAY_BIND_ALL -DNO_TK -DTCLCL_CLASSINSTVAR -DNDEBUG -DLINUX_TCP_HEADER -DUSE_SHM >> -DHAVE_LIBTCLCL -DHAVE_TCLCL_H -DHAVE_LIBOTCL1_0A8 -DHAVE_OTCL_H -DHAVE_LIBTK8_3 -DHAVE_TK_H >> -DHAVE_LIBTCL8_3 -DHAVE_TCL_H -DHAVE_CONFIG_H -DNS_DIFFUSION -DSMAC_NO_SYNC -DSTL_NAMESPACE=std >> -DUSE_SINGLE_ADDRESS_SPACE -DALLOW_RANDOM -I. -I/usr/ns-allinone-2.26/tclcl-1.0b13 -I/usr/ns-allinone-2.26/otcl-1.0a8 - >> I/usr/ns-allinone-2.26/include -I/usr/ns-allinone-2.26/include -I/usr/include/pcap -I./tcp -I./common -I./link -I./queue -I./adc -I./apps -I./mac >> -I./mobile -I./trace -I./routing -I./tools -I./classifier -I./mcast -I./diffusion3/lib/main -I./diffusion3/lib -I./diffusion3/lib/nr -I./diffusion3/ns >> -I./diffusion3/diffusion -I./asim/ -I./qs -o common/rawpacket.o common/rawpacket.cc >> In file included from common/agent.h:47, >> from common/rawpacket.cc:35: >> /usr/include/libnet.h:87:2: #error "byte order has not been specified, you'll >> need to #define either LIBNET_LIL_ENDIAN or LIBNET_BIG_ENDIAN. See the >> documentation regarding the libnet-config script." >> make: *** [common/rawpacket.o] Error 1 >> Ns make failed! >> See http://www.isi.edu/nsnam/ns/ns-problems.html for problems You can see next the entire output. What can I do to fix it? I'm using Libnet-1.0.2a. Thank you. Antonio. ============================================================ * Build ns-2.26 ============================================================ loading cache ./config.cache No .configure file found in current directory Continuing with default options... checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for c++... (cached) c++ checking whether the C++ compiler (c++ ) works... yes checking whether the C++ compiler (c++ ) is a cross-compiler... no checking whether we are using GNU C++... (cached) yes checking whether c++ accepts -g... (cached) yes checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking for main in -lXbsd... (cached) no checking for socket in -lsocket... (cached) no checking for gethostbyname in -lnsl... (cached) yes checking for dcgettext in -lintl... (cached) no checking for getnodebyname in -ldnet_stub... (cached) no checking that c++ can handle -O2... no checking if STL works without any namespace... no checking if STL works with namespace std... yes checking will use STL... yes checking for tcl.h... -I../include checking for libtcl8.3... -L../lib -ltcl8.3 checking for init.tcl... ../lib/tcl8.3 checking for tclsh8.3.2... (cached) ../bin/tclsh8.3 checking for tk.h... -I../include checking for libtk8.3... -L../lib -ltk8.3 checking for tk.tcl... ../lib/tk8.3 checking for otcl.h... -I../otcl-1.0a8 checking for libotcl1.0a8... -L../otcl-1.0a8 -lotcl checking for tclcl.h... -I../tclcl-1.0b13 checking for libtclcl... -L../tclcl-1.0b13 -ltclcl checking for tcl2c++... ../tclcl-1.0b13 checking for X11 header files checking for X11 library archive checking for XOpenDisplay in -lX11... (cached) no checking for libXext.a checking for libtcldbg... no checking dmalloc... not requested with --with-dmalloc checking for perl... /usr/bin checking for ANSI C header files... (cached) yes checking for bcopy... (cached) yes checking for bzero... (cached) yes checking for fesetprecision... (cached) no checking for getrusage... (cached) yes checking for sbrk... (cached) yes checking for snprintf... (cached) yes checking for arpa/inet.h... (cached) yes checking for netinet/in.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for time.h... (cached) yes checking for unistd.h... (cached) yes checking for net/ethernet.h... (cached) yes checking return type of random... long checking for int8_t... (cached) yes checking for int16_t... (cached) yes checking for int32_t... (cached) yes checking for u_int8_t... (cached) yes checking for u_int16_t... (cached) yes checking for u_int32_t... (cached) yes checking for u_char... (cached) yes checking for u_int... (cached) yes checking for strtoq... (cached) yes checking for strtoll... (cached) yes checking size of long... (cached) 4 checking for __int64_t... no checking for long long... yes checking for int64_t... (cached) yes checking which kind of 64-bit int to use... int64_t checking for struct ether_header... found checking for struct ether_addr... found checking for addr2ascii... (cached) no checking for Linux compliant tcphdr... found checking for BSD compliant tcphdr... not found checking for socklen_t... (cached) yes checking for main in -lpcap... (cached) yes checking to make nse... yes Explicitly disabling static compilation checking for dlopen in -ldl... (cached) yes checking for a BSD compatible install... (cached) /usr/bin/install -c creating ./config.status creating Makefile creating tcl/lib/ns-autoconf.tcl creating indep-utils/webtrace-conv/ucb/Makefile creating indep-utils/webtrace-conv/dec/Makefile creating indep-utils/webtrace-conv/nlanr/Makefile creating indep-utils/webtrace-conv/epa/Makefile creating indep-utils/cmu-scen-gen/setdest/Makefile creating autoconf.h autoconf.h is unchanged c++ -c -DTCP_DELAY_BIND_ALL -DNO_TK -DTCLCL_CLASSINSTVAR -DNDEBUG -DLINUX_TCP_HEADER -DUSE_SHM -DHAVE_LIBTCLCL -DHAVE_TCLCL_H -DHAVE_LIBOTCL1_0A8 -DHAVE_OTCL_H -DHAVE_LIBTK8_3 -DHAVE_TK_H -DHAVE_LIBTCL8_3 -DHAVE_TCL_H -DHAVE_CONFIG_H -DNS_DIFFUSION -DSMAC_NO_SYNC -DSTL_NAMESPACE=std -DUSE_SINGLE_ADDRESS_SPACE -DALLOW_RANDOM -I. -I/usr/ns-allinone-2.26/tclcl-1.0b13 -I/usr/ns-allinone-2.26/otcl-1.0a8 -I/usr/ns-allinone-2.26/include -I/usr/ns-allinone-2.26/include -I/usr/include/pcap -I./tcp -I./common -I./link -I./queue -I./adc -I./apps -I./mac -I./mobile -I./trace -I./routing -I./tools -I./classifier -I./mcast -I./diffusion3/lib/main -I./diffusion3/lib -I./diffusion3/lib/nr -I./diffusion3/ns -I./diffusion3/diffusion -I./asim/ -I./qs -o common/rawpacket.o common/rawpacket.cc In file included from common/agent.h:47, from common/rawpacket.cc:35: /usr/include/libnet.h:87:2: #error "byte order has not been specified, you'll need to #define either LIBNET_LIL_ENDIAN or LIBNET_BIG_ENDIAN. See the documentation regarding the libnet-config script." make: *** [common/rawpacket.o] Error 1 Ns make failed! See http://www.isi.edu/nsnam/ns/ns-problems.html for problems From Antonio.Gonzalez1 at pandora.be Tue May 18 09:34:27 2004 From: Antonio.Gonzalez1 at pandora.be (=?iso-8859-1?Q?Antonio_Gonz=E1lez_Kirchenmayer?=) Date: Tue May 18 09:34:39 2004 Subject: [nsclick-users] Timer under nsclick : debuging discovers References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> <002801c43836$2642fbd0$772d5351@Antwerp> <40A245F1.7040502@cs.colorado.edu> <002e01c43c10$5eef9780$8ee4a551@Antwerp> <40A8C568.6040400@cs.colorado.edu> <000901c43c63$d76a3ff0$8ee4a551@Antwerp> <40A94F97.1030208@cs.colorado.edu> Message-ID: <001101c43ced$9b476680$8ee4a551@Antwerp> Yes I have got the line: Simulator set node_factory_ Node/MobileNode/ClickNode So it is ok. I have debuged with care as you said and I'm sure that "simclick_sim_schedule" is not called, neither "RouterThread::wait()" who is in charge of calling "simclick_sim_schedule". So if "simclick_sim_schedule" is not called there are no Events generated (the timed ones I guess), and ClickClassifier::handle ( Event * ) is not fired. I have dicovered that when the program is in ClickClassifier::command(), and it enters in the case "loadclick" it goes to simclick_click_run. "simclick_click_run" calls RouterThread::driver(). Then in line 343 of routerthread.cc ( within RouterThread::driver() ) you can see: if (*runcount >0 ) { // run ocassional tasks: timers, select, ect. iter++; if ( iter % DRIVER_ITER_ANY == 0 ) wait(iter); } So for calling wait(), *runcount must be > 0, but it is not. In result wait() is not called. I continued debuging in this way, and never, in the many times that the program goes througth the line 343, *runcount is > 0. So I guess that arround here is the problem. What do you think? Can you suggest other debug steps to figure out the problem? Thank you. Antonio. ----- Original Message ----- From: "Michael Neufeld" To: "Antonio Gonz?lez Kirchenmayer" Sent: Tuesday, May 18, 2004 1:49 AM Subject: Re: [nsclick-users] Timer under nsclick : debuging > The classifier should be getting set for you when the node is created. > As long as you've got a line like this: > > Simulator set node_factory_ Node/MobileNode/ClickNode > > things should be getting setup correctly. > > Have you tried stepping through the code which sets the timer, i.e. > setting a breakpoint in your Click code and tracing through? I'm curious > as to what code path it's taking -- simclick_sim_schedule really should > be getting called at some point, and something is pretty broken if it > isn't. You might want to rebuild Click without the -O2 flag if you > haven't already -- debugging it is pretty annoying when optimizations > are occuring. > > -Mike From Michael.Neufeld at Colorado.EDU Tue May 18 09:54:58 2004 From: Michael.Neufeld at Colorado.EDU (Michael Neufeld) Date: Tue May 18 09:55:43 2004 Subject: [nsclick-users] Timer under nsclick : debuging discovers In-Reply-To: <001101c43ced$9b476680$8ee4a551@Antwerp> References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> <002801c43836$2642fbd0$772d5351@Antwerp> <40A245F1.7040502@cs.colorado.edu> <002e01c43c10$5eef9780$8ee4a551@Antwerp> <40A8C568.6040400@cs.colorado.edu> <000901c43c63$d76a3ff0$8ee4a551@Antwerp> <40A94F97.1030208@cs.colorado.edu> <001101c43ced$9b476680$8ee4a551@Antwerp> Message-ID: <40AA31D2.90401@cs.colorado.edu> What I suspect is that there may be an issue with the Click timer handling code and the nsclick patch. As I mentioned in an earlier e-mail, sometimes updates to the internal Click scheduler require changes to the nsclick configuration, and sometimes those don't always get made right away. What it looks like offhand is that such a change may have occured. Since I'm not working with the absolute latest CVS vesion I haven't had a chance to verify this. There should be code in RouterThread::wait which makes a call to simclick_sim_schedule for the next timer set to expire. Further debugging is going to likely require some work in the Click scheduler and its timer code. I've got a couple of deadlines looming, so can't spend a whole lot of time on things this week, but may have some time to look at it in more detail at some point next week. In the meantime I'll provide what help I can if you're going to continue working through the problem. What I would probably do next is to look in router.cc and routerthread.cc and see how timers get setup and executed by the non-nsclick Click configuration. That may provide some insight as to why the nsclick timers aren't working for you right now. -Mike Antonio Gonz?lez Kirchenmayer wrote: > Yes I have got the line: > Simulator set node_factory_ Node/MobileNode/ClickNode > So it is ok. > > I have debuged with care as you said and I'm sure that > "simclick_sim_schedule" is not called, > neither "RouterThread::wait()" who is in charge of > calling "simclick_sim_schedule". > > So if "simclick_sim_schedule" is not called there are no Events generated > (the timed ones I guess), > and ClickClassifier::handle ( Event * ) is not fired. > > I have dicovered that when the program is in ClickClassifier::command(), > and it enters in the case "loadclick" it goes to simclick_click_run. > "simclick_click_run" calls RouterThread::driver(). > Then in line 343 of routerthread.cc ( within RouterThread::driver() ) > you can see: > if (*runcount >0 ) { > // run ocassional tasks: timers, select, ect. > iter++; > if ( iter % DRIVER_ITER_ANY == 0 ) > wait(iter); > } > > So for calling wait(), *runcount must be > 0, but it is not. > In result wait() is not called. > I continued debuging in this way, and never, in the many > times that the program goes througth the line 343, > *runcount is > 0. > > So I guess that arround here is the problem. > What do you think? > > Can you suggest other debug steps to figure out the problem? > > Thank you. Antonio. > > ----- Original Message ----- > From: "Michael Neufeld" > To: "Antonio Gonz?lez Kirchenmayer" > Sent: Tuesday, May 18, 2004 1:49 AM > Subject: Re: [nsclick-users] Timer under nsclick : debuging > > > >>The classifier should be getting set for you when the node is created. >>As long as you've got a line like this: >> >>Simulator set node_factory_ Node/MobileNode/ClickNode >> >>things should be getting setup correctly. >> >>Have you tried stepping through the code which sets the timer, i.e. >>setting a breakpoint in your Click code and tracing through? I'm curious >>as to what code path it's taking -- simclick_sim_schedule really should >>be getting called at some point, and something is pretty broken if it >>isn't. You might want to rebuild Click without the -O2 flag if you >>haven't already -- debugging it is pretty annoying when optimizations >>are occuring. >> >>-Mike > > > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs-lists.cs.colorado.edu > http://cs-lists.cs.colorado.edu/mailman/listinfo/nsclick-users From Antonio.Gonzalez1 at pandora.be Wed May 19 14:40:40 2004 From: Antonio.Gonzalez1 at pandora.be (=?iso-8859-1?Q?Antonio_Gonz=E1lez_Kirchenmayer?=) Date: Wed May 19 14:41:02 2004 Subject: [nsclick-users] Timer under nsclick : debuging discovers References: <001201c437a0$e6b01150$772d5351@Antwerp> <40A154D3.6050902@cs.colorado.edu> <002801c43836$2642fbd0$772d5351@Antwerp> <40A245F1.7040502@cs.colorado.edu> <002e01c43c10$5eef9780$8ee4a551@Antwerp> <40A8C568.6040400@cs.colorado.edu> <000901c43c63$d76a3ff0$8ee4a551@Antwerp> <40A94F97.1030208@cs.colorado.edu> <001101c43ced$9b476680$8ee4a551@Antwerp> <40AA31D2.90401@cs.colorado.edu> Message-ID: <001501c43de1$8ffdd710$8ee4a551@Antwerp> Hi Eddie, That's working but you forgot to put one ifndef to avoid the goto: // run loop again, unless driver is stopped if (*runcount > 0) { #ifndef CLICK_NS // Everyone except the NS driver stays in driver() until the driver is // stopped. goto driver_loop; #endif } else { unlock_tasks(); bool b = _master->check_driver(); nice_lock_tasks(); #ifndef CLICK_NS <---------------------------------- if (b) goto driver_loop; <---------------------------------- #endif } Thank you very much, Michael, Eddie. As we say in spain "Os debo unas ca?as!!!". That means "I own you a couple of beers!!!" Antonio. ----- Original Message ----- From: "Eddie Kohler" To: "Michael Neufeld" Cc: "Antonio Gonz?lez Kirchenmayer" ; ; Sent: Wednesday, May 19, 2004 7:49 PM Subject: Re: [nsclick-users] Timer under nsclick : debuging discovers Michael: First, good luck on your deadline! Second, we should really check in a regression test of nsclick functionality into click/test/. Otherwise this sort of problem might happen again and again. Antonio: You're right, the fact that "*runcount" is 0 is a problem. The "runcount" value should be 1. And I think I know why, so I checked in a fix. Please update Click and let me know if anything has changed. Eddie On May 18, 2004, at 8:54 AM, Michael Neufeld wrote: > What I suspect is that there may be an issue with the Click timer > handling code and the nsclick patch. As I mentioned in an earlier > e-mail, sometimes updates to the internal Click scheduler require > changes to the nsclick configuration, and sometimes those don't always > get made right away. What it looks like offhand is that such a change > may have occured. Since I'm not working with the absolute latest CVS > vesion I haven't had a chance to verify this. There should be code in > RouterThread::wait which makes a call to simclick_sim_schedule for the > next timer set to expire. Further debugging is going to likely require > some work in the Click scheduler and its timer code. I've got a couple > of deadlines looming, so can't spend a whole lot of time on things > this week, but may have some time to look at it in more detail at some > point next week. In the meantime I'll provide what help I can if > you're going to continue working through the problem. What I would > probably do next is to look in router.cc and routerthread.cc and see > how timers get setup and executed by the non-nsclick Click > configuration. That may provide some insight as to why the nsclick > timers aren't working for you right now. > > -Mike > > Antonio Gonz?lez Kirchenmayer wrote: >> Yes I have got the line: >> Simulator set node_factory_ Node/MobileNode/ClickNode >> So it is ok. >> I have debuged with care as you said and I'm sure that >> "simclick_sim_schedule" is not called, >> neither "RouterThread::wait()" who is in charge of >> calling "simclick_sim_schedule". >> So if "simclick_sim_schedule" is not called there are no Events >> generated >> (the timed ones I guess), >> and ClickClassifier::handle ( Event * ) is not fired. >> I have dicovered that when the program is in >> ClickClassifier::command(), >> and it enters in the case "loadclick" it goes to simclick_click_run. >> "simclick_click_run" calls RouterThread::driver(). >> Then in line 343 of routerthread.cc ( within RouterThread::driver() ) >> you can see: >> if (*runcount >0 ) { >> // run ocassional tasks: timers, select, ect. >> iter++; >> if ( iter % DRIVER_ITER_ANY == 0 ) >> wait(iter); >> } >> So for calling wait(), *runcount must be > 0, but it is not. >> In result wait() is not called. >> I continued debuging in this way, and never, in the many >> times that the program goes througth the line 343, >> *runcount is > 0. >> So I guess that arround here is the problem. >> What do you think? >> Can you suggest other debug steps to figure out the problem? >> Thank you. Antonio. >> ----- Original Message ----- From: "Michael Neufeld" >> >> To: "Antonio Gonz?lez Kirchenmayer" >> Sent: Tuesday, May 18, 2004 1:49 AM >> Subject: Re: [nsclick-users] Timer under nsclick : debuging >>> The classifier should be getting set for you when the node is >>> created. >>> As long as you've got a line like this: >>> >>> Simulator set node_factory_ Node/MobileNode/ClickNode >>> >>> things should be getting setup correctly. >>> >>> Have you tried stepping through the code which sets the timer, i.e. >>> setting a breakpoint in your Click code and tracing through? I'm >>> curious >>> as to what code path it's taking -- simclick_sim_schedule really >>> should >>> be getting called at some point, and something is pretty broken if it >>> isn't. You might want to rebuild Click without the -O2 flag if you >>> haven't already -- debugging it is pretty annoying when optimizations >>> are occuring. >>> >>> -Mike >> _______________________________________________ >> nsclick-users mailing list >> nsclick-users@cs-lists.cs.colorado.edu >> http://cs-lists.cs.colorado.edu/mailman/listinfo/nsclick-users > _______________________________________________ > nsclick-users mailing list > nsclick-users@cs-lists.cs.colorado.edu > http://cs-lists.cs.colorado.edu/mailman/listinfo/nsclick-users