Hey there, Thanks for all the help. I've put several lines of debug into this function, and can now confirm it's being called, and that argc does indeed == 3.
However, crucially (strcmp(argv[1], "newtrace") never evaluates to 0, and therefore the newtrace_ variable is never set. Do you (or anyone else in the list) with better ns knowledge than me know who calls CMUTrace::command ? Is it likely to be the ClickNode code? Thanks again for all the help here, Best Regards, Dave -----Original Message----- From: ?e Olbert [mailto:[EMAIL PROTECTED] Sent: 26 February 2007 10:05 To: David Bath Subject: Re: [ns] new wireless trace format Hi! its set here in cmu-trace.cc: CMUTrace::command(int argc, const char*const* argv) { if(argc == 3) { if(strcmp(argv[1], "node") == 0) { node_ = (MobileNode*) TclObject::lookup(argv[2]); if(node_ == 0) return TCL_ERROR; return TCL_OK; } if (strcmp(argv[1], "newtrace") == 0) { newtrace_ = atoi(argv[2]); return TCL_OK; } } return Trace::command(argc, argv); } this is the method to handle tcl commands sent to cmu-trace.cc. in your tcl script: $ns_ use-newtrace So this means that the ns_ (simulator object) is the one that probably calls cmu-trace.cc, this call is made from tcl code. You could add a print statement to cmu-trace.cc when newtrace is set to see if it it becomes set =) Then either go after the tcl code or dig deeper in cmu-trace.cc Good luck! > > Thanks once again for the reply. . . > > Had a read through cmu-trace.cc, and I'm not 100% convinced I can tell > where newtrace_ is being set. > > I may be wrong, but the fact that I /am/ getting node tracing for the > lower layers (MAC, AGT etc) when using nsclick (for info: when using > nsclick, the routing part is handed off to click, so I would not expect > to see any RTR or IFQ log entries) indicates that CMUTrace is being > executed. The only other possibility is that the clicknode has > implemented tracing all on its own, which seems quite unlikely. > > Which component is responsible for setting the newtrace_ variable? Is > it possible that clicknodes are somehow mangling it? > > Cheers, > > Dave > > -----Original Message----- > From: ?e Olbert [mailto:[EMAIL PROTECTED] > Sent: 26 February 2007 09:05 > To: David Bath > Subject: RE: [ns] new wireless trace format > > Hi! > > I have no idea about click as such, just thought this was an interesting > problem. > > cmu-trace.cc prints in new-format if the packet type is not tagged: > > // use tagged format if appropriate > if (pt_->tagged()) { > > <code> > > return; > } > if (newtrace_) { > > <code> > > Since you say you set newtrace I guess it means that it never gets to > the > if (newtrace_) statement. > > On a side note: There is no mention about click in the traceformats > available here.. > http://nsnam.isi.edu/nsnam/index.php/NS-2_Trace_Formats#New_Wireless_Tra > ce_Formats > > It looks like you have to implement it yourself =P > > Regards > >> Hey there, >> >> Thanks for reply. >> >> This is the same sort of conclusion I came to - but I'm not quite sure >> how to check that, and whether it falls into the Click or ns domain... >> I've cross-posted to the Click list, so they might have some >> suggestions. >> >> I don't understand well enough the tracing architecture - the > ClickNode >> types can clearly print something, as I can happily get old trace > format >> output. Any pointers on what I can check in cmu-trace.cc (or anywhere >> else) to verify if there's code to handle newtrace format? >> >> Curiously, I don't seem to be able to get location data in old trace >> format, (but works fine if I don't use ClickNodes) so I wonder if >> perhaps this is a clue to where the problem is? >> >> Thanks for continuing help. >> >> Dave >> >> > > >
